Discussion: improve humongous objects handling for G1
thomas.schatzl at oracle.com
Wed Jan 22 09:40:04 UTC 2020
On 21.01.20 15:26, Liang Mao wrote:
> Hi Thomas,
> Thank you for pointing out my mistake for comparing iterating object array
> with card scanning that I missed the detail that card scanning doesn't need
> to scan the whole object array.
> I didn't provide gc log because I haven't sufficient statistics data about
> humongous distribution or the object arrays. The solution is just
> because increasing G1HeapRegionSize fixes the problem so I want to do
> the same to
> G1HeapRegionSize=32m. In my earlier memory of tunning some
> typical applications,
> humongous objects occupy more than half of the used heap after young GC with
> default G1HeapRegionSize. I guess perhaps half of our applications may
> the issue with default setting. So currently we use the G1HeapRegionSize as
> approximately 1/500 of Xmx.
> I know that iterating humongous object array in young GC might significantly
> degrade the pause time orientied philosophy. But if the pause time is
> already in
> expectation with CMS such behavior isn't doing anything worse but avoid
> the GC
> turbulence by concurrent mark. Beside the obvious penalty to pause time, do
> you have any other concerns?
Ultimately, no, but given that there are options that seem all-around
better or there are things (e.g. humongous object tail allocations) to
do first I would not spend time on that at this time :)
>> Note that its allocation could still be counted against the eden
>> allowance in some situations. This could be seen as a way to slow down
>> the mutator while it is busy trying to complete the marking. >
>> I am however not sure if it helps a lot assuming that changes to perform
>> eager reclaim on objArrays won't work during marking btw. There would be
>> need for a different kind of enforcing such an allocation penalty.
> I'm sorry I didn't get these 2 paragraphs. Could you please explain more?
The first sentence starts talking about a hybrid approach: keep the
object in old gen, but still account it against the allowed eden allocation.
The problem is how to account this: you do not really want to account
the full regions against it, because that would cause more gcs than CMS
as we don't/can't allocate into tail of humongous objects at all.
Counting fractions of regions would leave you with the decision to be
conservative and make an eden allocation region unused.
E.g. eden allocation budget is 50 regions, you allocate 50 humongous
objects half a region each. Should that exhaust the budget (in case
regions are counted fully)? This would mean that G1 would do collections
at double the rate of CMS.
An option would be to make them count at their real size (for purposes
of determining when eden is "exhausted"), but that might leave you with
a fraction of a region for the last region.
The other problem is of course, while it's accounted for its actual
size, it still takes twice space in the heap (i.e. the to-space
This is why the mention of "in some situations" - if you are eating into
the reserve already, it's probably better to account them in full anyway.
Note that otoh if you keep the object in young gen logically too, you
could imagine allocating into its tail. However keeping humongous
(objArray) objects in young gen logically has the other bad properties
we talked about earlier. You could even vary the strategy between
objArray and non-objArrays. So this needs some more thought, and the
policy written down, and tested on "real" applications. :)
The last sentence in that paragraph refers to somehow slow down the
mutator when eating in the reserve to complete the marking in time.
The second paragraph is about questioning the slowing down mechanism a
bit: even during this situation, when you are marking, and slowing down
the mutator, additional gcs do not help you a lot wrt to eager reclaim
of humongous objArray objects, as the most likely (initial)
implementation of that would not do eager reclaim during marking (it's
doable, you need to keep the satb invariant).
Yeah, these two paragraphs compressed my thoughts maybe a bit too much. ;)
More information about the hotspot-gc-dev