java - 了解 Hotspot JVM 进程的内部碎片属性

Question

对于堆内和堆外分配。堆上 - 在三个主要垃圾收集器的上下文中:CMS、Parallel Old 和 G1。

目前我所知道的(或认为我知道的):

• 所有对象(堆上)分配都四舍五入到 8 字节边界(或 2 的更大幂，由 -XX:ObjectAlignmentInBytes 配置。
• G1
  • 对于小于区域大小(1 到 32 MB，可能在 堆大小/2048 左右)的堆上分配，没有内部碎片，因为没有必要，因为分配器从不“填补漏洞”。
  • 对于较大区域大小的分配，它会将分配向上舍入到区域大小。 IE。 区域大小 + 1 字节 的分配非常不吉利，它浪费了将近 50% 的内存。

• 对于CMS，我找到的唯一相关信息是

  Naturally old space PLABs mimic structure of indexed free list space. Each thread preallocates certain number of chunk of each size below 257 heap words (large chunk allocated from global space).

  来自 http://blog.ragozin.info/2011/11/java-gc-hotspots-cms-promotion-buffers.html . 据我了解，所谓的“全局空间”是主要的旧空间。

问题:

• 以上说法正确吗？
• CMS 中主要旧空间的碎片属性是什么？超过“257 个堆字”的分配怎么办？
• 如何使用 Parallel Old GC 管理旧空间？
• Hotspot JVM 是使用系统内存分配器进行堆外分配，还是使用特定的分配器重新管理它？

更新。讨论主题:https://groups.google.com/forum/#!topic/mechanical-sympathy/A-RImwuiFZE

Answer 1

• 据我所知，上述陈述是正确的，尽管 CMS 上的位缺少很多上下文来解释它。
• CMS 容易出现碎片(在旧空间，CMS 运行的地方)，这是它的主要缺陷之一。如果它碎片太多，它可能偶尔不得不停止世界并进行全标记和(滑动)压缩以消除碎片，这会导致应用程序出现大的停顿。正是这个缺陷经常被引用为开发 G1 的原因。一些系统(例如 HBase)故意使用固定大小的 block 进行大部分分配，以防止或显着减少碎片化 CMS，从而避免长时间的 stop-the-world 暂停。
• ParallelOldGC(或一般的“旧 GC”)不会碎片化。对象被保留在旧堆中，当它用完空间时，将运行一个完整的标记和压缩循环。它可以比任何其他分配器更快地执行此完整 GC，但是每 2 GB 堆的典型运行时间为 1 秒，这对于大型堆或对延迟敏感的应用程序来说可能太长了。
• Hotspot 根据目的使用了各种堆外分配策略。分配 native 字节缓冲区不同于它自己对编译代码或分析数据的分配。我无法在这里权威地回答任何细节，但我只能假设其中大部分不使用系统分配器，否则 Hotspot 的性能不会像它那样好。此外，还有一些可以调整的参数来控制这个空间的一部分，例如-XX:ReservedCodeCacheSize，这表明这样的内存区域是通过间接管理的，而不是直接通过系统分配器管理的。简而言之，如果系统分配器直接用于热点中的任何细粒度分配，我会感到相当惊讶。