RFC: Dynamic groups support

[Dmitry Chuyko]

It works. And results with dynamic groups are the same as with generated 
groups.

Single threads distribution for all groups matching specified pattern is 
handy but may be confusing if there are different number of methods in 
groups.
Replacing @Threads[method] with at GroupThreads is a little pain as it's a 
string replacement. Agree with private argument that having different 
annotations for class and methods is less confusing.
Groups multiplication is a powerful but not obvious feature along with 
rounding. But for me it would be more clear to write also @Threads(32), 
@GroupThreads(.25), @GroupThreads(.75) (or -t 32 -tg 1,4 or -t 32 -tg 
16.0,48.0) and get 8 and 24.

Dmitry

On 11/18/2013 9:24 PM, Aleksey Shipilev wrote:
> Hi,
>
> Following up to Nitsan's (external) and Dmitry's (internal) thread on
> asymmetric benchmark support in JMH, I would like to solicit the review
> on this change:
>   http://cr.openjdk.java.net/~shade/jmh/jmh-dynamic-groups-1.patch
>
> I would like Nitsan and Dmitry to apply this patch over the fresh tip,
> and try to build the benchmarks they like. If you see something is
> missing there which does not fit your use cases, speak up. I'll do some
> polishing meanwhile.
>
> Gruesome details:
>
>   *) This change eliminates the static group assignment, and pushes for
> dynamic group assignment. That is, you don't need to set @Threads
> anymore for @Group in advance. Instead, you can select the thread group
> distribution at runtime.
>
>   There are two ways to control it:
>      a) With the new command line option "-tg INT,INT,...,INT".
>      b) With the new API method "threadGroups(int... groups)".
>
>   This opens up the way to have a single asymmetric benchmark, and juggle
> the thread distribution in runtime.
>
>   *) @Threads is illegal on @Group now, for two reasons: first, it
> clashes with the JMH meaning of "hinting the default thread count",
> second, the group API is slightly changed, and so we need to break it in
> some way. With this change, you will have to use @GroupThreads for
> telling JMH how many threads should be the part of group. This opens up
> the way to say...
>
>    @Threads(12)
>    class T {
>       @GMB
>       @Group("Z")
>       @GroupThreads(1)
>       void test1() { ... }
>
>       @GMB
>       @Group("Z")
>       @GroupThreads(5)
>       void test2() { ... }
>    }
>
>   This will run 2 groups with {1,5} threads each. Like @Threads,
> @GroupThreads is only the hint for the default distribution. Overriding
> it from cli/api can produce another distribution.  Notice that by
> playing with both @Threads/@GroupThreads, -t/-tg,
> .threads()/threadGroups(), you may configure the run quite flexibly.
>
>   *) The number of worker threads now gets automatically rounded to the
> group unit. In the example above, running it with -t 13 will
> automatically populate 3 groups with {1,5} threads each, totalling 18
> threads.
>
> Thanks,
> -Aleksey.