On 14-05-2012 21:51, Steven Schveighoffer wrote:
I have an idea on how to create logical const without any language or compiler changes -- it will exist purely in druntime.The idea is based on this: Whenever you allocate an object, you use a memory block. An object, by default, has the following memory layout: monitor - (void *).sizeof bytes vtbl - (void *).sizeof bytes interface_vtbls[] - (void *)sizeof x number of interfaces. So by default, 8 bytes on 32bit, 16 bytes on 64 bit. Add any members, and they may increase the size. This object goes into the GC heap. Yet the GC heap has only 16, 32, 64, 128, etc. sized blocks. So for instance a class object that requires 24 bytes actually consumes 32. This leaves 8 bytes of "scratch space". Using a druntime lookup we can get access to that entire memory block, including the scratch space. And since we use druntime to look it up, *not* the object and its contained members (which remember don't include the scratch space), it is *not* typed as const or immutable, or whatever the class data is. In essence, a const(MyObj) is a pointer to a struct that looks like: struct FicticiousMyObjStruct { const(MyObj_data); // not a reference, the actual data ubyte[8] scratchspace; } So we need two pieces for this proposal: 1. An accessor in Object for this scratch space. This should be a) efficient, and b) opaque. 2. An allocator for a new object that can allocate a minimal scratch space. So for instance, if your object consumes 32 bytes, but you need 20 bytes of scratch space, you want the runtime to allocate a 64 byte block. So instead of saying new MyObject, you'd say newScratchSpace!MyObject(20) And I think that's it. Since nothing before this proposal ever referred to or used that scratch space, it's not in danger of breaking existing code. The only caveat is, it can't properly be typed as shared or not (it could be accessible from multiple threads, depending on if the actual type is immutable). It also should be recommended that the scratch space not contain any GC pointers, since it's *not* participating in the type system properly, the GC may not treat it as a pointer. And of course, we need a better name than newScratchSpace. -Steve
Another concern I have is that this couples a feature tightly to the implementation of the GC. What if another GC doesn't use the same allocation scheme?
-- - Alex
