On Sun, 25 Oct 2026 07:22:27 GMT, Yunbo Zhang <[email protected]> wrote:
>> My concern here is that this seems to end up becoming a bit of an endless >> effort. I think a more appropriate direction here is to first establish >> whether all benchmarks should either A) be possible to run with any -t >> override), B) somehow be able to specify their own un-overridable thread >> count, or C) not be expected to deal with arbitrary overrides of -t. >> >> Once that is established, it would be more clear what should be the >> appropriate fix. > >> My concern here is that this seems to end up becoming a bit of an endless >> effort. I think a more appropriate direction here is to first establish >> whether all benchmarks should either A) be possible to run with any -t >> override), B) somehow be able to specify their own un-overridable thread >> count, or C) not be expected to deal with arbitrary overrides of -t. >> >> Once that is established, it would be more clear what should be the >> appropriate fix. > > Thank you for your guidance, Viktor. I see your point. > > I'd prefer JMH to support declaring a fixed worker count, through an > annotation or another mechanism, so that `-t` cannot override it. Benchmarks > that need a fixed worker count would use this annotation. Those without it > would be expected to support multiple workers. > > I'll hold off on further changes to this PR until we agree on a direction. @benshuai5D @dholmes-ora Fair enough. Addressing it on a bench-by-bench basis is fine with me. ------------- PR Comment: https://git.openjdk.org/jdk/pull/33239#issuecomment-6413412127
