Benchmark Inheritance

[Alex Averbuch]

Thanks Aleksey,
Two questions..

--- 1 ---
I'll see if I can restructure the project to get around these things.
Given the following requirements, Are there any JMH patterns you could
suggest?

          Simple database read benchmark
           * Simple schema: single-valued records, configurable value type
(10-20 types)
           * 5-10 benchmark methods (per value type)
           * Benchmark methods must be run within long living transactions
(to avoid overhead of transaction creation)

--- 2 ---
In one of my previous emails I wrote:
"<------ (3) why was BaseBenchmark.tearDown() not called here? This is
cause of error I am guessing."
Do you know why this occurs?

On Thu, Jun 23, 2016 at 10:37 AM, Aleksey Shipilev <
aleksey.shipilev at oracle.com> wrote:

> On 23.06.2016 12:41, Aleksey Shipilev wrote:
> > You are caught in a very unlucky place with benchmark hierarchy,
> > abstract classes, and @State DAGs. The problem goes like this:
> >
> > IntProperty.getProperty(TxState txState):
> >   implicit state: IntPropertyRead instance (this)
> >   states: TxState
> >
> > ...resolution continues:
> >
> > TxState.setUp:
> >   state: PropertyReadBenchmark
> >
> > The underlying reason is that @State dependency matching machinery is
> > oblivious of class hierarchies: IntPropertyRead and
> > PropertyReadBenchmark are *distinct* states for it.
>
> Thinking more about it, this is lesser of two evils.
>
>
> > So it fails when PropertyReadBenchmark is abstract: it cannot be a
> > @State on its own -- only its subclasses can be instantiated. The
> > compiler would fail to produce an auxiliary JMH classes for
> > PropertyReadBenchmark, without having all the abstract methods
> implemented.
>
> This case should have better diagnostics (fixed):
>  https://bugs.openjdk.java.net/browse/CODETOOLS-7901706
>
>
> > It fails if make PropertyReadBenchmark non-abstract: the compilation
> > will proceed, and the dependency matching machinery will feed the
> > *PropertyReadBenchmark* instance into TxState.setUp, not the
> > *IntPropertyRead* one. Of course, it you put exception into
> > PropertyReadBenchmark.propertyDefinition, it would throw.
>
> This is actually a correct behavior: we should keep matching by class
> name, regardless if there are classes that can be substituted for each
> other. This eliminates nasty ambiguities, e.g.:
>
>   @State
>   public class State1 {}
>
>   @State
>   public class State2 extends State1 {}
>
>   @Benchmark
>   public void test(State1 s1, State2 s2) {
>     assert (s1 instanceof State1); // oops, can use State2 here?
>     assert (s2 instanceof State2);
>   }
>
> Thanks,
> -Aleksey
>
>
>
>
>