Discussion on JDK-8245511: G1 adaptive IHOP does not account for reclamation of humongous objects by young GC

[Thomas Schatzl]

Hi,

On 26.05.20 20:21, Luo, Ziyi wrote:
> Hi Thomas
> 
> Thank you for looking into JDK-8245511. I open this thread to discuss the
> questions you raised in comments (I’m not an author yet :)).

There's an easy way to get author quickly and subsequently be much 
faster: instead of trying to get in a huge patch in that takes multiple 
review rounds, each round having a long turnaround time because you do 
not have access to the tools (jira, cr.openjdk), first do two "boring" 
starter bugs (at today's count there are 55 "starter" bugs open in the 
gc component), some of which would probably take you half an hour or 
less each. ;)

>> If you compare latest jdk15 behavior which does not show this problem here
> at all like with earlier jdks (you tagged 15 as affected, but I can't
> reproduce with latest. Might be a local fluke though).
> 
> You are right about the test result. The probem is not reproducible in
> jdk-15-ea+24. I look deep into the gc log, I found some anomalies with the
> humongous regions e.g.,
> 
> % cat gc-vanilla-15-30353-2020-05-26_17-03-39.log | grep "Humongous regions"
> [3.256s][info ][gc,heap        ] GC(0) Humongous regions: 228->0
> [10.209s][info ][gc,heap           ] GC(2) Humongous regions: 78->0
> ...
> [20.034s][info ][gc,heap           ] GC(5) Humongous regions: 0->0
> [20.914s][info ][gc,heap           ] GC(7) Humongous regions: 0->0
> <No humongous allocations at all according to the gc heap stats>
> ...
> 
> I suspect this is because the humongous object size is set the same as the
> region size in the repro program and somehow jdk15 treats such objects as not
> humongous (Correct if I were wrong). I adjusted the humongous object size 1.5
> times of the region size. Now the problem is reproducible in jdk15. I'll
> update the repro program in JBS.
> 

The dummy allocations made in the program are always humongous, nothing 
changed here (half a region size). However the C2 compiler optimizes 
away these useless allocations. :)

I.e. run with gc+region=trace logging and look for "ALLOC(HUMS" with and 
without some additional code to do something "useful" with them, e.g. 
"System.out.println(newHumongousObject())" or assign it to a static member.

Increasing the humongous object size makes the program work for some 
reason, probably C2 has a threshold for object size it will consider for 
this optimization, but that does not make the test more correct.

Let's keep further discussion in the mailing list since all of us can 
directly participate. I will just post a final reference to this thread 
in JIRA.

Looking forward to your review request. :) (Fwiw, at this time 
reviewing, or at least reviewers okay'ing it, must happen in the mailing 
list as per https://openjdk.java.net/contribute/).

Thanks,
   Thomas