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 <[email protected]> wrote: > > >> On Oct 11, 2016, at 3:02 PM, Jay Abbott via swift-evolution >> <[email protected]> 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 [email protected] Runtime Wrangler > >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
