<div dir="ltr">Karl, interesting point... perhaps a similar scheme could work for value types (using the COW refcount)?<br></div><br><div class="gmail_quote"><div dir="ltr">On Thu, 13 Oct 2016 at 16:02 Karl Wagner &lt;<a href="mailto:razielim@gmail.com">razielim@gmail.com</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto" class="gmail_msg"><div class="gmail_msg"><div style="direction:inherit" class="gmail_msg">That&#39;s great! I suppose the idea of allocating a bit of extra storage for similar data in value types is some sort of heresy?</div><div style="direction:inherit" class="gmail_msg"><br class="gmail_msg"></div><div style="direction:inherit" class="gmail_msg">Would there be a conceptual reason for that; which explains why it&#39;s okay for reference-types but not for values? Personally I feel like it&#39;s a kind of C legacy, due to performance and layout expectations that C sets about value-types ¯\_(ツ)_/¯</div><div style="direction:inherit" class="gmail_msg"><br class="gmail_msg"></div><div style="direction:inherit" class="gmail_msg">Karl</div><div style="direction:inherit" class="gmail_msg"><br class="gmail_msg"></div><div style="direction:inherit" class="gmail_msg"><br class="gmail_msg"></div>Sent from my iPad</div></div><div dir="auto" class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg">On 12 Oct 2016, at 07:54, Greg Parker &lt;<a href="mailto:gparker@apple.com" class="gmail_msg" target="_blank">gparker@apple.com</a>&gt; wrote:<br class="gmail_msg"><br class="gmail_msg"></div><blockquote type="cite" class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg"><div class="gmail_msg"><blockquote type="cite" class="gmail_msg"><div class="gmail_msg">On Oct 11, 2016, at 3:02 PM, Jay Abbott via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>&gt; wrote:</div><br class="m_8205625084749916880Apple-interchange-newline gmail_msg"><div class="gmail_msg"><div dir="ltr" class="gmail_msg"><div class="gmail_msg">Implementation idea No. 4:</div></div></div></blockquote><blockquote type="cite" class="gmail_msg"><div class="gmail_msg"><div dir="ltr" class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg">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:<br class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">* References to members defined in extensions would compile to have an offset symbol instead of a value - so they can be fixed up later<br class="gmail_msg"></div><div class="gmail_msg">* The linker would scan all the shared objects that are referenced (and thus might get linked)<br class="gmail_msg">* Build up a list of Stored Properties In ExtensionS (SPIES, muhahaha) for each class.<br class="gmail_msg">* Append the extra fields (increase the size the class), decide where each member goes in the extended layout and fixup the offsets<br class="gmail_msg">* Carry on with normal relocation<br class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">There are quite a few assumptions in the above, and probably quite a few misunderstandings about how things work on my part too (I&#39;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&#39;s linking right now? Is it ok for the size to change - I don&#39;t know if it&#39;s a static sizeof() or if it could be (or already is) stored in the isa?<br class="gmail_msg"></div></div></div></blockquote><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">This sort of scheme isn&#39;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&#39;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.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg"></div><blockquote type="cite" class="gmail_msg"><div class="gmail_msg">Ole Begemann wrote:</div></blockquote><blockquote type="cite" class="gmail_msg"><br class="gmail_msg"></blockquote><blockquote type="cite" class="gmail_msg"><div class="gmail_msg">For what it&#39;s worth, Greg Parker (Cc&#39;ed) started a discussion back in March that I think is relevant here: <a href="https://lists.swift.org/pipermail/swift-dev/Week-" class="gmail_msg" target="_blank">https://lists.swift.org/pipermail/swift-dev/Week-</a>of-Mon-20160314/001424.html<br class="gmail_msg"><br class="gmail_msg">Here&#39;s the relevant part:<br class="gmail_msg"><br class="gmail_msg">&quot;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.<br class="gmail_msg"><br class="gmail_msg">Today, each object stores 64-bits of refcounts and flags after the isa field.<br class="gmail_msg"><br class="gmail_msg">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.<br class="gmail_msg"><br class="gmail_msg">Advantages:<br class="gmail_msg">…<br class="gmail_msg">* Allows inexpensive per-object storage for future features like associated references or class extensions with instance variables.<br class="gmail_msg">…&quot;<br class="gmail_msg"><br class="gmail_msg">I don&#39;t know the current status of this idea (implemented? planned? abandoned?). Also, it&#39;s worth noting that this would only apply to classes, not value types.<br class="gmail_msg"></div></blockquote><div class="gmail_msg"><br class="gmail_msg"></div></div><div class="gmail_msg">I&#39;m working on this right now: <a href="https://github.com/gparker42/swift/tree/new-refcount-representation" class="gmail_msg" target="_blank">https://github.com/gparker42/swift/tree/new-refcount-representation</a></div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">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 &quot;real&quot; 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&#39;t have additional storage, and there is no contention over a big global association table like there is in Objective-C&#39;s associated object implementation.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">Note that the runtime implementation is not the only problem. The optimizer folks hate the fact that stored properties in extensions defeat the compiler&#39;s visibility into the deinit behavior of all types, even if most types are unaffected at runtime.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">-- </div><div class="gmail_msg">Greg Parker     <a href="mailto:gparker@apple.com" class="gmail_msg" target="_blank">gparker@apple.com</a>     Runtime Wrangler</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg"><br class="gmail_msg"></div></div></blockquote></div></blockquote></div>