logical const idea - scratchspace

Steven Schveighoffer schveiguy at yahoo.com
Mon May 14 12:51:09 PDT 2012


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


More information about the Digitalmars-d mailing list