[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