Measuring performance changes from applying 4837946 patch (original) (raw)

Brian Burkhalter brian.burkhalter at oracle.com
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.

Thanks,

Brian

More information about the core-libs-dev mailing list