Message: 2
Date: Sat, 19 Jul 2014 15:00:17 +1000
From: Kyle Van Berendonck <[email protected]>
To: "[email protected]" <[email protected]>
Subject: Thread status constants
Message-ID:
<CAFSvR6A3maSWngY=GJdATvGPjTAyuPokXZ5=rLtLT=ebyds...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi,
I found these:
https://github.com/ghc/ghc/blob/5f3c5384df59717ca8013c5df8d1f65692867825/includes/rts/Constants.h#L194
They go only 0-14, so there's some long chains of branches and stuff in hot
paths that could be cleaned up into single &-masked branches by changing
these into a set of flags.
And then I saw these:
https://github.com/ghc/ghc/blob/master/libraries/base/GHC/Conc/Sync.lhs#L483
Where does 16 and 17 come from -- I couldn't find them in the header files
anywhere?
Kyle
Hi Kyle,
I had a look at these constants just recently.
About 16 and 17, see here:
https://github.com/ghc/ghc/blob/master/rts/PrimOps.cmm#L853
About the others:The block reasons received two updates just recently.
Turns out that the eventlog (GHC's post-mortem tracing for threadscope
et al.) expects these states to have particular values (those in
includes/rts/Constants.h, consider them a fixed ABI for the time being).
See here for the story:
https://ghc.haskell.org/trac/ghc/ticket/9003
NB: Darn... base still uses GHC-7.8.2 constants. Thanks for the pointer!
About your proposal to use bit masks:
Did you find some of those hot paths?
I believe (believe, unchecked...) that there are not too many places
where a complete switch over all possible reasons is done (apart from
debug output maybe); the typical use is rather to compare to one single
constant than to all. So the performance might not increase too much
from optimisations. Again, just a hunch, not verified.
If the RTS contains code specialised to the current constants, these
places need to be kept symbolic, to avoid future breakage when new
states are added.
A fix which removes the tight implicit dependency of ghc-events from the
constants in includes/rts/Constants.h is pending, btw.
/ Jost
_______________________________________________
ghc-devs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/ghc-devs
