[MLton-devel] pinned objects

[Stephen Weeks]

> I've been looking at your gc and thinking about how to incorporate
> pinned objects based on (my understanding of) the treadmill.  
...

Pretty much along the lines I was thinking of.

I'm not sure why we need pinned-normals.  Why not just pinned-arrays?

As to the header words, we are about to switch to a new scheme where
the header word contains an index into a constant array in which each
element describes an object type/layout.  So, there is no more need to
worry about stealing bits.

The other big question is where to get the space for the pinned
objects.  I am currently working on implementing pinned, large (>1M)
arrays, and for these the answer is easy -- do a separate mmap for
each large array.  Once I get this working, we can think about smaller
objects.

Also, I'm thinking of just using a singly linked list for now.  Then,
allocation of a pinned large array (PLA) mmaps and links to the front
of the list.  GC marks PLAs in this list when it visits them, and at
the end of the collection, walks through the list and munmaps any
unmarked PLAs.

> When GC encounters a pinned-object, it must determine whether the
> object is on the from-pinned-chain or the to-pinned-chain.  This
> cannot be indicated by overwriting the object's header with
> FORWARDED as is currently done for non-pinned objects.  The only
> solution I see right now is to reserve yet another a bit somewhere
> in the pinned-object header to indicate which semi-space it is in

As to marking PLAs, yeah it needs another bit, but I don't mind adding
a whole new word (or even page) since the object is >1M.

> When GC encounters a pinned-object on the to-pinned-chain, do
> nothing.  When GC encounters a pinned-object on the from-pinned-chain,
> unlink it and relink it into the to-pinned-chain, and traverse the
> object for more pointers.

It's a bit trickier, since the GC needs to maintain two to-space sets,
the usual queue in to-space for objects that have been copied but
whose pointers have not yet been forwarded, as well as a queue/stack
of pinned objects that have been marked as in to-space but have not
yet been traversed.  I'll probably just keep a linked list as a
stack.

> This all seems pretty easy, except for the issue of choosing
> bits/representation for pinned-objects.  Am I right in thinking that
> stack objects would never be pinned?

Yes.  I don't see any point in it.

> By putting the chain pointers before the header (+ length in case of
> an array), all existing code that manipulates objects will not have
> to change (eg. GC_size).  Is there any other existing code that
> would have to be aware of pinned-objects?

Yes.  The load/save world code will need to be modified too.

> Now that I'm finally looking at mmap (2), it adds some twists.  A
> mlton version of it would essentially behave like another kind of
> object allocation routine, returning you a pinned-object that mirrors
> changes to the underlying file.  For now, let's assume one mlton
> pinned-object per file.  For arrays, the file should include the
> array's size word so that you can read it, and in general the file
> probably also should include the object header word.

I don't see why.  I would think that the file would not include any of
the mlton-specific stuff, and would just consist of the data, which is
the byte/word array elements.  The header and length would be prefixed
in the previous page.

> Since mmap works on page boundaries, one might try to arrange things
> such that a page boundary falls between between the chain pointers and
> the rest of the object, and the page holding the chain pointers is
> allocated by regular OS allocation.  This would require the runtime to
> guarantee to let you allocate a normal page of data at the one page
> before the mapped data, but I'm hesitant about expecting this,
> especially from windoze.  You'd also be wasting the rest of the
> page.

I'm thinking this is only for large objects, so we just mmap the space
we need, plus one extra page for the array header and length, and any
chain pointers.  Do you really have cases in mind where the one extra
page hurts?

_______________________________________________________________

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