[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