logical const idea - scratchspace

[Alex Rønne Petersen]

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