On 2008 Sep 19, at 17:14, Manlio Perillo wrote:
Brandon S. Allbery KF8NH ha scritto:
There are two ways to handle a growable stack; both start with allocating each stack in a separate part of the address space with room to grow it downward. The simpler way uses stack probes on function entry to detect impending stack overflow. The harder (and less portable) one involves trapping page faults ("segmentation violation" on POSIX), enlarging the stack, and restarting the instruction that caused the trap; this requires fairly detailed knowledge of the CPU and the way signals or page faults are handled by the OS. (There's also a hybrid which many POSIXish systems use, trapping the page fault specifically when running the stack probe; the probe is designed to be safe to either restart or ignore, so it can be handled more portably.)
What implementation is used in GHC?
I haven't looked at the GHC implementation.
Is this more easy to implement with a pure functional language like Haskell, or the same implementation can be used with a procedural language like C?
You can use it with pretty much any language, as long as you can limit the size of stack frames. (If a stack frame is larger than the stack probe distance you might just get an unhandled page fault.) The main question is whether you ant to absorb the additional complexity; it's a bit harder to debug memory issues when you have to deal with page faults yourself. (A *real* segmentation violation might be hidden by the stack grow code.) -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH