[swift-evolution] stored properties in extensions (was: associated objects)

[Karl Wagner]

That's great! I suppose the idea of allocating a bit of extra storage for similar data in value types is some sort of heresy?

Would there be a conceptual reason for that; which explains why it's okay for reference-types but not for values? Personally I feel like it's a kind of C legacy, due to performance and layout expectations that C sets about value-types ¯\_(ツ)_/¯

Karl


Sent from my iPad

> On 12 Oct 2016, at 07:54, Greg Parker <gparker at apple.com> wrote:
> 
> 
>> On Oct 11, 2016, at 3:02 PM, Jay Abbott via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> Implementation idea No. 4:
>> 
>> The basic concept is that the dynamic linker would fixup the offsets as well as relocating the addersses, allowing the size of objects (and maybe structs?) to change at link-time. The process might be something like this:
>> 
>> * References to members defined in extensions would compile to have an offset symbol instead of a value - so they can be fixed up later
>> * The linker would scan all the shared objects that are referenced (and thus might get linked)
>> * Build up a list of Stored Properties In ExtensionS (SPIES, muhahaha) for each class.
>> * Append the extra fields (increase the size the class), decide where each member goes in the extended layout and fixup the offsets
>> * Carry on with normal relocation
>> 
>> There are quite a few assumptions in the above, and probably quite a few misunderstandings about how things work on my part too (I'm not an expert at this), however I think it should work in principle. Some questions about my assumptions: Can linker know in advance all the potential modules that could be linked, or is this done more lazily and it only knows about what it's linking right now? Is it ok for the size to change - I don't know if it's a static sizeof() or if it could be (or already is) stored in the isa?
> 
> This sort of scheme isn't dynamic enough. The worst-case is a extension in a library that gets dlopen()ed at runtime on a class that is already loaded. The build-time linker can't know anything about it. The loader and the runtime will see it, but at that point the class may already be in use and may already have instances allocated. If you want to handle the dlopen() case then you need some way to add storage to arbitrary objects that have already been allocated.
> 
> 
>> Ole Begemann wrote:
>> 
>> For what it's worth, Greg Parker (Cc'ed) started a discussion back in March that I think is relevant here: https://lists.swift.org/pipermail/swift-dev/Week-of-Mon-20160314/001424.html
>> 
>> Here's the relevant part:
>> 
>> "I am considering a new representation for Swift refcounts and other per-object data. This is an outline of the scheme. Comments and suggestions welcome.
>> 
>> Today, each object stores 64-bits of refcounts and flags after the isa field.
>> 
>> In this new system, each object would store a pointer-size field after the isa field. This field would have two cases: it could store refcounts and flags, or it could store a pointer to a side allocation that would store refcounts and flags and additional per-object data.
>> 
>> Advantages:
>> …
>> * Allows inexpensive per-object storage for future features like associated references or class extensions with instance variables.
>> …"
>> 
>> I don't know the current status of this idea (implemented? planned? abandoned?). Also, it's worth noting that this would only apply to classes, not value types.
> 
> I'm working on this right now: https://github.com/gparker42/swift/tree/new-refcount-representation
> 
> If it goes well it will provide the runtime implementation space needed for associated objects or stored properties in extensions. Such storage would be less efficient than "real" stored properties. Any object with that storage attached would also suffer additional performance penalties to refcounting and deallocation. On the plus side there is no memory penalty to objects that don't have additional storage, and there is no contention over a big global association table like there is in Objective-C's associated object implementation.
> 
> Note that the runtime implementation is not the only problem. The optimizer folks hate the fact that stored properties in extensions defeat the compiler's visibility into the deinit behavior of all types, even if most types are unaffected at runtime.
> 
> 
> -- 
> Greg Parker     gparker at apple.com     Runtime Wrangler
> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161013/fdd3c208/attachment-0001.html>