[Git][ghc/ghc][wip/24275] 8 commits: JS: Mark spurious CI failures js_fragile(24259)

[Zubin (@wz1000)]

Zubin pushed to branch wip/24275 at Glasgow Haskell Compiler / GHC


Commits:
8bef8d9f by Luite Stegeman at 2023-12-14T04:31:33-05:00
JS: Mark spurious CI failures js_fragile(24259)

This marks the spurious test failures on the JS platform as
js_fragile(24259), so we don't hold up merge requests while
fixing the underlying issues.

See #24259

- - - - -
1c79526a by Finley McIlwaine at 2023-12-15T12:24:40-08:00
Late plugins

- - - - -
000c3302 by Finley McIlwaine at 2023-12-15T12:24:40-08:00
withTiming on LateCCs and late plugins

- - - - -
be4551ac by Finley McIlwaine at 2023-12-15T12:24:40-08:00
add test for late plugins

- - - - -
7c29da9f by Finley McIlwaine at 2023-12-15T12:24:40-08:00
Document late plugins

- - - - -
9a52ae46 by Ben Gamari at 2023-12-20T07:07:26-05:00
Fix thunk update ordering

Previously we attempted to ensure soundness of concurrent thunk update
by synchronizing on the access of the thunk's info table pointer field.
This was believed to be sufficient since the indirectee (which may
expose a closure allocated by another core) would not be examined
until the info table pointer update is complete.

However, it turns out that this can result in data races in the presence
of multiple threads racing a update a single thunk. For instance,
consider this interleaving under the old scheme:

            Thread A                             Thread B
            ---------                            ---------
    t=0     Enter t
      1     Push update frame
      2     Begin evaluation

      4     Pause thread
      5     t.indirectee=tso
      6     Release t.info=BLACKHOLE

      7     ... (e.g. GC)

      8     Resume thread
      9     Finish evaluation
      10    Relaxed t.indirectee=x

      11                                         Load t.info
      12                                         Acquire fence
      13                                         Inspect t.indirectee

      14    Release t.info=BLACKHOLE

Here Thread A enters thunk `t` but is soon paused, resulting in `t`
being lazily blackholed at t=6. Then, at t=10 Thread A finishes
evaluation and updates `t.indirectee` with a relaxed store.

Meanwhile, Thread B enters the blackhole. Under the old scheme this
would introduce an acquire-fence but this would only synchronize with
Thread A at t=6. Consequently, the result of the evaluation, `x`, is not
visible to Thread B, introducing a data race.

We fix this by treating the `indirectee` field as we do all other
mutable fields. This means we must always access this field with
acquire-loads and release-stores.

See #23185.

- - - - -
f4b53538 by Vladislav Zavialov at 2023-12-20T07:08:02-05:00
docs: Fix link to 051-ghc-base-libraries.rst

The proposal is no longer available at the previous URL.

- - - - -
8a8d964d by Zubin Duggal at 2023-12-20T17:53:22+05:30
driver: Really don't lose track of nodes when we fail to resolve cycles

This fixes a bug in 8db8d2fd1c881032b1b360c032b6d9d072c11723, where we could lose
track of acyclic components at the start of an unresolved cycle. We now ensure we
never loose track of any of these components.

As T24275 demonstrates, a "cyclic" SCC might not really be a true SCC:

When viewed without boot files, we have a single SCC

```
[REC main:T24275B [main:T24275B {-# SOURCE #-},
                   main:T24275A {-# SOURCE #-}]
     main:T24275A [main:T24275A {-# SOURCE #-}]]
```

But with boot files this turns into

```
[NONREC main:T24275B {-# SOURCE #-} [],
 REC main:T24275B [main:T24275B {-# SOURCE #-},
                   main:T24275A {-# SOURCE #-}]
    main:T24275A {-# SOURCE #-} [main:T24275B],
 NONREC main:T24275A [main:T24275A {-# SOURCE #-}]]
```

Note that this is truly not an SCC, as no nodes are reachable from T24275B.hs-boot.
However, we treat this entire group as a single "SCC" because it seems so when we
analyse the graph without taking boot files into account.

To handle this, I extended `findCycle` to not assume its input is an SCC, and to
try harder to find cycles in its input.

Fixes #24275

- - - - -


30 changed files:

- compiler/GHC/Core/LateCC.hs
- compiler/GHC/Data/Graph/Directed.hs
- compiler/GHC/Driver/Main.hs
- compiler/GHC/Driver/Make.hs
- compiler/GHC/Driver/Plugins.hs
- compiler/GHC/StgToCmm/Bind.hs
- docs/users_guide/9.10.1-notes.rst
- docs/users_guide/extending_ghc.rst
- libraries/base/tests/all.T
- rts/Apply.cmm
- rts/Compact.cmm
- rts/Heap.c
- rts/Interpreter.c
- rts/Messages.c
- rts/PrimOps.cmm
- rts/StableName.c
- rts/StgMiscClosures.cmm
- rts/ThreadPaused.c
- rts/Threads.c
- rts/Updates.cmm
- rts/Updates.h
- rts/include/Cmm.h
- rts/include/rts/TSANUtils.h
- rts/include/stg/SMP.h
- rts/sm/Evac.c
- rts/sm/NonMovingMark.c
- rts/sm/Storage.c
- testsuite/driver/testlib.py
- testsuite/tests/backpack/cabal/T20509/all.T
- testsuite/tests/backpack/cabal/bkpcabal02/all.T


The diff was not included because it is too large.


View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/0de44f902c6e86ddb79310fff8596820958c05e0...8a8d964d555a1bd18a64617b62d61d537e28a0c9

-- 
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/0de44f902c6e86ddb79310fff8596820958c05e0...8a8d964d555a1bd18a64617b62d61d537e28a0c9
You're receiving this email because of your account on gitlab.haskell.org.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-commits/attachments/20231220/9246e1fe/attachment.html>