Maybe D is right about GC after all !

[Neia Neutuladh]

On Thursday, 21 December 2017 at 11:08:23 UTC, thedeemon wrote:
> A good GC requires the compiler to add special bookkeeping code 
> to every pointer mutation in the heap, and to generate special 
> data for each function to help GC find all the pointers in its 
> stack and closures.

Precise stack scanning requires compiler support, yes.

You can use mprotect(2) for write barriers, and that doesn't 
require compiler support. It's relatively inefficient, though.

> Without such help from the compiler you can't make anything 
> decent, just a slow half-conservative GC that scans whole heap 
> every time and leaks memory being unable to tell whether some 
> stack value is a number or a pointer.

Numbers tend very much to be small, and pointer values tend not 
to be small, especially on 64-bit. So it shouldn't be that common 
to confuse the two. It should be more common to confuse floating 
point values for pointers, but the odds go down as address space 
increases.

Actually, there's an idea. Instrument real-world code to 
determine what address ranges are least likely to be hit by a 
false pointer, then try to arrange the GC to concentrate 
allocations in those ranges.

> Go compiler includes that special bookkeeping, so the running 
> code is a bit slower but GC can be fast, its GC can analyze 
> heap concurrently, it can clean it by parts. With C you can't 
> do that. D compiler also doesn't insert that bookkeeping code, 
> so running code is fast as C but GC is slow and sloppy.

D also offers better support for not allocating than Go. 
const/immutable to reduce defensive copies. 
std.experimental.allocator. GC.addRange for when you mix the GC 
with manually allocated memory.

Go's only objective with its collector is to reduce the maximum 
pause time, and it's not bad at that. The JVM is going for low 
overhead with its default parameters, and you can muck about with 
it to prioritize low pause times; it's better than Go at both. D 
is currently going for predictability.