Another precise GC implementation #2418

rainers · 2018-12-27T18:18:28Z

This is a variation of #1603, but with less changes to the GC interface.

It works without adding an emplace function and new BlkAttr flags. Instead, it assumes knowledge about the implementation of dynamic arrays. The APPENDABLE attribute tells the GC to repeat the pointer bitmap given by the elements type info. In addition, a memory block in the large object pool with APPENDABLE set is assumed to contain data starting at offset 16.

There is no longer a bit reserved for each possible memory location for data in the large object pool. Instead the rtInfo of its type is saved for every page, so allocation has almost no overhead in that case. This also allows restricting scanning to the actual size of the type.

In case you are running the conservative GC, the overhead of having the option to switch to the precise GC is hardly noticable:

a bool check when creating an AA (it has to build the (key,value)-pair type info at runtime for precise information (this already happens if either has a destructor)
a bool check per allocation
a bool check during collection
some additional bytes for each type info containing the pointer bitmap (identical bitmaps merged).

The checks in the GC could be omitted by making the GC a template with preciseness as a parameter. That duplicates a lot of code, though. I'd reconsider that after #1924 is available so you can easily opt-in/out at link time.

In general, the precise version still has druntime/benchmark results 0-10% slower than the conservative GC on Win64, the difference is smaller for Win32. The tests don't produce many false pointers, though.

dlang-bot · 2018-12-27T18:18:29Z

Thanks for your pull request, @rainers!

Bugzilla references

Your PR doesn't reference any Bugzilla issue.

If your PR contains non-trivial changes, please reference a Bugzilla issue or create a manual changelog.

Testing this PR locally

If you don't have a local development environment setup, you can use Digger to test this PR:

dub fetch digger
dub run digger -- build "master + druntime#2418"

src/core/bitop.d

thewilsonator · 2018-12-28T12:00:11Z

src/gc/config.d

@@ -16,7 +16,7 @@ struct Config
 {
    bool disable;            // start disabled
    ubyte profile;           // enable profiling with summary when terminating program
-    string gc = "conservative"; // select gc implementation conservative|manual
+    string gc = "precise"; // select gc implementation conservative|precise|manual


Do we really want to change that default?

No, but I want the tests to run with the precise version. It should be reverted to "conservative" before merging.

src/gc/bits.d

src/rt/typeinfo/ti_cdouble.d

thewilsonator · 2018-12-28T12:03:11Z

src/rt/dmain2.d

@@ -65,11 +65,12 @@ extern (C) void _d_monitor_staticctor();
 extern (C) void _d_monitor_staticdtor();
 extern (C) void _d_critical_init();
 extern (C) void _d_critical_term();
-extern (C) void gc_init();
+extern (C) void gc_config() @nogc;


Does this really need to change?

The AA initialization reads the configuration once, but as the GC is initialized lazily, its configuration needs to be updated early. I don't like checking for "precise" in aaa_init(), though. It should be something other implementations can also configure.

As an alternative we could also opt to generate the RTInfo of the key/value pair unconditionally (maybe with some optimization for no pointers), in the hope that the compiler will generate the proper typeinfo eventually.

rainers · 2018-12-28T14:01:41Z

With respect to splitting it up: seperate PRs don't make much sense without the GC, so I'm a bit hesitant. I can make them seperate commits, though.

schveiguy · 2018-12-28T16:45:39Z

seperate PRs don't make much sense without the GC

The bitrange changes can stand alone.

rainers · 2018-12-28T19:24:01Z

The bitrange changes can stand alone.

Actually I thought the rtInfo changes could be made seperate as they might have an influence on other stuff, but the bit range functions are never called without the GC. I'll move both to seperate PRs to reduce the size of the changes.

rainers · 2018-12-30T10:52:45Z

rebased and added a test case to actually check skipping false pointers. I hope it's not going to be a cause for spurious failures as there is no guarantee no other false pointers exist.

rainers · 2018-12-30T10:55:59Z

src/gc/impl/conservative/gc.d

@@ -243,6 +247,39 @@ debug (LOGGING)

 /* ============================ GC =============================== */

+
+debug(PRINTF)
+void printGCBits(GCBits* bits)


I think these and other debug functions (LOGGING/PRINTF) should go to the bottom of the file, but that's for another PR.

wilzbach · 2019-01-04T14:30:52Z

src/gc/config.d

@@ -36,7 +36,7 @@ struct Config
        string s = "GC options are specified as whitespace separated assignments:
    disable:0|1    - start disabled (%d)
    profile:0|1|2  - enable profiling with summary when terminating program (%d)
-    gc:conservative|manual - select gc implementation (default = conservative)
+    gc:conservative|precise|manual - select gc implementation (default = conservative)


Just a reminder to update the spec too (or at least open up a PR, s.t. it doesn't get lost once this PR has been merged): https://github.com/dlang/dlang.org/blob/master/spec/garbage.dd#L386

dlang/dlang.org#2553

marcioapm · 2019-01-07T17:20:50Z

What is the impact? Would be nice to get some impact estimates on the changelog.

wilzbach · 2019-01-07T18:07:29Z

What is the impact? Would be nice to get some impact estimates on the changelog.

From @rainers's initial comment:

In general, the precise version still has druntime/benchmark results 0-10% slower than the conservative GC on Win64, the difference is smaller for Win32. The tests don't produce many false pointers, though.

rainers · 2019-01-12T09:07:24Z

BTW: the failure on buildkite is that the ocean library needs a tiny patch sociomantic-tsunami/ocean#663 that is already merged, but not yet available in a tagged version. As the default GC will be reverted to 'conservative' that shouldn't be a blocker.

The precisegc test can be a source of spurious errors though due to false pointers on the stack or in registers. Maybe it should be changed to just not crash?

rainers · 2019-01-14T08:22:09Z

The precisegc test can be a source of spurious errors though due to false pointers on the stack or in registers. Maybe it should be changed to just not crash?

The test now only produces some output instead of failing. It still verifies that not more objects are collected than expected.

I've also restored the conservative GC as the default now.

thewilsonator · 2019-01-14T09:14:17Z

Let me know when this is good to go.

rainers · 2019-01-16T22:21:54Z

I've made a (hopefully) last change: the dependency of aaa.d on gc.config.gc == "precise" was a bit ugly, so I changed fakeEntryTI to always generate the proper RTInfo for the key/value pair struct:

it is now available for other GC implementations, too
there is a lot happening when Impl is being created, the TypeInfo entry only adds a bit extra. It might be created a bit more often with the conservative GC, but is now optimized to be created less often for the precise GC
it is no longer limited to small key/value pairs (512 bytes for 64-bit process, 128 bytes for 32-bit process), but generates proper RTInfo for any size.
it has some direct unittests for proper RTInfo generation
long term, the TypeInfo for the key/value pair struct should be generated by the compiler and added to TypeInfoAssocArray, making all this runtime generation obsolete.

For testing purposes, the default GC is back to "precise", I'll revert it once tests have passed.

rainers · 2019-01-17T07:19:24Z

Let me know when this is good to go.

Tests passed (but ocean as expected), so I reverted to "conservative". I squashed commits to remove temporary changes. Good to go IMO.

rainers · 2019-01-17T08:40:43Z

Hooray! It's just been about 6 years since its first incarnation... ;-) The first PR was a bit later, though: #1022

rainers added the GC garbage collector label Dec 27, 2018

rainers requested review from andralex, Burgos, DmitryOlshansky, MartinNowak, schveiguy, WalterBright and wilzbach as code owners December 27, 2018 18:18

rainers mentioned this pull request Dec 27, 2018

precise GC without array support #1977

Closed

rainers force-pushed the gc_precise_appendable branch from fc43b86 to cb41c06 Compare December 28, 2018 08:59

rainers mentioned this pull request Dec 28, 2018

prepare for precise garbage collection sociomantic-tsunami/ocean#663

Merged

thewilsonator reviewed Dec 28, 2018

View reviewed changes

This was referenced Dec 28, 2018

add range operations to GCBits to help copying bitmaps in a precise GC #2421

Merged

generate pointer bitmap as RTInfo for TypeInfo.rtInfo() #2422

Merged

rainers force-pushed the gc_precise_appendable branch from cb41c06 to accbaac Compare December 30, 2018 10:50

rainers commented Dec 30, 2018

View reviewed changes

thewilsonator approved these changes Dec 30, 2018

View reviewed changes

rainers force-pushed the gc_precise_appendable branch 5 times, most recently from d893479 to a0fb48d Compare January 3, 2019 08:21

wilzbach reviewed Jan 4, 2019

View reviewed changes

rainers force-pushed the gc_precise_appendable branch from a0fb48d to 4e8ca00 Compare January 8, 2019 08:18

rainers mentioned this pull request Jan 11, 2019

Document precise GC dlang/dlang.org#2553

Merged

rainers force-pushed the gc_precise_appendable branch from 85fd082 to 4dce5d7 Compare January 12, 2019 09:20

rainers force-pushed the gc_precise_appendable branch from 6d79712 to efdeaa7 Compare January 16, 2019 22:08

rainers force-pushed the gc_precise_appendable branch from efdeaa7 to 7756913 Compare January 16, 2019 22:37

Add precise gc implementation

bb81ee4

rainers force-pushed the gc_precise_appendable branch from 7756913 to bb81ee4 Compare January 17, 2019 07:17

add changelog

2731088

thewilsonator added the auto-merge label Jan 17, 2019

dlang-bot merged commit c86e4a0 into dlang:master Jan 17, 2019

rainers mentioned this pull request Sep 28, 2019

Add precise gc implementation #1603

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Another precise GC implementation #2418

Another precise GC implementation #2418

rainers commented Dec 27, 2018 •

edited

Loading

dlang-bot commented Dec 27, 2018

thewilsonator Dec 28, 2018

rainers Dec 28, 2018

thewilsonator Dec 28, 2018

rainers Dec 28, 2018

rainers Dec 30, 2018

rainers commented Dec 28, 2018

schveiguy commented Dec 28, 2018

rainers commented Dec 28, 2018

rainers commented Dec 30, 2018

rainers Dec 30, 2018

wilzbach Jan 4, 2019

rainers Jan 11, 2019

marcioapm commented Jan 7, 2019

wilzbach commented Jan 7, 2019

rainers commented Jan 12, 2019

rainers commented Jan 14, 2019 •

edited

Loading

thewilsonator commented Jan 14, 2019

rainers commented Jan 16, 2019

rainers commented Jan 17, 2019

rainers commented Jan 17, 2019

Another precise GC implementation #2418

Another precise GC implementation #2418

Conversation

rainers commented Dec 27, 2018 • edited Loading

dlang-bot commented Dec 27, 2018

Bugzilla references

Testing this PR locally

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

rainers commented Dec 28, 2018

schveiguy commented Dec 28, 2018

rainers commented Dec 28, 2018

rainers commented Dec 30, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

marcioapm commented Jan 7, 2019

wilzbach commented Jan 7, 2019

rainers commented Jan 12, 2019

rainers commented Jan 14, 2019 • edited Loading

thewilsonator commented Jan 14, 2019

rainers commented Jan 16, 2019

rainers commented Jan 17, 2019

rainers commented Jan 17, 2019

rainers commented Dec 27, 2018 •

edited

Loading

rainers commented Jan 14, 2019 •

edited

Loading