| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
| |
I'm not entirely sure we are careful about ensuring this; this is a
last-ditch check.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Here the following changes are introduced:
- A read barrier machine op is added to Cmm.
- The order in which a closure's fields are read and written is changed.
- Memory barriers are added to RTS code to ensure correctness on
out-or-order machines with weak memory ordering.
Cmm has a new CallishMachOp called MO_ReadBarrier. On weak memory machines, this
is lowered to an instruction that ensures memory reads that occur after said
instruction in program order are not performed before reads coming before said
instruction in program order. On machines with strong memory ordering properties
(e.g. X86, SPARC in TSO mode) no such instruction is necessary, so
MO_ReadBarrier is simply erased. However, such an instruction is necessary on
weakly ordered machines, e.g. ARM and PowerPC.
Weam memory ordering has consequences for how closures are observed and mutated.
For example, consider a closure that needs to be updated to an indirection. In
order for the indirection to be safe for concurrent observers to enter, said
observers must read the indirection's info table before they read the
indirectee. Furthermore, the entering observer makes assumptions about the
closure based on its info table contents, e.g. an INFO_TYPE of IND imples the
closure has an indirectee pointer that is safe to follow.
When a closure is updated with an indirection, both its info table and its
indirectee must be written. With weak memory ordering, these two writes can be
arbitrarily reordered, and perhaps even interleaved with other threads' reads
and writes (in the absence of memory barrier instructions). Consider this
example of a bad reordering:
- An updater writes to a closure's info table (INFO_TYPE is now IND).
- A concurrent observer branches upon reading the closure's INFO_TYPE as IND.
- A concurrent observer reads the closure's indirectee and enters it. (!!!)
- An updater writes the closure's indirectee.
Here the update to the indirectee comes too late and the concurrent observer has
jumped off into the abyss. Speculative execution can also cause us issues,
consider:
- An observer is about to case on a value in closure's info table.
- The observer speculatively reads one or more of closure's fields.
- An updater writes to closure's info table.
- The observer takes a branch based on the new info table value, but with the
old closure fields!
- The updater writes to the closure's other fields, but its too late.
Because of these effects, reads and writes to a closure's info table must be
ordered carefully with respect to reads and writes to the closure's other
fields, and memory barriers must be placed to ensure that reads and writes occur
in program order. Specifically, updates to a closure must follow the following
pattern:
- Update the closure's (non-info table) fields.
- Write barrier.
- Update the closure's info table.
Observing a closure's fields must follow the following pattern:
- Read the closure's info pointer.
- Read barrier.
- Read the closure's (non-info table) fields.
This patch updates RTS code to obey this pattern. This should fix long-standing
SMP bugs on ARM (specifically newer aarch64 microarchitectures supporting
out-of-order execution) and PowerPC. This fixes issue #15449.
Co-Authored-By: Ben Gamari <ben@well-typed.com>
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Fixes #16857.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It is important that `heapCensus` and `LdvCensusForDead` traverse the
same areas.
`heapCensus` increases the `not_used` counter which tracks how many
closures are live but haven't been used yet.
`LdvCensusForDead` increases the `void_total` counter which tracks how
many dead closures there are.
The `LAG` is then calculated by substracting the `void_total` from
`not_used` and so it is essential that `not_used >= void_total`. This
fact is checked by quite a few assertions.
However, if a program has low maximum residency but allocates a lot in
the nursery then these assertions were failing (see #16753 and #15903)
because `LdvCensusForDead` was observing dead closures from the nursery
which totalled more than the `not_used`. The same closures were not
counted by `heapCensus`.
Therefore, it seems that the correct fix is to make `LdvCensusForDead`
agree with `heapCensus` and not traverse the nursery for dead closures.
Fixes #16100 #16753 #15903 #8982
|
| |
|
|
|
| |
It is possible that void_total is exactly equal to not_used and the
other assertions for this check for <= rather than <.
|
| |
|
|
|
|
|
|
|
| |
This implements the correct fix for #11627 by skipping over the slop
(which is zeroed) rather than adding special case logic for LARGE
ARR_WORDS which runs the risk of not performing a correct census by
ignoring any subsequent blocks.
This approach implements similar logic to that in Sanity.c
|
| | |
|
| |
|
|
|
|
| |
This allows us to run (but ignore the result of) fragile testcases.
Hopefully this should allow us to more easily spot when a fragile test
becomes un-fragile.
|
| | |
|
| |
|
|
| |
This is the same as T5611 but with an unsafe call to sleep.
|
| |
|
|
|
| |
The original issue, #5611, was concerned with safe calls. However, the
test inexplicably used an unsafe call. Fix this.
|
| | |
|
| |
|
|
|
| |
The test seems to have been missing the name of its script and didn't
build with HEAD. How it made it through CI is beyond me.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This commit partly reverts e69619e923e84ae61a6bb4357f06862264daa94b
commit by reintroducing Sf_SafeInferred SafeHaskellMode.
We preserve whether module was declared or inferred Safe. When
declared-Safe module imports inferred-Safe, we warn. This inferred
status is volatile, often enough it's a happy coincidence, something
which cannot be relied upon. However, explicitly Safe or Trustworthy
packages won't accidentally become Unsafe.
Updates haddock submodule.
|
| |
|
|
|
| |
Metric Increase:
haddock.Cabal
|
| | |
|
| | |
|
| |
|
|
|
| |
Sleep to avoid non-determinism due to Darwin's poor mtime resolution.
Fixes #16855.
|
| |
|
|
|
|
|
|
|
|
|
| |
Previously, as described in Note [Primop wrappers], `hasNoBinding` would
return False in the case of `PrimOpId`s. This would result in eta
expansion of unsaturated primop applications during CorePrep. Not only
did this expansion result in unnecessary allocations, but it also meant
lead to rather nasty inconsistencies between the CAFfy-ness
determinations made by TidyPgm and CorePrep.
This fixes #16846.
|
| |
|
|
|
| |
The debugging involved in finding #16846 wouldn't have been necessary
had the consistentCafInfo check been enabled. However, :wq
|
| | |
|
| | |
|
| |
|
|
| |
Due to #16858.
|
| | |
|
| |
|
|
|
|
| |
Originally I was thinking of just skipping the test unless
compiled_debugged==True. However, the test will likely be useful even
without -DS, so let's run it either way.
|
| | |
|
| |
|
|
|
|
|
| |
* Make it pass mypy
* Fix a typo in test name field
* Report more stderr output
* Report stdout output
|
| |
|
|
|
|
|
|
|
| |
This tries to put the testsuite driver into a slightly more maintainable
condition:
* Add type annotations where easily done
* Use pathlib.Path instead of str paths
* Make it pass the mypy typechecker
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
This resolves #16809 (https://gitlab.haskell.org/ghc/ghc/issues/16809).
This patch removes the unnecessary dependency on configure-generated
flags `windowsHost`, `osxHost` and `iosHost`, using the information
provided by the module `System.Info` instead.
We also take care to use the `CrossCompiling` flag generated by the
configure script only after the latter had a chance to run.
|
| | |
|
| |
|
|
|
|
|
| |
LLVM version numberinf changed recently. Previously, releases were numbered
4.0, 5.0 and 6.0 but with version 7, they dropped the redundant ".0".
Fix requires for Llvm detection and some code.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes three infelicities related to the programs that are
(and aren't) accepted with `UnliftedNewtypes`:
* Enabling `UnliftedNewtypes` would permit newtypes to have return
kind `Id Type`, which had disastrous results (i.e., GHC panics).
* Data family declarations ending in kind `TYPE r` (for some `r`)
weren't being accepted if `UnliftedNewtypes` wasn't enabled,
despite the GHC proposal specifying otherwise.
* GHC wasn't warning about programs that _would_ typecheck if
`UnliftedNewtypes` were enabled in certain common cases.
As part of fixing these issues, I factored out the logic for checking
all of the various properties about data type/data family return
kinds into a single `checkDataKindSig` function. I also cleaned up
some of the formatting in the existing error message that gets
thrown.
Fixes #16821, fixes #16827, and fixes #16829.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Previously in the case where GHC was dynamically linked we would load
static objects one-by-one by linking each into its own shared object and
dlopen'ing each in order. However, this meant that the link would fail
in the event that the objects had cyclic symbol dependencies.
Here we fix this by merging each "run" of static objects into a single
shared object and loading this.
Fixes #13786 for the case where GHC is dynamically linked.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
When we revert a CAF we must reset the STATIC_LINK field lest the GC
might ignore the CAF (e.g. as it carries the STATIC_FLAG_LIST flag) and
will consequently overlook references to object code that we are trying
to unload. This would result in the reachable object code being
unloaded. See Note [CAF lists] and Note [STATIC_LINK fields].
This fixes #16842.
Idea-due-to: Phuong Trinh <lolotp@fb.com>
|
| |
|
|
| |
As described in #16845.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
Previously we would hackily evaluate a textual code snippet to compute
actions to disable I/O buffering and flush the stdout/stderr handles.
This broke in a number of ways (#15336, #16563).
Instead we now ship a module (`GHC.GHCi.Helpers`) with `base` containing
the needed actions. We can then easily refer to these via `Orig` names.
|
| |
|
|
| |
As noted in #16855.
|
| |
|
|
|
|
|
|
|
| |
As noted in #16841, there are currently a variety of bugs in the
unloading logic. These only affect Windows since code unloading is
disabled on Linux, where we build with `GhcDynamic=YES` by default.
In the interest of getting the tree green on Windows disable code
unloading until the issues are resolved.
|
