| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
| |
Test Plan: New unit test
Reviewers: andrewthad, niteria, bgamari, erikd
Subscribers: rwbarton, thomie, carter
GHC Trac Issues: #14900
Differential Revision: https://phabricator.haskell.org/D4485
|
| |
|
| |
|
|
|
|
| |
(the CPP guard is already wrapped with the same guard in line 1549)
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: bgamari, erikd, simonmar
Reviewed By: bgamari
Subscribers: rwbarton, thomie, carter
Differential Revision: https://phabricator.haskell.org/D4441
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: bgamari, erikd, simonmar
Reviewed By: bgamari
Subscribers: rwbarton, thomie, carter
Differential Revision: https://phabricator.haskell.org/D4450
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Adds quick-cross-ncg flavour.
- Fix windows wchar with `_s` for mingw
- Lookup windres, dllwrap and objdump
- Fix type.
Reviewers: bgamari, hvr, Phyx, erikd, simonmar
Reviewed By: bgamari
Subscribers: rwbarton, thomie, erikd, carter
Differential Revision: https://phabricator.haskell.org/D4430
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
`all_tasks_mutex` should be released before calling `releaseCapability_`
in the parent process as `releaseCapability_` spawns worker tasks in
some cases.
Reviewers: bgamari, erikd, simonmar
Subscribers: rwbarton, thomie, carter
GHC Trac Issues: #14538
Differential Revision: https://phabricator.haskell.org/D4460
|
|
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: bgamari, erikd, simonmar
Reviewed By: simonmar
Subscribers: rwbarton, thomie, carter
GHC Trac Issues: #11777
Differential Revision: https://phabricator.haskell.org/D4427
|
|
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: bgamari, erikd, simonmar
Reviewed By: bgamari, simonmar
Subscribers: Phyx, rwbarton, thomie, carter
GHC Trac Issues: #11777
Differential Revision: https://phabricator.haskell.org/D4428
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The pattern `threadCapability =<< myThreadId` is used a lot in code
that uses `hs_try_putmvar`, I want to make it cheaper.
Test Plan: validate
Reviewers: bgamari, erikd
Reviewed By: bgamari
Subscribers: rwbarton, thomie, carter
Differential Revision: https://phabricator.haskell.org/D4381
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The make build system appears to be doing a bit of magic in order to supply
the profiled flavours of libHSrts and libCffi, as they're not advertised in
the 'extra-library-flavours' field of rts.cabal.in. This patch explicitly
advertises _p and _thr_p flavours of the RTS library and libCffi, but only
when the RTS is configured with the (newly introduced) 'profiling' flag.
This is necessary for Hadrian, as a branch (soon to be merged) does away with
ghc-cabal and relies just on Cabal to get package information. Without this
patch, Cabal can never inform us that _p and _thr_p flavours should be
built (and registered in the package db) as well, which obviously prevents us
from building a profiled GHC.
Reviewers: bgamari, erikd, simonmar
Reviewed By: bgamari
Subscribers: rwbarton, thomie, carter
Differential Revision: https://phabricator.haskell.org/D4409
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
cabal introduces SPDX identifier, and as such we need to change the
BSD3 license name. Also the >= qualifier is no longer prefered.
Test Plan: ./validate
Reviewers: bgamari, erikd, simonmar
Reviewed By: bgamari
Subscribers: alpmestan, rwbarton, thomie, carter
Differential Revision: https://phabricator.haskell.org/D4406
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: bgamari, erikd, simonmar
Reviewed By: simonmar
Subscribers: rwbarton, thomie, carter
Differential Revision: https://phabricator.haskell.org/D4393
|
|
|
|
| |
`NO_PROMOTE_THUNKS` is never defined
|
|
|
|
|
|
| |
This was an oversight from 2671cccde749ed64129097358f81bff43480cdb9
as it wasn't obvious to assume one would go the trouble to manually
construct the pkg-db entries... :-)
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: bgamari, erikd, simonmar
Reviewed By: bgamari
Subscribers: rwbarton, thomie, carter
Differential Revision: https://phabricator.haskell.org/D4390
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: bgamari, erikd, simonmar
Reviewed By: bgamari
Subscribers: rwbarton, thomie, carter
Differential Revision: https://phabricator.haskell.org/D4386
|
|
|
|
|
|
|
|
|
|
|
|
| |
Test Plan: Validate
Reviewers: erikd, simonmar
Reviewed By: simonmar
Subscribers: rwbarton, thomie, carter
Differential Revision: https://phabricator.haskell.org/D4374
|
|
|
|
|
|
|
|
|
|
|
|
| |
Test Plan: Validate
Reviewers: erikd, simonmar
Reviewed By: simonmar
Subscribers: rwbarton, thomie, carter
Differential Revision: https://phabricator.haskell.org/D4373
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
GCC's __sync primitives apparently "usually" imply a full barrier,
meaning they can be used to emulate the more precise C11 atomics albeit
with a loss of efficiency. This restores compatibility with GCC 4.4.
This partially reverts commit 59de290928e6903337f31c1f8107ac8a98ea145d.
Test Plan: Validate on Centos
Reviewers: hvr, simonmar, trommler
Subscribers: rwbarton, thomie, erikd, carter
GHC Trac Issues: #14244
Differential Revision: https://phabricator.haskell.org/D4364
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This prevents the register being picked up as a scratch register.
Otherwise the allocator would be free to use it before a call. This
fixes #14619.
Test Plan: ci, repro case on #14619
Reviewers: bgamari, Phyx, erikd, simonmar, RyanGlScott, simonpj
Reviewed By: Phyx, RyanGlScott, simonpj
Subscribers: simonpj, RyanGlScott, Phyx, rwbarton, thomie, carter
GHC Trac Issues: #14619
Differential Revision: https://phabricator.haskell.org/D4348
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Test Plan: validate
Reviewers: simonmar, erikd
Reviewed By: simonmar
Subscribers: rwbarton, thomie, carter
GHC Trac Issues: #14725
Differential Revision: https://phabricator.haskell.org/D4346
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently runtime keeps hold to 4*used_memory. This includes, in
particular, nursery, which can be quite large on multiprocessor
machines: 16 CPUs x 64Mb each is 1GB. Multiplying it by 4 means whatever
actual memory usage is, runtime will never release memory under 4GB, and
this is quite excessive for processes which only need a lot of memory
shortly (think building data structures from large files).
This diff makes multiplier to apply only to GC-managed memory, leaving
all "static" allocations alone.
Test Plan: make test TEST="T14702"
Reviewers: bgamari, erikd, simonmar
Reviewed By: simonmar
Subscribers: rwbarton, thomie, carter
GHC Trac Issues: #14702
Differential Revision: https://phabricator.haskell.org/D4338
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Provide information about paths more likely to be taken in the cmm files
used by the rts.
This leads to slightly better assembly being generated.
Reviewers: bgamari, erikd, simonmar
Subscribers: alexbiehl, rwbarton, thomie, carter
GHC Trac Issues: #14672
Differential Revision: https://phabricator.haskell.org/D4324
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On Windows we use the function `win32AllocStack` to do stack
allocations in 4k blocks and insert a stack check afterwards
to ensure the allocation returned a valid block.
The problem is this function does something that by C semantics
is pointless. The stack allocated value can never escape the
function, and the stack isn't used so the compiler just optimizes
away the entire function body.
After considering a bunch of other possibilities I think the simplest
fix is to just disable optimizations for the function.
Alternatively inline assembly is an option but the stack check function
doesn't have a very portable name as it relies on e.g. `libgcc`.
Thanks to Sergey Vinokurov for helping diagnose and test.
Test Plan: ./validate
Reviewers: bgamari, erikd, simonmar
Reviewed By: bgamari
Subscribers: rwbarton, thomie, carter
GHC Trac Issues: #14669
Differential Revision: https://phabricator.haskell.org/D4343
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Rename to whitehole_gc_spin, in preparation for adding stats for the
whitehole busy-loop in SMPClosureOps.
Make whitehole_gc_spin volatile, and move it to be defined and
statically initialised in GC.c. This saves some #ifs, and I'm pretty
sure it should be volatile.
Test Plan: ./validate
Reviewers: bgamari, erikd, simonmar
Reviewed By: bgamari
Subscribers: rwbarton, thomie, carter
Differential Revision: https://phabricator.haskell.org/D4300
|
|
|
|
| |
This reverts commit a1a689dda48113f3735834350fb562bb1927a633.
|
|
|
|
| |
This reverts commit a770226e03f09b767fdb4ce826162a5c0f29ec29.
|
|
|
|
|
|
|
|
| |
Reviewers: simonmar, erikd
Subscribers: rwbarton, thomie, carter
Differential Revision: https://phabricator.haskell.org/D4312
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
get/setAllocationCounter didn't take into account allocations in the
current block. This was known at the time, but it turns out to be
important to have more accuracy when using these in a fine-grained
way.
Test Plan:
New unit test to test incrementally larger allocaitons. Before I got
results like this:
```
+0
+0
+0
+0
+0
+4096
+0
+0
+0
+0
+0
+4064
+0
+0
+4088
+4056
+0
+0
+0
+4088
+4096
+4056
+4096
```
Notice how the results aren't always monotonically increasing. After
this patch:
```
+344
+416
+488
+560
+632
+704
+776
+848
+920
+992
+1064
+1136
+1208
+1280
+1352
+1424
+1496
+1568
+1640
+1712
+1784
+1856
+1928
+2000
+2072
+2144
```
Reviewers: niteria, bgamari, hvr, erikd
Subscribers: rwbarton, thomie, carter
Differential Revision: https://phabricator.haskell.org/D4288
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This makes the testsuite pass clean on Windows again.
It also fixes the `libstdc++-6.dll` error harbormaster
was showing.
I'm marking some tests as isolated tests to reduce their
flakiness (mostly concurrency tests) when the test system
is under heavy load.
Updates process submodule.
Test Plan: ./validate
Reviewers: hvr, bgamari, erikd, simonmar
Reviewed By: bgamari
Subscribers: rwbarton, thomie, carter
Differential Revision: https://phabricator.haskell.org/D4277
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Test Plan: validate
Reviewers: bgamari, niteria, erikd, dfeuer
Reviewed By: dfeuer
Subscribers: Yuras, dfeuer, rwbarton, thomie, carter
GHC Trac Issues: #14497
Differential Revision: https://phabricator.haskell.org/D4254
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This was presumably a vestige of the days when the profiled RTS couldn't
run threaded. Fixes #14545.
Test Plan: simonmar
Reviewers: erikd, simonmar
Reviewed By: simonmar
Subscribers: rwbarton, thomie, carter
GHC Trac Issues: #14545
Differential Revision: https://phabricator.haskell.org/D4245
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The failure is visible when we build a cross-compiler
from linux to mingw32 as:
```
$ ./configure --host=x86_64-pc-linux-gnu \
--target=x86_64-w64-mingw32
$ make
rts/linker/PEi386.c:159:10: error:
fatal error: Psapi.h: No such file or directory
#include <Psapi.h>
^~~~~~~~~
|
159 | #include <Psapi.h>
| ^
```
The problem here is case-sensitive linux filesystem. On windows
it does not matter what case is used for includes and libraries.
mingw32 provides all libraries and headers lowercase. This change
fixes case for <dbghelp.h>, <psapi.h>, -ldbghelp, -lpsapi.
Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>
Reviewers: bgamari, erikd, simonmar
Reviewed By: bgamari
Subscribers: rwbarton, thomie, carter
Differential Revision: https://phabricator.haskell.org/D4247
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: erikd, simonmar, hvr
Reviewed By: hvr
Subscribers: hvr, rwbarton, thomie
Differential Revision: https://phabricator.haskell.org/D4238
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On 64-bit UNIX and Windows, Haskell `Int` has 64 bits
but C `int msecs` has 32 bits, resulting in an overflow.
This commit fixes it by switching fdReady() to take int64_t,
into which a Haskell `Int` will always fit.
(Note we could not switch to `long long` because that is
32 bit on 64-bit Windows machines.)
Further, to be able to actually wait longer than ~49 days,
we put loops around the waiting syscalls (they all accept only
32-bit integers).
Note the timer signal would typically interrupt the syscalls
before the ~49 days are over, but you can run Haskell programs
without the timer signal, an we want it to be correct in all
cases.
Reviewers: bgamari, austin, hvr, NicolasT, Phyx
Reviewed By: bgamari, Phyx
Subscribers: syd, Phyx, rwbarton, thomie
GHC Trac Issues: #14262
Differential Revision: https://phabricator.haskell.org/D4011
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Test Plan: ./validate
Reviewers: bgamari, erikd, simonmar
Reviewed By: bgamari
Subscribers: rwbarton, thomie
GHC Trac Issues: #14513
Differential Revision: https://phabricator.haskell.org/D4226
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
mut_elapsed should deduct retainer profiling and heap censuses, just as
mut_cpu does.
mutator_cpu_ns should not deduct retainer profiling or heap censuses,
since those times are included in stats.gc_cpu_ns.
Reviewers: bgamari, erikd, simonmar
Reviewed By: simonmar
Subscribers: rwbarton, thomie
Differential Revision: https://phabricator.haskell.org/D4185
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: erikd, simonmar
Reviewed By: simonmar
Subscribers: rwbarton, thomie
Differential Revision: https://phabricator.haskell.org/D4194
|
|
|
|
|
|
|
|
|
|
| |
Overlap with commit 2f463873, resulted in `hooks/LongGCSync.c`
missing from the `rts.cabal.in` file. As the `rts.cabal` file is only
used by hadrian, this did not trigger with the make base build
system which can do globbing.
Also ignore the `rts.cabal` file, as it's generated by configure
from the `rts.cabal.in`.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
GC sync is the time between a GC being intiated and all the mutator
threads finally stopping so that the GC can start. Problems that cause
the GC sync to be delayed are hard to find and can cause dramatic
slowdowns for heavily parallel programs.
The new flag --long-gc-sync=<time> helps by emitting a warning and
calling a user-overridable hook when the GC sync time exceeds the
specified threshold. A debugger can be used to set a breakpoint when
this happens and inspect the stacks of threads to find the culprit.
Test Plan:
```
$ ./inplace/bin/ghc-stage2 +RTS --long-gc-sync=0.0000001 -S
Alloc Copied Live GC GC TOT TOT Page Flts
bytes bytes bytes user elap user elap
1135856 51144 153736 0.000 0.000 0.002 0.002 0 0 (Gen: 0)
1034760 94704 188752 0.000 0.000 0.002 0.002 0 0 (Gen: 0)
1038888 134832 228888 0.009 0.009 0.011 0.011 0 0 (Gen: 1)
1025288 90128 235184 0.000 0.000 0.012 0.012 0 0 (Gen: 0)
1049088 130080 333984 0.000 0.000 0.013 0.013 0 0 (Gen: 0)
Warning: waited 0us for GC sync
1034424 73360 331976 0.000 0.000 0.013 0.013 0 0 (Gen: 0)
```
Also tested on a real production problem.
Reviewers: niteria, bgamari, erikd
Subscribers: rwbarton, thomie
Differential Revision: https://phabricator.haskell.org/D4193
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We were accumulating the gc times of the previous gc.
`stats.gc.{cpu,elappsed}_ns` were being accumulated into
`stats.gc_{cpu,elapsed}_ns` before they were set.
There is also a change in that heap profiling will no longer cause gc
events to
be emitted.
Reviewers: bgamari, erikd, simonmar
Reviewed By: bgamari
Subscribers: rwbarton, thomie
GHC Trac Issues: #14257, #14445
Differential Revision: https://phabricator.haskell.org/D4184
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The update of GHC's in-tree libffi causes warnings about
undefined macros and hence validate fails.
Also mark broken tests that have a ticket.
Fixes #14353
Test Plan: ./validate (on AIX and powerpc if possible)
Reviewers: bgamari, hvr, erikd, simonmar
Reviewed By: bgamari
Subscribers: snowleopard, rwbarton, thomie
GHC Trac Issues: #14353, #11259, #14455, #11261
Differential Revision: https://phabricator.haskell.org/D4181
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is in preparation for cabalification of the `rts`. To be actually
able to parse this file, a rather recent Cabal is required. One after
commit 357d49d of haskell/cabal. The relevant PR to support the new
`asm-sources` and `cmm-sources` is haskell/cabal/pull/4857.
Not that this does *not* allow cabal to build the RTS. It does however
provide enough information such that cabal can `copy` and `register`
the package properly in the package database, if all the build
artifacts have been build properly.
As such it does not require any custom handling of the `rts` package.
As the rts as well as all the other packages built by the GHC built
system are built outside of cabal anyway.
Reviewers: bgamari, hvr, erikd, simonmar
Reviewed By: bgamari
Subscribers: rwbarton, thomie, erikd
Differential Revision: https://phabricator.haskell.org/D4174
|
|
|
|
|
|
|
| |
These removes left-overs from e3ba26f8b49700b41ff4672f3f7f6a4e453acdcc
where I implemented `compareByteArray#` as an out-of-line primop, which
got optimised into an inline primop shortly afterwards
(as per 7673561555ae354fd9eed8de1e57c681906e2d49).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixing #14244 required the newer gcc atomic built-ins that are provided
from 4.7 and up. This updates the test to check for minimum gcc version
4.7.
The version tests for 3.4 (!), 4.4, and 4.6 are no longer needed and can
be removed. This makes the build system simpler.
Test Plan: validate
Reviewers: austin, bgamari, hvr, simonmar
Reviewed By: bgamari
Subscribers: rwbarton, thomie, erikd
Differential Revision: https://phabricator.haskell.org/D4165
|