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

[Hohensee, Paul]

Typo, webrev s/b webrev.05.

JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8195115
Webrev: http://cr.openjdk.java.net/~phh/8195115/webrev.05/
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

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

    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