On Sat, 1 Jul 2023 07:53:17 GMT, Swati Sharma <d...@openjdk.org> wrote:
> The below benchmark files have scaling issues due to cache contention and > leads to poor scaling when run on multiple threads. The patch sets the scope > from benchmark level to thread level to fix the issue: > - org/openjdk/bench/java/io/DataOutputStreamTest.java > - org/openjdk/bench/java/lang/ArrayCopyObject.java > - org/openjdk/bench/java/lang/ArrayFiddle.java > - org/openjdk/bench/java/time/format/DateTimeFormatterBench.java > - org/openjdk/bench/jdk/incubator/vector/IndexInRangeBenchmark.java > - org/openjdk/bench/jdk/incubator/vector/MemorySegmentVectorAccess.java > - org/openjdk/bench/jdk/incubator/vector/StoreMaskedBenchmark.java > - org/openjdk/bench/jdk/incubator/vector/StoreMaskedIOOBEBenchmark.java > - org/openjdk/bench/vm/compiler/ArrayFill.java > - org/openjdk/bench/vm/compiler/IndexVector.java > > Also removing the static scope for variables in > org/openjdk/bench/jdk/incubator/vector/VectorFPtoIntCastOperations.java for > better scaling. > > Please review and share your feedback. > > Thanks, > Swati Not review this PR, but just raise a question. Should a JMH test, at least in JDK repo, always uses `@State(Scope.Thread)`, even though it uses only one thread? I just looked through those JMH tests, and found all of them, like the bellows, don't specify the number of threads via `@Threads`. org/openjdk/bench/java/io/DataOutputStreamTest.java org/openjdk/bench/java/lang/ArrayCopyObject.java I suppose the default number of threads is 1. Maybe the default value will be overridden via the commands when running these JMH tests in bulk (?) ------------- PR Comment: https://git.openjdk.org/jdk/pull/14746#issuecomment-1629261727
