Ability to add "jvm arguments" based on "@Param"

[Aleksey Shipilev]

On 06/05/2015 01:31 PM, Vladimir Sitnikov wrote:
>> Is it really *that* hard?
> 
> a) This raises a bar significantly. I can code that, no problem. The
> problem is if you "just want bind operationsPerInvocation to a single
> parameter", then you have to enumerate all the parameters.

Yes. Using the API would *always* be harder than using any implicit
thing the framework has. The trick is to recognize whether it is hard
enough to warrant complicating the framework implementation. There is
always a consideration where to draw a line in the framework interface.


> If you just want having different flight recorder files (or garbage
> collector log files), you have to write your own profiler.
> Well, recording jfrs via ExternalProfiler is not that bad. However,
> running tests with different concurrency levels is not "just adding an
> option".
> 
> b) "progress bar" feature is broken when you run in separate Runners, isn't it?

Yes, but only if you presume the progress should be tracked across
Runner calls.

>> Suggest to extend the API to expose more knobs. (More
> likely to fly)
> 
> What if ChainedOptionsBuilder#postConfigurator is added to
> post-process the options?
> It is just a proof of concept (no documentation, very little testing,
> naming issues not solved, etc etc).

Oh, good one. I wonder if you can simplify it by recognizing you want to
tap into (Options,BenchmarkListEntry) -> BenchmarkParams conversion,
like this:
  http://cr.openjdk.java.net/~shade/jmh/postconfigurator-1.patch

The upside for this approach is that it does not introduce more concepts
than required, and uses the public BenchmarkParams [1] to communicate
the actual parameters.

Thanks,
-Aleksey

[1]
http://hg.openjdk.java.net/code-tools/jmh/file/6609eea91d87/jmh-samples/src/main/java/org/openjdk/jmh/samples/JMHSample_31_InfraParams.java