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

[Thomas Stuefe]

On Wed, 13 Mar 2024 09:49:11 GMT, Axel Boldt-Christmas <aboldtch 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.

> Thank you @xmas92 for your great help. I misunderstood the meaning of the Thread scope. @tstuefe, the suggested help from @xmas92 is the solution.

Neat! Nice small patch.

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

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