| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
CONSTR_NOCAF was introduced with 55d535da10d as a replacement for
CONSTR_STATIC and CONSTR_NOCAF_STATIC, however, as explained in Note
[static constructors], we copy CONSTR_NOCAFs (which can also be seen in
evacuate) during GC, and they can become dead, like other CONSTR_X_Ys.
processHeapClosureForDead is updated to reflect this.
Test Plan: Validates on x86_64. Existing failures on i386.
Reviewers: simonmar, bgamari, erikd
Reviewed By: simonmar, bgamari
Subscribers: rwbarton, thomie, carter
GHC Trac Issues: #7836, #15063, #15087, #15165
Differential Revision: https://phabricator.haskell.org/D4928
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There was a lock-order reversal between lockTSO() and the TVar lock,
see #15136 for the details.
It turns out we can fix this pretty easily by just deleting all the
locking code(!). The principle for unblocking a `BlockedOnSTM` thread
then becomes the same as for other kinds of blocking: if the TSO
belongs to this capability then we do it directly, otherwise we send a
message to the capability that owns the TSO. That is, a thread blocked
on STM is owned by its capability, as it should be.
The possible downside of this is that we might send multiple messages
to wake up a thread when the thread is on another capability. This is
safe, it's just not very efficient. I'll try to do some experiments
to see if this is a problem.
Test Plan: Test case from #15136 doesn't deadlock any more.
Reviewers: bgamari, osa1, erikd
Reviewed By: osa1
Subscribers: rwbarton, thomie, carter
GHC Trac Issues: #15136
Differential Revision: https://phabricator.haskell.org/D4956
|
|
|
|
|
|
| |
This reverts commit 8736715857d08cc1f88d766c257b39c05df20639.
I hadn't intended on merging this.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously we would prevent any operating system not providing the
MEM_NORESERVE flag
from using the two-step allocator. Afterall, Linux will reserve
swap-space for
a mapping unless this flag is given, which is most certainly not what
we want.
However, it seems that FreeBSD provides the reservation-only mapping
behavior
that we expect despite not providing the MEM_NORESERVE macro. In fact,
it
provided the macro until 2014, when it was removed on account of not
being
implemented in the kernel. However, empirical evidence suggests that
just plain
mmap does what we want.
Reviewers: erikd, simonmar
Subscribers: rwbarton, thomie, erikd, carter
GHC Trac Issues: #15348
Differential Revision: https://phabricator.haskell.org/D4939
|
|
|
|
|
|
| |
This reverts commit 6bb0c5db818c1ba9cd5fe1785a3020cfddf0c223.
See discussion in D4905.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It shouldn't be necessary to lock the `MVar` closure on `tryReadMVar`, since it
just reads one field of the structure and doesn't make any modifications. So
let's not.
Reviewers: bgamari, erikd, simonmar, fryguybob, osa1
Reviewed By: osa1
Subscribers: osa1, rwbarton, thomie, carter
Differential Revision: https://phabricator.haskell.org/D4905
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: simonmar, bgamari, erikd
Reviewed By: simonmar
Subscribers: rwbarton, thomie, carter
Differential Revision: https://phabricator.haskell.org/D4893
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
protect mmaped addresses from writes after being initially manipulated
Test Plan: ./validate
Reviewers: bgamari, erikd, simonmar
Reviewed By: bgamari
Subscribers: angerman, carlostome, rwbarton, thomie, carter
GHC Trac Issues: #14069
Differential Revision: https://phabricator.haskell.org/D4817
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently we belch some output to stderr but fail to abort, resulting in
a busy loop. Fixes #15292.
Test Plan:
* Validate
* try running program under environment without timerfd capabilities;
ensure we don't busy-loop
Reviewers: simonmar, erikd
Reviewed By: simonmar
Subscribers: rwbarton, thomie, carter
GHC Trac Issues: #15929
Differential Revision: https://phabricator.haskell.org/D4875
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Use bool instead of HsBool
* Use barf instead of sysErrorBelch; stg_exit
Test Plan: Validate
Reviewers: erikd, simonmar
Subscribers: rwbarton, thomie, carter
Differential Revision: https://phabricator.haskell.org/D4874
|
|
|
|
|
|
|
|
|
|
|
|
| |
Test Plan: Used it in anger
Reviewers: bgamari, erikd
Reviewed By: bgamari
Subscribers: rwbarton, thomie, carter
Differential Revision: https://phabricator.haskell.org/D4873
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It seems like we currently support string literals in Cmm, so we can use
__LINE__ CPP macro in assertion macros. This improves error messages
that previously looked like
ASSERTION FAILED: file (null), line 1302
(null) part now shows the actual file name.
Also inline some single-use string literals in PrimOps.cmm.
Reviewers: bgamari, simonmar, erikd
Reviewed By: bgamari
Subscribers: rwbarton, thomie, carter
Differential Revision: https://phabricator.haskell.org/D4862
|
|
|
|
| |
This reverts commit 86210b238b86d810874a2315d1715546a4006cea.
|
|
|
|
|
|
| |
As pointed out in #12951, this was a temporary measure to allow GHC to be
bootstrapped on Windows with GHC 7.10. This release is now out of our bootstrap
support window so let's remove it.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Test Plan: Validate using LLVM assembler
Reviewers: carter, erikd, simonmar
Reviewed By: simonmar
Subscribers: rwbarton, thomie
GHC Trac Issues: #15207
Differential Revision: https://phabricator.haskell.org/D4781
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixes #15040.
Reviewers: bgamari, simonmar
Reviewed By: bgamari
Subscribers: rwbarton, thomie, carter
Differential Revision: https://phabricator.haskell.org/D4772
|
|
|
|
|
|
| |
This reverts commit e4c41ec2b1f2f222c9c8a83ef64d4e566aa47a44.
rts.cabal.in isn't processed by CPP.
|
|
|
|
|
|
|
|
|
|
| |
Test Plan: Test with Hadrian
Reviewers: simonmar, snowleopard, erikd
Subscribers: rwbarton, thomie, carter
Differential Revision: https://phabricator.haskell.org/D4846
|
|
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: erikd, simonmar
Reviewed By: simonmar
Subscribers: rwbarton, thomie, carter
GHC Trac Issues: #14492
Differential Revision: https://phabricator.haskell.org/D4811
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: bgamari, simonmar, erikd
Reviewed By: simonmar
Subscribers: rwbarton, thomie, carter
Differential Revision: https://phabricator.haskell.org/D4835
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Test Plan: Validate
Reviewers: erikd, simonmar
Reviewed By: simonmar
Subscribers: rwbarton, thomie, carter
Differential Revision: https://phabricator.haskell.org/D4798
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For the same reason with MUT_ARR_PTRS_CLEAN we don't need to scavenge
SMALL_MUT_ARR_PTRS_CLEAN in mut_lists.
Because SMALL_MUT_ARR_PTRS doesn't have a card table we don't have a
special case when scavenging SMALL_MUT_ARR_PTRS_DIRTY in a mut_list.
Test Plan: this validates
Reviewers: simonmar, bgamari, erikd
Reviewed By: simonmar, bgamari
Subscribers: rwbarton, thomie, carter
Differential Revision: https://phabricator.haskell.org/D4800
|
|
|
|
|
|
|
|
|
|
|
|
| |
Test Plan: this validates
Reviewers: simonmar, bgamari, erikd
Reviewed By: simonmar
Subscribers: rwbarton, thomie, carter
Differential Revision: https://phabricator.haskell.org/D4795
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
SMALL_MUT_ARR_PTRS_FROZEN0 -> SMALL_MUT_ARR_PTRS_FROZEN_DIRTY
SMALL_MUT_ARR_PTRS_FROZEN -> SMALL_MUT_ARR_PTRS_FROZEN_CLEAN
MUT_ARR_PTRS_FROZEN0 -> MUT_ARR_PTRS_FROZEN_DIRTY
MUT_ARR_PTRS_FROZEN -> MUT_ARR_PTRS_FROZEN_CLEAN
Naming is now consistent with other CLEAR/DIRTY objects (MVAR, MUT_VAR,
MUT_ARR_PTRS).
(alternatively we could rename MVAR_DIRTY/MVAR_CLEAN etc. to MVAR0/MVAR)
Removed a few comments in Scav.c about FROZEN0 being on the mut_list
because it's now clear from the closure type.
Reviewers: bgamari, simonmar, erikd
Reviewed By: simonmar
Subscribers: rwbarton, thomie, carter
Differential Revision: https://phabricator.haskell.org/D4784
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When we attempt to reserve the heap, we query the system's rlimit to
establish the starting point for our search over sizes.
Test Plan: Validate
Reviewers: erikd, simonmar
Reviewed By: simonmar
Subscribers: rwbarton, thomie, carter
GHC Trac Issues: #14492
Differential Revision: https://phabricator.haskell.org/D4754
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This feature has some very serious correctness issues (#14310),
introduces a great deal of complexity, and hasn't seen wide usage.
Consequently we are removing it, as proposed in Proposal #77 [1]. This
is heavily based on a patch from fryguybob.
Updates stm submodule.
[1] https://github.com/ghc-proposals/ghc-proposals/pull/77
Test Plan: Validate
Reviewers: erikd, simonmar, hvr
Reviewed By: simonmar
Subscribers: rwbarton, thomie, carter
GHC Trac Issues: #14310
Differential Revision: https://phabricator.haskell.org/D4760
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When we allocate the heap on POSIX platforms we generally just ask for a
1TB chunk of address space and call it a day. However, if the user has
set a ulimit then this request will fail. In this case we would
previously try successively smaller allocation requests, reducing the
request size by a factor of two each time.
However, this means that GHC will significantly allocate a significantly
smaller heap than the available physical memory size in some
circumstances. Imagine, for instance, a machine with 512 GB of physical
memory but a ulimit of 511 GB: we would be limited to a 256 GB heap.
We now use a less aggressive back-off policy, reducing by one-eighth the
last allocation size each try.
Thanks to luispedro for the suggested approach.
Test Plan: Validate
Reviewers: simonmar, erikd
Subscribers: rwbarton, thomie
GHC Trac Issues: #14492
Differential Revision: https://phabricator.haskell.org/D4215
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On 32-bit Linux `outofmem` did not fail with the expected out-of-memory
error message, instead failing with,
outofmem: internal error: getMBlock: mmap: Invalid argument
This happened because, `my_mmap` would attempt to `madvise` even if the
`mmap` call failed. So while `mmap` returns `ENOMEM` we nevertheless try
to `madvise`, which clobbers `errno`, giving us the unexpected `EINVAL`
error. Consequently we don't detect this to be an out-of-memory error.
This should fix #15060.
Test Plan: `make test TEST=outofmem` on i386
Reviewers: simonmar, erikd
Reviewed By: simonmar
Subscribers: rwbarton, thomie, carter
GHC Trac Issues: #15060
Differential Revision: https://phabricator.haskell.org/D4704
|
| |
|
| |
|
|
|
|
| |
Makes it possible to print STACK (StgStack) objects easily in gdb
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Fix a number of issues that have broken the 32 bit build.
This makes it build again.
Test Plan: ./validate
Reviewers: hvr, goldfire, bgamari, erikd, simonmar
Reviewed By: bgamari
Subscribers: rwbarton, thomie, carter
Differential Revision: https://phabricator.haskell.org/D4691
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This pulls parts of Joachim Breitner's ghc-heap-view library inside GHC.
The bits added are the C hooks into the RTS and a basic Haskell wrapper
to these C hooks. The main reason for these to be added to GHC proper
is that the code needs to be kept in sync with the closure types
defined by the RTS. It is expected that the version of HeapView shipped
with GHC will always work with that version of GHC and that extra
functionality can be layered on top with a library like ghc-heap-view
distributed via Hackage.
Test Plan: validate
Reviewers: simonmar, hvr, nomeata, austin, Phyx, bgamari, erikd
Reviewed By: bgamari
Subscribers: carter, patrickdoc, tmcgilchrist, rwbarton, thomie
Differential Revision: https://phabricator.haskell.org/D3055
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This was blatantly wrong due to copy-paste blindness:
* labels were shadowed, which GHC doesn't warn about(!), resulting in
plainly wrong behavior
* the sharing check was omitted
* the wrong closure layout was being used
Moreover, the test wasn't being run due to its primitive dependency, so
I didn't even notice. Sillyness.
Test Plan: install `primitive`, `make test TEST=compact_small_array`
Reviewers: simonmar, erikd
Reviewed By: simonmar
Subscribers: rwbarton, thomie, carter
GHC Trac Issues: #13857.
Differential Revision: https://phabricator.haskell.org/D4702
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Recent changes to SRTs (D4632, D4637) also required changes to
RetainerProfile.c. This should hopefully get things working again.
Test Plan: validate with profiling turned on
Reviewers: bgamari, osa1, tdammers, erikd
Subscribers: rwbarton, thomie, carter
Differential Revision: https://phabricator.haskell.org/D4707
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
See the new note.
This should fix cb5c2fe875965b7aedbc189012803fc62e48fb3f enough
to unbreak Windows and OS X builds.
Test Plan: manual testing with patched gdb
Reviewers: bgamari, simonmar, erikd
Reviewed By: bgamari
Subscribers: rwbarton, thomie, carter
Differential Revision: https://phabricator.haskell.org/D4694
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The idea here is to save a little code size and some work in the GC,
by collapsing FUN_STATIC closures and their SRTs.
This is (4) in a series; see D4632 for more details.
There's a tradeoff here: more complexity in the compiler in exchange
for a modest code size reduction (probably around 0.5%).
Results:
* GHC binary itself (statically linked) is 1% smaller
* -0.2% binary sizes in nofib (-0.5% module sizes)
Full nofib results comparing D4634 with this: P177 (ignore runtimes,
these aren't stable on my laptop)
Test Plan: validate, nofib
Reviewers: bgamari, niteria, simonpj, erikd
Subscribers: thomie, carter
Differential Revision: https://phabricator.haskell.org/D4637
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
An info table with an SRT normally looks like this:
StgWord64 srt_offset
StgClosureInfo layout
StgWord32 layout
StgWord32 has_srt
But we only need 32 bits for srt_offset on x86_64, because the small
memory model requires that code segments are at most 2GB. So we can
optimise this to
StgClosureInfo layout
StgWord32 layout
StgWord32 srt_offset
saving a word. We can tell whether the info table has an SRT or not,
because zero is not a valid srt_offset, so zero still indicates that
there's no SRT.
Test Plan:
* validate
* For results, see D4632.
Reviewers: bgamari, niteria, osa1, erikd
Subscribers: thomie, carter
Differential Revision: https://phabricator.haskell.org/D4634
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
- Previously we would hvae a single big table of pointers per module,
with a set of bitmaps to reference entries within it. The new
representation is identical to a static constructor, which is much
simpler for the GC to traverse, and we get to remove the complicated
bitmap-traversal code from the GC.
- Rewrite all the code to generate SRTs in CmmBuildInfoTables, and
document it much better (see Note [SRTs]). This has been something
I've wanted to do since we moved to the new code generator, I
finally had the opportunity to finish it while on a transatlantic
flight recently :)
There are a series of 4 diffs:
1. D4632 (this one), which does the bulk of the changes
2. D4633 which adds support for smaller `CmmLabelDiffOff` constants
3. D4634 which takes advantage of D4632 and D4633 to save a word in
info tables that have an SRT on x86_64. This is where most of the
binary size improvement comes from.
4. D4637 which makes a further optimisation to merge some SRTs with
static FUN closures. This adds some complexity and the benefits
are fairly modest, so it's not clear yet whether we should do this.
Results (after (3), on x86_64)
- GHC itself (staticaly linked) is 5.2% smaller
- -1.7% binary sizes in nofib, -2.9% module sizes. Full nofib results: P176
- I measured the overhead of traversing all the static objects in a
major GC in GHC itself by doing `replicateM_ 1000 performGC` as the
first thing in `Main.main`. The new version was 5-10% faster, but
the results did vary quite a bit.
- I'm not sure if there's a compile-time difference, the results are
too unreliable.
Test Plan: validate
Reviewers: bgamari, michalt, niteria, simonpj, erikd, osa1
Subscribers: thomie, carter
Differential Revision: https://phabricator.haskell.org/D4632
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: A better alternative to D4657.
Test Plan:
```
cd testsuite/tests/codeGen/should_run
../../../../inplace/bin/ghc-stage2 -debug cgrun001
nm cgrun001 | grep findPtr
```
Reviewers: bgamari, Phyx, erikd
Subscribers: rwbarton, thomie, carter
Differential Revision: https://phabricator.haskell.org/D4683
|
|
|
|
|
|
|
|
|
|
| |
Test Plan: Validate with Hadrian and `libnuma` support
Reviewers: snowleopard, hvr, erikd, simonmar
Subscribers: izgzhen, alpmestan, thomie, carter
Differential Revision: https://phabricator.haskell.org/D4616
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
commit b2ff5dde399cd012218578945ada1d9ff68daa35 "Fix #15038"
added new stable closure 'absentSumFieldError_closure' to
base package. This closure is used in rts package.
Unfortunately the symbol was not explicitly exported and build
failed on windows as:
```
"inplace/bin/ghc-stage1" -o ...hsc2hs.exe ...
rts/dist/build/libHSrts.a(RtsStartup.o): In function `hs_init_ghc':
rts/RtsStartup.c:272:0: error:
undefined reference to `base_ControlziExceptionziBase_absentSumFieldError_closure'
|
272 | getStablePtr((StgPtr)absentSumFieldError_closure);
| ^
```
This change adds 'absentSumFieldError_closure' to explicit export
into libHSbase.def.
Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>
|
|
|
|
| |
This reverts commit d4abd031f6e8c2fa01f8949f60d8a02cca513804.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This optimisation level is specifically designed to provide the benefits
of optimisation without the obfuscation that sometimes results.
Test Plan: Validate
Reviewers: simonmar
Reviewed By: simonmar
Subscribers: rwbarton, thomie, carter
Differential Revision: https://phabricator.haskell.org/D4675
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
GCC 8 now generates warnings for incompatible function pointer casts
[-Werror=cast-function-type]. Apparently there are a few of those in rts
code, which makes `./validate` unhappy (since we compile with `-Werror`)
This commit tries to fix these issues by changing the functions to have
the correct type (and, if necessary, moving the casts into those
functions).
For instance, hash/comparison function are declared (`Hash.h`) to take
`StgWord` but we want to use `StgWord64[2]` in `StaticPtrTable.c`.
Instead of casting the function pointers, we can cast the `StgWord`
parameter to `StgWord*`. I think this should be ok since `StgWord`
should be the same size as a pointer.
Signed-off-by: Michal Terepeta <michal.terepeta@gmail.com>
Test Plan: ./validate
Reviewers: bgamari, erikd, simonmar
Reviewed By: bgamari
Subscribers: rwbarton, thomie, carter
Differential Revision: https://phabricator.haskell.org/D4673
|