Re: [GHC] #8611: nofib’s cacheprof’s allocations nondeterminisitic

[GHC]

#8611: nofib’s cacheprof’s allocations nondeterminisitic
-------------------------------------+-------------------------------------
        Reporter:  nomeata           |                Owner:  (none)
            Type:  bug               |               Status:  new
        Priority:  normal            |            Milestone:
       Component:  NoFib benchmark   |              Version:  8.5
  suite                              |
      Resolution:                    |             Keywords:
Operating System:  Unknown/Multiple  |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  None/Unknown      |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:  #4450             |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------
Changes (by sgraf):

 * related:   => #4450


Comment:

 Just a few notes while it's still fresh in my head. I always compared two
 traces via `rr`.

 - Based on my observation that bytes copied was the first metric to
 diverge, I did some printf debugging in the RTS.
 - I noticed that the first divergence comes from copying additional
 blackholes. After evacuating the blackhole in trace B, it resumes 'normal'
 operation, e.g. does the same thing trace A would do instead of evacuating
 the black hole.
 - The black holes are evacuated when the stack is scavenged. They're
 pointed to by update frames, all of which originally pointed to
 `stg_sel_0_upd` selector thunks.
 - I also noticed that the `mut_list_size` output of `+RTS -Dg` varies
 between the two traces, and it's never because of any mutable primitives
 (e.g., arrays, MVars, etc.).

 I'm not sure what pushes (or fails to push) the update frames. Maybe it
 has to do with `ThreadPaused.c:stackSqueeze()`? Maybe this is related to
 #4450?

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