summaryrefslogtreecommitdiff
path: root/rts
Commit message (Collapse)AuthorAgeFilesLines
* Drop mk/{build,install,config}.mk.inBen Gamari2022-08-251-7/+3
|
* Drop make build systemBen Gamari2022-08-252-987/+0
| | | | | | | | | | | Here we at long last remove the `make`-based build system, it having been replaced with the Shake-based Hadrian build system. Users are encouraged to refer to the documentation in `hadrian/doc` and this [1] blog post for details on using Hadrian. Closes #17527. [1] https://www.haskell.org/ghc/blog/20220805-make-to-hadrian.html
* rts: Consistently use MiB in stats outputBen Gamari2022-08-241-1/+1
| | | | Previously we would say `MB` even where we meant `MiB`.
* compiler: Drop --build-id=none hackBen Gamari2022-08-181-1/+0
| | | | | | | | | Since 2011 the object-joining implementation has had a hack to pass `--build-id=none` to `ld` when supported, seemingly to work around a linker bug. This hack is now unnecessary and may break downstream users who expect objects to have valid build-ids. Remove it. Closes #22060.
* typoEric Lindblad2022-08-161-2/+2
|
* rts/linker: Resolve iconv_* on FreeBSDBen Gamari2022-08-091-9/+50
| | | | | | | | | | FreeBSD's libiconv includes an implementation of the iconv_* functions in libc. Unfortunately these can only be resolved using dlvsym, which is how the RTS linker usually resolves such functions. To fix this we include an ad-hoc special case for iconv_*. Fixes #20354.
* rts: Ensure that Array# card arrays are initializedBen Gamari2022-08-082-1/+7
| | | | | | | | | | | | In #19143 I noticed that newArray# failed to initialize the card table of newly-allocated arrays. However, embarrassingly, I then only fixed the issue in newArrayArray# and, in so doing, introduced the potential for an integer underflow on zero-length arrays (#21962). Here I fix the issue in newArray#, this time ensuring that we do not underflow in pathological cases. Fixes #19143.
* rts: remove redundant stg_traceCcszhCheng Shao2022-08-083-17/+0
| | | | | | This out-of-line primop has no Haskell wrapper and hasn't been used anywhere in the tree. Furthermore, the code gets in the way of !7632, so it should be garbage collected.
* Add a primop to query the label of a threadBen Gamari2022-08-063-0/+13
|
* rts: Move thread labels into TSOBen Gamari2022-08-0620-140/+117
| | | | | | | This eliminates the thread label HashTable and instead tracks this information in the TSO, allowing us to use proper StgArrBytes arrays for backing the label and greatly simplifying management of object lifetimes when we expose them to the user with the coming `threadLabel#` primop.
* Add primop to list threadsBen Gamari2022-08-067-3/+55
| | | | | | | A user came to #ghc yesterday wondering how best to check whether they were leaking threads. We ended up using the eventlog but it seems to me like it would be generally useful if Haskell programs could query their own threads.
* rts: Fix code styleBen Gamari2022-08-061-14/+14
|
* Add one more sanity check in stg_restore_cccsAndreas Klebinger2022-08-061-0/+4
|
* Improve BUILD_PAP commentsAndreas Klebinger2022-08-061-0/+3
|
* rts/nonmoving: Don't scavenge objects which weren't evacuatedBen Gamari2022-07-253-5/+93
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This fixes a rather subtle bug in the logic responsible for scavenging objects evacuated to the non-moving generation. In particular, objects can be allocated into the non-moving generation by two ways: a. evacuation out of from-space by the garbage collector b. direct allocation by the mutator Like all evacuation, objects moved by (a) must be scavenged, since they may contain references to other objects located in from-space. To accomplish this we have the following scheme: * each nonmoving segment's block descriptor has a scan pointer which points to the first object which has yet to be scavenged * the GC tracks a set of "todo" segments which have pending scavenging work * to scavenge a segment, we scavenge each of the unmarked blocks between the scan pointer and segment's `next_free` pointer. We skip marked blocks since we know the allocator wouldn't have allocated into marked blocks (since they contain presumably live data). We can stop at `next_free` since, by definition, the GC could not have evacuated any objects to blocks above `next_free` (otherwise `next_free wouldn't be the first free block). However, this neglected to consider objects allocated by path (b). In short, the problem is that objects directly allocated by the mutator may become unreachable (but not swept, since the containing segment is not yet full), at which point they may contain references to swept objects. Specifically, we observed this in #21885 in the following way: 1. the mutator (specifically in #21885, a `lockCAF`) allocates an object (specifically a blackhole, which here we will call `blkh`; see Note [Static objects under the nonmoving collector] for the reason why) on the non-moving heap. The bitmap of the allocated block remains 0 (since allocation doesn't affect the bitmap) and the containing segment's (which we will call `blkh_seg`) `next_free` is advanced. 2. We enter the blackhole, evaluating the blackhole to produce a result (specificaly a cons cell) in the nursery 3. The blackhole gets updated into an indirection pointing to the cons cell; it is pushed to the generational remembered set 4. we perform a GC, the cons cell is evacuated into the nonmoving heap (into segment `cons_seg`) 5. the cons cell is marked 6. the GC concludes 7. the CAF and blackhole become unreachable 8. `cons_seg` is filled 9. we start another GC; the cons cell is swept 10. we start a new GC 11. something is evacuated into `blkh_seg`, adding it to the "todo" list 12. we attempt to scavenge `blkh_seg` (namely, all unmarked blocks between `scan` and `next_free`, which includes `blkh`). We attempt to evacuate `blkh`'s indirectee, which is the previously-swept cons cell. This is unsafe, since the indirectee is no longer a valid heap object. The problem here was that the scavenging logic *assumed* that (a) was the only source of allocations into the non-moving heap and therefore *all* unmarked blocks between `scan` and `next_free` were evacuated. However, due to (b) this is not true. The solution is to ensure that that the scanned region only encompasses the region of objects allocated during evacuation. We do this by updating `scan` as we push the segment to the todo-segment list to point to the block which was evacuated into. Doing this required changing the nonmoving scavenging implementation's update of the `scan` pointer to bump it *once*, instead of after scavenging each block as was done previously. This is because we may end up evacuating into the segment being scavenged as we scavenge it. This was quite tricky to discover but the result is quite simple, demonstrating yet again that global mutable state should be used exceedingly sparingly. Fixes #21885 (cherry picked from commit 0b27ea23efcb08639309293faf13fdfef03f1060)
* rts/nonmoving: Track segment stateBen Gamari2022-07-252-1/+28
| | | | | | | | It can often be useful during debugging to be able to determine the state of a nonmoving segment. Introduce some state, enabled by DEBUG, to track this. (cherry picked from commit 40e797ef591ae3122ccc98ab0cc3cfcf9d17bd7f)
* rts/ProfHeap: Ensure new Censuses are zeroedBen Gamari2022-07-191-0/+1
| | | | | | | | When growing the Census array ProfHeap previously neglected to zero the new part of the array. Consequently `freeEra` would attempt to free random words that often looked suspiciously like pointers. Fixes #21880.
* Allow running memInventory when the concurrent nonmoving gc is enabledTeo Camarasu2022-07-182-5/+14
| | | | | | | | If the nonmoving gc is enabled and we are using a threaded RTS, we now try to grab the collector mutex to avoid memInventory and the collection racing. Before memInventory was disabled.
* rts/linker: Ensure that __cxa_finalize is called on code unloadBen Gamari2022-07-162-0/+25
|
* rts/linker: Clean up section kindsBen Gamari2022-07-161-2/+5
|
* rts/linker: Fix resolution of __dso_handle on DarwinBen Gamari2022-07-161-1/+1
| | | | Darwin expects a leading underscore.
* rts/linker/Elf: Work around GCC 6 init/fini behaviorBen Gamari2022-07-161-3/+19
| | | | | | | It appears that GCC 6t (at least on i386) fails to give init_array/fini_array sections the correct SHT_INIT_ARRAY/SHT_FINI_ARRAY section types, instead marking them as SHT_PROGBITS. This caused T20494 to fail on Debian.
* rts/linker/MachO: Introduce finalizer supportBen Gamari2022-07-163-0/+32
|
* rts/linker/MachO: Use section flags to identify initializersBen Gamari2022-07-161-20/+11
|
* rts/linker/MachO: Drop dead codeBen Gamari2022-07-161-1/+0
|
* rts/linker/PEi386: Fix exception unwind unregistrationBen Gamari2022-07-161-8/+9
| | | | | | | RtlDeleteFunctionTable expects a pointer to the .pdata section yet we passed it the .xdata section. Happily, this fixes #21354.
* rts/linker/PEi386: Respect dtor/ctor priorityBen Gamari2022-07-162-2/+45
| | | | | | | Previously we would run constructors and destructors in arbitrary order despite explicit priorities. Fixes #21847.
* rts/linker/PEi386: Ensure that all .ctors/.dtors sections are runBen Gamari2022-07-162-21/+63
| | | | | | | | It turns out that PE objects may have multiple `.ctors`/`.dtors` sections but the RTS linker had assumed that there was only one. Fix this. Fixes #21618.
* rts/linker/PEi386: Add finalization supportBen Gamari2022-07-163-1/+49
| | | | | | This implements #20494 for the PEi386 linker. Happily, this also appears to fix `T9405`, resolving #21361.
* rts/linker/PEi386: Refactor handling of oc->infoBen Gamari2022-07-162-4/+10
| | | | | | | | | | | Previously we would free oc->info after running initializers. However, we can't do this is we want to also run finalizers. Moreover, freeing oc->info so early was wrong for another reason: we will need it in order to unregister the exception tables (see the call to `RtlDeleteFunctionTable`). In service of #20494.
* rts/linker/PEi386: Rename finit field to finiBen Gamari2022-07-163-5/+5
| | | | fini is short for "finalizer", which does not contain a "t".
* rts/linker/Elf: Introduce support for invoking finalizers on unloadBen Gamari2022-07-164-3/+90
| | | | Addresses #20494.
* rts/linker/Elf: Check that there are no NULL ctorsBen Gamari2022-07-161-0/+1
|
* rts: forkOn context switches the target capabilityDouglas Wilson2022-07-164-8/+14
| | | | Fixes #21824
* Make keepAlive# out-of-lineBen Gamari2022-07-164-0/+29
| | | | | | | | | | | | | | This is a naive approach to fixing the unsoundness noticed in #21708. Specifically, we remove the lowering of `keepAlive#` via CorePrep and instead turn it into an out-of-line primop. This is simple, inefficient (since the continuation must now be heap allocated), but good enough for 9.4.1. We will revisit this (particiularly via #16098) in a future release. Metric Increase: T4978 T7257 T9203
* rts: Fix AdjustorPool bitmap manipulationBen Gamari2022-07-131-14/+14
| | | | | | | | | | | | | | Previously the implementation of bitmap_first_unset assumed that `__builtin_clz` would accept `uint8_t` however it apparently rather extends its argument to `unsigned int`. To fix this we simply revert to a naive implementation since handling the various corner cases with `clz` is quite tricky. This should be fine given that AdjustorPool isn't particularly hot. Ideally we would have a single, optimised bitmap implementation in the RTS but I'll leave this for future work. Fixes #21838.
* RTS: Add stack marker to StgCRunAsm.SAndreas Schwab2022-07-071-6/+5
| | | | | Every object file must be properly marked for non-executable stack, even if it contains no code.
* rts: allow NULL to be used as an invalid StgStablePtrAdam Sandberg Ericsson2022-07-075-6/+39
|
* Remove a bogus #define from ClosureMacros.hAndreas Klebinger2022-07-061-1/+0
|
* Ticky:Make json info a separate field.Andreas Klebinger2022-07-043-2/+5
| | | | Fixes #21233
* rts: gc stats: account properly for copied bytes in sequential collectionsDouglas Wilson2022-07-011-0/+7
| | | | | | | | | | | We were not updating the [copied,any_work,scav_find_work, max_n_todo_overflow] counters during sequential collections. As well, we were double counting for parallel collections. To fix this we add an `else` clause to the `if (is_par_gc())`. The par_* counters do not need to be updated in the sequential case because they must be 0.
* eventlog: Don't leave dangling pointers hanging aroundBen Gamari2022-06-221-0/+2
| | | | | | | Previously we failed to reset pointers to various eventlog buffers to NULL after freeing them. In principle we shouldn't look at them after they are freed but nevertheless it is good practice to set them to a well-defined value.
* Transcribe discussion from #21483 into a NoteMatthew Pickering2022-06-221-0/+78
| | | | | | | | | In #21483 I had a discussion with Simon Marlow about the memory retention behaviour of -Fd. I have just transcribed that conversation here as it elucidates the potentially subtle assumptions which led to the design of the memory retention behaviours of -Fd. Fixes #21483
* Revert "Ticky:Make json info a separate field."Matthew Pickering2022-06-222-3/+1
| | | | | | This reverts commit da5ff10503e683e2148c62e36f8fe2f819328862. This was pushed directly without review.
* Ticky:Make json info a separate field.Andreas Klebinger2022-06-212-1/+3
|
* linker: only keep rtl exception tables if they have been relocatedTamar Christina2022-06-201-5/+6
|
* ghc-heap: Don't Box NULL pointersBen Gamari2022-06-181-6/+11
| | | | | | | | | Previously we could construct a `Box` of a NULL pointer from the `link` field of `StgWeak`. Now we take care to avoid ever introducing such pointers in `collect_pointers` and ensure that the `link` field is represented as a `Maybe` in the `Closure` type. Fixes #21622
* getProcessCPUTime: Fix the getrusage fallback to account for system CPU timeMatthew Pickering2022-06-091-1/+2
| | | | | | | | | | | | | | | | | | | | | | | clock_gettime reports the combined total or user AND system time so in order to replicate it with getrusage we need to add both system and user time together. See https://stackoverflow.com/questions/7622371/getrusage-vs-clock-gettime Some sample measurements when building Cabal with this patch t1: rusage t2: clock_gettime t1: 62347518000; t2: 62347520873 t1: 62395687000; t2: 62395690171 t1: 62432435000; t2: 62432437313 t1: 62478489000; t2: 62478492465 t1: 62514990000; t2: 62514992534 t1: 62515479000; t2: 62515480327 t1: 62515485000; t2: 62515486344 Fixes #21656
* Split out `GHC.HsToCore.{Breakpoints,Coverage}` and use `SizedSeq`John Ericson2022-06-021-1/+1
| | | | | | | | | | | | | | | | | | | As proposed in https://gitlab.haskell.org/ghc/ghc/-/merge_requests/7508#note_432877 and https://gitlab.haskell.org/ghc/ghc/-/merge_requests/7508#note_434676, `GHC.HsToCore.Ticks` is about ticks, breakpoints are separate and backend-specific (only for the bytecode interpreter), and mix entry writing is just for HPC. With this split we separate out those interpreter- and HPC-specific its, and keep the main `GHC.HsToCore.Ticks` agnostic. Also, instead of passing the reversed list and count around, we use `SizedSeq` which abstracts over the algorithm. This is much nicer to avoid noise and prevents bugs. (The bugs are not just hypothetical! I missed up the reverses on an earlier draft of this commit.)
* Rename `HsToCore.{Coverage -> Ticks}`John Ericson2022-06-021-1/+1
| | | | | | The old name made it confusing why disabling HPC didn't disable the entire pass. The name makes it clear --- there are other reasons to add ticks in addition.
View Lorry Controller Status