Discussion: improve humongous objects handling for G1

[Thomas Schatzl]

Hi Man,

On 22.01.20 06:05, Man Cao wrote:
> Hi all,
> 
> Thanks for the great discussion from Thomas and Liang!
> 
> Regarding to GC logs, histogram of humongous allocations, and a more 
> concrete example, I guess we are in the same boat here. We only advised 
> users to increase G1HeapRegionSize, which would work around many cases 
> of the problem. We have not yet closely studied patterns of the 
> problematic humongous allocations. I will do such a study and follow up 
> with some statistics and GC logs when I get my hands on them.
> [...]
> 
>  > Btw the same text also indicates that copying seems like a non-starter
>  > anyway, as, quoting from the text "One use case, SPECjbb2015 benchmark
>  > is not being able to finish RT curve...".
>  > Not sure what prevents arraylets in particular from being O(1); a
>  > particular access is slower though due to the additional indirection
>  > with the spine.
>  > ...
>  > Which means that there is significant optimization work needed to make
>  > array access "as fast" as before in jitted code
> These two issues:
> (1) copying for JNI Critical
> (2) slowing down typical jitted code for array accesses
> do sound like performance deal-breakers, particularly if they are only 
> required for G1+arraylets but not other collectors. There are some use 
> cases of JNI Critical on arrays that are solely for performance reasons, 
> and we'd rather not slow them down

+1

> 
>  > It could help with all problems but cases where you allocate a very
>  > large of humongous objects and you can't keep the humognous object
>  > tails filled. This option still keeps the invariant that humongous
>  > objects need to be allocated at a region boundary.
>  >
>  > Most of the other ideas you propose below also (seem to) retain this
>  > property.
> Agreed. It seems that JDK-8172713 would help most ideas anyway.

Yeah :)

>  > Maybe it is sufficient as "most" applications only use single or low
>  > double-digit GB heaps at the moment where the entire reservation still
>  > fits into the 32gb barrier.
> I also had the same thought. Most of our important workloads have heap 
> sizes less than 20GB.
> If the "reserve multiple MaxHeapSize" approach could work with 
> compressed oops for <16GB heap, then it is quite acceptable.

I agree, it could help in a lot of cases while not (apparently) costing 
much. On 32 bit systems this is simply disabled (ie. -Xmx == reservation 
size).

I think even a small over-reservation would help in a lot of cases for 
external fragmentation.

One could think of "cheating" a little with the actual memory 
usage/commit size by only committing what the humongous object actually 
needs if you wanted. This would complicate size accounting quite a bit 
though (and increase commit/uncommit calls), so JDK-8172713 seems 
favorable at least.

> That said, now I do agree that I should first study the patterns of 
> humongous allocation and look into improvement on eager reclamation.
> 
> For the approach from Liang/Alibaba, I'm optimistic that it could solve 
> many problems migrating from ParNew+CMS to G1. Because it handles 
> humongous allocations in a similar way as ParNew+CMS does, plus G1 has 
> the advantage of not copying humongous objects, the pause 
> duration/frequency would probably not degrade compared to ParNew/CMS.
> I also agree with Thomas that it may increase pause duration compared to 
> current G1 due to extra scanning, and allocation spikes might affect 
> other aspects of G1. I noticed in the description for JDK-8027959: "a) 
> logically keep LOBs in young gen, doing in-place aging", which sounds 
> like the GC team have explored this approach for eager reclamation 
> before?

Yes, with the issue described before (with objArray humongous objects - 
non-objArrays are not an issue from a scanning POV, but they still are 
from an accounting one).

It might be the best of both worlds if we could make eager
> reclamation of humongous objArrays work without putting them in young 
> gen, and further improve eager reclamation in general.
> 

Considering only the "avoid humongous object fragmentation" area, yes :)

Thanks,
   Thomas