[8u] RFR backport of JDK-8144732: VM_HeapDumper hits assert with bad dump_len

[Hohensee, Paul]

The JBS issue and changeset links you posted are for 8150432, not 8144732, which was confusing. The webrev is for 8144732 though.

I can find only two places where your patch is different from the original changeset, net of line numbers/file locations. The rest looks fine. They are:

In heapDumper.cpp, there should be only one blank line after the definition of WRITE_ARRAY.

In arguments.cpp, the obsolete_jvm_flags entry for SegmentedHeapDumpThreshold was changed to conform to 8u. If you apply the patch and issue
	java -XX: -XX:SegmentedHeapDumpThreshold=2g
you get "OpenJDK 64-Bit Server VM warning: ignoring option AutoShutdownNMT; support was removed in 9.0", which is confusing since we're running 8.
But, you get the same message from
	java -XX: -XX:+AutoShutdownNMT
so the problem isn’t unique to this patch, and likely the result of previous backports. For this patch, I'd use
	  { "SegmentedHeapDumpThreshold",    JDK_Version::jdk_update(8, 242), JDK_Version::jdk(10) },

It would be great if you would file an issue to fix the other two (there's also UseOldInlining, which doesn't generate a message because it hasn't been removed from c2_globals.hpp, which it should be).

Thanks,

Paul

On 10/9/19, 2:12 AM, "jdk8u-dev on behalf of Denghui Dong" <jdk8u-dev-bounces at openjdk.java.net on behalf of denghui.ddh at alibaba-inc.com> wrote:

    Hi Team:
      The previous webrev didn't contain original commit information, so I made a new webrev in http://cr.openjdk.java.net/~ddong/8144732/hotspot.00/
      Can you help to review it ? I think it is worth backporting.
    
    Thanks
    Denghui Dong
    ------------------------------------------------------------------
    From:kelthuzadx <1948638989 at qq.com>
    Send Time:2019年10月7日(星期一) 10:28
    To:董登辉(卓昂) <denghui.ddh at alibaba-inc.com>
    Subject:Re: [8u] RFR backport of JDK-8144732: VM_HeapDumper hits assert with bad dump_len
    
    Good job， it ‘s necessary to support large heap dump since 8u contains g1gc whose design principle is managing the large heap
    
    
    ------------------ Original ------------------
    From: Denghui Dong <denghui.ddh at alibaba-inc.com>
    Date: Sat,Oct 5,2019 10:27 AM
    To: jdk8u-dev <jdk8u-dev at openjdk.java.net>
    Subject: Re: [8u] RFR backport of JDK-8144732: VM_HeapDumper hits assert with bad dump_len
    Any comments ?
    
    Thanks,
    Denghui Dong
    ------------------------------------------------------------------
    From:董登辉(卓昂) <denghui.ddh at alibaba-inc.com>
    Send Time:2019年9月25日(星期三) 16:02
    To:jdk8u-dev <jdk8u-dev at openjdk.java.net>
    Subject:Re: [8u] RFR backport of JDK-8144732: VM_HeapDumper hits assert with bad dump_len
    
    
    A correction:
    Original bug: https://bugs.openjdk.java.net/browse/JDK-8144732
    
    Thanks
    Denghui Dong
    ------------------------------------------------------------------
    From:董登辉(卓昂) <denghui.ddh at alibaba-inc.com>
    Send Time:2019年9月25日(星期三) 14:25
    To:jdk8u-dev <jdk8u-dev at openjdk.java.net>
    Subject:[8u] RFR backport of JDK-8144732: VM_HeapDumper hits assert with bad dump_len
    
    Hi all, 
      I'd like to request a backport of JDK-8144732.
    
      In our production environment, many application use large heap, and there are some
    big arrays in the heap. When developers use jmap to dump heap, and use Eclipse MAT(mostly) 
    or jhat to analyze the file, often got error. For example:
    
    public class BigArray {
      public static void main(String[] args) throws Exception {
        long[] b = new long[1024 * 1024 * 1024 / 2];
        Object o = new Object();
        synchronized(o) {
          o.wait(60000);
        }
      }
    }
    
      If you run the above code, and use jmap to generate a dump file, then use jhat to parse it,
    you will got a warning message:
    
    "WARNING: Error reading heap dump or heap dump segment:  Byte count is -4294967296 instead of 0"
    
      Eclipse MAT also can't parse the dump file correctly.
    
      The root cause is the length of the segment exceeds the limit.
    
      I found that JDK-8144732 can resolve this problem, because it can truncate the array whose
    size is too large and ensure a segment length within limit.
    
    The patch (from JDK9) doesn't apply cleanly.
    
    Original bug: https://bugs.openjdk.java.net/browse/JDK-8150432
    
    Original patch: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/91a26000bfb5
    
    My webrev: http://cr.openjdk.java.net/~luchsh/8144732_8u/
    
    Testing:
      jdk/test/demo/jvmti/hprof/HeapDumpTest.java passed.
      jdk/test/sun/tools/jhat/HatHeapDump1Test.java passed.
    
      What's your comments ?
    
    Thanks
    Denghui Dong