D future ...

Walter Bright via Digitalmars-d digitalmars-d at puremagic.com
Wed Dec 21 23:44:54 PST 2016


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.



More information about the Digitalmars-d mailing list