RFR: 8320534: fatal error for the NMTBenchmark test run for the mainline build

Axel Boldt-Christmas aboldtch at openjdk.org
Wed Mar 13 09:52:17 UTC 2024


On Tue, 13 Feb 2024 09:59:52 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

> This benchmark creates and manages threads internally. So, the number of threads is determined by the benchmark and cannot be set in command line arguments.
> The number of threads in BenchmarkParams is checked and an exception is thrown if it is invalid.

I am curious if this whole issue could be solved with:

diff --git a/test/micro/org/openjdk/bench/vm/runtime/NMTBenchmark.java b/test/micro/org/openjdk/bench/vm/runtime/NMTBenchmark.java
index 9337b4df531..512697db891 100644
--- a/test/micro/org/openjdk/bench/vm/runtime/NMTBenchmark.java
+++ b/test/micro/org/openjdk/bench/vm/runtime/NMTBenchmark.java
@@ -35,7 +35,7 @@
 
 @BenchmarkMode(Mode.AverageTime)
 @OutputTimeUnit(TimeUnit.MILLISECONDS)
- at State(Scope.Benchmark)
+ at State(Scope.Thread)
 @Warmup(iterations = 2, time = 1, timeUnit = TimeUnit.SECONDS)
 @Measurement(iterations = 5, time = 1, timeUnit = TimeUnit.SECONDS)
 public abstract class NMTBenchmark {


My experience with JMH is very limited but reading the documentation of [scope](https://javadoc.io/doc/org.openjdk.jmh/jmh-core/latest/org/openjdk/jmh/annotations/Scope.html) when the state scope is Thread all instances will be distinct across the worker threads so the `long addresses[];` will be distinct per worker thread. While right now this will be shared across the worker threads, so we may have multiple threads freeing the same memory.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17824#issuecomment-1993977758


More information about the hotspot-runtime-dev mailing list