A fast copying collector for D would require write barriers: using memory barriers everytime a pointer is written. This has a runtime cost.
> which runs at every allocation.
The article explains in great depth that this is not the case.
> which runs at every allocation.
The article explains in great depth that this is not the case.
As does using a conservative/"very slow" GC. I'm sceptical, but it may be that D's situation means trading a pervasive slowness (if the parent is true, I don't know) for no write barriers is the right choice, differing to the conventional wisdom from other languages, but that's the argument you need to make, not just that write barriers are slow.
What workaround do you have in mind, and how does it not apply to write barriers?
Walter Bright was right about segmented stacks, I'm tempted to think he's right about write barriers too.
However, if you don't know statically what kind of heap a pointer is in, you're going to have a poorly performing GC system no matter what.
This is not how garbage collectors work. At all.
[1] http://blog.ragozin.info/2011/06/understanding-gc-pauses-in-...
Their purpose is to capture some information about the updated pointer that the GC can then use to avoid a full heap scan. Card marking marks a 'region' as dirty (such as 128/256/512 bytes of memory). This buffer recording the dirty/clean areas is rescanned as part of the evacuation of the generation being collected. Any pointers to the generation then being collected are updated.
Sequential store buffers (SSBs) can be used to record the address of the object being updated or a pointer to the pointer itself. Again rescanned during collection. SSBs can be easily thread-local avoiding the need for thread synchronisation, except during a collection cycle which already requires thread synchronisation.
Write barrier tend to be optimised heavily as they're used quite frequently. The use of atomic barriers or branch instructions (barring fast path exits) would inhibit performance.
No, for two reasons:
1. Write barriers are not necessary if an object is in a nursery, which is true for most objects per the generational hypothesis. This is trivial to check based on the pointer value.
2. You can have thread local remembered sets.
> To make fast GC it needs to be generational, but generational GC means write barriers: you can't just freely mutate memory, every pointer mutation must be accompanied by additional bookkeeping.
I guess that in the context of D generations are not possible or practical. If you have any idea why it should be possible, you may write a DIP.
I'm skeptical, however, if it will offer a real improvement.
Yes but what when it leaves it?
You have to update all pointers to another location.
When it passes to the Gen2 slab all references that point to it need to be updated, and those changes need to propagate to all threads, and all cores. The simplest way to do this is a memory barrier.
Well the real simplest way is just "never multi-thread" and this is OCaml's GC is so fast. No write barriers, 1 thread only, final destination.