#2090: Better stack management please
-----------------------------+----------------------------------------------
Reporter: guest | Owner:
Type: feature request | Status: new
Priority: normal | Milestone:
Component: Runtime System | Version: 6.8.2
Severity: normal | Resolution:
Keywords: | Difficulty: Unknown
Testcase: | Architecture: Unknown
Os: Unknown |
-----------------------------+----------------------------------------------
Changes (by simonmar):
* difficulty: => Unknown
Comment:
Essentially there are three suggestions here, I'll deal with them one at a
time:
=== use a different default for the max stack size (+RTS -K) ===
I'm happy to go along with whatever is the popular opinion here.
Personally I never encounter a program that exceeds the current stack
limit and is not in an infinite loop, but I'm prepared to believe that
others do. Please let us know.
=== reduce the memory allocated to a stack when it shrinks ===
This is not hard to implement - probably a couple of hours work, and
confined to just one place. It could be done possibly without even
copying the stack: just split the TSO into two, copy the TSO structure
into the higher bit, and leave the low bit as a !ThreadRelocated, the GC
will clean it up. Don't forget for this to be really useful we also need
to do #698.
=== use a linked list of stack chunks instead of a single contiguous stack
===
This is a much harder proposition - there's lots of code in the RTS that
traverses stacks, and it would all have to change (and get more
complicated, at that). The current decision to use contiguous stacks was
made consciously in order to keep things simple. We'd need some
convincing evidence that the lack of stack chunks is really hurting, to
make it worthwhile doing this. My impression is that there are more
important things.
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2090#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
_______________________________________________
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
