[GHC] #10414: Buggy behavior with threaded runtime (-N1 working, -N2 getting into <<loop>>)
GHC
ghc-devs at haskell.org
Fri Jul 3 15:03:13 UTC 2015
#10414: Buggy behavior with threaded runtime (-N1 working, -N2 getting into
<<loop>>)
-------------------------------------+-------------------------------------
Reporter: exio4 | Owner:
Type: bug | Status: new
Priority: normal | Milestone:
Component: Compiler | Version: 7.10.1
Resolution: | Keywords:
Operating System: Unknown/Multiple | Architecture:
Type of failure: Incorrect result | Unknown/Multiple
at runtime | Test Case:
Blocked By: | Blocking:
Related Tickets: | Differential Revisions:
-------------------------------------+-------------------------------------
Comment (by simonpj):
We need Simon Marlow's advice here.
What you say does seem plausible:
* With lazy blackholing, a single-entry thunk will never be black-holed.
Lazy black-holing only black-holes thunks with an update frame on the
stack, and single-entry thunks do not push an update frame. So that could
explain why `-feager-blackholing` is required.
* Rather to my surprise, a single-entry thunk is black-holed. I can't see
any good reason why this happens. Look at
`StgCmmClosure.blackHoleOnEntry`.
* Re comment:22 we need Simon to say. It would be pretty bad if every
module had to be compiled consistently. However I note that the comment
in `Scav.c` is in code that messes with update frames, and so single-entry
thunks probably don't matter.
Even if all this is right, we still don't know why we get `<<loop>>`. I'm
assuming that this means we have entered a black hole, ''that is under
evaluation by this thread''; but suddenly I'm not sure. (For a black hole
being evaluated by another thread, we'd block.)
I suggest you try making `blackHoleOnEntry` return False for single-entry
thunks.
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10414#comment:23>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
More information about the ghc-tickets
mailing list