[GHC] #10613: Mechanism for checking that we only enter single-entry thunks once

[GHC]

#10613: Mechanism for checking that we only enter single-entry thunks once
-------------------------------------+-------------------------------------
        Reporter:  bgamari           |                Owner:
            Type:  feature request   |               Status:  new
        Priority:  normal            |            Milestone:
       Component:  Compiler          |              Version:  7.10.1
      Resolution:                    |             Keywords:
Operating System:  Unknown/Multiple  |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  Other             |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by nomeata):

 >  A counting indirection sounds like the right kind of thing.

 Looking a bit into this `IND_COUNTING` now; so I’ll go into “dumping notes
 into trac” mode, for the future benefit of me or whoever else continues.

 There is already a closure type `IND_PERM` which is not removed by the GC;
 our counting indirections requires the same behavior. So this is a good
 start, I guess. The following comments are observations from looking at
 every mention of `IND_PERM` in the code.

  * `Cmm.h` has macros to `ENTER` a closure, which shortcuts indirections
 without calling their entry code. This is not what we want for an
 `IND_COUNTING`; so we should use the `default` code there, to actually
 enter the counting closure.
  * Should the interpreter also count entries? I don’t see any reference to
 `ticky` in `Interpreter.c`, so probably not.
  * Should `rts/Stable.c` preserve `IND_COUNTING`? It does not preserve
 `IND_PERM`, so probably not.
  * Fun fact: tricky and profiling do currently not mix. As I plan to do
 this counting as part of ticky, this means I can ignore problems with
 profiling in the RTS (the closures still have to work, of course).
  * `scavenge_mark_stack` does nothing for `IND_PERM` with a comment I
 don’t fully understand. Will revisit.

 Weird. I only find lots of code that ''handles'' `IND_PERM`, but none that
 actually creates closures of that type. Is all that dead code, likely
 since 2010’s reimplementation of BLACHOLES by Simon Marlow?
 (changeset:5d52d9b/ghc)

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