Not really. Allocation and deallocation for a system that does not support object movement (and hence compaction) is inherently non-trivial. In most modern GCs

Not really. Allocation and deallocation for a system that does not support object movement (and hence compaction) is inherently non-trivial. In most modern GCs allocation is bump-the-pointer with TLABs, you can get cheaper than that. If the first generation GC is a copying GC you pay absolutely nothing for collecting a dead object. Compare that to explicit allocation/deallocation schemes. The biggest problem with GC however is not the cost of allocation/deallocation but the fact that it's pretty hard to make GCs incremental at a very fine-grain level. Java, btw, at least with Hotspot JVM, does escape analysis, that will allocate non-escaping objects on stack. Heck, these objects may even just end up in a register (with unused data members discarded).