Re: Discussion: improve humongous objects handling for G1

[Liang Mao]

Hi Thomas,

Thanks for your rich explanation. I saw those problems but didn't
think so much:) My previous approach definitely would increase the
GC frequency so after you provide idea of canceling cm cycle I 
thought it would be a better one.

Thanks,
Liang






------------------------------------------------------------------
From:Thomas Schatzl <thomas.schatzl at oracle.com>
Send Time:2020 Jan. 22 (Wed.) 17:40
To:"MAO, Liang" <maoliang.ml at alibaba-inc.com>; Man Cao <manc at google.com>; hotspot-gc-dev <hotspot-gc-dev at openjdk.java.net>
Subject:Re: Discussion: improve humongous objects handling for G1

Hi Liang,

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 
> straightforward
> 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 
> encounter
> 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 
exhaustion issue).

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. ;)

Thanks,
   Thomas