GC: optimize sweeping and allocation

[rainers]

The druntime-benchmarks mostly don't show a huge difference for these changes, but rand_small changes from

rand_small       3.637 s,    12 MB, 7642 GC 1262 ms, Pauses  444 ms <    0 ms

on win64 to

rand_small       3.260 s,    12 MB, 7642 GC 1080 ms, Pauses  439 ms <    0 ms

Results are more impressive for the extended vdparser test also shown here:

win32: 10.110 s, 1035 MB,   11 GC 1660 ms, Pauses 1361 ms <  562 ms
win64: 10.740 s, 1355 MB,   13 GC 1370 ms, Pauses 1030 ms <  385 ms

is changed to

win32: 7.600 s, 1035 MB,   11 GC 1594 ms, Pauses 1309 ms <  536 ms
win64: 7.570 s, 1419 MB,   13 GC 1410 ms, Pauses 1078 ms <  417 ms

[dlang-bot]

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#2520"

[rainers]

Ouch, sweep and recover cannot be combined if dtors of dead objeccts still access other dead objects. Closing for now...

[Geod24]

Ouch, sweep and recover cannot be combined if dtors of dead objeccts still access other dead objects. Closing for now...

The dtors are not supposed to access GC allocated objects though, as the order in which they run is not guaranteed. So isn't that exhibiting an issue in current current ?

[rainers]

The dtors are not supposed to access GC allocated objects though, as the order in which they run is not guaranteed. So isn't that exhibiting an issue in current current ?

It seems to happen in std.regex for reference counting. We could enforce it (by allowing crashes) but it also pretty much restricts even more what can sensibly be done in a dtor. Right now, other dead objects without a dtor are still in a valid state.

[rainers]

Added WIP: need to cleanup the history now that part of the changes have been reverted...

[Geod24]

It seems to happen in std.regex for reference counting.

Shouldn't that be done with malloc / free instead ?

[rainers]

Shouldn't that be done with malloc / free instead ?

Sorry, can't tell. The regex code is indistinguishable from magic. I just noted that a pointer in a dead object was modified by 1.

[Geod24]

Shall we summon our wizard in chief, @DmitryOlshansky ?

[rainers]

I'll split this into a couple of smaller PRs.