[GHC] #15571: Eager AP_STACK blackholing causes incorrect size info for sanity checks

[GHC]

#15571: Eager AP_STACK blackholing causes incorrect size info for sanity checks
-------------------------------------+-------------------------------------
        Reporter:  osa1              |                Owner:  (none)
            Type:  bug               |               Status:  new
        Priority:  normal            |            Milestone:  8.6.1
       Component:  Runtime System    |              Version:  8.5
      Resolution:                    |             Keywords:
Operating System:  Unknown/Multiple  |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  None/Unknown      |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:  #15508            |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by osa1):

 We discussed this. Simon is right in comment:1 that this is problem with
 eager
 blackholing in general. However, eager blackholing is optional, so if
 you're
 working on the RTS and you need sanity checks can always not use it (which
 is
 the default). The problem with AP_STACK eager blackholing is more serious
 as it
 can't be disabled (expect perhaps in non-threaded runtime?)

 Anyways, we came up with this plan:

 - Implement a new stack frame AP_STACK_EAGER_BLACKHOLE which is exactly
 like
   the EAGER_BLACKHOLE but indicates that the object that became an eager
   blackhole was an AP_STACK.

 - (Only in debug runtime) Allocate one more word when allocating an
 AP_STACK
   and record its size. Note that this is only possible because we only
 allocate
   AP_STACKs in runtime (and not in generated code).

 - When eagerly blackholing an AP_STACK use AP_STACK_EAGER_BLACKHOLE
 instead of
   EAGER_BLACKHOLE and record the AP_STACK's size.

 - When we actually BLACKHOLE the AP_STACK_EAGER_BLACKHOLE in
 `threadPaused` we
   look at the size of the object and we can correctly return the
 `AP_STACK`
   size in `closure_sizeW()` because we recorded it in step (2).

 Simon, did I get this right? One thing I'm not sure (and forgot to ask at
 the
 meeting) is (3) in the bug report. I don't know if we're supposed to zero
 the
 slop when blackholing an AP_STACK eager blackhole in `threadPaused`. We
 enter
 the AP_STACK right after eagerly blackholing it, but I'm not sure if we
 can
 call `threadPaused` before being done with the stack. Can you comment on
 this?

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