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@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@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution