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

[Greg Parker]

> On Mar 17, 2017, at 4:07 PM, Joe Groff <jgroff at apple.com> wrote:
> 
>> On Mar 17, 2017, at 4:04 PM, Greg Parker <gparker at apple.com <mailto:gparker at apple.com>> wrote:
>> 
>>> On Mar 17, 2017, at 8:19 AM, Joe Groff <jgroff at apple.com <mailto:jgroff at apple.com>> wrote:
>>> 
>>> 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.)

The stable ABI will have affordances for statically-emitted objects. For now you can use the machinery in GlobalObjects.cpp. When the stable ABI progresses we'll find all uses of that code and update them.

One likely possibility is that we emit some bit pattern directly, but also emit enough metadata so that the runtime could find all such objects at launch time. (For example on Mach-O the objects could all be emitted into the same section.) That way we get high performance now but preserve the ability to rewrite the objects in the future, on the assumption that such ABI evolution will be rare. The Objective-C runtime uses this technique in several places.


-- 
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/20170317/0d335916/attachment.html>