JDK-8255383 : Add -XX:+DumpPerfMapAtExit to write Linux perf map file on VM shutdown
  • Type: CSR
  • Component: hotspot
  • Sub-Component: svc
  • Priority: P4
  • Status: Closed
  • Resolution: Withdrawn
  • Fix Versions: 16
  • Submitted: 2020-10-26
  • Updated: 2020-10-27
  • Resolved: 2020-10-27
Related Reports
CSR :  
Description
Summary
-------

Add a new command line option, -XX:+DumpPerfMapAtExit, which will write a map file in the format used by Linux perf at VM shutdown. The map file can then be used by perf to convert addresses to symbol names.

Problem
-------

JDK-8254723 adds a new diagnostic command Compiler.perfmap to write a map file for the current code cache contents of a running VM. During the review for this feature [1] two reviewers suggested it would be useful to also have an option to write the map file on exit, instead of having to use "jcmd <pid> Compiler.perfmap" while the VM is running. This would support a common use case of perf like

  perf record -- workload

Where "workload" terminates after some time.

Solution
--------

Add a new command line product option, -XX:+DumpPerfMapAtExit to write the map on exit. It can be used like this

  perf record -- java -XX:+DumpPerfMapAtExit Workload

Specification
-------------

See the changes in pull request [1] for implementation details.

When DumpPerfMapAtExit is enabled, just before VM shutdown, the start address, length, and symbol name of each entry in the code cache is written to a file /tmp/perf-$PID.map. The format of this file is described in [2].

Additionally, enabling DumpPerfMapAtExit sets the default value of UseCodeCacheFlushing to false. This is to ensure that the map file contains symbol names for all methods compiled during the life of the VM, and to prevent reuse of address ranges so that each address decodes to a unique symbol. This behaviour can be overridden by explicitly setting -XX:+UseCodeCacheFlushing.

This option is only available on Linux, as this file format is specific to perf which is a Linux-only tool.

[1] https://github.com/openjdk/jdk/pull/760

[2] https://github.com/torvalds/linux/blob/master/tools/perf/Documentation/jit-interface.txt

Comments
> Does "for diagnostic purposes" include production options that are for diagnostics? Yes, this FAQ was explicitly put in to make it clear(er) that Hotspot diagnostic and experimental flags do not need CSR requests. I think Thomas's comment was more product versus debug, rather than product-flag versus diagnostic-flag.
26-10-2020

@dholmes It was suggested below to make it a production option rather than a diagnostic VM option: https://github.com/openjdk/jdk/pull/760#pullrequestreview-514359130 Does "for diagnostic purposes" include production options that are for diagnostics?
26-10-2020

[~ngasson] Adding a diagnostic flag does not require a CSR request. https://wiki.openjdk.java.net/display/csr/CSR+FAQs > Interfaces that are experimental or for diagnostic purposes do not > need to go through CSR process, but the CSR process may be employed if > feedback from the CSR reviewers is desired. Update: I assumed this would be a diagnostic flag. I don't see why it needs to be a product flag.
26-10-2020