[MLton-devel] new GC object layout

[Matthew Fluet]

> > Also, we might have the opportunity to treat stack-frames more like
> > regular objects.  
> 
> 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.

The benefit would be more uniform treatment in the runtime system.
Tracing and updating a stack would just be repeated invocations of trace
and update object, rather than unique code.  But, the cost might be high.

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

Oh.  I get it now.

enum {NORMAL, STACK, ARRAY};

Then some entries in the object type might be

{NORMAL, 7, 3} /* object is 7 words, with 3 non-pointers */
{NORMAL, 7, 4, {0, 4, 8, 16}} /* alternatively, object is 7 words,
                                 with 4 pointers at offsets
                                 0, 4, 8, and 16. */
{STACK} /* no additional info needed */
{ARRAY, 34} /* elements have objectType[34] */

where if I had a real type system, I would write
  datatype objType = Normal of int * int
                (* | Normal of int * int list *)
                   | Stack
                   | Array of int

That makes sense.


_______________________________________________________________

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