Simon Marlow wrote:
The point is, GHC has no such thing as the "overall program memory limit" unless by that you mean the total amount of memory + swap in your machine. You can set a limit with +RTS -M, but there isn't one by default. So what happens when you write a program with a space leak is that it gobbles up all the memory, and turns on the hard disk light for a few minutes until the OS gives up and kills it. Or at least, you hope it kills your program and not something else important you were doing at the time.

Well if having "unbounded" (by default) memory use in the form of heap
is OK with most users then I can't see why the same should not be OK
for stack. An errant program is just as likely to explode the heap
as it is the stack AFAICS.

We used to have a default heap limit, for the reason above, but I was persuaded to remove it because it was too much of a pain to keep having to say +RTS -M<whatever> when your program ran out of memory. So we could do the same with the stack limit - the only concern is whether it will be highly inconvenient when we accidentally write programs with infinite loops, which in my experience seem to occur more than space-leaky programs.

To be honest, in all my years of Haskelling I can't think of a single
occasion where I've had a program get stuck in an infinite loop. I've
had plenty of stack overflows, and they're reported on the mailing
lists pretty regularly, but on all such occasions it's been caused
by deep but very definitely finite recursion.

We could also set the limit a lot higher than it currently is. Or, we could try to figure out how much memory is in the machine and set it based on that. Basically, I don't care that much, unless it means I have to do a lot of work to implement it :)

I don't think just keeping the implementation as it is and just changing
(or removing) the limit is really an option. Unfortunately, as things
are at present, using a lot of stack with a program compiled by ghc
really is a "bug" and the limit does provide users with some
protection against this. But IMO the bug is in the ghc rts, not the
users source code most of the time :-(

I think at the minimum, the stack shrinking mod you suggested should
be implemented before the limit is removed.

Regards
--
Adrian Hey























_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Reply via email to