[swift-evolution] stored properties in extensions

[Jay Abbott]

Interestingly, if all the stored properties defined in extensions could be
determined at link-time, the size/layout of the side-table could include
them directly, removing the need for further indirection. The offsets would
still need to be fixed up, which would add some complexity to the
implementation.

On Wed, 12 Oct 2016 at 00:54 Jay Abbott <jay at abbott.me.uk> wrote:

> Wow, that's a very interesting post. Sounds a lot simpler to implement
> than my idea about fixing up offsets in the linker and preserves binary
> compatability just the same.
>
> I got some complaints when I first started talking about this that the
> runtime would have to track extra pointers and performance would be
> affected because of additional levels of indirection, which I didn't fully
> understand because it seems fairly trivial to me. Perhaps this twin-purpose
> refcount/side-table pointer also suffers the same concerns?
>
> On Wed, 12 Oct 2016 at 00:21 Ole Begemann via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>  > I think the language devs must have some idea how this will work, but
>
>  > don't seem to want to share/discuss it at the moment. I was hoping for
>
>  > some feedback about my implementation ideas - whether they are along the
>
>  > right lines, or way off, or not necessary (because the implementation
>
>  > strategy is already known). Perhaps this the wrong list for that kind of
>
>  > discussion?
>
>
>
> 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.
>
>
>
> Ole
>
> _______________________________________________
>
> swift-evolution mailing list
>
> swift-evolution at swift.org
>
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161012/99e7ca7c/attachment.html>