Bulat Ziganshin wrote:
Hello Matthew,
Monday, February 4, 2008, 11:45:51 PM, you wrote:
That would be nice. But its only beneficial if there are programs
which takes large amounts of stack at some point, but then shrink down
to very little stack and continue for a reasonable amount of time.
From the 'when I was a lad' department...
Thinking back to when Java transitioned to a garbage collector that could give
memory back to the OS, we got some unexpected benefits. Consider a machine
i would be also happy if ghc will return unused *heap* memory back to
OS - it's immediately required for my GUI program where users may open
huge files and then close them. but i personally don't have the same
need for *stack*
How do you know you don't or won't have the same need for stack?
Given that most most real programs are going to pull in library code
written by all sorts of people, don't you want your program to be robust
and memory efficient even if it makes use of libraries whose authors
chose stack gobbling in preference to heap gobbling, or who used a
(currently non-existant AFAIK) CPS based implementation for development?
I just don't get this idea that the current implementation (8M limit
IIRC in the absence of +RTS options) is good. 8M is still a pretty
big stack and (8M - 4K) per thread seems like an awful lot of memory
to waste to me. If we're all so sure that big stacks are a "bug" then
why bother allowing them to grow at all. Why not just limit them to 4K?
Actually I think the latter option above might be good way to discover
how many "bug" free Haskell progs there really are out there. Precious
few I suspect :-(
Regards
--
Adrian Hey
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
