logical const idea - scratchspace

[Dmitry Olshansky]

On 14.05.2012 23: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)
>

Hack of the year?
It looks somewhat backwards but I like it. Especially the "no changes in 
the compiler/language".

> 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).

I take it that you just love reusing slack space found after the sloppy 
D runtime in some beneficial nontrivial way! :)

>
> 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


-- 
Dmitry Olshansky