[MLton-devel] new GC object layout

Stephen Weeks MLton@mlton.org
Wed, 8 May 2002 15:08:58 -0700


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

Agreed.

> 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 don't see any real benefit from doing this, and there is a cost in
an extra word per frame and the pressure for 2^19 header words.

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

I hadn't planned on using any particular index values (or bits).  I
was planning on using an enum in the constant array of object types. 

_______________________________________________________________

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