> On Mar 17, 2017, at 4:04 PM, Greg Parker <gpar...@apple.com> wrote:
>
>>
>> On Mar 17, 2017, at 8:19 AM, Joe Groff <jgr...@apple.com
>> <mailto:jgr...@apple.com>> wrote:
>>
>>
>>> On Mar 16, 2017, at 9:02 PM, Greg Parker <gpar...@apple.com
>>> <mailto:gpar...@apple.com>> wrote:
>>>
>>>>
>>>> On Mar 16, 2017, at 7:35 PM, John McCall <rjmcc...@apple.com
>>>> <mailto:rjmcc...@apple.com>> wrote:
>>>>
>>>>> On Mar 16, 2017, at 4:23 PM, Joe Groff <jgr...@apple.com
>>>>> <mailto:jgr...@apple.com>> wrote:
>>>>>
>>>>>> On Mar 14, 2017, at 3:53 PM, Greg Parker via swift-dev
>>>>>> <swift-dev@swift.org <mailto:swift-dev@swift.org>> wrote:
>>>>>>
>>>>>>> On Mar 14, 2017, at 2:16 PM, John McCall <rjmcc...@apple.com
>>>>>>> <mailto:rjmcc...@apple.com>> wrote:
>>>>>>>
>>>>>>>> On Mar 14, 2017, at 5:08 PM, Jordan Rose via swift-dev
>>>>>>>> <swift-dev@swift.org <mailto: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.
>>>>>>
>>>>>> 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.
>>>
>>> Oops, dropped my reply somewhere. Yes, that's correct. The only barriers
>>> are the store-release in swift_release and the matching acquire before
>>> deinit. Truly inert objects would perform neither of those. They would
>>> perform the load and then shortcut out at the "this object is unusual" bit
>>> test before the incremented store.
>>>
>>> You can initialize your objects with a refcount field of `uintptr_t(1)` for
>>> now. That's the same value used for newly-allocated objects. Note that the
>>> `1` is not the strong retain count.
>>>
>>> Is this going in the compiler's codegen somewhere? We should have a test
>>> and a big comment in RefCount.h for the dependency, assuming it can't be
>>> easily handled automatically at build time, because these values will
>>> certainly change in the future.
>>
>> It might at some point, but I was thinking of using this in the runtime for
>> now. We already have a few statically-emitted objects for the empty
>> containers that could benefit from this, but they could presumably use API
>> from RefCount.h to grab a constexpr bit pattern with which to initialize
>> themselves.
>
> Good: we already support that usage. Struct HeapObject has a constexpr
> initializer that sets the refcounts to that value. See
> stdlib/public/stubs/GlobalObjects.cpp for some similar uses.
>
> (But wait, objects for empty containers are already in GlobalObjects.cpp. Are
> you adding more such objects?)
I was considering it as a possibility for statically emitting literal key path
objects as part of Foundation's recent language proposal
(https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170313/033998.html
<https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170313/033998.html>).
Even for this case, I don't think I'd have the compiler statically emit the
bit pattern, but have accesses to the object go through a runtime call that
lazily reifies it. (That way, if we change the object format, we can also still
reallocate the older compiler-emitted format.)
-Joe
_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev
