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