[swift-dev] statically initialized arrays
Greg Parker
gparker at apple.com
Thu Jun 15 22:04:41 CDT 2017
> On Jun 15, 2017, at 9:24 AM, John McCall via swift-dev <swift-dev at swift.org> wrote:
>
>> On Jun 15, 2017, at 10:52 AM, Arnold via swift-dev <swift-dev at swift.org> wrote:
>>
>>> On Jun 14, 2017, at 2:56 PM, Dave Abrahams via swift-dev <swift-dev at swift.org> wrote:
>>>
>>>> on Wed Jun 14 2017, Erik Eckstein <swift-dev-AT-swift.org> wrote:
>>>>
>>>> I’m about implementing statically initialized arrays. It’s about
>>>> allocating storage for arrays in the data section rather than on the
>>>> heap.
>>>
>>> W00t! I'd like to do the same for String, i.e. encode the entire buffer
>>> in the data section. I was looking for Array example code to follow but
>>> couldn't find it.
>>
>> We have support for constant string buffers as of PR 8701 and PR 8692. The former PR shows the protocol that has to be implemented.
>>
>> (The implementation currently exposes the ref count ABI. This can/needs to be fixed when we move to a stable abi by running an once initializer)
>
> It would be reasonable to arrange for a specific bit pattern to be a guaranteed "do not reference-count this" pattern even under a stable ABI. We just have to be careful about picking it.
>
> If we didn't want to do that, the best solution would be an absolute symbol — although we'd have to use an entire word for the refcount, even on 64-bit.
I don't think the absolute symbol size is a problem. We are unlikely to ever make that part of the object header less than a full word. The refcount itself can be a subset of that word, as long as the number of different initial values for the entire word is reasonably small.
There are some other possible tricks. One is to hardcode the initial value and emit all such constant objects into a dedicated section. Then any future runtime that wants to use a new ABI can find all of the old objects and update them when they are loaded. A dedicated section would also help tools like the linker and shared cache to find these objects for optimization purposes. (That's probably less important for arrays than it is for strings. Note that C strings have their own section for just this reason.) And if these objects are read-only when the ABI is unchanged then the section helps keep the clean objects away from dirty pages.
--
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/20170615/4a2115f2/attachment.html>
More information about the swift-dev
mailing list