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