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.
