#5645: Sharing across functions causing space leak
---------------------------------+------------------------------------------
Reporter: tener | Owner:
Type: bug | Status: new
Priority: normal | Component: Compiler
Version: 7.2.1 | Keywords:
Testcase: | Blockedby:
Os: Unknown/Multiple | Blocking:
Architecture: Unknown/Multiple | Failure: None/Unknown
---------------------------------+------------------------------------------
I have two test functions in code that both have a lazy list declared like
this:
{{{
let elements = [0 .. someBigInt]
}}}
If, from main, I run both of them, the compiler decides to share this list
among them. In effect the memory is exhausted.
If only one function is called, the memory used is constant and low.
The workaround is to declare on of them like this:
{{{
let elements = [0] ++ [1 .. someBigInt]
}}}
But this is very ugly.
What worries me most is that this is very non-obvious behaviour: if the
list is declared locally inside a function, the compiler shouldn't (?)
share it between two functions. It feels wrong.
If one of the functions is declared in different module, this behavior
disappears. Seems like CSE is not done across modules boundaries.
Another workaround (tested) is to disable CSE with -fno-cse switch. You
can test it works with "make workaround". The bug can be tested with "make
bug".
The compiler behaves this way across the versions. I've tested 6.12.3,
7.0.2, 7.0.3, 7.0.4, 7.2.1, 7.2.2.
My platform should be irrelevant, but for the sake of completeness:
{{{
Linux raptor 3.1.0-4-ARCH #1 SMP PREEMPT Mon Nov 7 22:47:18 CET 2011
x86_64 Intel(R) Core(TM) i7 CPU 870 @ 2.93GHz GenuineIntel GNU/Linux
}}}
The code for reproducing is attached. Again, run it with "make bug" or
simply "make".
I'm experimenting with high-performance FIFO queues. The implementation
attached is quite potent, capable of processing 40M messages / second on
my machine in one-producer one-consumer case.
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/5645>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
_______________________________________________
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
