| |
![Walter Bright's Gravatar profile Gravatar of Walter Bright](//www.gravatar.com/avatar/12afde220e4ce94ad89f6598f7686f32?d=identicon&s=32) | Posted by Walter Bright in reply to Anonymouse | Permalink Reply |
|
Walter Bright ![Walter Bright's Gravatar profile Gravatar of Walter Bright](//www.gravatar.com/avatar/12afde220e4ce94ad89f6598f7686f32?d=identicon&s=80)
Posted in reply to Anonymouse
| On 3/31/2024 8:52 AM, Anonymouse wrote:
> We don't have a moving, recompacting, generational GC though. This doesn't invalidate the points he makes, but it's not quite apples vs apples.
D doesn't have a moving collector because if there is a pointer into a GC allocated object, and the object is moved, then the pointer is pointing to garbage. There goes memory safety out the window.
It is possible to detect those pointers and "pin" that particular allocation so it doesn't move, and I wrote such a collector long ago. It's called a partially compacting collector. (I thought I had invented this, but then later found a paper on it.)
This could be done for D, it isn't that hard.
As for a generational collector, this relies on the collector being notified when an allocated object gets mutated. This requires adding a "write gate" to the generated code. All writes through pointers execute additional code to notify the collector that the object changed.
This is fine if all memory is allocated via the collector. But in a mixed allocator environment, you're looking at a severe performance cost. So D doesn't do that.
At one point I did implement a scheme whereby the the GC's pages were marked "read only", and so when a write was done, the CPU would seg fault. A handler was made for the seg fault which notified the GC that it changed, and made the page writeable again. This involved no extra code for writes.
Unfortunately, benchmarking showed that it was way too slow to be viable. Oh well.
|