Class WinPerfAsmProfiler

  • All Implemented Interfaces:
    ExternalProfiler, Profiler

    public class WinPerfAsmProfiler
    extends AbstractPerfAsmProfiler
    Windows performance profiler based on "xperf" utility.

    You must install Windows Performance Toolkit. Once installed, locate directory with xperf.exe file and either add it to PATH environment variable, or set it to jmh.perfasm.xperf.dir system property.

    This profiler counts only SampledProfile events. To achieve this, we set xperf providers to loader+proc_thread+profile. You may optionally save xperf binary or parsed outputs using jmh.perfasm.savePerfBin or jmh.perfasm.savePerf system properties respectively. If you do so and want to log more events, you can use jmh.perfasm.xperf.providers system property to override providers. However, you must specify loader, proc_thread and profile providers anyway. Otherwise sample events will not be generated and profiler will show nothing.

    By default JDK distributive do not have debug symbols. If you want to analyze JVM internals, you must build OpenJDK on your own. Once built, go to bin/server directory and unpack jvm.diz. Now you have jvm.pdb file with JVM debug symbols. Finally, you must set debug symbols directory to jmh.perfasm.symbol.dir system property.

    This profiler behaves differently comparing to it's Linux counterpart LinuxPerfAsmProfiler. Linux profiler employs perf utility which can be used to profile a single process. Therefore, Linux profiler wraps forked JVM command line. In contrast, xperf cannot profile only a single process. It have -PidNewProcess argument, but it's sole purpose is to start profiling before the process is started, so that one can be sure that none events generated by this process are missed. It does not filter events from other processes anyhow. For this reason, this profiler doesn't alter forked JVM startup command. Instead, it starts xperf recording in beforeTrial(BenchmarkParams) method, and stops in ExternalProfiler.afterTrial(org.openjdk.jmh.results.BenchmarkResult, long, java.io.File, java.io.File). This leaves possibility to run this profiler in conjunction with some other profiler requiring startup command alteration.

    For this reason the profiler must know PID of forked JVM process.