On Tue, 14 Jan 2025 19:12:45 GMT, Gerard Ziemski <gziem...@openjdk.org> wrote:
> Here is another, hopefully, closer to the final iteration of NMT benchmarking > mechanism. > > To use, you first need to record the pattern of operations, ex: > > `./build/macosx-aarch64-server-release/xcode/build/jdk/bin/java > -XX:+UnlockDiagnosticVMOptions -XX:NMTRecordMemoryAllocations=0x7FFFFFFF -jar > build/macosx-aarch64-server-release/images/jdk/demo/jfc/J2Ddemo/J2Ddemo.jar` > > This will run the target app, and log all the allocations in chronological > order. This will produce a few files: > - hs_nmt_pid22770_allocs_record.log (is the chronological record of the the > desired operations) > - hs_nmt_pid22770_info_record.log (is the record of default NMT memory > overhead and the NMT state) > - hs_nmt_pid22770_threads_record.log (is the record of thread names that can > be retrieved later when processing) > > Now you can use those recording to actually benchmark your proposed changes, > ex: > > `./build/macosx-aarch64-server-release/xcode/build/jdk/bin/java > -XX:+UnlockDiagnosticVMOptions -XX:NMTBenchmarkRecordedPID=22770 > -XX:NMTBenchmarkRecordedLoops=10` > > Which will produce yet another file: > > - hs_nmt_pid23527_benchmark.log > > that contains the details of the session, which can be further processed and > analyzed by a tool, such as the one in jdk/src/utils/nmt, however, if you are > looking just for one performance number look for `time:2744190[ns] > [samples:115263]` in the output. > > The total time for this particular run is 2,744,190 nanosecond or ~2.7 > seconds, which you can use to compare `before` and `after` your change. I'm really not sure what this is actually trying to benchmark - who will be collecting this data and analysing it and what will they do with their results? That aside, generating the logs in a training run is okay, but the tool for processing those logs should reside elsewhere. A few initial passing comments. src/demo/share/jfc/J2Ddemo/java2d/Intro.java line 449: > 447: System.exit(0); > 448: } > 449: Scene scene = director.get(index); Leftover debugging code? src/hotspot/share/nmt/memLogRecorder.cpp line 27: > 25: // record pattern of allocations of memory calls: > 26: // > 27: // ./build/macosx-aarch64-server-release/xcode/build/jdk/bin/java > -XX:+UnlockDiagnosticVMOptions -XX:NMTRecordMemoryAllocations=0x7FFFFFFF -jar > build/macosx-aarch64-server-release/images/jdk/demo/jfc/J2Ddemo/J2Ddemo.jar You don't need the full paths in these examples src/hotspot/share/nmt/memLogRecorder.cpp line 43: > 41: // then to actually run the benchmark: > 42: // > 43: // ./build/macosx-aarch64-server-release/xcode/build/jdk/bin/java > -XX:+UnlockDiagnosticVMOptions -XX:NMTBenchmarkRecordedPID=43100 > -XX:NMTBenchmarkRecordedLoops=10 ?? How does this run anything - you haven't passed an initial class to the Java invocation? src/hotspot/share/nmt/memLogRecorder.cpp line 98: > 96: // ??? > 97: #endif > 98: pthread_mutex_init(&_mutex, NULL); You need to use existing synchronization API here. Either Mutex or PlatformMutex depending on initialization constraints; maybe a Semaphore if the others can't work. src/hotspot/share/nmt/memLogRecorder.hpp line 37: > 35: #elif defined(WINDOWS) > 36: // ??? > 37: #endif You need to use existing synchronization API here. Either Mutex or PlatformMutex depending on initialization constraints; maybe a Semaphore if the others can't work. ------------- Changes requested by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23115#pullrequestreview-2557544778 PR Review Comment: https://git.openjdk.org/jdk/pull/23115#discussion_r1919324156 PR Review Comment: https://git.openjdk.org/jdk/pull/23115#discussion_r1919325893 PR Review Comment: https://git.openjdk.org/jdk/pull/23115#discussion_r1919328324 PR Review Comment: https://git.openjdk.org/jdk/pull/23115#discussion_r1919328661 PR Review Comment: https://git.openjdk.org/jdk/pull/23115#discussion_r1919324004
