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

Question

用于堆上分配和堆外分配。堆-在三大垃圾收集器的上下文中: CMS、ParallOldandandG1。

我所知道(或认为我知道的)到目前为止：

• 所有对象(堆上)分配都被舍入到8个字节的边界(或者-XX:ObjectAlignmentInBytes配置的更大的2次方)。
• G1
  • 对于堆上分配小于区域大小(1到32 MB，可能在堆大小/2048左右)，没有内部碎片，因为没有必要，因为分配程序从不“填补漏洞”。
  • 对于较大的区域大小的分配，它将分配到区域大小。也就是说，分配区域大小+1字节是非常不幸的，它浪费了几乎50%的内存。

​

• 对于CMS，我发现的唯一相关信息是 自然老空间PLAB模仿索引自由列表空间的结构。每个线程分配每个大小低于257个堆字的一定数量的块(从全局空间分配的大块)。

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

问题：

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

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

Answer 1

• 据我所知，上面的陈述是正确的，尽管关于CMS的部分缺少很多上下文来解释它。
• CMS容易分散(在其运行CMS的旧空间中)，这是它的主要缺陷之一。如果它的碎片太多，它可能偶尔不得不停止世界，做一个完整的标记和(滑动)压缩以删除碎片，这将导致应用程序中的大量停顿。正是这个缺陷经常被认为是开发G1的原因。有些系统(例如HBase)有意识地使用固定大小的块来分配它们的大部分资源，以防止或显著减少分散的CMS，以避免长时间的停止-世界停顿。
• ParallelOldGC (或一般的“旧GC”)不破片。对象被固定到旧堆中，当它耗尽空间时，将运行一个完整的标记和紧凑的循环。它可以比任何其他分配器更快地完成这个完整的GC，但是对于大堆或延迟敏感应用程序来说，典型的运行时间是每2GB 1秒，这可能太长了。
• Hotspot根据目的使用了各种策略进行堆外分配。分配本机字节缓冲区与为已编译代码或分析数据分配本机字节缓冲区不同。在这里，我不能权威地回答任何细节，但我只能假设其中的大部分不使用系统分配器，否则Hotspot的性能就不会像它那样好。此外，还有一些参数可以调优以控制某些空间，例如-XX:ReservedCodeCacheSize，这意味着这样的内存区域是通过间接管理的，而不是直接通过系统分配器管理的。总之，如果系统分配器直接用于热点中的任何细粒度分配，我会感到相当惊讶。