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

[Thomas Schatzl]

Hi Liang,

On 17.02.20 07:03, Liang Mao wrote:
> 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.
> 

I agree, but we still need to fix the test in some way ;)

>> - 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?
> 

Just for reference for others, they (except compiler.compiler, but they 
do not work since jdk8) can be made working with the following options

--add-exports=java.xml/com.sun.org.apache.xerces.internal.parsers=ALL-UNNAMED 

--add-exports=java.xml/com.sun.org.apache.xerces.internal.util=ALL-UNNAMED

as described in the specjvm2008 faq q4.8 [0]

> 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?

Although I think you already got what I meant: current heap sizing 
without the patch already by default sizes the heap too large, i.e. the 
same scores could be achieved using less heap. The change now increases 
the heap even more (obviously without increasing the performance 
either). This seems undesirable.

I saw in the other email that you proposed a fix for that already, I 
will look into this.

Thanks,
   Thomas

[0] https://www.spec.org/jvm2008/docs/FAQ.html#Q4.8