Agree with what you wrote, but the GC system also imposes various forms of overhead that aren't reflected in the paper. Some are explicit: read/write barriers, finalizers, weak references, etc. Others are implicit in the language limitations necessary to support GC: no unions, no interior pointers, no pointer packing, no easy C interop, etc.
It's difficult to measure this overhead, because you design the program around the limitations of your language. The point is that, by rejecting GC, you gain certain flexibilities that can enable higher-performance designs. Merely removing GC from a Java app doesn't capture that.
It's difficult to measure this overhead, because you design the program around the limitations of your language. The point is that, by rejecting GC, you gain certain flexibilities that can enable higher-performance designs. Merely removing GC from a Java app doesn't capture that.