Enforce eager blackholing in the runtime and fix generic updateThunk

[TerrorJack]

Eager blackholing

We enforce the -feager-blackholing option in ahc. This means that when GHC generates the entry code for thunks (see https://gitlab.haskell.org/ghc/ghc/-/blob/ghc-8.8/compiler/codeGen/StgCmmBind.hs#L603), the thunk is immediately overwritten by a blackhole. The benefits are:

• Plugging potential space leak (the thunk no longer references the free variables)
• Cheap. We don't need to use real CAS instruction when targetting WebAssembly.
• Easy to reason about.

Eager blackholing and multi-threading

In a multi-threaded world, the same thunk may be entered by different threads. Since we have global eager blackholing, we have the assumption of:

• If a thunk is still a thunk, it's not being evaluated anywhere (no update frames point to it)
• If a thunk is being evaluated, it's a blackhole and points to the owner TSO or the TSO blocking queue
• If a thunk is being evaluated, there'll only be a single update frame pointing to it.

Nice properties right? Thus the generic updateThunk function only needs to handle blackholes.

The bug

The problem is, -feager-blackholing has no effect on hand-written Cmm sources in the runtime. There are special thunks defined in StgStdThunks.cmm; they aren't blackholed when entered, and they only push non-blackhole flavor of update frames in the entry code. This breaks the nice properties listed above, and confuses updateThunk. One example of relevant bug is #579.

The solution

We need to implement at least one of the listed items:

• Teach updateThunk to be smarter and handle the non-blackholed thunks as well. I'm not totally sure this is the only place we need to change.
• Enforce eager blackholing for rts Cmm sources as well, so that all those nice properties still hold.