- Mar 09, 2024
-
-
Ben Gamari authored
Don't allocate a Ptr constructor per frame.
-
Ben Gamari authored
Here we add the unit ID to the info table provenance structure.
-
Ben Gamari authored
This allows us to shave a 64-bit word off of the packed IPE entry size.
-
Ben Gamari authored
-
Ben Gamari authored
Previously we would eagerly allocate `InfoTableEnt`s for each info table registered in the info table provenance map. However, this costs considerable memory and initialization time. Instead we now lazily decode these tables. This allows us to use one-third the memory *and* opens the door to taking advantage of sharing opportunities within a module. This required considerable reworking since lookupIPE now must be passed its result buffer.
-
Ben Gamari authored
-
Ben Gamari authored
-
There is nothing platform-dependent about our GOT implementation and GOT support is needed by `T24171` on i386.
-
This replicates the behavior on Windows, where `Hi.exe` will produce profiling output named `Hi.prof` instead of `Hi.exe.prof`. While in the area I also fixed the extension-stripping logic, which incorrectly rewrote `Hi.exefoo` to `Hi.foo`. Closes #24515.
-
- Mar 08, 2024
-
-
This fixes a regression in retainer set profiling introduced by b0293f78. Prior to that commit the heap traversal word would be initialized by `SET_HDR` using `LDV_RECORD_CREATE`. However, the commit added a `doingLDVProfiling` check in `LDV_RECORD_CREATE`, meaning that this initialization no longer happened. Given that this initialization was awkwardly indirectly anyways, I have fixed this by explicitly initializating the heap traversal word to `NULL` in `SET_PROF_HDR`. This is equivalent to the previous behavior, but much more direct. Fixes #24513.
-
- Mar 06, 2024
-
-
This commit adds an assertion to Bdescr() to assert the pointer is indeed heap allocated. This is useful to rule out RTS bugs that attempt to access non-existent block descriptor of a static closure, #24492 being one such example.
-
This commit exposes HeapAlloc.h as a public header. The intention is to expose HEAP_ALLOCED/HEAP_ALLOCED_GC, so they can be used in assertions in other public headers, and they may also be useful for user code.
-
This patch adds a -xr RTS option to control the size of virtual memory address space reserved by the two step allocator on a 64-bit platform, see added documentation for explanation. Closes #24498.
-
Use faster implementations for the following primitives in the JS backend by not using JavaScript's BigInt: - plusInt64 - minusInt64 - minusWord64 - timesWord64 - timesInt64 Co-authored-by:Josh Meredith <joshmeredith2008@gmail.com>
-
- Mar 01, 2024
-
-
This implements Proposal 0475, introducing the `ListTuplePuns` extension which is enabled by default. Disabling this extension makes it invalid to refer to list, tuple and sum type constructors by using built-in syntax like `[Int]`, `(Int, Int)`, `(# Int#, Int# #)` or `(# Int | Int #)`. Instead, this syntax exclusively denotes data constructors for use with `DataKinds`. The conventional way of referring to these data constructors by prefixing them with a single quote (`'(Int, Int)`) is now a parser error. Tuple declarations have been moved to `GHC.Tuple.Prim` and the `Solo` data constructor has been renamed to `MkSolo` (in a previous commit). Unboxed tuples and sums now have real source declarations in `GHC.Types`. Unit and solo types for tuples are now called `Unit`, `Unit#`, `Solo` and `Solo#`. Constraint tuples now have the unambiguous type constructors `CTuple<n>` as well as `CUnit` and `CSolo`, defined in `GHC.Classes` like before. A new parser construct has been added for the unboxed sum data constructor declarations. The type families `Tuple`, `Sum#` etc. that were intended to provide nicer syntax have been omitted from this change set due to inference problems, to be implemented at a later time. See the MR discussion for more info. Updates the submodule utils/haddock. Updates the cabal submodule due to new language extension. Metric Increase: haddock.base Metric Decrease: MultiLayerModulesTH_OneShot size_hello_artifact Proposal document: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0475-tuple-syntax.rst Merge request: ghc/ghc!8820 Tracking ticket: ghc/ghc#21294
-
- Feb 28, 2024
-
-
In nonmovingTidyWeaks we want to check if the key of a weak pointer lives in the non-moving heap. We do this by checking the flags of the block the key lives in. But we need to be careful with values that live outside the Haskell heap, since they will lack a block descriptor and looking for one may lead to a segfault. In this case we should just accept that it isn't on the non-moving heap. Resolves #24492
-
- Feb 27, 2024
-
-
See added comment for details. Closes #24423.
-
- Use ClosureType for InfoProv.ipDesc. - Use ClosureType for CloneStack.closureType. - Now ghc-heap re-exports this type from ghc-internal. See the accompanying CLC proposal: https://github.com/haskell/core-libraries-committee/issues/210 Resolves #22600
-
- Feb 25, 2024
-
-
Ben Gamari authored
-
Ben Gamari authored
Bumps haddock submodule due to testsuite output changes.
-
- Feb 21, 2024
-
-
This is just a minor cleanup I found while reviewing the implementation.
-
Fixes #24445
-
This commit removes the unused HAVE_C11_ATOMICS macro. We used to have a few places that have fallback paths when HAVE_C11_ATOMICS is not defined, but that is completely redundant, since the FP_CC_SUPPORTS__ATOMICS configure check will fail when the C compiler doesn't support C11 style atomics. There are also many places (e.g. in unreg backend, SMP.h, library cbits, etc) where we unconditionally use C11 style atomics anyway which work in even CentOS 7 (gcc 4.8), the oldest distro we test in our CI, so there's no value in keeping HAVE_C11_ATOMICS.
-
-
This avoids segfaults when the mutator modifies closures as we examine them. Resolves #24393
-
- Feb 17, 2024
-
-
This commit removes the redundant logic of initializing each Capability's rCCCS to CCS_SYSTEM in initProfiling(). Before initProfiling() is called during RTS startup, each Capability's rCCCS has already been assigned CCS_SYSTEM when they're first initialized.
-
In addition to existing Acquire/Release fences, this commit adds SEQ_CST fence support to GHC, allowing Cmm code to explicitly emit a fence that enforces total memory ordering. The following logic is added: - The MO_SeqCstFence callish MachOp - The %prim fence_seq_cst() Cmm syntax and the SEQ_CST_FENCE macro in Cmm.h - MO_SeqCstFence lowering logic in every single GHC codegen backend
-
When freeing a `HashTable` there is no reason to walk over the hash list before freeing it if the user has not given us a `dataFreeFun`. Noticed while looking at #24410.
-
There are RESERVED_STACK_WORDS free words (currently 21) on the stack, so omit the checks. Suggested by Cheng Shao.
-
First step towards fixing #24331. Replace foreign prim imports with real primops.
-
-
- Feb 14, 2024
-
-
This commit fixes two wasm unreg regressions caught by a nightly pipeline: - Unknown stg_scheduler_loopzh symbol when compiling scheduler.cmm - Invalid _hs_constructor(101) function name when handling ctor
-
-
The strings in IPE events may be of unbounded length. Limit the lengths of these fields to 64k characters to ensure that we don't exceed the maximum event length.
-
Previously many of the `post*` implementations would first compute the length of the event's strings in order to determine the event length. Later we would then end up computing the length yet again in `postString`. Now we instead pass the string length to `postStringLen`, avoiding the repeated work.
-
- Feb 13, 2024
-
-
This commit cleans up how we include the xxhash.h header and only define XXH_INLINE_ALL, which is sufficient to inline the xxHash functions without symbol collision.
-
This commit enables XXH3_64bits hash to be used on all 64-bit platforms. Previously it was only enabled on x86_64, so platforms like aarch64 silently falls back to using XXH32 which degrades the hashing function quality.
-
-
This commit adds rts/ghc-internal logic to support the wasm backend's JSFFI functionality.
-
The pure Haskell implementation causes i386 regression in unrelated work that can be fixed by using C-based atomic increment, see added comment for details.
-
