[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