Henning Thielemann wrote on Haskell Cafe:
Attached is a program with a space leak... I have coded a simple 'map' function, once using unsafePerformIO and once without. UnsafePerformIO has a space leak in some circumstances. In the main program I demonstrate cases with and without space leak. Without space leak the program writes a file to the disk until it is full.
Bertram Felgenhauer wrote:
The program relies on the GC doing short-cut evaluation of record selectors to avoid a space leak... Use of suffix: Due to the call of Main.go1 this is *not* a record selector. It is compiled to an actual case expression, which to the garbage collector looks just like an ordinary thunk. A reference to Main.ds is kept around until the suffix is about to be processed and a memory leak ensues. The good news is that the problem is completely unrelated to unsafePerformIO (the presence of unsafePerformIO makes optimisations more difficult, but any pure function of sufficient complexity would have the same effect).
Is there already a GHC Trac bug for this? Link to Bertram's original email, with detailed analysis of the GHC Core: http://www.haskell.org/pipermail/haskell-cafe/2010-June/079479.html Thanks, Yitz
On 30/06/2010 18:13, Yitzchak Gale wrote:
Henning Thielemann wrote on Haskell Cafe:
Attached is a program with a space leak... I have coded a simple 'map' function, once using unsafePerformIO and once without. UnsafePerformIO has a space leak in some circumstances. In the main program I demonstrate cases with and without space leak. Without space leak the program writes a file to the disk until it is full.
Bertram Felgenhauer wrote:
The program relies on the GC doing short-cut evaluation of record selectors to avoid a space leak... Use of suffix: Due to the call of Main.go1 this is *not* a record selector. It is compiled to an actual case expression, which to the garbage collector looks just like an ordinary thunk. A reference to Main.ds is kept around until the suffix is about to be processed and a memory leak ensues. The good news is that the problem is completely unrelated to unsafePerformIO (the presence of unsafePerformIO makes optimisations more difficult, but any pure function of sufficient complexity would have the same effect).
Is there already a GHC Trac bug for this?
This is it: http://hackage.haskell.org/trac/ghc/ticket/2607
Link to Bertram's original email, with detailed analysis of the GHC Core:
http://www.haskell.org/pipermail/haskell-cafe/2010-June/079479.html
Added to the ticket, thanks. Cheers, Simon
participants (2)
-
Simon Marlow -
Yitzchak Gale