[swift-dev] Statically-emitted or statically-allocated objects with new refcounting

[John McCall]

> On Mar 16, 2017, at 4:23 PM, Joe Groff <jgroff at apple.com> wrote:
>> On Mar 14, 2017, at 3:53 PM, Greg Parker via swift-dev <swift-dev at swift.org> wrote:
>> 
>>> 
>>> On Mar 14, 2017, at 2:16 PM, John McCall <rjmccall at apple.com> wrote:
>>> 
>>>> On Mar 14, 2017, at 5:08 PM, Jordan Rose via swift-dev <swift-dev at swift.org> wrote:
>>>> 
>>>>> On Mar 14, 2017, at 13:52, Greg Parker via swift-dev <swift-dev at swift.org> wrote:
>>>>> 
>>>>>> On Mar 14, 2017, at 1:34 PM, Greg Parker via swift-dev <swift-dev at swift.org> wrote:
>>>>>> 
>>>>>>> On Mar 14, 2017, at 12:43 PM, Joe Groff <jgroff at 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.