Don't allocate a Ptr constructor per frame.

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.

Such that we can add new helpers into GHC.InfoProv.Types without
breakage.

Ben Gamari authored 1 year ago and Marge Bot committed 1 year ago

Here we introduce the `Backtraces` type and associated machinery for
attaching these via `ExceptionContext`. These has a few compile-time
regressions (`T15703` and `T9872d`) due to the additional dependencies
in the exception machinery.

As well, there is a surprisingly large regression in the
`size_hello_artifact` test. This appears to be due to various `Integer` and
`Read` bits now being reachable at link-time. I believe it should be
possible to avoid this but I have accepted the change for now to get the
feature merged.

CLC Proposal: https://github.com/haskell/core-libraries-committee/issues/199
GHC Proposal: https://github.com/ghc-proposals/ghc-proposals/pull/330

Metric Increase:
    T15703
    T9872d
    size_hello_artifact

Teo Camarasu authored 2 years ago and Marge Bot committed 1 year ago

- 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

These will be incrementally moved to the export sites in `base` where
possible.

Bumps haddock submodule due to testsuite output changes.

Ben Gamari authored 1 year ago and Marge Bot committed 1 year ago

Here we move a good deal of the implementation of `base` into a new
package, `ghc-internal` such that it can be evolved independently
from the user-visible interfaces of `base`.

While we want to isolate implementation from interfaces, naturally, we
would like to avoid turning `base` into a mere set of module re-exports.
However, this is a non-trivial undertaking for a variety of reasons:

 * `base` contains numerous known-key and wired-in things, requiring
   corresponding changes in the compiler

 * `base` contains a significant amount of C code and corresponding
   autoconf logic, which is very fragile and difficult to break apart

 * `base` has numerous import cycles, which are currently dealt with via
   carefully balanced `hs-boot` files

 * We must not break existing users

To accomplish this migration, I tried the following approaches:

* [Split-GHC.Base]: Break apart the GHC.Base knot to allow incremental
  migration of modules into ghc-internal: this knot is simply too
  intertwined to be easily pulled apart, especially given the rather
  tricky import cycles that it contains)

* [Move-Core]: Moving the "core" connected component of base (roughly
  150 modules) into ghc-internal. While the Haskell side of this seems
  tractable, the C dependencies are very subtle to break apart.

* [Move-Incrementally]:

  1. Move all of base into ghc-internal
  2. Examine the module structure and begin moving obvious modules (e.g.
     leaves of the import graph) back into base
  3. Examine the modules remaining in ghc-internal, refactor as necessary
     to facilitate further moves
  4. Go to (2) iterate until the cost/benefit of further moves is
     insufficient to justify continuing
  5. Rename the modules moved into ghc-internal to ensure that they don't
     overlap with those in base
  6. For each module moved into ghc-internal, add a shim module to base
     with the declarations which should be exposed and any requisite
     Haddocks (thus guaranteeing that base will be insulated from changes
     in the export lists of modules in ghc-internal

Here I am using the [Move-Incrementally] approach, which is empirically
the least painful of the unpleasant options above

Bumps haddock submodule.

Metric Decrease:
    haddock.Cabal
    haddock.base
Metric Increase:
    MultiComponentModulesRecomp
    T16875
    size_hello_artifact

Ben Gamari authored 1 year ago and Marge Bot committed 1 year ago

The only non-move changes here are whitespace changes to pass the
`whitespace` test and a few testsuite adaptations.

Ben Gamari authored 2 years ago and Marge Bot committed 2 years ago

The source file name can very often be shared across many IPE entries
whereas the source coordinates are generally unique. Separate the two to
exploit sharing of the former.

Matthew Pickering authored 2 years ago and Marge Bot committed 2 years ago

Fixes #21894

Sven Tennie authored 3 years ago and Marge Bot committed 3 years ago

Emit an Info Table Provenance Entry (IPE) for every stack represeted info table
if -finfo-table-map is turned on.

To decode a cloned stack, lookupIPE() is used. It provides a mapping between
info tables and their source location.

Please see these notes for details:

- [Stacktraces from Info Table Provenance Entries (IPE based stack unwinding)]
- [Mapping Info Tables to Source Positions]

Metric Increase:
    T12545

Sven Tennie authored 4 years ago and Marge Bot committed 3 years ago

Add `StackSnapshot#` primitive type that represents a cloned stack (StgStack).
The cloning interface consists of two functions, that clone either the treads
own stack (cloneMyStack) or another threads stack (cloneThreadStack).

The stack snapshot is offline/cold, i.e. it isn't evaluated any further. This is
useful for analyses as it prevents concurrent modifications.

For technical details, please see Note [Stack Cloning].

Co-authored-by: Ben Gamari <bgamari.foss@gmail.com>
Co-authored-by: Matthew Pickering <matthewtpickering@gmail.com>