转载

JDK 12 正式收录了我们的 Patch

国庆假期归来就收到喜讯，之前给社区提交的patch（ PerfMa给OpenJDK社区提交的第一个Patch ）已经正式收录到JDK12了（点击“阅读原文”，可查看详情），非常感谢社区的小伙伴的积极配合，从提交issue开始到正式修复并打入JDK12耗时才10天的时间，这个效率已经挺赞了，测试用例还是社区小伙伴给写的，PerfMa会和社区不断保持联系，贡献出我们的一份力量，服务好Java小伙伴们。

另外第二个Patch（假笨说-Metaspace使用很少就触发了Full GC?(第二个社区Patch) ）考虑到会修改一些语义，和之前的一些GC日志表达上会不一致，和我之前的考虑有些类似，因此可能不太会考虑我的提议，虽然他们也认同我的考虑，下面是社区给的回复：

FWIW, I agree this is confusing, and personally would prefer the
committed size be printed as you suggests, but I guess this may break
a lot of tooling.

Note that the gap between committed and used can be quite large in the
following pathological scenarios:

a) lots of class loaders which do not load many classes and stop
loading classes at an inconvenient time: when having been handed a
larger memory chunk after having used up four small chunks - which the
JVM takes as proof that this classloader is here to stay and therefore
may just as well get a large chunk to gnaw on.
This leads to fragmentation and there is no easy way to avoid it. We
can play around with chunk sizes and allocation strategies but there
will always be pathological scenarios since the JVM needs to guess and
may guess wrongly.

b) when class loaders died and their memory chunks are returned to the
internal metaspace freelists. They are not always uncommitted
immediately; in fact they never may be uncommitted. They will be
reused when other classloaders load classes, which may never happen.

Note: to analyze these situations better we (SAP) added a new command
to jcmd, "VM.metaspace". Among other things, the command outputs a
"Waste" section, which details both (a) and (b) and some minor other
waste scenarios. That command is now upstream in stock OpenJDK, so it
should be available in jdk11.

Thanks, Thomas