On 12/21/2016 7:57 PM, Chris Wright wrote:
You can implement write barriers as runtime calls, but omit them in @nogc code.
@nogc code is code that doesn't allocate from the gc. It can still write to gc allocated objects, however, so that idea won't work.
However, this would be costly -- it's an expensive technique in general; the current GC mallocs each object instead of mmaping a range of memory; and in D you can't move heap objects safely,
You can if using a "mostly copying" generational collector, which is what I did long ago. It works.
so you can't distinguish generations based on pointers (you'd have to mark GC data structures, and it's O(log n) to find the right one). You can implement write barriers with mprotect. However, this won't give you good granularity. You just know that someone wrote something to an 8 kilobyte block of memory that has a pointer in it somewhere. This requires the GC to use mmap instead of malloc, and it is strongly encouraged not to put pointer-free objects in the same page as objects with pointers.
Using mprotect works, and I wrote a generational collector using it long ago, but it is even slower.
