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