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