[MLton] Stack size?
Fri, 8 Jul 2005 08:59:05 -0400 (EDT)
> So, as I dug a bit deeper into the insides of MLton's threads, I found that
> it copies the stack of the thread calling 'newThread'. Is this right?
No. 'newThread' copies the stack of the thread suspended as 'base'. The
'base' thread is a snapshot of the main thread taken very early (i.e,.
when 'base' is evaluated) in the evaluation of the Basis Library, when the
stack is very small. The way that newThread works is that it bangs the
new function to be evaluated by the new thread into the (unit -> unit)
option ref 'func', copies the 'base' stack into a new thread, and then,
when returning to atomicSwitch, immediately switches to the new thread,
resumes evaluation of the 'base' expression, which now finds a SOME in
'func', extracts the function and begins evaluating it on the new stack.
> Why doesn't a new thread get a new stack?
> I am now concerned that if I try to crank up the number of threads, they
> will be using too much stack for my application to reach 40k clients like C.
You shouldn't be seeing an SML thread using more stack space than they
need to evaluate. There may be an extra frame or two at the bottom
corresponding to the stack when 'base' was copied, but it shouldn't be
more than a couple hundred bytes. You might be more interested in the
@MLton thread-shrink-ratio 0.5 -- runtime option which controls how
quickly a thread seen by the GC has its stack shrunk to a minimal size.
(The cost of this is that when a thread has been shrunk but then resumes,
it will incur a GC to grow to a larger size.)
> There's also a fair bit of work done by the runtime to make a thread and
> context switch; why are so many layers needed?
Correctness. We want to make sure that all the proper invariants are
maintained, and that is best acheived by appropriate abstraction.
But, in the cycle of abstraction vs. optimization, we've currently heavily
swung to the abstraction side. So, there is probably a bit of efficiency
to be gained without too much effort.