[Git][ghc/ghc][wip/gc/nonmoving-nonconcurrent] 9 commits: rts: Fix macro parenthesisation

Fri May 17 18:04:20 UTC 2019

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

Commits:
48504bf5 by Ben Gamari at 2019-05-16T01:46:28Z
rts: Fix macro parenthesisation

- - - - -
a2b74bc7 by Ben Gamari at 2019-05-16T16:31:34Z
Merge branch 'wip/gc/misc-rts' into wip/gc/preparation

- - - - -
a53d4411 by Ömer Sinan Ağacan at 2019-05-16T16:37:44Z
rts/StableName: Expose FOR_EACH_STABLE_NAME, freeSnEntry, SNT_size

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

- - - - -
0444df2a by Ben Gamari at 2019-05-16T20:39:49Z
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.

- - - - -
fb0e64f9 by Ömer Sinan Ağacan at 2019-05-16T20:40:20Z
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.

- - - - -
bf21f978 by Ben Gamari at 2019-05-17T00:42:44Z
rts: Introduce flag to enable the nonmoving old generation

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

- - - - -
fb1513a7 by Ben Gamari at 2019-05-17T00:42:44Z
rts: Introduce debug flag for non-moving GC

- - - - -
242f9ff8 by Ömer Sinan Ağacan at 2019-05-17T17:00:12Z
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>

- - - - -
24c946a5 by Ben Gamari at 2019-05-17T17:00:12Z
testsuite: Add nonmoving WAY

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

- - - - -

28 changed files:

- docs/users_guide/runtime_control.rst
- includes/rts/Flags.h
- includes/rts/storage/Block.h
- includes/rts/storage/InfoTables.h
- libraries/base/GHC/RTS/Flags.hsc
- rts/Capability.c
- rts/Capability.h
- rts/RtsFlags.c
- rts/RtsStartup.c
- rts/StableName.c
- rts/StableName.h
- rts/Trace.h
- rts/Weak.c
- rts/ghc.mk
- 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
- + rts/sm/NonMovingMark.c
- + rts/sm/NonMovingMark.h
- + rts/sm/NonMovingScav.c
- + rts/sm/NonMovingScav.h
- + rts/sm/NonMovingSweep.c
- + rts/sm/NonMovingSweep.h
- rts/sm/Sanity.c

The diff was not included because it is too large.

View it on GitLab: https://gitlab.haskell.org/ghc/ghc/compare/68e5616f404b14a0e02b7d719bf1d50865dba44b...24c946a53b690984c45e6522d90603844ae8730b

-- 
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/compare/68e5616f404b14a0e02b7d719bf1d50865dba44b...24c946a53b690984c45e6522d90603844ae8730b
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/20190517/4c4632b6/attachment.html>