[Git][ghc/ghc][wip/gc/nonmoving-nonconcurrent] 17 commits: rts/GC: Add an obvious assertion during block initialization

Ben Gamari gitlab at gitlab.haskell.org
Wed Jun 19 18:28:03 UTC 2019 


Ben Gamari pushed to branch wip/gc/nonmoving-nonconcurrent at Glasgow Haskell Compiler / GHC


Commits:
673a0e41 by Ömer Sinan Ağacan at 2019-06-19T18:17:47Z
rts/GC: Add an obvious assertion during block initialization

Namely ensure that block descriptors are initialized with valid
generation numbers.

Co-Authored-By: Ben Gamari <ben at well-typed.com>

- - - - -
1baa6967 by Ben Gamari at 2019-06-19T18:17:48Z
rts: Add Note explaining applicability of selector optimisation depth limit

This was slightly non-obvious so a note seems deserved.

- - - - -
4c866b4f by Ben Gamari at 2019-06-19T18:17:48Z
rts/Capability: A few documentation comments

- - - - -
d930ba9b by Ben Gamari at 2019-06-19T18:17:48Z
rts: Give stack flags proper macros

This were previously quite unclear and will change a bit under the
non-moving collector so let's clear this up now.

- - - - -
5f8f04b7 by Ben Gamari at 2019-06-19T18:17:48Z
rts/GC: Refactor gcCAFs

- - - - -
c8ee5c5f by Ben Gamari at 2019-06-19T18:17:48Z
rts: Fix macro parenthesisation

- - - - -
4f65be60 by Ben Gamari at 2019-06-19T18:17:48Z
rts: Fix CPP linter issues

- - - - -
ada2e65e by Ömer Sinan Ağacan at 2019-06-19T18:19:53Z
Disallow allocating megablocks, again

- - - - -
7f6f49e0 by Ömer Sinan Ağacan at 2019-06-19T18:20:02Z
Comments

- - - - -
64cf96a3 by Ben Gamari at 2019-06-19T18:20:36Z
Merge branches 'wip/gc/misc-rts' and 'wip/gc/aligned-block-allocation' into wip/gc/preparation

- - - - -
2413f243 by Ömer Sinan Ağacan at 2019-06-19T18:21:20Z
rts/StableName: Expose FOR_EACH_STABLE_NAME, freeSnEntry, SNT_size

These will be needed when we implement sweeping in the nonmoving
collector.

- - - - -
a5767c98 by Ben Gamari at 2019-06-19T18:21:20Z
rts: Disable aggregate-return warnings from gcc

This warning is a bit of a relic; there is little reason to avoid
aggregate return values in 2019.

- - - - -
17d23113 by Ömer Sinan Ağacan at 2019-06-19T18:21:21Z
rts/Scav: Expose scavenging functions

To keep the non-moving collector nicely separated from the moving
collector its scavenging phase will live in another file,
`NonMovingScav.c`. However, it will need to use these functions so
let's expose them.

- - - - -
437933b8 by Ben Gamari at 2019-06-19T18:21:21Z
rts: Introduce flag to enable the nonmoving old generation

This flag will enable the use of a non-moving oldest generation.

- - - - -
8d190c83 by Ben Gamari at 2019-06-19T18:21:21Z
rts: Introduce debug flag for non-moving GC

- - - - -
3f9bd459 by Ömer Sinan Ağacan at 2019-06-19T18:22:09Z
rts: Non-concurrent mark and sweep

This implements the core heap structure and a serial mark/sweep
collector which can be used to manage the oldest-generation heap.
This is the first step towards a concurrent mark-and-sweep collector
aimed at low-latency applications.

The full design of the collector implemented here is described in detail
in a technical note

    B. Gamari. "A Concurrent Garbage Collector For the Glasgow Haskell
    Compiler" (2018)

The basic heap structure used in this design is heavily inspired by

    K. Ueno & A. Ohori. "A fully concurrent garbage collector for
    functional programs on multicore processors." /ACM SIGPLAN Notices/
    Vol. 51. No. 9 (presented by ICFP 2016)

This design is intended to allow both marking and sweeping
concurrent to execution of a multi-core mutator. Unlike the Ueno design,
which requires no global synchronization pauses, the collector
introduced here requires a stop-the-world pause at the beginning and end
of the mark phase.

To avoid heap fragmentation, the allocator consists of a number of
fixed-size /sub-allocators/. Each of these sub-allocators allocators into
its own set of /segments/, themselves allocated from the block
allocator. Each segment is broken into a set of fixed-size allocation
blocks (which back allocations) in addition to a bitmap (used to track
the liveness of blocks) and some additional metadata (used also used
to track liveness).

This heap structure enables collection via mark-and-sweep, which can be
performed concurrently via a snapshot-at-the-beginning scheme (although
concurrent collection is not implemented in this patch).

The mark queue is a fairly straightforward chunked-array structure.
The representation is a bit more verbose than a typical mark queue to
accomodate a combination of two features:

 * a mark FIFO, which improves the locality of marking, reducing one of
   the major overheads seen in mark/sweep allocators (see [1] for
   details)

 * the selector optimization and indirection shortcutting, which
   requires that we track where we found each reference to an object
   in case we need to update the reference at a later point (e.g. when
   we find that it is an indirection). See Note [Origin references in
   the nonmoving collector] (in `NonMovingMark.h`) for details.

Beyond this the mark/sweep is fairly run-of-the-mill.

[1] R. Garner, S.M. Blackburn, D. Frampton. "Effective Prefetch for
    Mark-Sweep Garbage Collection." ISMM 2007.

Co-Authored-By: Ben Gamari <ben at well-typed.com>

- - - - -
439e50c3 by Ben Gamari at 2019-06-19T18:22:09Z
testsuite: Add nonmoving WAY

This simply runs the compile_and_run tests with `-xn`, enabling the
nonmoving oldest generation.

- - - - -


30 changed files:

- docs/users_guide/runtime_control.rst
- includes/Rts.h
- includes/rts/Flags.h
- includes/rts/storage/Block.h
- includes/rts/storage/GC.h
- includes/rts/storage/InfoTables.h
- includes/rts/storage/TSO.h
- libraries/base/GHC/RTS/Flags.hsc
- rts/Capability.c
- rts/Capability.h
- rts/PrimOps.cmm
- rts/RtsFlags.c
- rts/RtsStartup.c
- rts/Schedule.c
- rts/Schedule.h
- rts/StableName.c
- rts/StableName.h
- rts/Threads.c
- rts/Trace.h
- rts/Weak.c
- rts/ghc.mk
- rts/rts.cabal.in
- rts/sm/BlockAlloc.c
- rts/sm/Evac.c
- rts/sm/GC.c
- rts/sm/GC.h
- rts/sm/GCAux.c
- rts/sm/GCThread.h
- + rts/sm/NonMoving.c
- + rts/sm/NonMoving.h


The diff was not included because it is too large.


View it on GitLab: https://gitlab.haskell.org/ghc/ghc/compare/fbaf283cc9d30f3e6fc4e5815ce1c9674d41d5d6...439e50c3d1f575d6886f3f8fdac937b8d93f10a0

-- 
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/compare/fbaf283cc9d30f3e6fc4e5815ce1c9674d41d5d6...439e50c3d1f575d6886f3f8fdac937b8d93f10a0
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/20190619/073ecb9a/attachment.html>

More information about the ghc-commits mailing list