<div dir="ltr"><div dir="ltr" class="gmail_msg">Wow, that&#39;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.<br><br>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&#39;t fully understand because it seems fairly trivial to me. Perhaps this twin-purpose refcount/side-table pointer also suffers the same concerns?<br class="gmail_msg"></div><br class="gmail_msg"><div class="gmail_quote gmail_msg"><div dir="ltr" class="gmail_msg">On Wed, 12 Oct 2016 at 00:21 Ole Begemann via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>&gt; wrote:<br class="gmail_msg"></div><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> &gt; I think the language devs must have some idea how this will work, but<br class="gmail_msg"><br> &gt; don&#39;t seem to want to share/discuss it at the moment. I was hoping for<br class="gmail_msg"><br> &gt; some feedback about my implementation ideas - whether they are along the<br class="gmail_msg"><br> &gt; right lines, or way off, or not necessary (because the implementation<br class="gmail_msg"><br> &gt; strategy is already known). Perhaps this the wrong list for that kind of<br class="gmail_msg"><br> &gt; discussion?<br class="gmail_msg"><br><br class="gmail_msg"><br>For what it&#39;s worth, Greg Parker (Cc&#39;ed) started a discussion back in<br class="gmail_msg"><br>March that I think is relevant here:<br class="gmail_msg"><br><a href="https://lists.swift.org/pipermail/swift-dev/Week-of-Mon-20160314/001424.html" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.swift.org/pipermail/swift-dev/Week-of-Mon-20160314/001424.html</a><br class="gmail_msg"><br><br class="gmail_msg"><br>Here&#39;s the relevant part:<br class="gmail_msg"><br><br class="gmail_msg"><br>&quot;I am considering a new representation for Swift refcounts and other<br class="gmail_msg"><br>per-object data. This is an outline of the scheme. Comments and<br class="gmail_msg"><br>suggestions welcome.<br class="gmail_msg"><br><br class="gmail_msg"><br>Today, each object stores 64-bits of refcounts and flags after the isa<br class="gmail_msg"><br>field.<br class="gmail_msg"><br><br class="gmail_msg"><br>In this new system, each object would store a pointer-size field after<br class="gmail_msg"><br>the isa field. This field would have two cases: it could store refcounts<br class="gmail_msg"><br>and flags, or it could store a pointer to a side allocation that would<br class="gmail_msg"><br>store refcounts and flags and additional per-object data.<br class="gmail_msg"><br><br class="gmail_msg"><br>Advantages:<br class="gmail_msg"><br>…<br class="gmail_msg"><br>* Allows inexpensive per-object storage for future features like<br class="gmail_msg"><br>associated references or class extensions with instance variables.<br class="gmail_msg"><br>…&quot;<br class="gmail_msg"><br><br class="gmail_msg"><br>I don&#39;t know the current status of this idea (implemented? planned?<br class="gmail_msg"><br>abandoned?). Also, it&#39;s worth noting that this would only apply to<br class="gmail_msg"><br>classes, not value types.<br class="gmail_msg"><br><br class="gmail_msg"><br>Ole<br class="gmail_msg"><br>_______________________________________________<br class="gmail_msg"><br>swift-evolution mailing list<br class="gmail_msg"><br><a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a><br class="gmail_msg"><br><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="gmail_msg"><br></blockquote></div></div>