> > If one runs Hugs under Mach, and Mach knows how to enlarge the
> > stack, is there any point of letting Hugs STG have its own
> > stack. I mean, is that not going to be slower with a stack
> > implemented on higher level?
> Well, the difference (with a well-written software stack) is one if
> in software per stack operation versus a hardware check.
A software stack can still use hardware protection. Most machines
with memory protection hardware provide some variant of mprotect
to let applications modify protection.
Using hardware protection isn't necessarily faster than software
protection:
1) There's the fixed costs of having an MMU examine every memory
access. We can't turn these off on a program-by-program basis so
let's ignore them.
2) The cost of taking a memory protection trap and propagating that
up to the user is unreasonably high on modern architectures.
My boss likes to compare a Pentium III (or equivalent) with a
train going at 200 mph and then trying to make a 90 degree turn.
3) A good compiler can do an awful lot to predict stack usage.
Even the STG-Hugs bytecode interpreter (which is pretty much
unoptimised) only does one stack check per basic block.
If stack checks were a significant fraction of GHC's execution,
I'm certain the GHC team would find a way to fix that.
And then you have to remember that modern architectures can make it
very hard to determine exactly which instruction caused the trap and
which instructions had already been executed. So you can detect the
stack overflow just fine but have a very hard time figuring out
how to recover from it if you want to do something useful like
resize the stack.
Finally, there's the assumption that you have just one stack.
STG-Hugs supports concurrency so it uses multiple stacks. It's hard
to use conventional OS threads/stacks for this purpose because
conventional threads provide no control over when context switches
happen and their stacks cannot be moved (to recover from the
inevitable overflows).
--
Alastair Reid
