On Wed, 7 Oct 2026 07:24:14 GMT, Yunbo Zhang <[email protected]> wrote:
> Please review this small benchmark fix. > > Running `ThreadStartJoin` with two workers can fail: `java -jar > benchmarks.jar -t 2 ThreadStartJoin` > > > # Warmup Iteration 1: <failure> > > java.lang.IllegalThreadStateException > at java.base/java.lang.Thread.start(Thread.java:1494) > at > org.openjdk.bench.java.lang.ThreadStartJoin.test(ThreadStartJoin.java:62) > at > org.openjdk.bench.java.lang.jmh_generated.ThreadStartJoin_test_jmhTest.test_avgt_jmhStub(ThreadStartJoin_test_jmhTest.java:238) > at > org.openjdk.bench.java.lang.jmh_generated.ThreadStartJoin_test_jmhTest.test_AverageTime(ThreadStartJoin_test_jmhTest.java:177) > at > java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) > > > **Fix:** Change `Scope.Benchmark` to `Scope.Thread` so each worker has its > own thread array. > > The test is meant to measure the cost of creating, starting, and waiting for > a batch of threads to finish, not having multiple workers operate on the same > thread array. So this looks like a low-risk change that keeps the benchmark's > original intent. > > **Testing:** > - ThreadStartJoin: 1/2/4 workers passed, using the default CPU count and > `-XX:ActiveProcessorCount=1` and `2`. > > --------- > - [x] I confirm that I make this contribution in accordance with the [OpenJDK > Interim AI Policy](https://openjdk.org/legal/ai). Drive-by comment as I don't deal at all with JMH, but does running this kind of benchmark with more than one worker actually make any sense? These seem intended to be trivial single-threaded benchmarks. ------------- PR Comment: https://git.openjdk.org/jdk/pull/33239#issuecomment-6050090850
