[Git][ghc/ghc][wip/T23923-mikolaj-take-2] 23 commits: Prefer packed representation for CompiledByteCode

Tue Apr 16 06:46:48 UTC 2024

Mikolaj Konarski pushed to branch wip/T23923-mikolaj-take-2 at Glasgow Haskell Compiler / GHC

Commits:
868c8a78 by Fendor at 2024-04-09T08:51:50-04:00
Prefer packed representation for CompiledByteCode

As there are many 'CompiledByteCode' objects alive during a GHCi
session, representing its element in a more packed manner improves space
behaviour at a minimal cost.

When running GHCi on the agda codebase, we find around 380 live
'CompiledByteCode' objects. Packing their respective 'UnlinkedByteCode'
can save quite some pointers.

- - - - -
be3bddde by Alan Zimmerman at 2024-04-09T08:52:26-04:00
EPA: Capture all comments in a ClassDecl

Hopefully the final fix needed for #24533

- - - - -
3d0806fc by Jade at 2024-04-10T05:39:53-04:00
Validate -main-is flag using parseIdentifier

Fixes #24368

- - - - -
dd530bb7 by Rodrigo Mesquita at 2024-04-10T05:40:29-04:00
rts: free error message before returning

Fixes a memory leak in rts/linker/PEi386.c

- - - - -
e008a19a by Alexis King at 2024-04-10T05:40:29-04:00
linker: Avoid linear search when looking up Haskell symbols via dlsym

See the primary Note [Looking up symbols in the relevant objects] for a
more in-depth explanation.

When dynamically loading a Haskell symbol (typical when running a splice or
GHCi expression), before this commit we would search for the symbol in
all dynamic libraries that were loaded. However, this could be very
inefficient when too many packages are loaded (which can happen if there are
many package dependencies) because the time to lookup the would be
linear in the number of packages loaded.

This commit drastically improves symbol loading performance by
introducing a mapping from units to the handles of corresponding loaded
dlls. These handles are returned by dlopen when we load a dll, and can
then be used to look up in a specific dynamic library.

Looking up a given Name is now much more precise because we can get
lookup its unit in the mapping and lookup the symbol solely in the
handles of the dynamic libraries loaded for that unit.

In one measurement, the wait time before the expression was executed
went from +-38 seconds down to +-2s.

This commit also includes Note [Symbols may not be found in pkgs_loaded],
explaining the fallback to the old behaviour in case no dll can be found
in the unit mapping for a given Name.

Fixes #23415

Co-authored-by: Rodrigo Mesquita (@alt-romes)

- - - - -
dcfaa190 by Rodrigo Mesquita at 2024-04-10T05:40:29-04:00
rts: Make addDLL a wrapper around loadNativeObj

Rewrite the implementation of `addDLL` as a wrapper around the more
principled `loadNativeObj` rts linker function. The latter should be
preferred while the former is preserved for backwards compatibility.

`loadNativeObj` was previously only available on ELF platforms, so this
commit further refactors the rts linker to transform loadNativeObj_ELF
into loadNativeObj_POSIX, which is available in ELF and MachO platforms.

The refactor made it possible to remove the `dl_mutex` mutex in favour
of always using `linker_mutex` (rather than a combination of both).

Lastly, we implement `loadNativeObj` for Windows too.

- - - - -
12931698 by Rodrigo Mesquita at 2024-04-10T05:40:29-04:00
Use symbol cache in internal interpreter too

This commit makes the symbol cache that was used by the external
interpreter available for the internal interpreter too.

This follows from the analysis in #23415 that suggests the internal
interpreter could benefit from this cache too, and that there is no good
reason not to have the cache for it too. It also makes it a bit more
uniform to have the symbol cache range over both the internal and
external interpreter.

This commit also refactors the cache into a function which is used by
both `lookupSymbol` and also by `lookupSymbolInDLL`, extending the
caching logic to `lookupSymbolInDLL` too.

- - - - -
dccd3ea1 by Ben Gamari at 2024-04-10T05:40:29-04:00
testsuite: Add test for lookupSymbolInNativeObj

- - - - -
1b1a92bd by Alan Zimmerman at 2024-04-10T05:41:05-04:00
EPA: Remove unnecessary XRec in CompleteMatchSig

The XRec for [LIdP pass] is not needed for exact printing, remove it.

- - - - -
6e18ce2b by Ben Gamari at 2024-04-12T08:16:09-04:00
users-guide: Clarify language extension documentation

Over the years the users guide's language extension documentation has
gone through quite a few refactorings. In the process some of the
descriptions have been rendered non-sensical. For instance, the
description of `NoImplicitPrelude` actually describes the semantics of
`ImplicitPrelude`.

To fix this we:

 * ensure that all extensions are named in their "positive" sense (e.g.
   `ImplicitPrelude` rather than `NoImplicitPrelude`).
 * rework the documentation to avoid flag-oriented wording
   like "enable" and "disable"
 * ensure that the polarity of the documentation is consistent with
   reality.

Fixes #23895.

- - - - -
a933aff3 by Zubin Duggal at 2024-04-12T08:16:45-04:00
driver: Make `checkHomeUnitsClosed` faster

The implementation of `checkHomeUnitsClosed` was traversing every single path
in the unit dependency graph - this grows exponentially and quickly grows to be
infeasible on larger unit dependency graphs.

Instead we replace this with a faster implementation which follows from the
specificiation of the closure property - there is a closure error if there are
units which are both are both (transitively) depended upon by home units and
(transitively) depend on home units, but are not themselves home units.

To compute the set of units required for closure, we first compute the closure
of the unit dependency graph, then the transpose of this closure, and find all
units that are reachable from the home units in the transpose of the closure.

- - - - -
23c3e624 by Andreas Klebinger at 2024-04-12T08:17:21-04:00
RTS: Emit warning when -M < -H

Fixes #24487

- - - - -
d23afb8c by Ben Gamari at 2024-04-12T08:17:56-04:00
testsuite: Add broken test for CApiFFI with -fprefer-bytecode

See #24634.

- - - - -
a4bb3a51 by Ben Gamari at 2024-04-12T08:18:32-04:00
base: Deprecate GHC.Pack

As proposed in #21461.

Closes #21540.

- - - - -
55eb8c98 by Ben Gamari at 2024-04-12T08:19:08-04:00
ghc-internal: Fix mentions of ghc-internal in deprecation warnings

Closes #24609.

- - - - -
b0fbd181 by Ben Gamari at 2024-04-12T08:19:44-04:00
rts: Implement set_initial_registers for AArch64

Fixes #23680.

- - - - -
14c9ec62 by Ben Gamari at 2024-04-12T08:20:20-04:00
ghcup-metadata: Use Debian 9 binaries on Ubuntu 16, 17

Closes #24646.

- - - - -
35a1621e by Ben Gamari at 2024-04-12T08:20:55-04:00
Bump unix submodule to 2.8.5.1

Closes #24640.

- - - - -
a1c24df0 by Finley McIlwaine at 2024-04-12T08:21:31-04:00
Correct default -funfolding-use-threshold in docs

- - - - -
0255d03c by Oleg Grenrus at 2024-04-12T08:22:07-04:00
FastString is a __Modified__ UTF-8

- - - - -
c3489547 by Matthew Pickering at 2024-04-12T13:13:44-04:00
rts: Improve tracing message when nursery is resized

It is sometimes more useful to know how much bigger or smaller the
nursery got when it is resized.

In particular I am trying to investigate situations where we end up with
fragmentation due to the nursery (#24577)

- - - - -
5e4f4ba8 by Simon Peyton Jones at 2024-04-12T13:14:20-04:00
Don't generate wrappers for `type data` constructors with StrictData

Previously, the logic for checking if a data constructor needs a wrapper or not
would take into account whether the constructor's fields have explicit
strictness (e.g., `data T = MkT !Int`), but the logic would _not_ take into
account whether `StrictData` was enabled. This meant that something like `type
data T = MkT Int` would incorrectly generate a wrapper for `MkT` if
`StrictData` was enabled, leading to the horrible errors seen in #24620. To fix
this, we disable generating wrappers for `type data` constructors altogether.

Fixes #24620.

Co-authored-by: Ryan Scott <ryan.gl.scott at gmail.com>

- - - - -
3a835a3c by Mikolaj Konarski at 2024-04-16T08:45:53+02:00
Add DCoVarSet to PluginProv (!12037)

- - - - -

30 changed files:

- .gitlab/rel_eng/mk-ghcup-metadata/mk_ghcup_metadata.py
- compiler/GHC.hs
- compiler/GHC/ByteCode/Asm.hs
- compiler/GHC/ByteCode/Linker.hs
- compiler/GHC/ByteCode/Types.hs
- compiler/GHC/Core/Coercion.hs
- compiler/GHC/Core/Coercion/Opt.hs
- compiler/GHC/Core/FVs.hs
- compiler/GHC/Core/Lint.hs
- compiler/GHC/Core/TyCo/FVs.hs
- compiler/GHC/Core/TyCo/Rep.hs
- compiler/GHC/Core/TyCo/Subst.hs
- compiler/GHC/Core/TyCo/Tidy.hs
- compiler/GHC/Core/Type.hs
- compiler/GHC/CoreToIface.hs
- compiler/GHC/Data/FastString.hs
- compiler/GHC/Data/FlatBag.hs
- compiler/GHC/Driver/Main.hs
- compiler/GHC/Driver/Make.hs
- compiler/GHC/Driver/Plugins.hs
- compiler/GHC/Driver/Session.hs
- compiler/GHC/Hs/Binds.hs
- compiler/GHC/HsToCore/Quote.hs
- compiler/GHC/Iface/Ext/Ast.hs
- compiler/GHC/Iface/Rename.hs
- compiler/GHC/Iface/Syntax.hs
- compiler/GHC/Iface/Tidy.hs
- compiler/GHC/Iface/Type.hs
- compiler/GHC/IfaceToCore.hs
- compiler/GHC/Linker/Loader.hs

The diff was not included because it is too large.

View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/df626244ff1c081da196adce80f2393008985301...3a835a3c6a5afce8aca4e29e51f884fbd2739a9a

-- 
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/df626244ff1c081da196adce80f2393008985301...3a835a3c6a5afce8aca4e29e51f884fbd2739a9a
You're receiving this email because of your account on gitlab.haskell.org.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-commits/attachments/20240416/c8299dd4/attachment-0001.html>