2 ms·
The reason why their allocator is faster than Boehm isn't because of conservative stack scanning. You can move objects while using conservative stack scanning.
by pizlonator 1y ago
The reason why their allocator is faster than Boehm isn't because of conservative stack scanning.
You can move objects while using conservative stack scanning. This is a common approach. JavaScriptCore used to use it.
You can have super fast allocation in a non-moving collector, but that involves an algorithm that is vastly different from the Boehm one. I think the fastest non-moving collectors have similar allocation fast paths to the fastest moving collectors. JavaScriptCore has a fast non-moving allocator called bump'n'pop. In Fil-C, I use a different approach that I call SIMD turbosweep. There's also the Immix approach. And there are many others.