[WIP] precise GC as presented at DConf 2013

[rainers]

This is the precise GC as presented at DConf 2013. It generates pointer bitmaps for each type T using RTInfo!T and stores a bitmap alongside pool memory to use for following only pointer references.

RTInfo generation isn't working properly at the moment (needs dlang/dmd#3958 or dlang/dmd#2480), but using the compiler default will just scan some types conservatively instead of precisely.

Some notes:

• only the heap is scanned precisely, not stacks or the data/TLS segments
• compilation is slower: I measured 3:46min for the "quick" test suite on Win32 instead of 3:26 for master (we might need a special trait to avoid a lot of CTFE)
• execution is slower: the allocation heavy druntime benchmarks take 58sec instead of 51sec (unfortunately there are 2 list-benchmark which don't give reliable timings).
• associative arrays need a dirty hack to support precise scanning of the key/value pairs in Entry: the TypeInfo for that is geneerated at runtime and stored in the Impl struct of each instance.
• dynamic arrays need to "re-emplace" their type info pointer bitmaps for large arrays, because data is "sometimes" placed at an offset of 16 bytes

I'm opening this as a pull request to verify building on other platforms aswell as making it more publically visible and open for review/discussion.

I plan to create another version that stores type info per allocation block and use this during scanning. This can avoid the troubles for the arrays, but will not allow reassigning new types to partial memory blocks (e.g. when using std.emplace on fields of a class).

[rainers]

The tests are currently not passing due to https://issues.dlang.org/show_bug.cgi?id=13738 (dlang/dmd#4147) and https://issues.dlang.org/show_bug.cgi?id=13736 (dlang/dmd#4143).

[rainers]

I've tried to reduce the additional compilation time by replacing some CTFE code with cachable template instances. For the dmd test suite this brought the gap dwon from 20 seconds to about 15 seconds.

Considering that the test suite spends most of the time not compiling, I benchmarked building Visual D: the debug version takes about 16% longer (22 seconds instead of 19), the release version is even worse with 23% (43 seconds instead 35). Please note that Visual D imports most of the Windows SDK and the full Visual Studio SDK, so it contains a lot of struct definitions and interfaces.

I guess for this to be acceptable we must make the pointer bitmap a compiler trait.

The binary size overhead of the release version was about 0.5% (2491kB instead of 2480kB).

[rainers]

I guess for this to be acceptable we must make the pointer bitmap a compiler trait.

I have implemented the trait here: dlang/dmd#4192
My tests don't show any measurable loss of compilation speed when using the trait, plus it avoids troubles when using Unqual on shared(T[N]).

[rainers]

I plan to create another version that stores type info per allocation block and use this during scanning.

This is now available here: #1057

[MartinNowak]

unfortunately there are 2 list-benchmark which don't give reliable timings

Use avgtime and take the minima of 10 or 100 runs, that works because noise in benchmarks is mostly additive.

[rainers]

Use avgtime and take the minima of 10 or 100 runs, that works because noise in benchmarks is mostly additive.

I use it sometimes, but I'm unsure about a sole minimum being very representative (on a mobile processor where a lot of magic goes). If there are false pointers, they sometimes don't go away by just rerunning the same program. When comparing precise to imprecise scanning, you might even want to see the effects of false pointers ;-)

At the moment, I don't see these shaky results, though.

[rainers]

Updated to recent changes of the GC. With the getPointerBitmap trait, there is no longer a compile time penalty, but it's still 0-20% slower in the benchmarks, mostly during allocation. The benchmarks don't suffer much from false pointers, though.

[MartinNowak]

Twice as big and can't be returned in registers, that looks expensive.

[MartinNowak]

Might be better to use a second stack for the pools in parallel.

[rainers]

I was hoping for any function calls dealing with ScanRange to be inlined, though I didn't check yet.

[MartinNowak]

Or you might try to pack the struct and change passing and return to Range + Pool*, using ref return for pop.

[rainers]

I checked the disassembly: it's all inlined AFAICT. So the struct needs 50% more memory (there is no padding), but there is probably not a lot we can do here. The non-precise version might use the Range struct though, so we could templatize ToScanStack on that type.
Indexing might be a little more expensive than with a struct size of 8/16, so we could also use a pointer to walk the stack.

[MartinNowak]

I'll have a look at the benchmarks, we definitely need to get this fast enough.

[MartinNowak]

You should move this test to before p1 is dereferenced. If something isn't a pointer we should perform as little work as possible. This loop is key to make this thing fast.

[rainers]

The previous versions had some optimization to this respect, but I wanted to make minimal changes to begin with. The benchmarks don't show a large increase in scanning time, the preformance decrease is caused by setting the pointer bitmaps.

[MartinNowak]

But it might be possible to make up for this by improving the marking time.

[rainers]

I just tried it: without further optimizations, moving the code above p = *p1 slows down marking by up to 10%. (Win32 on i7 mobile)

[rainers]

This change is unrelated, but the current version causes a range error when building druntime without -release.
The return value of _d_newarrayU is confusing, as it actually returns the length for T[], not void[]. It should rather just return void*

[MartinNowak]

Delay until we have an idea how to get this fast, e.g. 2.068?

[rainers]

Delay until we have an idea how to get this fast, e.g. 2.068?

Yes. I'm also waiting for either dlang/dmd#2480 or dlang/dmd#3958 making some progress. This GC implementation still works with the incomplete RTInfo by making conservative assumptions, though.

[rainers]

Rebased.

[DemiMarie]

What is the status of this? Will this be merged?

[rainers]

Rebased in preparation of the PR's first anniversary.

[PetarKirov]

@rainers what's the status of this PR? Are there any serious showstoppers before this can be merged, or is it only the performance that you want to improve?

[rainers]

Are there any serious showstoppers before this can be merged, or is it only the performance that you want to improve?

AFAICT this is good enough to be included. @MartinNowak has some reservations regarding performance, but I don't see a faster solution in the near future. I tried some microtuning in the past, but that is rather frustrating when done against the dmd backend.

Before actual merging I'd make it opt-in rather than opt-out. Presice scanning is enabled in this PR so the auto-tester is actually running any of the new code.

What's missing is some documentation (some notes on what has to be done to get your manually managed memory scanned precisely), but I'd rather postpone writing it until this PR has a good chance of being merged.

[rainers]

Rebased. Needs dlang/dmd#5566 to build phobos unittests, though.

[DemiMarie]

I would love to see this. Next step is incremental concurrent collection.

[MartinNowak]

Next step is incremental concurrent collection.

It is unlikely that we'll add write barriers, so we can't use classical techniques (e.g. generational) for incremental collection.

[rainers]

Closing in favor of #1603