summaryrefslogtreecommitdiff
path: root/rts/RtsSymbols.c
Commit message (Collapse)AuthorAgeFilesLines
* Documentation and refactoring in CCS related codeÖmer Sinan Ağacan2019-01-121-3/+0
| | | | | | | | | - Remove REGISTER_CC and REGISTER_CCS macros, add functions registerCC and registerCCS to Profiling.c. - Reduce scope of symbols: CC_LIST, CCS_LIST, CC_ID, CCS_ID - Document CC_LIST and CCS_LIST
* PPC NCG: Remove Darwin supportPeter Trommler2019-01-011-9/+0
| | | | | | | Support for Mac OS X on PowerPC has been dropped by Apple years ago. We follow suit and remove PowerPC support for Darwin. Fixes #16106.
* rts: fix build failure on OpenBSD (_DYNAMIC symbol collision)Sergei Trofimovich2018-12-291-1/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Build failure on OpenBSD-6.4 the the following: ``` rts/RtsSymbols.c:994:1: error: error: redefinition of '_DYNAMIC' as different kind of symbol | 994 | RTS_OPENBSD_ONLY_SYMBOLS | ^ RTS_OPENBSD_ONLY_SYMBOLS ^ ``` On OpenBSD `_DYNAMIC` was always defined in `<elf.h>` headers but used not to be included. The change explicitly includes `<elf.h>` as a source of symbol definition. Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org> Test Plan: build-tested on OpenBSD-6.4 Reviewers: bgamari, erikd, simonmar Subscribers: rwbarton, carter GHC Trac Issues: #15945 Differential Revision: https://phabricator.haskell.org/D5461
* Finish stable splitDavid Feuer2018-08-291-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Long ago, the stable name table and stable pointer tables were one. Now, they are separate, and have significantly different implementations. I believe the time has come to finish the split that began in #7674. * Divide `rts/Stable` into `rts/StableName` and `rts/StablePtr`. * Give each table its own mutex. * Add FFI functions `hs_lock_stable_ptr_table` and `hs_unlock_stable_ptr_table` and document them. These are intended to replace the previously undocumented `hs_lock_stable_tables` and `hs_lock_stable_tables`, which are now documented as deprecated synonyms. * Make `eqStableName#` use pointer equality instead of unnecessarily comparing stable name table indices. Reviewers: simonmar, bgamari, erikd Reviewed By: bgamari Subscribers: rwbarton, carter GHC Trac Issues: #15555 Differential Revision: https://phabricator.haskell.org/D5084
* Add traceBinaryEvent# primopMitsutoshi Aoe2018-08-211-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This adds a new primop called traceBinaryEvent# that takes the length of binary data and a pointer to the data, then emits it to the eventlog. There is some example code that uses this primop and the new event: * [traceBinaryEventIO][1] that calls `traceBinaryEvent#` * [A patch to ghc-events][2] that parses the new `EVENT_USER_BINARY_MSG` There's no corresponding issue on Trac but it was discussed at ghc-devs [3]. [1] https://github.com/maoe/ghc-trace-events/blob /fb226011ef1f85a97b4da7cc9d5f98f9fe6316ae/src/Debug/Trace/Binary.hs#L29) [2] https://github.com/maoe/ghc-events/commit /239ca77c24d18cdd10d6d85a0aef98e4a7c56ae6) [3] https://mail.haskell.org/pipermail/ghc-devs/2018-May/015791.html Reviewers: bgamari, erikd, simonmar Reviewed By: bgamari Subscribers: rwbarton, thomie, carter Differential Revision: https://phabricator.haskell.org/D5007
* Replace atomicModifyMutVar#David Feuer2018-07-151-1/+2
| | | | | | | | | | | | Reviewers: simonmar, hvr, bgamari, erikd, fryguybob, rrnewton Reviewed By: simonmar Subscribers: fryguybob, rwbarton, thomie, carter GHC Trac Issues: #15364 Differential Revision: https://phabricator.haskell.org/D4884
* Rename some mutable closure types for consistencyÖmer Sinan Ağacan2018-06-051-4/+4
| | | | | | | | | | | | | | | | | | | | | | | 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
* rts: Rip out support for STM invariantsBen Gamari2018-06-021-1/+0
| | | | | | | | | | | | | | | | | | | | | | | 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
* An overhaul of the SRT representationSimon Marlow2018-05-161-0/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Remove MAX_PATH restrictions from RTS, I/O manager and various utilitiesTamar Christina2018-03-311-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This shims out fopen and sopen so that they use modern APIs under the hood along with namespaced paths. This lifts the MAX_PATH restrictions from Haskell programs and makes the new limit ~32k. There are only some slight caveats that have been documented. Some utilities have not been upgraded such as lndir, since all these things are different cabal packages I have been forced to copy the source in different places which is less than ideal. But it's the only way to keep sdist working. Test Plan: ./validate Reviewers: hvr, bgamari, erikd, simonmar Reviewed By: bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #10822 Differential Revision: https://phabricator.haskell.org/D4416
* Improve accuracy of get/setAllocationCounterBen Gamari2018-03-191-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: hvr, erikd, simonmar, jrtc27, trommler Reviewed By: simonmar Subscribers: trommler, jrtc27, rwbarton, thomie, carter Differential Revision: https://phabricator.haskell.org/D4363
* myThreadId# is trivial; make it an inline primopSimon Marlow2018-02-181-1/+0
| | | | | | | | | | | | | | | 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
* Revert "Improve accuracy of get/setAllocationCounter"Ben Gamari2018-01-181-2/+2
| | | | This reverts commit a1a689dda48113f3735834350fb562bb1927a633.
* Improve accuracy of get/setAllocationCounterSimon Marlow2018-01-081-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* base: fdReady(): Fix timeouts > ~49 days overflowing. Fixes #14262.Niklas Hambüchen2017-11-241-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Remove left-overs from compareByteArray# inline conversionHerbert Valerio Riedel2017-11-091-1/+0
| | | | | | | 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).
* Add -falignment-sanitization flagBen Gamari2017-10-291-0/+1
| | | | | | | | | | | | | | | | | | | Here we add a flag to instruct the native code generator to add alignment checks in all info table dereferences. This is helpful in catching pointer tagging issues. Thanks to @jrtc27 for uncovering the tagging issues on Sparc which inspired this flag. Test Plan: Validate Reviewers: simonmar, austin, erikd Reviewed By: simonmar Subscribers: rwbarton, trofi, thomie, jrtc27 Differential Revision: https://phabricator.haskell.org/D4101
* Implement new `compareByteArrays#` primopHerbert Valerio Riedel2017-10-161-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The new primop compareByteArrays# :: ByteArray# -> Int# {- offset -} -> ByteArray# -> Int# {- offset -} -> Int# {- length -} -> Int# allows to compare the subrange of the first `ByteArray#` to the (same-length) subrange of the second `ByteArray#` and returns a value less than, equal to, or greater than zero if the range is found, respectively, to be byte-wise lexicographically less than, to match, or be greater than the second range. Under the hood, the new primop is implemented in terms of the standard ISO C `memcmp(3)` function. It is currently an out-of-line primop but work is underway to optimise this into an inline primop for a future follow-up Differential (see D4091). This primop has applications in packages like `text`, `text-short`, `bytestring`, `text-containers`, `primitive`, etc. which currently have to incur the overhead of an ordinary FFI call to directly or indirectly invoke `memcmp(3)` as well has having to deal with some `unsafePerformIO`-variant. While at it, this also improves the documentation for the existing `copyByteArray#` primitive which has a non-trivial type-signature that significantly benefits from a more explicit description of its arguments. Reviewed By: bgamari Differential Revision: https://phabricator.haskell.org/D4090
* base: fdReady(): Improve accuracy and simplify code.Niklas Hambüchen2017-09-191-0/+1
| | | | | | | | | | | | | | | | | | | | | | | This is done by reusing the existing cross-platform `getProcessElapsedTime()` function, which already provides nanosecond monotonic clocks, and fallback for platforms that don't have those. To do this, `getProcessElapsedTime()` had to be moved from a private RTS symbol into the public interface. Accuracy is improved in 2 ways: * Use of the monotonic clock where available * Measuring the total time spent waiting instead of a sum of intervals (between which there are small gaps) Reviewers: bgamari, austin, hvr, erikd, simonmar Reviewed By: bgamari Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3953
* rts: Add regsterCc(s)List to RTS symbols listBen Gamari2017-09-131-0/+2
| | | | | | | | | | | | | | These are helpers added in a8da0de27e600211f04601ac737c329d6603c700 to register cost centres. They are invoked while loading profiled code and therefore need to be in the RTS's symbol list. Test Plan: Validate, trying starting GHCi in profiled GHC build Reviewers: austin, erikd, simonmar Subscribers: rwbarton, thomie, RyanGlScott Differential Revision: https://phabricator.haskell.org/D3950
* Initialize hs_init with UTF8 encoded arguments on Windows.Andreas Klebinger2017-07-271-2/+0
| | | | | | | | | | | | | | | | | | | | | | | Summary: Get utf8 encoded arguments before we call hs_init and use them instead of ignoring hs_init arguments. This reduces differing behaviour of the RTS between windows and linux and simplifies the code involved. A few testcases were changed to expect the same result on windows as on linux after the changes. This fixes #13940. Test Plan: ./validate Reviewers: austin, hvr, bgamari, erikd, simonmar, Phyx Subscribers: Phyx, rwbarton, thomie GHC Trac Issues: #13940 Differential Revision: https://phabricator.haskell.org/D3739
* Prefer #if defined to #ifdefBen Gamari2017-04-281-2/+2
| | | | Our new CPP linter enforces this.
* hs_add_root() RTS API removalSergei Trofimovich2017-04-171-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | Before ghc-7.2 hs_add_root() had to be used to initialize haskell modules when haskell was called from FFI. commit a52ff7619e8b7d74a9d933d922eeea49f580bca8 ("Change the way module initialisation is done (#3252, #4417)") removed needs for hs_add_root() and made function a no-op. For backward compatibility '__stginit_<module>' symbol was not removed. This change removes no-op hs_add_root() function and unused '__stginit_<module>' symbol from each haskell module. Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org> Test Plan: ./validate Reviewers: simonmar, austin, bgamari, erikd Reviewed By: simonmar Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3460
* Report heap overflow in the same way as stack overflowSimon Marlow2017-04-021-1/+2
| | | | | | | | | | | | | | | | | | | | | | | Now that we throw an exception for heap overflow, we should only print the heap overflow message in the main thread when the HeapOverflow exception is caught, rather than as a side effect in the GC. Stack overflows were already done this way, I just made heap overflow consistent with stack overflow, and did some related cleanup. Fixes broken T2592(profasm) which was reporting the heap overflow message twice (you would only notice when building with profiling libs enabled). Test Plan: validate Reviewers: bgamari, niteria, austin, DemiMarie, hvr, erikd Reviewed By: bgamari Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3394
* Make list of deprecated symbols on Windows weak.Tamar Christina2017-02-261-6/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We have a unfortunate workaround in place for the fact that most packages out there use POSIX names for symbols even on Windows. This means that we have to recognize e.g. both `_ungetch` and `ungetch`. The former is the actual symbol name on windows and the latter is the POSIX variant. The problem is that on normal windows programs `ungetch` should not be in the global namespace. To work around this, we now mark the deprecated symbols as weak symbols in the global namespace. This provides the flexibility we need: * If you use the symbol without defining it, we assume you meant to use the POSIX variant. * If you actually define the symbol, we'll hence forth use that definition and assume you didn't mean to use POSIX code. This is how MingW64's wrapper also works. This requires D3028. Fixes #13210. Test Plan: ./validate Reviewers: austin, bgamari, erikd, simonmar Reviewed By: bgamari Subscribers: thomie, #ghc_windows_task_force Differential Revision: https://phabricator.haskell.org/D3154
* Ditch static flagsSylvain Henry2017-02-021-2/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | This patch converts the 4 lasting static flags (read from the command line and unsafely stored in immutable global variables) into dynamic flags. Most use cases have been converted into reading them from a DynFlags. In cases for which we don't have easy access to a DynFlags, we read from 'unsafeGlobalDynFlags' that is set at the beginning of each 'runGhc'. It's not perfect (not thread-safe) but it is still better as we can set/unset these 4 flags before each run when using GHC API. Updates haddock submodule. Rebased and finished by: bgamari Test Plan: validate Reviewers: goldfire, erikd, hvr, austin, simonmar, bgamari Reviewed By: simonmar Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2839 GHC Trac Issues: #8440
* Add support for StaticPointers in GHCiBen Gamari2017-02-021-0/+1
| | | | | | | | | | | | | | | | | | | | | Here we add support to GHCi for StaticPointers. This process begins by adding remote GHCi messages for adding entries to the static pointer table. We then collect binders needing SPT entries after linking and send the interpreter a message adding entries with the appropriate fingerprints. Test Plan: `make test TEST=StaticPtr` Reviewers: facundominguez, mboes, simonpj, simonmar, goldfire, austin, hvr, erikd Reviewed By: simonpj, simonmar Subscribers: RyanGlScott, simonpj, thomie Differential Revision: https://phabricator.haskell.org/D2504 GHC Trac Issues: #12356
* Unbreak libGHCi by adding missing symbol.Tamar Christina2017-01-161-0/+1
| | | | | | | | | | | | | | | | Summary: Someone committed a new public symbol `purgeObj` again without adding it to the symbols table. Test Plan: ./validate Reviewers: austin, bgamari, simonmar, erikd Reviewed By: erikd Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2980
* Throw an exception on heap overflowDemi Obenour2017-01-101-0/+2
| | | | | | | | | | | | | | | | | This changes heap overflow to throw a HeapOverflow exception instead of killing the process. Test Plan: GHC CI Reviewers: simonmar, austin, hvr, erikd, bgamari Reviewed By: simonmar, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2790 GHC Trac Issues: #1791
* Make globals use sharedCAFMoritz Angermann2016-12-111-0/+5
| | | | | | | | | | | | | | | | | | | Summary: The use of globals is quite painful when multiple rts are loaded, e.g. when plugins are loaded, which bring in a second rts. The sharedCAF appraoch was employed for the FastStringTable; I've taken the libery to extend this to the other globals I could find. This is a reboot of D2575, that should hopefully not exhibit the same windows build issues. Reviewers: Phyx, simonmar, goldfire, bgamari, austin, hvr, erikd Reviewed By: Phyx, simonmar, bgamari Subscribers: mpickering, thomie Differential Revision: https://phabricator.haskell.org/D2773
* Add `_unlock_file` to RTS symbolsTamar Christina2016-12-101-1/+2
| | | | | | | | Reviewers: bgamari, austin, erikd, simonmar Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2818
* rts: Provide _lock_file in symbol table on WindowsBen Gamari2016-12-091-1/+24
| | | | | | | | | | Test Plan: Validate on Windows, ensure that linking works. Reviewers: Phyx, austin, erikd, simonmar Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2817
* Overhaul of Compact Regions (#12455)Simon Marlow2016-12-071-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This commit makes various improvements and addresses some issues with Compact Regions (aka Compact Normal Forms). This was the most important thing I wanted to fix. Compaction previously prevented GC from running until it was complete, which would be a problem in a multicore setting. Now, we compact using a hand-written Cmm routine that can be interrupted at any point. When a GC is triggered during a sharing-enabled compaction, the GC has to traverse and update the hash table, so this hash table is now stored in the StgCompactNFData object. Previously, compaction consisted of a deepseq using the NFData class, followed by a traversal in C code to copy the data. This is now done in a single pass with hand-written Cmm (see rts/Compact.cmm). We no longer use the NFData instances, instead the Cmm routine evaluates components directly as it compacts. The new compaction is about 50% faster than the old one with no sharing, and a little faster on average with sharing (the cost of the hash table dominates when we're doing sharing). Static objects that don't (transitively) refer to any CAFs don't need to be copied into the compact region. In particular this means we often avoid copying Char values and small Int values, because these are static closures in the runtime. Each Compact# object can support a single compactAdd# operation at any given time, so the Data.Compact library now enforces mutual exclusion using an MVar stored in the Compact object. We now get exceptions rather than killing everything with a barf() when we encounter an object that cannot be compacted (a function, or a mutable object). We now also detect pinned objects, which can't be compacted either. The Data.Compact API has been refactored and cleaned up. A new compactSize operation returns the size (in bytes) of the compact object. Most of the documentation is in the Haddock docs for the compact library, which I've expanded and improved here. Various comments in the code have been improved, especially the main Note [Compact Normal Forms] in rts/sm/CNF.c. I've added a few tests, and expanded a few of the tests that were there. We now also run the tests with GHCi, and in a new test way that enables sanity checking (+RTS -DS). There's a benchmark in libraries/compact/tests/compact_bench.hs for measuring compaction speed and comparing sharing vs. no sharing. The field totalDataW in StgCompactNFData was unnecessary. Test Plan: * new unit tests * validate * tested manually that we can compact Data.Aeson data Reviewers: gcampax, bgamari, ezyang, austin, niteria, hvr, erikd Subscribers: thomie, simonpj Differential Revision: https://phabricator.haskell.org/D2751 GHC Trac Issues: #12455
* Overhaul GC statsSimon Marlow2016-12-061-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Visible API changes: * The C struct `GCDetails` gives the stats about a single GC. This is passed to the `gcDone()` callback if one is set via the RtsConfig. (previously we just passed a collection of values, so this is more extensible, at the expense of breaking the existing API) * `RTSStats` gives cumulative stats since the start of the program, and includes the `GCDetails` for the most recent GC. This struct can be obtained via `getRTSStats()` (the old `getGCStats()` has been removed, and `getGCStatsEnabled()` has been renamed to `getRTSStatsEnabled()`) Improvements: * The per-GC stats and cumulative stats are now cleanly separated. * Inside the RTS we have a top-level `RTSStats` struct to keep all our stats in, previously this was just a collection of strangely-named variables. This struct is mostly just copied in `getRTSStats()`, so the implementation of that function is a lot shorter. * Types are more consistent. We use a uint64_t byte count for all memory values, and Time for all time values. * Names are more consistent. We use a suffix `_bytes` for all byte counts and `_ns` for all time values. * We now collect information about the amount of memory in large objects and compact objects in `GCDetails`. (the latter was the reason I started doing this patch but it seems to have ballooned a bit!) * I fixed a bug in the calculation of the elapsed MUT time, and added an ASSERT to stop the calculations going wrong in the future. For now I kept the Haskell API in `GHC.Stats` the same, by impedence-matching with the new API. We could either break that API and make it match the C API more closely, or we could add a new API and deprecate the old one. Opinions welcome. This stuff is very easy to get wrong, and it's hard to test. Reviews welcome! Test Plan: manual testing validate Reviewers: bgamari, niteria, austin, ezyang, hvr, erikd, rwbarton, Phyx Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2756
* Install toplevel handler inside fork.Alexander Vershilov2016-12-021-0/+1
| | | | | | | | | | | | | | | | | | | | When rts is forked it doesn't update toplevel handler, so UserInterrupt exception is sent to Thread1 that doesn't exist in forked process. We install toplevel handler when fork so signal will be delivered to the new main thread. Fixes #12903 Reviewers: simonmar, austin, erikd, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2770 GHC Trac Issues: #12903
* Add missing SMP symbols to RT linker.Tamar Christina2016-11-181-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Add some missing symbols that we export from the public headers but forgot to include in the runtime linker's symbol table. This is a bit of a unsatifactory patch, since we have a bit of a cat and mouse game going. We should find a way to automate this. But I know of no good solutions at the moment that won't add all rts symbols (including those we don't have an extern declaration for.). So for now, just add the ones reported missing. Test Plan: inplace/bin/ghc-stage2.exe --interactive Reviewers: RyanGlScott, austin, erikd, simonmar, bgamari Reviewed By: bgamari Subscribers: thomie, #ghc_windows_task_force Differential Revision: https://phabricator.haskell.org/D2727 GHC Trac Issues: #12846
* Add some missing RTS symbolsSimon Marlow2016-10-181-0/+9
| | | | | | | | | | | | Test Plan: validate Reviewers: austin, bgamari, erikd Reviewed By: bgamari, erikd Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2589
* Added support for deprecated POSIX functions on Windows.Tamar Christina2016-09-011-0/+121
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: With the introduction of 8.0.1 We've stopped supporting in GHCi the use of POSIX functions under their deprecated names on Windows. This to be compatible with object and libraries from the most popular compilers on the platform (Microsoft and Intel compilers). However this brings a confusing disparity between the compiled and interpreted behavior since MingW-W64 does support the deprecated names. Also It seems clear that package writers won't update their packages to properly support Windows. As such I have added redirects in the RTS for the deprecated functions as listed on https://msdn.microsoft.com/en-us/library/ms235384.aspx. This won't export the functions (as in, they won't be in the symbol table of compiled code for the RTS.) but we inject them into the symbol table of the dynamic linker at startup. Test Plan: ./validate and make test TEST="ffi017 ffi021" Reviewers: thomie, simonmar, RyanGlScott, bgamari, austin, hvr, erikd Reviewed By: simonmar, bgamari Subscribers: RyanGlScott, #ghc_windows_task_force Differential Revision: https://phabricator.haskell.org/D2500 GHC Trac Issues: #12209, #12497, #12496
* Tag pointers in interpreted constructorsmniip2016-08-301-1/+7
| | | | | | | | | | | | | | | | | | | | | Instead of stg_interp_constr_entry there are now 7 functions (one for each value of the tag bits) that tag the constructor pointer before returning. This is consistent with compiled constructors' entry code, and expectations that compiled code places on compiled constructors. The iserv protocol is extended with an extra field that explains what pointer tag the constructor should use. Test Plan: Added tests for #12523 Reviewers: erikd, bgamari, hvr, austin, simonmar Reviewed By: simonmar Subscribers: osa1, thomie, rwbarton Differential Revision: https://phabricator.haskell.org/D2473 GHC Trac Issues: #12523
* Fix GHCi perf-llvm build on x86_64Erik de Castro Lopo2016-08-141-0/+4
| | | | | | | | | | | | | | | | | | | | | | | With BuildFlavour set to `perf-llvm`, GHCi would fail as soon as it was run with: ghc-stage2: .../ghc-prim/dist-install/build/HSghc-prim-0.5.0.0.o: unknown symbol `__udivti3' ghc-stage2: unable to load package `ghc-prim-0.5.0.0' Fix this by adding `__udivti3` and `__umodti3` to RtsSymbols.c. Test Plan: Validate Reviewers: simonmar, austin, bgamari, Phyx, trofi Reviewed By: Phyx, trofi Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2449 GHC Trac Issues: #11981
* Compact RegionsGiovanni Campagna2016-07-201-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | This brings in initial support for compact regions, as described in the ICFP 2015 paper "Efficient Communication and Collection with Compact Normal Forms" (Edward Z. Yang et.al.) and implemented by Giovanni Campagna. Some things may change before the 8.2 release, but I (Simon M.) wanted to get the main patch committed so that we can iterate. What documentation there is is in the Data.Compact module in the new compact package. We'll need to extend and polish the documentation before the release. Test Plan: validate (new test cases included) Reviewers: ezyang, simonmar, hvr, bgamari, austin Subscribers: vikraman, Yuras, RyanGlScott, qnikst, mboes, facundominguez, rrnewton, thomie, erikd Differential Revision: https://phabricator.haskell.org/D1264 GHC Trac Issues: #11493
* Rename isPinnedByteArray# to isByteArrayPinned#Ben Gamari2016-06-041-1/+2
| | | | | | | | | | | | Reviewers: simonmar, duncan, erikd, austin Reviewed By: austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2290 GHC Trac Issues: #12059
* rts: Add isPinnedByteArray# primopBen Gamari2016-05-181-0/+1
| | | | | | | | | | | | | | | | | Adds a primitive operation to determine whether a particular `MutableByteArray#` is backed by a pinned buffer. Test Plan: Validate with included testcase Reviewers: austin, simonmar Reviewed By: austin, simonmar Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2217 GHC Trac Issues: #12059
* Fix histograms for ticky codeMateusz Lenik2016-05-181-1/+4
| | | | | | | | | | | | | | | | | | | | This patch fixes Cmm generation required to produce histograms when compiling with -ticky flag, strips dead code from rts/Ticky.c and reworks it to use a shared constant in both C and Haskell code. Fixes #8308. Test Plan: T8308 Reviewers: jstolarek, simonpj, austin Reviewed By: simonpj Subscribers: mpickering, simonpj, bgamari, mlen, thomie, jstolarek Differential Revision: https://phabricator.haskell.org/D931 GHC Trac Issues: #8308
* Change runtime linker to perform lazy loading of symbols/sectionsTamar Christina2016-04-111-317/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The Runtime Linker is currently eagerly loading all object files on all platforms which do not use the system linker for `GHCi`. The problem with this approach is that it requires all symbols to be found. Even those of functions never used/called. This makes the number of libraries required to link things like `mingwex` quite high. To work around this the `rts` was relying on a trick. It itself was compiled with `MingW64-w`'s `GCC`. So it was already linked against `mingwex`. As such, it re-exported the symbols from itself. While this worked it made it impossible to link against `mingwex` in user libraries. And with this means no `C99` code could ever run in `GHCi` on Windows without having the required symbols re-exported from the rts. Consequently this rules out a large number of packages on Windows. SDL2, HMatrix etc. After talking with @rwbarton I have taken the approach of loading entire object files when a symbol is needed instead of doing the dependency tracking on a per symbol basis. This is a lot less fragile and a lot less complicated to implement. The changes come down to the following steps: 1) modify the linker to and introduce a new state for ObjectCode: `Needed`. A Needed object is one that is required for the linking to succeed. The initial set consists of all Object files passed as arguments to the link. 2) Change `ObjectCode`'s to be indexed but not initialized or resolved. This means we know where we would load the symbols, but haven't actually done so. 3) Mark any `ObjectCode` belonging to `.o` passed as argument as required: ObjectState `NEEDED`. 4) During `Resolve` object calls, mark all `ObjectCode` containing the required symbols as `NEEDED` 5) During `lookupSymbol` lookups, (which is called from `linkExpr` and `linkDecl` in `GHCI.hs`) is the symbol is in a not-yet-loaded `ObjectCode` then load the `ObjectCode` on demand and return the address of the symbol. Otherwise produce an unresolved symbols error as expected. 6) On `unloadObj` we then change the state of the object and remove it's symbols from the `reqSymHash` table so it can be reloaded. This change affects all platforms and OSes which use the runtime linker. It seems there are no real perf tests for `GHCi`, but performance shouldn't be impacted much. We gain a lot of time not loading all `obj` files, and we lose some time in `lookupSymbol` when we're finding sections that have to be loaded. The actual finding itself is O(1) (Assuming the hashtnl is perfect) It also consumes slighly more memory as instead of storing just the address of a symbol I also store some other information, like if the symbol is weak or not. This change will break any packages relying on renamed POSIX functions that were re-named and re-exported by the rts. Any packages following the proper naming for functions as found on MSDN will work fine. Test Plan: ./validate on all platforms which use the Runtime linker. Reviewers: thomie, rwbarton, simonmar, erikd, bgamari, austin, hvr Reviewed By: erikd Subscribers: kgardas, gridaphobe, RyanGlScott, simonmar, rwbarton, #ghc_windows_task_force Differential Revision: https://phabricator.haskell.org/D1805 GHC Trac Issues: #11223
* - fix tests on OpenBSD which requires _DYNAMIC symbolKarel Gardas2015-12-231-1/+2
| | | | | | | | | | | | | Summary: This patch adds _DYNAMIC symbol to the list of OpenBSD symbols. The patch fixes unknown _DYNAMIC symbol runtime linker error caused by recent update of unix library. Reviewers: bgamari, austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1689
* Maintain cost-centre stacks in the interpreterSimon Marlow2015-12-211-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Breakpoints become SCCs, so we have detailed call-stack info for interpreted code. Currently this only works when GHC is compiled with -prof, but D1562 (Remote GHCi) removes this constraint so that in the future call stacks will be available without building your own GHCi. How can you get a stack trace? * programmatically: GHC.Stack.currentCallStack * I've added an experimental :where command that shows the stack when stopped at a breakpoint * `error` attaches a call stack automatically, although since calls to `error` are often lifted out to the top level, this is less useful than it might be (ImplicitParams still works though). * Later we might attach call stacks to all exceptions Other related changes in this diff: * I reduced the number of places that get ticks attached for breakpoints. In particular there was a breakpoint around the whole declaration, which was often redundant because it bound no variables. This reduces clutter in the stack traces and speeds up compilation. * I tidied up some RealSrcSpan stuff in InteractiveUI, and made a few other small cleanups Test Plan: validate Reviewers: ezyang, bgamari, austin, hvr Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1595 GHC Trac Issues: #11047
* Implement phase 1 of expanded FloatingDan Doel2015-12-211-0/+4
| | | | | | | | | | | | | | | | - This part of the proposal is to add log1p, expm1, log1pexp and log1mexp to the Floating class, and export the full Floating class from Numeric Reviewers: ekmett, #core_libraries_committee, bgamari, hvr, austin Reviewed By: ekmett, #core_libraries_committee, bgamari Subscribers: Phyx, RyanGlScott, ekmett, thomie Differential Revision: https://phabricator.haskell.org/D1605 GHC Trac Issues: #11166
* rts: Always export Libdw* symbolsBen Gamari2015-11-231-4/+0
| | | | | | | | | | | | | Otherwise we'll get link time failures as `base` always builds `GHC.ExecutionStack`. Test Plan: Validate Reviewers: austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1519
* rts: Add LibdwPool, a pool for libdw sessionsBen Gamari2015-11-231-1/+4
| | | | Differential Revision: https://phabricator.haskell.org/D1198#40948
View Lorry Controller Status