[GHC] #13080: Memory leak caused by nested monadic loops
GHC
ghc-devs at haskell.org
Thu Jan 12 22:35:03 UTC 2017
#13080: Memory leak caused by nested monadic loops
-------------------------------------+-------------------------------------
Reporter: Feuerbach | Owner:
Type: bug | Status: new
Priority: normal | Milestone: 8.2.1
Component: Compiler | Version: 8.0.1
Resolution: | Keywords:
Operating System: Unknown/Multiple | Architecture:
Type of failure: Runtime | Unknown/Multiple
performance bug | Test Case:
Blocked By: | Blocking:
Related Tickets: | Differential Rev(s):
Wiki Page: |
-------------------------------------+-------------------------------------
Comment (by Feuerbach):
Simon: as a matter of fact, I would expect all the calls to expensive to
be recomputed. I think most programmers would interpret the above code as
{{{
while (1) {
for (n = 1; 1 <= 10000; n++) {
print(expensive(n));
}
}
}}}
If I wanted the calls to expensive to be shared, I would probably put them
into
a list. (Of course, a similar piece of code could be intended for `m =
[]`; but
based on `print`, it looks like something intended for an `IO`-like
monad.)
I do understand the tradeoffs involved, and I'm not saying that this
should be
obvious to the compiler. I'm just saying that this might not be the most
convincing example where the current behavior is the one a programmer
would
expect.
What if a programmer could annotate variables (like `worker` or `poll`)
as "function-like" vs "value-like"? "Function-like" means "I don't care
about this value, feel free to recompute it" and "value-like" means
"please cache it if possible".
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13080#comment:15>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
More information about the ghc-tickets
mailing list