Karl, interesting point... perhaps a similar scheme could work for value types (using the COW refcount)?
On Thu, 13 Oct 2016 at 16:02 Karl Wagner <[email protected]> wrote: > 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
