[MLton-devel] new GC object layout

[Stephen Weeks]

> Note, the above only works for arrays whose elements are either pointers
> or non-pointers.  If we have flattened arrays of 2-tuples, with each tuple
> element being a pointer, then we have 2^32 positions.  But, then we can
> use the count in the header.
> 
> Actually, maybe Steve has this in mind.  An array's header's index would
> indicate the shape of the array elements (right now, either 1 non-pointer
> or 1 pointer).  Then the count word would indicate the array element and
> the count in the header would indicate the position in the element.

Exactly.

> > 2. What is the rationale for the header word to follow the length?  Where
> > in the array do array references actually point?
> 
> Pointers (in objects pointing to other objects) always point to
> the first word of the actual object.  For arrays, this corresponds to the
> element at index 0.  Then, the header is always one word behind where the
> pointer points.  Furthermore, if the header turns out to tell us that the
> object is actually an array, we know the length is yet one more word
> behind.

And the reason for this decision is that finding a header given a
pointer is the most common operation in the GC, and so should be the
fastest.

> 3. Do you store the number of non-pointers in the constant array table entry?
> I wasn't sure from your description where this info. was kept.

Yes.  The constant array holds what is currently stored in header
words.

> 5. I had a similar question to Matthew, namely does this new scheme
> allow mixing pointers and non-pointers for normal objects, and does
> such functionality buy anything.

Yes it does, and as Matthew says may buy better cache behavior if we
can figure out how to layout objects.  But for the first cut I'm going
to stick with the current layout that groups all pointers together.


_______________________________________________________________

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