summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* Add regression test for #10504wip/T10504Ryan Scott2020-11-094-0/+15
| | | | | | | This issue was fixed at some point between GHC 8.0 and 8.2. Let's add a regression test to ensure that it stays fixed. Fixes #10504.
* Fix haddock submoduleBen Gamari2020-11-081-0/+0
| | | | The previous merge mistakenly reverted it.
* Merge remote-tracking branch 'origin/wip/tsan/all'Ben Gamari2020-11-0870-790/+1325
|\
| * Merge branch 'wip/tsan/stats' into wip/tsan/allBen Gamari2020-11-014-27/+62
| |\
| | * rts: Tear down stats_mutex after exitHeapProfilingwip/tsan/statsBen Gamari2020-11-014-5/+14
| | | | | | | | | | | | Since the latter wants to call getRTSStats.
| | * rts/Stats: Protect with mutexBen Gamari2020-11-011-3/+55
| | | | | | | | | | | | | | | While on face value this seems a bit heavy, I think it's far better than enforcing ordering on every access.
| | * rts/Stats: Hide a few unused unnecessarily global functionsBen Gamari2020-10-242-22/+0
| | |
| * | Merge branch 'wip/tsan/timer' into wip/tsan/allBen Gamari2020-11-017-34/+65
| |\ \
| | * | rts: Fix races in Pthread timer backend shudownwip/tsan/timerBen Gamari2020-10-241-8/+11
| | | | | | | | | | | | | | | | | | | | We can generally be pretty relaxed in the barriers here since the timer thread is a loop.
| | * | rts: Fix timer initializationBen Gamari2020-10-241-1/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously `initScheduler` would attempt to pause the ticker and in so doing acquire the ticker mutex. However, initTicker, which is responsible for initializing said mutex, hadn't been called yet.
| | * | suppress #17289 (ticker) raceBen Gamari2020-10-241-0/+4
| | | |
| | * | Fix #17289Ben Gamari2020-10-242-11/+19
| | | |
| | * | rts: Pause timer while changing capability countBen Gamari2020-10-242-11/+21
| | | | | | | | | | | | | | | | This avoids #17289.
| | * | rts: Accept benign races in ProftimerBen Gamari2020-10-241-5/+5
| | |/
| * | Merge branch 'wip/tsan/event-mgr' into wip/tsan/allBen Gamari2020-11-014-21/+34
| |\ \
| | * | Suppress data race due to closeBen Gamari2020-11-011-0/+1
| | | | | | | | | | | | | | | | This suppresses the other side of a race during shutdown.
| | * | Mitigate data races in event manager startup/shutdownwip/tsan/event-mgrBen Gamari2020-10-243-21/+33
| | |/
| * | Merge branch 'wip/tsan/stm' into wip/tsan/allBen Gamari2020-11-012-40/+58
| |\ \
| | * | rts/stm: Strengthen orderings to SEQ_CST instead of volatilewip/tsan/stmBen Gamari2020-10-242-23/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously the `current_value`, `first_watch_queue_entry`, and `num_updates` fields of `StgTVar` were marked as `volatile` in an attempt to provide strong ordering. Of course, this isn't sufficient. We now use proper atomic operations. In most of these cases I strengthen the ordering all the way to SEQ_CST although it's possible that some could be weakened with some thought.
| | * | rts/STM: Use atomicsBen Gamari2020-10-241-27/+45
| | |/ | | | | | | | | | | | | | | | | | | | | | This fixes a potentially harmful race where we failed to synchronize before looking at a TVar's current_value. Also did a bit of refactoring to avoid abstract over management of max_commits.
| * | Merge branch 'wip/tsan/misc' into wip/tsan/allBen Gamari2020-11-014-6/+10
| |\ \
| | * | rts: Use proper relaxe operations in getCurrentThreadCPUTimewip/tsan/miscGHC GitLab CI2020-10-241-2/+4
| | | | | | | | | | | | | | | | | | | | Here we are doing lazy initialization; it's okay if we do the check more than once, hence relaxed operation is fine.
| | * | rts: Avoid lock order inversion during forkBen Gamari2020-10-241-1/+3
| | | | | | | | | | | | | | | | Fixes #17275.
| | * | rts: Use relaxed atomics for whitehole spin statsBen Gamari2020-10-242-3/+3
| | |/
| * | Merge branch 'wip/tsan/wsdeque' into wip/tsan/allBen Gamari2020-11-014-174/+111
| |\ \
| | * | rts/WSDeque: Rewrite with proper atomicswip/tsan/wsdequeBen Gamari2020-10-244-174/+111
| | |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | After a few attempts at shoring up the previous implementation, I ended up turning to the literature and now use the proven implementation, > N.M. Lê, A. Pop, A.Cohen, and F.Z. Nardelli. "Correct and Efficient > Work-Stealing for Weak Memory Models". PPoPP'13, February 2013, > ACM 978-1-4503-1922/13/02. Note only is this approach formally proven correct under C11 semantics but it is also proved to be a bit faster in practice.
| * | Merge branch 'wip/tsan/storage' into wip/tsan/allBen Gamari2020-11-0127-282/+431
| |\ \
| | * | Strengthen ordering in releaseGCThreadsBen Gamari2020-11-011-2/+2
| | | |
| | * | rts: Annotate hopefully "benign" races in freeGroupBen Gamari2020-11-011-0/+25
| | | |
| | * | rts: Use relaxed ordering on spinlock counterswip/tsan/storageBen Gamari2020-10-302-2/+4
| | | |
| | * | rts/SpinLock: Separate out slow pathBen Gamari2020-10-303-10/+47
| | | | | | | | | | | | | | | | | | | | | | | | Not only is this in general a good idea, but it turns out that GCC unrolls the retry loop, resulting is massive code bloat in critical parts of the RTS (e.g. `evacuate`).
| | * | rts: Fix race in GC CPU time accountingGHC GitLab CI2020-10-301-3/+6
| | | | | | | | | | | | | | | | | | | | Ensure that the GC leader synchronizes with workers before calling stat_endGC.
| | * | rts: Join to concurrent mark thread during shutdownBen Gamari2020-10-304-1/+20
| | | | | | | | | | | | | | | | | | | | Previously we would take all capabilities but fail to join on the thread itself, potentially resulting in a leaked thread.
| | * | rts/Storage: Accept races on heap size countersBen Gamari2020-10-301-5/+8
| | | |
| | * | rts: Use RELEASE ordering in unlockClosureBen Gamari2020-10-301-3/+2
| | | |
| | * | rts/GC: Use atomicsBen Gamari2020-10-3011-175/+192
| | | |
| | * | rts/Weak: Eliminate data racesBen Gamari2020-10-242-18/+14
| | | | | | | | | | | | | | | | | | | | By taking all_tasks_mutex in stat_exit. Also better-document the fact that the task statistics are protected by all_tasks_mutex.
| | * | rts/Updates: Use proper atomic operationsBen Gamari2020-10-241-4/+2
| | | |
| | * | rts/Storage: Use atomicsBen Gamari2020-10-241-18/+17
| | | |
| | * | rts: Avoid data races in StablePtr implementationBen Gamari2020-10-242-5/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This fixes two potentially problematic data races in the StablePtr implementation: * We would fail to RELEASE the stable pointer table when enlarging it, causing other cores to potentially see uninitialized memory. * We would fail to ACQUIRE when dereferencing a stable pointer.
| | * | rts: Rework handling of mutlist scavenging statisticsBen Gamari2020-10-243-37/+83
| | | |
| | * | rts/BlockAlloc: Use relaxed operationsBen Gamari2020-10-241-6/+7
| | |/
| * | Merge branch 'wip/tsan/ci' into wip/tsan/allBen Gamari2020-11-0110-6/+55
| |\ \
| | * | testsuite: Mark T13702 as broken with TSAN due to #18884wip/tsan/ciBen Gamari2020-10-241-1/+4
| | | |
| | * | testsuite: Mark T3807 as broken with TSANBen Gamari2020-10-241-2/+5
| | | | | | | | | | | | | | | | Due to #18883.
| | * | TSANUtils: Ensure that C11 atomics are supportedBen Gamari2020-10-241-0/+4
| | | |
| | * | gitlab-ci: Disable documentation in TSAN buildBen Gamari2020-10-241-0/+3
| | | | | | | | | | | | | | | | | | | | Haddock chews through enough memory to cause the CI builders to OOM and there's frankly no reason to build documentation in this job anyways.
| | * | testsuite: Mark T9872[abc] as high_memory_usageBen Gamari2020-10-241-3/+6
| | | | | | | | | | | | | | | | These all have a maximum residency of over 2 GB.
| | * | testsuite: Mark hie002 as high_memory_usageBen Gamari2020-10-241-0/+1
| | | | | | | | | | | | | | | | | | | | This test has a peak residency of 1GByte; this is large enough to classify as "high" in my book.
| | * | testsuite: Skip high memory usage tests with TSANBen Gamari2020-10-241-0/+4
| | | | | | | | | | | | | | | | | | | | ThreadSanitizer significantly increases the memory footprint of tests, so much so that it can send machines into OOM.
View Lorry Controller Status