[Git][ghc/ghc][wip/backports-9.8] 11 commits: Fix several mistakes around free variables in iface breakpoints
Zubin (@wz1000)
gitlab at gitlab.haskell.org
Fri Feb 16 06:43:48 UTC 2024
Zubin pushed to branch wip/backports-9.8 at Glasgow Haskell Compiler / GHC
Commits:
06110767 by Torsten Schmits at 2024-02-16T12:13:37+05:30
Fix several mistakes around free variables in iface breakpoints
Fixes #23612 , #23607, #23998 and #23666.
MR: !11026
The fingerprinting logic in `Iface.Recomp` failed lookups when processing decls containing breakpoints for two reasons:
* IfaceBreakpoint created binders for free variables instead of expressions
* When collecting free names for the dependency analysis for fingerprinting, breakpoint FVs were skipped
(cherry picked from commit d3874407df4223a5e14a43571f4cc344349a537d)
- - - - -
88afc6ea by Ben Gamari at 2024-02-16T12:13:37+05:30
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.
(cherry picked from commit 9a52ae46a33b490161e1e3e1cc70caa46c60488a)
- - - - -
9e92e0ae by Andrei Borzenkov at 2024-02-16T12:13:38+05:30
Add changelog entry for renaming tuples from (,,...,,) to Tuple<n> (24291)
(cherry picked from commit 69abc7869bc504631e445083704115fc8a5d29c8)
- - - - -
b6fe819e by Zubin Duggal at 2024-02-16T12:13:38+05:30
ci: Allow release-hackage-lint to fail
Otherwise it blocks the ghcup metadata pipeline from running.
(cherry picked from commit 2e88063500d7ef33c83bd2de8ca5c7818ffbb026)
- - - - -
5c11dae4 by Ben Gamari at 2024-02-16T12:13:38+05:30
rts/EventLog: Place eliminate duplicate strlens
Previously many of the `post*` implementations would first compute the
length of the event's strings in order to determine the event length.
Later we would then end up computing the length yet again in
`postString`. Now we instead pass the string length to `postStringLen`,
avoiding the repeated work.
(cherry picked from commit 325b7613ebb2ca012a8969e20d35e95bfccc2bba)
- - - - -
eeda0cce by Ben Gamari at 2024-02-16T12:13:38+05:30
rts/eventlog: Place upper bound on IPE string field lengths
The strings in IPE events may be of unbounded length. Limit the lengths
of these fields to 64k characters to ensure that we don't exceed the
maximum event length.
(cherry picked from commit 8aafa51cb714fb16989089d4bc1ea7e7eb50124c)
- - - - -
043178f6 by Zubin Duggal at 2024-02-16T12:13:38+05:30
rts: drop unused postString function
(cherry picked from commit 0e60d52cc7e261da11c37bd649511584d92a688b)
- - - - -
0ac077af by Teo Camarasu at 2024-02-16T12:13:38+05:30
nonmoving: Add support for heap profiling
Add support for heap profiling while using the nonmoving collector.
We greatly simply the implementation by disabling concurrent collection for
GCs when heap profiling is enabled. This entails that the marked objects on
the nonmoving heap are exactly the live objects.
Note that we match the behaviour for live bytes accounting by taking the size
of objects on the nonmoving heap to be that of the segment's block
rather than the object itself.
Resolves #22221
(cherry picked from commit bedb4f0de102936099bda4e995cc83f1c344366c)
- - - - -
d61bae3a by Simon Peyton Jones at 2024-02-16T12:13:38+05:30
Make decomposeRuleLhs a bit more clever
This fixes #24370 by making decomposeRuleLhs undertand
dictionary /functions/ as well as plain /dictionaries/
(cherry picked from commit ca2e919ecca35db412e772d7eadd6a7c4fb20e4b)
- - - - -
2b534f79 by ARATA Mizuki at 2024-02-16T12:13:38+05:30
Support 128-bit SIMD on AArch64 via LLVM backend
(cherry picked from commit 015886ec78e598f850c4202efdee239bac63b8c7)
- - - - -
c5623c31 by ARATA Mizuki at 2024-02-16T12:13:38+05:30
x86: Don't require -mavx2 when using 256-bit floating-point SIMD primitives
Fixes #24222
(cherry picked from commit 7d9a2e44e8cce00e24671325aebe47d9e529aee5)
- - - - -
30 changed files:
- .gitlab-ci.yml
- compiler/CodeGen.Platform.h
- compiler/GHC.hs
- compiler/GHC/Cmm/CallConv.hs
- compiler/GHC/Core/Opt/SpecConstr.hs
- compiler/GHC/Core/Opt/Specialise.hs
- compiler/GHC/Core/Predicate.hs
- compiler/GHC/Core/Subst.hs
- compiler/GHC/HsToCore/Binds.hs
- compiler/GHC/StgToCmm/Bind.hs
- compiler/GHC/StgToCmm/Prim.hs
- docs/users_guide/9.8.1-notes.rst
- libraries/base/changelog.md
- libraries/ghc-prim/changelog.md
- rts/Apply.cmm
- rts/Capability.h
- rts/Compact.cmm
- rts/Heap.c
- rts/Interpreter.c
- rts/Messages.c
- rts/PrimOps.cmm
- rts/ProfHeap.c
- rts/RtsFlags.c
- rts/StableName.c
- rts/StgMiscClosures.cmm
- rts/ThreadPaused.c
- rts/Threads.c
- rts/Updates.cmm
- rts/Updates.h
- rts/eventlog/EventLog.c
The diff was not included because it is too large.
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/833b9b7ec54b5e9a18236a70700fc7696ab00d53...c5623c31f5f798e7b8e05cc2ef55d3f77309fff9
--
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/833b9b7ec54b5e9a18236a70700fc7696ab00d53...c5623c31f5f798e7b8e05cc2ef55d3f77309fff9
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/20240216/f9e1391f/attachment-0001.html>
More information about the ghc-commits
mailing list