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

[Greg Parker]

> 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 <mailto:swift-dev at swift.org>> wrote:
>> 
>>> On Mar 14, 2017, at 13:52, Greg Parker via swift-dev <swift-dev at swift.org <mailto:swift-dev at swift.org>> wrote:
>>> 
>>>> On Mar 14, 2017, at 1:34 PM, Greg Parker via swift-dev <swift-dev at swift.org <mailto:swift-dev at swift.org>> wrote:
>>>> 
>>>>> On Mar 14, 2017, at 12:43 PM, Joe Groff <jgroff at apple.com <mailto: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.


-- 
Greg Parker     gparker at apple.com <mailto:gparker at apple.com>     Runtime Wrangler


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-dev/attachments/20170314/0d3f8fd2/attachment.html>