[MLton] Ongoing parallel runtime work

[Vesa Karvonen]

On Jan 20, 2008 4:57 AM, Eric McCorkle <ericmcc at cs.brown.edu> wrote:
[...]
> In the beginning, I was planning not to do generational collection at this
> time, but I've built things to make it easy to add.  I'm reconsidering this,
> as supporting generational collection would make some aspects of calculating
> the root set alot easier (the global pointers and the currently-existing
> threads can be treated as externally-stored objects and described using type
> signatures).  However, the price is that *all* pointers must be represented
> with double-pointers, not just global pointers.  Does anyone have practical
> experience/observations which can inform this decision?

I would assume that with 64-bit machines having multiple GBs of memory
becoming the norm, memory usage will become less of an issue.  So, if
having double pointers would likely improve scalability, I would
probably experiment with it at least.

I don't know how the double pointers would actually be used and
whether a single object may be accessed in parallel by multiple cores
(you mention having the collector "claim" objects), but you mention
that one of them is used by the collector and the other by the mutator
(program's thread).  One thought that comes to mind here is that it
might make sense to layout objects in such a way that all the pointers
used by the collector are stored as a contiguous block (within an
object) and likewise for the pointers used by the mutator.  The point
is that when the mutator (or the collector) fetches a pointer, the CPU
will likely fetch other pointers used soon by the mutator (or the
collector).  Also, when pointers are mutated by the collector, it
would likely reduce contention between caches.  Actually, I would
assume that you've probably thought about issues like this already.

At any rate, I'm very interested in seeing parallel stuff in MLton.

-Vesa Karvonen