java11新特性--Epsilon:A No-Op Garbage Collector

简介

Epsilon垃圾回收器控制内存分配，但是不执行任何垃圾回收工作。一旦java的堆被耗尽，jvm就直接关闭。

目标

提供一个完全消极的GC实现，分配有限的内存分配，最大限度降低消费内存占用量和内存吞吐时的延迟时间。一个好的实现是隔离代码变化，不影响其他GC，对小限度的改变其他的JVM代码。

误区

它不是为了提供给java语言或jvm一个手动管理内存的功能。它不是为了介绍一种新的管理java heap的API。它不是为了适配自己而改变或清除JVM的内部接口。

动机

java实现了一系列的高度可配置化的GC实现。各种不同的垃圾回收器可以面对各种情况。但是有些时候使用一种独特的实现，而不是将其堆积在其他GC实现上将会是事情变得更加简单。

下面是no-op GC的几个使用场景：

• Performance testing,什么都不执行的GC非常适合用于差异性分析。no-op GC可以用于过滤掉GC诱发的新能损耗，比如GC线程的调度，GC屏障的消耗，GC周期的不合适触发，内存位置变化等。此外有些延迟者不是由于GC引起的，比如scheduling hiccups, compiler transition hiccups，所以去除GC引发的延迟有助于统计这些延迟。
• Memory pressure testing, 在测试java代码时，确定分配内存的阈值有助于设置内存压力常量值。这时no-op就很有用，它可以简单地接受一个分配的内存分配上限，当内存超限时就失败。例如：测试需要分配小于1G的内存，就使用-Xmx1g参数来配置no-op GC，然后当内存耗尽的时候就直接crash。
• VM interface testing, 以VM开发视角，有一个简单的GC实现，有助于理解VM-GC的最小接口实现。它也用于证明VM-GC接口的健全性。
• Extremely short lived jobs, 一个短声明周期的工作可能会依赖快速退出来释放资源，这个时候接收GC周期来清理heap其实是在浪费时间，因为heap会在退出时清理。并且GC周期可能会占用一会时间，因为它依赖heap上的数据量。
• Last-drop latency improvements, 对那些极端延迟敏感的应用，开发者十分清楚内存占用，或者是几乎没有垃圾回收的应用，此时耗时较长的GC周期将会是一件坏事。
• Last-drop throughput improvements, 即便对那些无需内存分配的工作，选择一个GC意味着选择了一系列的GC屏障，所有的OpenJDK GC都是分代的，所以他们至少会有一个写屏障。避免这些屏障可以带来一点点的吞吐量提升。

描述

Epsilon垃圾回收器和其他OpenJDK的垃圾回收器一样，使用-XX:+UseEpsilonGC开启。

Epsilon线性分配单个连续内存块。可复用现存VM代码中的TLAB部分的分配功能。非TLAB分配也是同一段代码，因为在此方案中，分配TLAB和分配大对象只有一点点的不同。

Epsilon用到的barrier是空的(或者说是无操作的)。因为该GC不执行任何的GC周期，不用关系对象图，对象标记，对象复制等。引进一种新的barrier-set实现可能是该GC对JVM最大的变化。

当java heap耗尽的时候，因为没有内存回收，没有内存再利用，所以我们会得到系统出错。下面有几个选项，这些大多在现有GC中已经出现过了：

• 抛出带有描述信息的OutOfMemoryError异常
• 执行heap dump操作（当带有-XX:+HeapDumpOnOutOfMemoryError时）
• 失败掉JVM并且执行可选的外部操作(使用 -XX:OnOutOfMemoryError=…)，比如开启一段调试程序或者通知外部监控系统

System.gc()将变得无效，因为没有内存回收操作。它的实现可能是告诉用户尝试强行GC是无效的。