> 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
>> <mailto:swift-dev@swift.org>> wrote:
>>
>>
>>> On Mar 14, 2017, at 1:34 PM, Greg Parker via swift-dev <swift-dev@swift.org
>>> <mailto:swift-dev@swift.org>> wrote:
>>>
>>>
>>>> On Mar 14, 2017, at 12:43 PM, Joe Groff <jgr...@apple.com
>>>> <mailto: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.
John.
_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev
