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