> On Mar 17, 2017, at 8:19 AM, Joe Groff <jgr...@apple.com> wrote: > > >> On Mar 16, 2017, at 9:02 PM, Greg Parker <gpar...@apple.com> wrote: >> >>> >>> On Mar 16, 2017, at 7:35 PM, John McCall <rjmcc...@apple.com> wrote: >>> >>>> On Mar 16, 2017, at 4:23 PM, Joe Groff <jgr...@apple.com> wrote: >>>> >>>>> On Mar 14, 2017, at 3:53 PM, Greg Parker via swift-dev >>>>> <swift-dev@swift.org> wrote: >>>>> >>>>>> On Mar 14, 2017, at 2:16 PM, John McCall <rjmcc...@apple.com> wrote: >>>>>> >>>>>>> On Mar 14, 2017, at 5:08 PM, Jordan Rose via swift-dev >>>>>>> <swift-dev@swift.org> wrote: >>>>>>> >>>>>>>> On Mar 14, 2017, at 13:52, Greg Parker via swift-dev >>>>>>>> <swift-dev@swift.org> wrote: >>>>>>>> >>>>>>>>> On Mar 14, 2017, at 1:34 PM, Greg Parker via swift-dev >>>>>>>>> <swift-dev@swift.org> wrote: >>>>>>>>> >>>>>>>>>> On Mar 14, 2017, at 12:43 PM, Joe Groff <jgr...@apple.com> wrote: >>>>>>>>>> >>>>>>>>>> Hey Greg, what are the correct refcounting bits now to set in a >>>>>>>>>> global statically-emitted heap object that shouldn't ever be >>>>>>>>>> released? >>>>>>>>> >>>>>>>>> For now use the same thing that stack-allocated objects use. I forget >>>>>>>>> what the bit pattern is exactly. (I assume you are not in strictly >>>>>>>>> read-only memory and can tolerate writes to the refcount word. We >>>>>>>>> don't yet have an implementation for immortal read-only objects.) >>>>>>>> >>>>>>>> Oh wait, you *don't* want to use what stack-allocated objects use. >>>>>>>> They get deinited without being deallocated, and I assume you want >>>>>>>> neither deinit nor dealloc. Let me work this out. >>>>>>> >>>>>>> Wouldn’t it be okay to just emit it with an unbalanced retain? >>>>>> >>>>>> It's better if there's some way to make an object completely ref-count >>>>>> inert. Often, the compiler only sees one side of a retain/release pair, >>>>>> like when you return a constant NSString — you know locally that you're >>>>>> retaining a constant string, but you're returning it to some context >>>>>> that has no idea what it's getting. If the object is just >>>>>> unbalanced-retained, you have to preserve the retain or else the caller >>>>>> might release it. (That's true even if the imbalance is quite large — >>>>>> no fair crashing the program but only after a function's been called >>>>>> 2^19 times! Imagine reproducing that...) Making the object completely >>>>>> inert means you can just unconditionally say "hey, I know R/R are no-ops >>>>>> on this value" and delete them as a peephole. >>>>> >>>>> That's right. Unbalanced retain is the solution today. I expect a truly >>>>> inert solution soon. >>>> >>>> Cool. Do you think we'd be able to avoid atomic barriers on inert objects, >>>> or would that unfairly impact freeable objects? >>> >>> Greg is the right person to answer this for certain, but retain and release >>> use a load + exchange pattern, and inertness will presumably be testable >>> based purely on the initial load. >> >> Oops, dropped my reply somewhere. Yes, that's correct. The only barriers are >> the store-release in swift_release and the matching acquire before deinit. >> Truly inert objects would perform neither of those. They would perform the >> load and then shortcut out at the "this object is unusual" bit test before >> the incremented store. >> >> You can initialize your objects with a refcount field of `uintptr_t(1)` for >> now. That's the same value used for newly-allocated objects. Note that the >> `1` is not the strong retain count. >> >> Is this going in the compiler's codegen somewhere? We should have a test and >> a big comment in RefCount.h for the dependency, assuming it can't be easily >> handled automatically at build time, because these values will certainly >> change in the future. > > It might at some point, but I was thinking of using this in the runtime for > now. We already have a few statically-emitted objects for the empty > containers that could benefit from this, but they could presumably use API > from RefCount.h to grab a constexpr bit pattern with which to initialize > themselves.
Good: we already support that usage. Struct HeapObject has a constexpr initializer that sets the refcounts to that value. See stdlib/public/stubs/GlobalObjects.cpp for some similar uses. (But wait, objects for empty containers are already in GlobalObjects.cpp. Are you adding more such objects?) -- Greg Parker gpar...@apple.com <mailto:gpar...@apple.com> Runtime Wrangler
_______________________________________________ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev
