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

[Hohensee, Paul]

Trying again with correct request template.

JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8195115
Webrev: http://cr.openjdk.java.net/~phh/8195115/webrev.06/
Backport review thread: http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2018-October/023507.html
Original review thread: http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2018-June/022305.html

Thanks,

Paul

On 10/19/18, 10:11 AM, "jdk8u-dev on behalf of Hohensee, Paul" <jdk8u-dev-bounces at openjdk.java.net on behalf of hohensee at amazon.com> wrote:

    Thanks, Thomas. Cutting distribution down to jdk8u-dev now, and asking for backport approval.
    
    Here's the email discussion: http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2018-June/022305.html
    
    Backport argument:
    
    At Amazon, we discovered more than a year ago that the MemoryPoolMXBean Usage attribute isn't very useful for monitoring, and more importantly, alarming on, excessive heap use. That's because it's an instantaneous measurement, so it includes yet-to-collected garbage. We moved to using CollectionUsage (usage after the last GC that affected the memory pool) instead as a measure of the long-term heap occupancy. If it's trending up without the app changing, there may be a memory leak, or just more load that might require a -Xmx increase.
    
    Once moved, however, we found that G1 was effectively useless to us because it reported incorrect values for the G1 old gen: mixed collections weren't updating its CollectionUsage. We patched our internal jdk8 distro, and last June, openjdk11. This is a backport of the latter. We believe that anyone monitoring server apps running G1 in jdk8u needs this fix.
    
    Thanks,
    
    Paul
    
    On 10/19/18, 9:24 AM, "Thomas Schatzl" <thomas.schatzl at oracle.com> wrote:
    
        Hi Paul,
        
        On Fri, 2018-10-12 at 00:03 +0000, Hohensee, Paul 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.
        
        I think the backport is good. Others need to decide whether this change
        is worth backporting.
        
        > 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?
        
        CC'ed Joe Darcy as I am not sure either.
        
        Thanks,
          Thomas