[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