[GHC] #917: -O introduces space leak

[GHC]

#917: -O introduces space leak
----------------------------------------+-----------------------------------
    Reporter:  claus.reinke@…           |       Owner:                  
        Type:  bug                      |      Status:  new             
    Priority:  lowest                   |   Milestone:  _|_             
   Component:  Compiler                 |     Version:  6.5             
    Keywords:                           |          Os:  Unknown/Multiple
Architecture:  Unknown/Multiple         |     Failure:  None/Unknown    
  Difficulty:  Unknown                  |    Testcase:                  
   Blockedby:                           |    Blocking:                  
     Related:                           |  
----------------------------------------+-----------------------------------

Comment(by nomeata):

 Replying to [comment:13 ezyang]:
 > While doing this automatically seems quite hard, would some generalized
 form of ``revertCAFs`` help folks out? The generalization would be on two
 axes: one is that it would apply to any closure on the heap, not just
 CAFs; and two is that you would be able to trigger the reversion from user
 code (some other thunk to force, which you can either throw away or poke
 with a ``seq``).

 Do you want a command that reverts all closures on the heap, or any
 (specific) closure on the heap? I assume the latter.

 It sounds like a variant of [http://arxiv.org/abs/1207.2017 dup] that
 works in hindsight, i.e. some thunks is being evaluated and later the
 programmer uses ```revertToThunk``` to turn back to the thunk.

 I don’t think this would work well in general: The original thunk is
 likely to retain stuff that you want to have thrown away when you evaluate
 it.

 It might be possibly reasonable to state in advance: I want to be able to
 revert this thunk later, please keep the necessary information around. I
 believe you can achieve this with ```dup``` (and manually remembering the
 copied thunk). That is, once it runs on your machine without segfaults :-)

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/917#comment:15>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler