RFR: Backport 8195115: G1 Old Gen MemoryPool CollectionUsage.used values don't reflect mixed GC results

[JC Beyler]

Hi Paul,

The biggest thing I saw in this RFR was that the flags for the test:
http://cr.openjdk.java.net/~phh/8195115/webrev.05/test/gc/g1/mixedgc/TestOldGenCollectionUsage.java.html

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 :)
Jc

On Thu, Oct 11, 2018 at 5:04 PM Hohensee, Paul <hohensee at amazon.com> wrote:

> Please review a backport to jdk8u.
>
>
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8195115
>
> Webrev: http://cr.openjdk.java.net/~phh/8195115/webrev.05/
>
> 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?
>
>
>
> Thanks,
>
>
>
> Paul
>
>
>
>
>


-- 

Thanks,
Jc
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20181011/3788560f/attachment.html>