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

Joe Groff jgroff at apple.com
Thu Mar 16 15:23:27 CDT 2017


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

-Joe


More information about the swift-dev mailing list