JDK-8260424 : Extend JMap to support parallel heap dump
  • Type: CSR
  • Component: core-svc
  • Sub-Component: tools
  • Priority: P4
  • Status: Closed
  • Resolution: Withdrawn
  • Fix Versions: 17
  • Submitted: 2021-01-26
  • Updated: 2021-04-21
  • Resolved: 2021-04-21
Related Reports
CSR :  
Description
Summary
------
Add a new sub-command option "parallel" to the existing "dump" jmap command line option, which specifies how many threads to use to generate the heap dump file.

Problem
-------
JDK-8239290 and related issues has introduced the parallel heap inspection, using the same mechanism for jmap -dump could help speed up heap dumping.

Solution
-------
Add a new sub-command option "parallel" to the existing "dump" jmap command line option, which specifies how many threads to use to generate the heap dump file.

Specification
------
Updated specification.

    Usage:
    jmap -clstats <pid>
        to connect to running process and print class loader statistics
    jmap -finalizerinfo <pid>
        to connect to running process and print information on objects awaiting finalization
    jmap -histo[:[<histo-options>]] <pid>
        to connect to running process and print histogram of java object heap
    jmap -dump:<dump-options> <pid>
        to connect to running process and dump java heap
    jmap -? -h --help
        to print this help message

    dump-options:
      live         dump only live objects
      all          dump all objects in the heap (default if one of "live" or "all" is not specified
      format=b     binary format
      file=<file>  dump heap to <file>
      gz=<number>  If specified, the heap dump is written in gzipped format using the given compression level.
                   1 (recommended) is the fastest, 9 the strongest compression.
     + parallel=<number>  Number of parallel threads to use for heap dump:
     +                    0 (the default) means let the VM determine the number of threads to use.
     +                    1 means use one thread (disable parallelism).
     +                    For any other value the VM will try to use the specified number of threads, but might use fewer.

    Example: jmap -dump:live,format=b,file=heap.bin,parallel=5 <pid>

    histo-options:
      live             count only live objects
      all              count all objects in the heap (default if one of "live" or "all" is not specified)
      file=<file>      dump data to <file>
    -  parallel=<count> generate histogram using this many parallel threads, default 0
    -                     0 use system determined number of threads
    -                     1 use one thread, i.e., disable parallelism
    -                     n use n threads, n must be positive
    + parallel=<number>  Number of parallel threads to use for heap inspection:
    +                     0 (the default) means let the VM determine the number of threads to use.
    +                     1 means use one thread (disable parallelism).
    +                     For any other value the VM will try to use the specified number of threads, but might use fewer.

    Example: jmap -histo:live,file=/tmp/histo.data,parallel=5 <pid>
Comments
As discussed in https://github.com/openjdk/jdk/pull/2261, the parallel=<n> opiton for jmap -histo is hard to be used for tuning the parallel dump, due to the current implementation of the parallel heap dump. So I withdraw this CSR. Thanks!
21-04-2021

Revise the specification to keep consistence for heap dump and heap inspection, as discussed at https://github.com/openjdk/jdk/pull/2379# Thanks
27-02-2021

Moving to Provisional. Please have one or more serviceability engineers review this request before it is Finalized for the second round of CSR review.
26-02-2021

reopen this CSR as discussed that we finally prefer the way to use "parallel=[N]" option.
18-02-2021

As commented, I have closed this CSR as there is a way to not introduce compatibility issue. Thanks
03-02-2021

As discussed at https://github.com/openjdk/jdk/pull/2261, adding a new "parallel" option to jmap would introduce backward compatibility issue which is complicated to fix. And also discussed to enable parallel dump by default without introducing new option sounds reasonable. I would suggest to close this CSR. Thanks. Lin
01-02-2021