Backport 8195115: G1 Old Gen MemoryPool CollectionUsage.used values don't reflect mixed GC results
hohensee at amazon.com
Fri Oct 12 14:13:48 UTC 2018
Thanks for the review, new webrev at http://cr.openjdk.java.net/~phh/8195115/webrev.06/.
The different requires were an artifact of me trying to get TestOldGenCollectionUsage.java to run. Good catch.
Jiangli changed the heap size to 14m to get it to work with CDS, see https://bugs.openjdk.java.net/browse/JDK-8210193.
From: JC Beyler <jcbeyler at google.com>
Date: Thursday, October 11, 2018 at 10:37 PM
To: "Hohensee, Paul" <hohensee at amazon.com>
Cc: "hotspot-gc-dev at openjdk.java.net" <hotspot-gc-dev at openjdk.java.net>, "serviceability-dev at openjdk.java.net" <serviceability-dev at openjdk.java.net>, "jdk8u-dev at openjdk.java.net" <jdk8u-dev at openjdk.java.net>
Subject: Re: RFR: Backport 8195115: G1 Old Gen MemoryPool CollectionUsage.used values don't reflect mixed GC results
The biggest thing I saw in this RFR was that the flags for the test:
were changed it seems:
- the @requires are different for the backport (you accept null for JDK8 for GC and also removed the @requires vm.opt.MaxGCPauseMillis == "null")
- the @run flags are different (-Xms/Xmx are 14m for the backport; they were 12 originally; there is a comment below in the backport saying this requires normally 12m though you ask for 14 in the @run)
What are the reasons for these differences?
Apart from that, the backport seemed ok but I'm not that well versed in the GC changes :)
On Thu, Oct 11, 2018 at 5:04 PM Hohensee, Paul <hohensee at amazon.com<mailto:hohensee at amazon.com>> wrote:
Please review a backport to jdk8u.
JDK11 patch: http://hg.openjdk.java.net/jdk/jdk/rev/5d3c5af82654
The backport is slightly different from the JDK11 patch due to G1 refactoring, hence my request for new review. I’ll ask for jdk8u approval once the backport is reviewed.
I backported two jtreg tests from JDK11, which pass. Also, all the hotspot gc jtreg tests pass as well as they do for jdk8u-dev.
There was a CSR involved, https://bugs.openjdk.java.net/browse/JDK-8196719. Does that have to be re-approved for jdk8u as well, and if so, what’s the process?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the serviceability-dev