Maybe D is right about GC after all !

[thedeemon]

On Thursday, 21 December 2017 at 22:45:23 UTC, Neia Neutuladh 
wrote:
> You can use mprotect(2) for write barriers, and that doesn't 
> require compiler support. It's relatively inefficient, though.

As I understand it's prohibitively inefficient, that's why this 
approach is not used by any real world GC.

>> 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.

Floating point values are also numbers, real numbers. ;)
Indeed in 64 bits our current GC is not too leaky. But still 
people encounter leaks occasionally, when trying to make long 
running services.

> 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.

I'm not sure all major OSs will let you choose freely address 
ranges when allocating memory.

> 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.

Sure, carefully written D code has all the means to outperform Go.