[MLton] cvs commit: improved GC structure

Matthew Fluet fluet@cs.cornell.edu
Fri, 9 Apr 2004 08:44:45 -0400 (EDT)


> One thing that caught my eye while reading this commit is that the
> ensureBytesFree argument to GC_switchToThread is not used in the fast
> branch of GC_switchToThread.  Shouldn't we do
>
> 		s->currentThread->bytesNeeded = ensureBytesFree;
>
> there as well?

Absolutely.  That's a bug.

> >    - folded Thread_switchTo into GC_threadSwitchTo.
>
> I was wondering if we could eliminate Thread_switchTo entirely and
> change the calls to Thread_switchTo in ssa-to-rssa into calls to
> GC_switchToThread?

There are a few functions in /runtime/basis/Thread.c that do nothing but
dispatch to their corresponding GC_ functions.  Maybe they should all be
made into calls to GC_ functions.  And maybe more of them should be
prims, since they could easily be implemented in ssa-to-rssa.

> >    - I modified the stack shrinking policy:
> ...
> >       + for heap stacks, if stack->used <= stack->reserved / 4,
> >          then shrink to stack->reserved / 2,
> >          else if stack->used <= stack->reserved / 2,
> >          then shink to stack->used.
> >         This allows stacks to shrink down to the minimal size, if they
> >         live through multiple GCs.
>
> The idea makes sense, but I don't understand how the code does this.
> What if stack->used = 3/4 stack->reserved?  Don't we want to shrink
> that down to minimal size too?

I never meant to claim it was perfect; there are plenty of corner cases
that won't be cleaned up.

> Since major GCs are infrequent, why not instantly shrink all paused
> stacks to minimal size?  Or maybe shrink them by a factor of two each
> time, until they drop below mutatorStackInvariant, at which point drop
> them to minimal size?

Are you suggesting that we only shrink stacks in a majorGC?  Currently,
the shrinking occurs in either a minorGC or a copying majorGC.  (And I
presume that there would be a way of also shrinking in a markCompact
majorGC.)  Or, maybe you're just noting that most threads that we see will
be tenured, so they'll effectively only be seen during a majorGC.

I don't want to drop stacks to minimal size too quickly, because that will
end up essentially forcing a GC at every switch to a thread that lived
through a GC.

So, I like the suggestion of shrinking by a factor of two until they drop
below the mutatorStackInvariant and then drop them to minimal size.