Measuring performance changes from applying 4837946 patch
brian.burkhalter at oracle.com
Wed Jun 5 15:13:21 UTC 2013
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