Discussion: improve humongous objects handling for G1
maoliang.ml at alibaba-inc.com
Sun Jan 19 07:08:38 UTC 2020
We Alibaba have experienced the same problem as Man introduced.
Some applications got frequent concurrent mark cycles and high
cpu usage and even some to-space exhausted failures because of
large amount of humongous object allocation even with
G1HeapRegionSize=32m. But those applications worked fine
with ParNew/CMS. We are working on some enhancements for better
reclamation of humongous objects. Our first intention is to reduce
the frequent concurrent cycles and possible to-space exhausted so
the heap utility or arraylets are not taken into consideration yet.
Our solution is more like a ParNew/CMS flow and will treat a
humongous object as young or old.
1. Humongous object allocation in mutator will be considered into
eden size and won't directly trigger concurrent mark cycle. That
will avoid the possible to-space exhausted while concurrent mark
is working and humongous allocations are "eating" the free regions.
2. Enhance the reclamation of short-live humongous object by
covering object array that current eager reclaim only supports
primitive type for now. This part looks same to JDK-8048180 and
JDK-8073288 Thomas mentioned. The evacuation flow will iterate
the humongous object array as a regular object if the humongous
object is "young" which can be distinguished by the "age" field
The patch is being tested. We will share it once it proves to
work fine with our applications. I don't know if any similar
approach has been already tried and any advices?
More information about the hotspot-gc-dev