Re: RFR: 8236073: G1: Use SoftMaxHeapSize to guide GC heuristics

Liang Mao maoliang.ml at alibaba-inc.com
Mon Feb 17 06:03:05 UTC 2020


Hi Thomas,

> - gc/g1/TestPeriodicCollection.java fails consistently because the heap 
> does not shrink as expected (but probably this is a test bug as it may 
> expect that uncommit occurs at remark).

The reason should be that the patch makes shrinking after mixed GC
but the mixed gc doesn't happen. It's the only issue I listed for
the change.

> - memory usage tends to be significantly higher with the change without 
> improving scores.

> E.g. I have been running specjvm2008 out-of-box with no settings on 
> different machine(s) (32gb ram min), and the build with the changes 
> almost consistently uses more heap (i.e. committed size) than without, 
> in the range of 10% without any performance increase.

> Specjvm2008 benchmarks are pretty simple application in terms of 
> behavior, i.e. does the same things all the time. This also means that 
> very likely the current sizing is already way beyond the point of 
> diminishing returns (actually, this is a known issue :)); I would prefer 
> if we did not add to that. ;)

I have 2 questions here.
1) specjvm2008 cannot run with jdk9+:
https://bugs.openjdk.java.net/browse/JDK-8202460
I face the same problem. Do you have any way to perform the test
in JDK15?

2) I didn't understand : "This also means that 
> very likely the current sizing is already way beyond the point of 
> diminishing returns (actually, this is a known issue :));"
Could you please explain more about this?


Thanks,
Liang






------------------------------------------------------------------
From:Thomas Schatzl <thomas.schatzl at oracle.com>
Send Time:2020 Feb. 15 (Sat.) 03:51
To:hotspot-gc-dev <hotspot-gc-dev at openjdk.java.net>
Subject:Re: RFR: 8236073: G1: Use SoftMaxHeapSize to guide GC heuristics

Hi,

On 12.02.20 12:16, Thomas Schatzl wrote:
> Hi Liang,
> 
> On 12.02.20 11:17, Liang Mao wrote:
>> Hi Thomas,
>>
>> I made a new patch for the issues we listed in JDK-8238686 and
>> JDK-8236073:
>> http://cr.openjdk.java.net/~luchsh/8236073.webrev.3/
> 
>    thanks. I only had time to quickly browse the change, and started 
> building and testing it internally. I will run it through our perf 
> benchmarks to look for regressions of out-of-box behavior.
> 
> I will need a day or two until I can get back to looking at the change 
> in detail. There is currently something else I need to look at. Sorry.

   initial results from testing:

- gc/g1/TestPeriodicCollection.java fails consistently because the heap 
does not shrink as expected (but probably this is a test bug as it may 
expect that uncommit occurs at remark).

- memory usage tends to be significantly higher with the change without 
improving scores.

E.g. I have been running specjvm2008 out-of-box with no settings on 
different machine(s) (32gb ram min), and the build with the changes 
almost consistently uses more heap (i.e. committed size) than without, 
in the range of 10% without any performance increase.

Specjvm2008 benchmarks are pretty simple application in terms of 
behavior, i.e. does the same things all the time. This also means that 
very likely the current sizing is already way beyond the point of 
diminishing returns (actually, this is a known issue :)); I would prefer 
if we did not add to that. ;)

Unfortunately I lost the graphs I had generated (manually), and I do not 
have more time available right now so can't show you right now.

I started some dacapo 2009 runs (running them for 30 iterations each).

Did not have time to look at the changes themselves any further or 
investigate the reasons for this memory usage increase than I already 
did earlier; will continue on Tuesday as I'm taking the day off Monday.

Thanks,
   Thomas



More information about the hotspot-gc-dev mailing list