Hannes Siebenhandl authored 1 year ago and Marge Bot committed 1 year ago

During heap analysis, we noticed that during generation of
'mi_extra_decls' we have lots of duplicates for the instances:

* `IfaceTyConInfo NotPromoted IfaceNormalTyCon`
* `IfaceTyConInfo IsPromoted IfaceNormalTyCon`

which should be shared instead of duplicated. This duplication increased
the number of live bytes by around 200MB while loading the agda codebase
into GHCi.

These instances are created during `CoreToIface` translation, in
particular `toIfaceTyCon`.

The generated core looks like:

    toIfaceTyCon
      = \ tc_sjJw ->
          case $wtoIfaceTyCon tc_sjJw of
          { (# ww_sjJz, ww1_sjNL, ww2_sjNM #) ->
          IfaceTyCon ww_sjJz (IfaceTyConInfo ww1_sjNL ww2_sjNM)
          }

whichs removes causes the sharing to work propery.

Adding explicit sharing, with NOINLINE annotations, changes the core to:

    toIfaceTyCon
      = \ tc_sjJq ->
          case $wtoIfaceTyCon tc_sjJq of { (# ww_sjNB, ww1_sjNC #) ->
          IfaceTyCon ww_sjNB ww1_sjNC
          }

which looks much more like sharing is happening.
We confirmed via ghc-debug that all duplications were eliminated and the
number of live bytes are noticeably reduced.

Alan Zimmerman authored 1 year ago and Marge Bot committed 1 year ago

Closes #24533

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

Without an understanding of immutable vs. mutable memory, the index
primop family have a potentially non-intuitive type signature:

    indexOffAddr :: Addr# -> Int# -> a
    readOffAddr  :: Addr# -> Int# -> State# d -> (# State# d, a #)

indexOffAddr# might seem like a free generality improvement, which it
certainly is not!

This change adds a brief note on mutability expectations for most
index/read/write access primops.

Cheng Shao authored 1 year ago and Marge Bot committed 1 year ago

This commit fixes an unnoticed out-of-bound memory access of genSym on
32-bit. ghc_unique_inc is 32-bit sized/aligned on 32-bit platforms,
but we mistakenly treat it as a Word64 pointer in genSym, and
therefore will accidentally load 2 garbage higher bytes, or with a
small but non-zero chance, overwrite something else in the data
section depends on how the linker places the data segments. This
regression was introduced in !11802 and fixed here.

Cheng Shao authored 1 year ago and Marge Bot committed 1 year ago

This reverts commit 615eb855. It was
originally intended to fix #24449, but it was merely sweeping the bug
under the rug. 3836a110 has properly
fixed the fragile test, and we no longer need the C version of genSym.
Furthermore, the C implementation causes trouble when compiling with
clang that targets i386 due to alignment warning and libatomic linking
issue, so it makes sense to revert it.

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

This is necessary for prereleases, where GHCup accesses the release via
`$ver/`

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

To do so is unsafe as we have no way of identifying references to
symbols provided by the object.

Fixes #24513. Fixes #23993.

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

The heap census may contain references (e.g. `Counter.identity`) to
static data which must be available when the census is reported at the
end of execution.

Fixes #24512.

Bumps haddock submodule.

The old `combine` approach was quite fragile due to use of filename
globbing. Moreover, it didn't parallelize well. This refactoring
makes the goal more obvious, parallelizes better, and is more robust.

This was previously mistakenly added to the GHC 9.8 release notes.

It appears that this was

This provides PVP compliance while maintaining a clear correspondence
between GHC releases and `ghc-internal` versions.

1 MByte was just too tight and failed intermittently on some platforms
(e.g. CentOS 7). Bumping the limit to 8 MByte should provide sufficient
headroom.

Fixes #23139.

In particular this fails on platforms without `dlinfo`. I plan to
address this but not before 9.10.1-alpha1.

I will fix this but not in time for 9.10.1-alpha1

Vladislav Zavialov authored 1 year ago and Marge Bot committed 1 year ago

* Mention TypeAbstractions in 9.10.1-notes.rst
* Set the status to "Experimental".
* Add a "Since: GHC 9.x" comment to each section.

Don't allocate a Ptr constructor per frame.

Here we add the unit ID to the info table provenance structure.

This allows us to shave a 64-bit word off of the packed IPE entry size.

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.

Vladislav Zavialov authored 1 year ago and Marge Bot committed 1 year ago

This should have been done in 0f0c53a5 but I missed it.

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

There is nothing platform-dependent about our GOT implementation and
GOT support is needed by `T24171` on i386.