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