64位虚拟地址空间下内存碎片已无影响？为何主流语言GC仍需内存压缩？

尽管64位系统拥有远超32位的虚拟地址空间，内存碎片带来的直接"地址耗尽"风险大幅降低，但V8、JVM等主流引擎的垃圾回收器依然保留内存压缩步骤，核心原因在于碎片会从多维度影响系统性能与内存使用效率：

• 内存分配效率下滑：标记-清除后，空闲内存被分割成大量零散小块，分配大对象时需要遍历空闲块列表寻找足够大的空间，耗时显著增加；即使是小对象，零散的空闲块也会让分配逻辑更复杂，比如V8新生代对象晋升到老生代时，连续空间的缺失会导致晋升操作变慢。
• CPU缓存命中率降低：现代CPU的性能高度依赖缓存机制，碎片化内存会让存活对象分散在不同的内存页中，导致缓存行无法被有效利用，频繁的缓存失效会直接拖慢程序的执行速度。
• 物理内存与页表的额外开销：64位虚拟地址空间虽大，但物理内存是有限资源。碎片化的虚拟内存块会占用更多的页表项，导致页表膨胀，增加操作系统的内存管理开销；部分场景（如DMA操作）需要连续的物理内存块，碎片会导致这类分配请求失败。
• 分代回收的设计适配：V8、JVM都采用分代回收策略，老生代/老年代中存活对象占比高，标记-清除后积累的碎片会持续影响后续的分配与回收效率。内存压缩后，存活对象被紧凑排列，既为新对象分配提供了连续的大块空间，也简化了后续标记阶段的遍历逻辑，提升整体回收效率。

内容的提问来源于stack exchange，提问作者Brian Phan