[MLton-devel] new GC object layout

[Matthew Fluet]

>   1. determine from the header word the object type (array,
>      normal, or stack) and the locations of pointers within the object
> * Normal objects have a header word, followed by all of the nonpointer
>   data, followed by all of the pointers.
> (1) is done via a constant array with one entry for each object layout
> in the program, with elements indexed by the 19 index bits in header
> words.

It seems as though you could relax the layout of normal objects with this
set-up, so that you could have an arbitrary mix of pointers and
non-pointers.  This complicates the format of the constant array and makes
processing objects slightly more complicated.  But, we have the
freedom later on to make more complicated object representation
decisions (optimize an object's layout for cache locality).  Also, we
might have the opportunity to treat stack-frames more like regular
objects.  Set up a stack frame like
|header word|... stack slots ...|return address|
Then when pushing a return address on the top of the stack, we also fill
in an appropriate header word (we know this statically, because the
return address uniquely identifies the frame-layout). Then the GC can
trace stacks from the bottom-up as just sequences of objects (we'd need to
be able to get the frame size from the constant array of object layouts,
but that doesn't seem to hard; we'd also need to be able to recognize the
last frame (wait, we'll know if we've run through the whole stack by the
GC_stack used field)). I'm probably missing something that makes this
overly complicated.

This would blow up the number of object layouts, so the 2^19 might be more
of an issue.

I assume that certain index values are reserved for distinguishing between
normal objects, stack objects, and array objects.  So, probably 2^17
object layouts with two bits to make the normal-stack-array distinction.

Otherwise, it sounds reasonable.


_______________________________________________________________

Have big pipes? SourceForge.net is looking for download mirrors. We supply
the hardware. You get the recognition. Email Us: bandwidth@sourceforge.net
_______________________________________________
MLton-devel mailing list
MLton-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlton-devel