> 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. -Joe _______________________________________________ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev
