2 ms·

> Forwarding is not really a problem, the algorithm is well known I understand it’s not a problem to make forwarding work, but making it not suck doesn’t seem

> Forwarding is not really a problem, the algorithm is well known I understand it’s not a problem to make forwarding work, but making it not suck doesn’t seem easy. My impression from the literature was that a moving collector requires either an O(heap) pause + write barrier (to rewrite all pointers at once), or a read barrier (to catch stale pointers on the fly), and neither of these options is all that pleasant—read barriers in particular are often decried as expensive. On the other hand, the articles doing the decrying are usually using a SPARC or the like as their reference point for up-to-date powerful hardware, so I’ve no idea how true any of this is in today’s superscalar world.

kaba0 3y ago
Can’t tell you much about the performance impact of a write barrier, but Java’s new ZGC went with read barriers (trading off some throughput) while making the pause times independent of heap size, not sure if that’s what you were referencing, but if not you might find it interesting.
chubot 3y ago
Right, that's why moving collectors are only used in the young/fast generation, for reasons of space and time. - you don't want the 2x space overhead for your entire heap - I don't know that any copying/moving GCs are incremental. You just collect the young objects all at once -- the CLR says they aim to make it cost as much as a page fault. I don't know the common policies offhand, but I imagine the young generation is like 512 KB to 4 MB, so it will fit in caches. The whole point is bump allocation and locality I don't have experience with GCs where the mutator dereferences through a pointer -- my impression is that's rare, but I'm not sure. In the normal Cheney collector, the forwarding pointers are only used during the algorithm itself. It has to update pointers for the mutator, but after that, the mutator does normal dereferencing.

kaba0 3y ago

Can’t tell you much about the performance impact of a write barrier, but Java’s new ZGC went with read barriers (trading off some throughput) while making the pause times independent of heap size, not sure if that’s what you were referencing, but if not you might find it interesting.

chubot 3y ago

Right, that's why moving collectors are only used in the young/fast generation, for reasons of space and time. - you don't want the 2x space overhead for your entire heap - I don't know that any copying/moving GCs are incremental. You just collect the young objects all at once -- the CLR says they aim to make it cost as much as a page fault. I don't know the common policies offhand, but I imagine the young generation is like 512 KB to 4 MB, so it will fit in caches. The whole point is bump allocation and locality I don't have experience with GCs where the mutator dereferences through a pointer -- my impression is that's rare, but I'm not sure. In the normal Cheney collector, the forwarding pointers are only used during the algorithm itself. It has to update pointers for the mutator, but after that, the mutator does normal dereferencing.