How to get rid of "Method parameters should be @State classes" in JMH when parameters come from another method?

Question

I'm working on a maven project. The scenario is something like below...

class Test {

    public void applyAll() {
        ....................
        ....................
        Collection<Migratable> applicableUpdates = SomeOtherClass.getApplicableUpdates();
        doUpdate(applicableUpdates);

    }

    @Benchmark
    public void apply(Migratable m) {
        ....................
        ....................
    }

    private void doUpdate(Collection<Migratable> applicableUpdates) throws Exception {
        for (Migratable m : applicableUpdates) {
            try {

                apply(m);

            } catch (Exception e) {
                logger.error("Falid to apply migration {}" + m, e);
                throw e;
            }
        }
    }
}

I need to compute how long it takes to execute each migration. Simply I need to compute the execution time of apply(Migratable m) method.
Now, when I build my project using "mvn clean install", build failed and it shows "Method parameters should be @State classes".

Here, parameter comes from another method doUpdate(Collection applicableUpdates) [see the scenario]. So how can I get rid of this error in given scenario?

Exocrine

You look up the JMH documentation and you run the performance test with JMH. If you are having trouble with that, you can come back to StackOverflow with a specific question. – Monolayer

Thanks @ErwinBolwidt. Think this time you'll understand the problem I'm facing. Actually, I'm stuck with this problem. – Exocrine

Answer 1

There are quite a few problems in your setup here and it seems you haven't actually looked at the samples of JMH; and I strongly advise you to do that.

A few notes...

1) You @Benchmark method returns void - it should return something; otherwise use BlackHoles (this is in the samples).

2) If parameters comes from another method it means that method should be a @SetUp method (this is in the samples)

3) The error that you are seeing has to do with the fact that your Migratable is not actually a @State class (this is again in the samples!)

At this point I can't stress that enough - but look and understand the samples. It's not going to be easy, this is micro-benchmark and as much as JMH tries to make things easier for us by hiding all the very complicated code, it still requires us to conform to the rules that exist there.

Checkbook

Thanks @Checkbook Migratable is an interface and State does not support abstract classes. And seeing this sample, it seems to me that @Benchmark can return void. Actually I'm new on this topic and still stuck. – Exocrine

@Exocrine for void methods read the samples about BlackHole. You will see that the sample that you provided is said to measure wrong. Its ok being new to the subject, we all were at some point in time. I use JMH for a lot of time and still get things wrong sometimes... – Checkbook

@Eugene...actually I cannot apply Blackholes' in my project seeing the sample. Now please, consider...you have this Test class. If you have to compute how long apply(Migratable m)` method takes in each time it is being called, how would you do that? It'll be helpful for me if you give the exact code with appropriate annotation(s) – Exocrine

Here, applyAll() method get applicableUpdates from another class and pass it to doUpdate(Collection<Migratable> applicableUpdates). doUpdate(Collection<Migratable> applicableUpdates) method pass each of the element of the list aplicableUpdates to apply(Migratable m) method. apply(Migratable m) method just update DB and return void. – Exocrine