Parametrise @Threads

[Joel Moberg]

I realise this is hard. I found that you can't yet limit number of threads
but you can set a affinity mask. Limiting the number of cores should give
better control and understanding for the benchmark stats, think about cache
locality and cpu migrations. But setting affinity is OS specific. I think
this could be supported by some additions to the JVM launcher in jmh, not
trivial but can work.

I am trying to use the Java API as far as I can. I know how to limit the
number of threads for a ExecutorService but I also use parallel streams.
For this case I found a suggestion to use a ForkJoinPool, see
http://stackoverflow.com/questions/21163108/custom-thread-pool-in-java-8-parallel-stream/22269778#22269778
.
I think this is confusing, overriding the pool, but should be more powerful
so it is good. Reading the comments and some related threads, it seems that
this should work.

Thanks,
Joel

On Thu, May 19, 2016 at 12:05 AM, Aleksey Shipilev <
aleksey.shipilev at oracle.com> wrote:

> On 04/29/2016 07:35 PM, Joel Moberg wrote:
> > I googled the list to find a way to parametrise the number of threads
> used
> > for a benchmark. This question was asked before here:
> > http://mail.openjdk.java.net/pipermail/jmh-dev/2014-October/001423.html.
> > There is a link to a issue describing that @Threads could accept
> > parameters. The suggestion is to either let some annotations accept a
> > sequence, or let users be able parametrize with @Params annotation. I
> think
> > the first suggestion is better, and maybe easier to implement (if
> > annotations can extend a base annotation?). I have not written any
> > annotation code yet. But I want this feature, and want to know if there
> > still is interest. Is there any way I can help?
>
> There is still interest. Alas, this touches the very core of JMH, and
> the required effort is not trivial. Many volunteers stepped forward with
> trying to implement this, never to be heard again.
>
> But, it is somewhat offset by the usual motto: annotations are not
> supposed to cover every single case -- expressing DSLs in annotations
> really sucks. If you need to code up some advanced scenario, use the
> Java API.
>
> Thanks,
> -Aleksey
>
>