summaryrefslogtreecommitdiffstats
path: root/compiler-rt/lib/tsan/rtl/tsan_clock.h
Commit message (Collapse)AuthorAgeFilesLines
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-191-4/+3
| | | | | | | | | | | | | | | | | to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
* tsan: optimize sync clock memory consumptionDmitry Vyukov2017-07-141-56/+151
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This change implements 2 optimizations of sync clocks that reduce memory consumption: Use previously unused first level block space to store clock elements. Currently a clock for 100 threads consumes 3 512-byte blocks: 2 64-bit second level blocks to store clock elements +1 32-bit first level block to store indices to second level blocks Only 8 bytes of the first level block are actually used. With this change such clock consumes only 2 blocks. Share similar clocks differing only by a single clock entry for the current thread. When a thread does several release operations on fresh sync objects without intervening acquire operations in between (e.g. initialization of several fields in ctor), the resulting clocks differ only by a single entry for the current thread. This change reuses a single clock for such release operations. The current thread time (which is different for different clocks) is stored in dirty entries. We are experiencing issues with a large program that eats all 64M clock blocks (32GB of non-flushable memory) and crashes with dense allocator overflow. Max number of threads in the program is ~170 which is currently quite unfortunate (consume 4 blocks per clock). Currently it crashes after consuming 60+ GB of memory. The first optimization brings clock block consumption down to ~40M and allows the program to work. The second optimization further reduces block consumption to "modest" 16M blocks (~8GB of RAM) and reduces overall RAM consumption to ~30GB. Measurements on another real world C++ RPC benchmark show RSS reduction from 3.491G to 3.186G and a modest speedup of ~5%. Go parallel client/server HTTP benchmark: https://github.com/golang/benchmarks/blob/master/http/http.go shows RSS reduction from 320MB to 240MB and a few percent speedup. Reviewed in https://reviews.llvm.org/D35323 llvm-svn: 308018
* tsan: refactor SyncClock codeDmitry Vyukov2017-07-121-0/+1
| | | | | | | | | 1. Add SyncClock::ResetImpl which removes code duplication between ctor and Reset. 2. Move SyncClock::Resize to SyncClock methods, currently it's defined between ThreadClock methods. llvm-svn: 307785
* tsan: prepare clock for future changesDmitry Vyukov2017-07-121-1/+2
| | | | | | | Pass ClockCache to ThreadClock::set and introduce ThreadCache::ResetCached. For now both are unused, but will reduce future diffs. llvm-svn: 307784
* Revert "Apply modernize-use-default to compiler-rt."Alexey Samsonov2015-10-301-1/+2
| | | | | | | | | | | | This reverts commit r250823. Replacing at least some of empty constructors with "= default" variants is a semantical change which we don't want. E.g. __tsan::ClockBlock contains a union of large arrays, and it's critical for correctness and performance that we don't memset() these arrays in the constructor. llvm-svn: 251717
* Apply modernize-use-default to compiler-rt.Angel Garcia Gomez2015-10-201-2/+1
| | | | | | | | | | | | Summary: Replace empty bodies of default constructors and destructors with '= default'. Reviewers: klimek, bkramer Subscribers: alexfh, cfe-commits Differential Revision: http://reviews.llvm.org/D13892 llvm-svn: 250823
* tsan: address comments in r214912Dmitry Vyukov2014-09-021-1/+1
| | | | | | See http://reviews.llvm.org/D4794 llvm-svn: 216900
* tsan: allocate vector clocks using slab allocatorDmitry Vyukov2014-08-051-13/+41
| | | | | | | | | | Vector clocks is the most actively allocated object in tsan runtime. Current internal allocator is not scalable enough to handle allocation of clocks in scalable way (too small caches). This changes transforms clocks to 2-level array with 512-byte blocks. Since all blocks are of the same size, it's possible to cache them more efficiently in per-thread caches. llvm-svn: 214912
* tsan: refactor storage of meta information for heap blocks and sync objectsDmitry Vyukov2014-05-291-0/+1
| | | | | | | | | | | | | | | The new storage (MetaMap) is based on direct shadow (instead of a hashmap + per-block lists). This solves a number of problems: - eliminates quadratic behaviour in SyncTab::GetAndLock (https://code.google.com/p/thread-sanitizer/issues/detail?id=26) - eliminates contention in SyncTab - eliminates contention in internal allocator during allocation of sync objects - removes a bunch of ad-hoc code in java interface - reduces java shadow from 2x to 1/2x - allows to memorize heap block meta info for Java and Go - allows to cleanup sync object meta info for Go - which in turn enabled deadlock detector for Go llvm-svn: 209810
* tsan: fix vector clocksDmitry Vyukov2014-04-111-11/+15
| | | | | | | the new optimizations break when thread ids gets reused (clocks go backwards) add the necessary tests as well llvm-svn: 206035
* tsan: optimize vector clock operationsDmitry Vyukov2014-03-241-15/+31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Make vector clock operations O(1) for several important classes of use cases. See comments for details. Below are stats from a large server app, 77% of all clock operations are handled as O(1). Clock acquire : 25983645 empty clock : 6288080 fast from release-store : 14917504 contains my tid : 4515743 repeated (fast) : 2141428 full (slow) : 2636633 acquired something : 1426863 Clock release : 2544216 resize : 6241 fast1 : 197693 fast2 : 1016293 fast3 : 2007 full (slow) : 1797488 was acquired : 709227 clear tail : 1 last overflow : 0 Clock release store : 3446946 resize : 200516 fast : 469265 slow : 2977681 clear tail : 0 Clock acquire-release : 820028 llvm-svn: 204656
* tsan: more precise handling of finalizersDmitry Vyukov2012-11-071-4/+1
| | | | llvm-svn: 167530
* tsan: don't release disabled clocksDmitry Vyukov2012-11-061-1/+2
| | | | llvm-svn: 167451
* tsan: add ReleaseStore() function that merely copies vector clock rather ↵Dmitry Vyukov2012-07-281-1/+2
| | | | | | | | than combines two clocks fix clock setup for finalizer goroutine (Go runtime) llvm-svn: 160918
* tsan: suport for Go finalizersDmitry Vyukov2012-07-251-0/+2
| | | | llvm-svn: 160723
* tsan: add shadow memory flush + fix few bugsDmitry Vyukov2012-05-221-4/+4
| | | | llvm-svn: 157270
* tsan: detect accesses to freed memoryDmitry Vyukov2012-05-171-2/+2
| | | | | | http://codereview.appspot.com/6214052 llvm-svn: 156990
* [tsan] run more kinds of builds as presubmit test (and fix gcc debug build)Kostya Serebryany2012-05-111-5/+5
| | | | llvm-svn: 156616
* [tsan] First commit of ThreadSanitizer (TSan) run-time library.Kostya Serebryany2012-05-101-0/+79
Algorithm description: http://code.google.com/p/thread-sanitizer/wiki/ThreadSanitizerAlgorithm Status: The tool is known to work on large real-life applications, but still has quite a few rough edges. Nothing is guaranteed yet. The tool works on x86_64 Linux. Support for 64-bit MacOS 10.7+ is planned for late 2012. Support for 32-bit OSes is doable, but problematic and not yet planed. Further commits coming: - tests - makefiles - documentation - clang driver patch The code was previously developed at http://code.google.com/p/data-race-test/source/browse/trunk/v2/ by Dmitry Vyukov and Kostya Serebryany with contributions from Timur Iskhodzhanov, Alexander Potapenko, Alexey Samsonov and Evgeniy Stepanov. llvm-svn: 156542
OpenPOWER on IntegriCloud