[GHC] #12620: Allow the user to prevent floating and CSE

GHC ghc-devs at haskell.org
Thu Sep 29 06:44:24 UTC 2016


#12620: Allow the user to prevent floating and CSE
-------------------------------------+-------------------------------------
        Reporter:  nomeata           |                Owner:
            Type:  feature request   |               Status:  new
        Priority:  normal            |            Milestone:
       Component:  Compiler          |              Version:  8.0.1
      Resolution:                    |             Keywords:
Operating System:  Unknown/Multiple  |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  None/Unknown      |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:  #9520, #8457      |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------
Changes (by edsko):

 * related:   => #9520, #8457


Comment:

 Right, so a lot of the thinking that led to this ticket came from trying
 to understand memory leaks in conduit code. See my recent blog post
 http://www.well-typed.com/blog/2016/09/sharing-conduit/ where these issues
 are described in great detail; this should also serve, I hope, as one
 "compelling use case".

 That said, I like the idea of a "noupdate" much better than a "nofloat".
 It would seem to me that its semantics would be easier to specify; and if
 it means I don't have to think so hard about what exactly the optimizer is
 doing to my code in order to understand why I do or do not have a memory
 leak, that would very welcome.

 I really like @duncan 's suggestion of having a type annotation on a type;
 though we might also want some adhoc way of saying "make ''this'' thunk
 not-updateable". An easyish experiment perhaps might be to declare a magic
 datatype

 {{{#!hs
 data DontUpdate a = DontUpdate a
 }}}

 with the property that any code that looks at the thunk in the payload of
 `DontUpdate` doesn't cause that thunk to be updated. Then in @duncan 's
 example we could define

 {{{#!hs
 data Pipe i o r = Yield o (DontUpdate (Pipe i o r))
 }}}

 That said, I'm not sure exactly what DontUpdate should do for the lambda;
 but this is a question about @duncan's proposal too. I ''think'' what we
 want to happen is that the thunks in the function closure never get
 updated (this, in a nutshell, is what is causing memory leaks in conduit
 code; see the blog post); but that's already more magical than just saying
 "don't update this thunk".

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


More information about the ghc-tickets mailing list