> 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. -- 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
