Measuring performance changes from applying 4837946 patch

Brian Burkhalter brian.burkhalter at
Wed Jun 5 15:13:21 UTC 2013

Hi Sergey,

Thanks for the comments and suggestions.

On Jun 5, 2013, at 2:20 AM, Aleksey Shipilev wrote:

> Sergey will follow up on the benchmark itself, I'm just being
> nit-picking below (not that it helps performance, but it does contribute
> to cleaner benchmark code):
>  a) if you only have the single State, you might as well use the
> benchmark instance itself to be the @State

I knew about @State but simply had not changed the test accordingly.

>  b) the annotations you are using on each method, can flow up to
> class-level annotation, and will be inherited by all the @GMB methods;

I was not aware of this.

>  c) it is a good idea to initialize the State fields within the @Setup
> method, because we guarantee correct initialization JMM-wise (try to run
> your benchmark on non-x86 hardware, and you can occasionally see the
> NPEs, because genericFactor1/2 might be null; you can also make the same
> effect with "final" on fields, but that wouldn't be the generic case).

That is good to know also. I read about State Fixtures but did not know of this behavior.

> Here's the complete code:

I'll try this updated version and see whether there is any change.



More information about the core-libs-dev mailing list