Thread status constants

Carter Schonwald carter.schonwald at gmail.com
Sat Jul 19 19:07:36 UTC 2014


Wait, does that mean the corresponding constants in base for 7.8.3 are
busted?

On Saturday, July 19, 2014, Jost Berthold <
berthold at mathematik.uni-marburg.de> wrote:

> Message: 2
>> Date: Sat, 19 Jul 2014 15:00:17 +1000
>> From: Kyle Van Berendonck <kvanberendonck at gmail.com>
>> To: "ghc-devs at haskell.org" <ghc-devs at haskell.org>
>> Subject: Thread status constants
>> Message-ID:
>>         <CAFSvR6A3maSWngY=GJdATvGPjTAyuPokXZ5=rLtLT=
>> EbYdSLKA at mail.gmail.com>
>> Content-Type: text/plain; charset="utf-8"
>>
>> Hi,
>>
>> I found these:
>> https://github.com/ghc/ghc/blob/5f3c5384df59717ca8013c5df8d1f6
>> 5692867825/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
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140719/c2e90257/attachment.html>


More information about the ghc-devs mailing list