This is as far as I got before I got interrupted:
http://cr.openjdk.java.net/~mikael/NioBenchmark.java
I haven't had time yet to verify that the benchmark code even measures
the right thing, much less figure out why I get the performance impact
with my fix. I can see many reasons why that could be the case, but it
would be good to know if it's something trivial which can be easily
fixed. In general, it sure would be nice to make this code behave and
perform without compiler specific annotations, especially given that
reliance on unaligned memory accesses and the cast specifically is
sketchy at best.
Cheers,
Mikael
On 2015-11-30 10:13, Alexander Smundak wrote:
On Wed, Nov 25, 2015 at 2:52 PM, <hotspot-dev-requ...@openjdk.java.net> wrote:
Have you looked anything at the performance of the generated code?
No. I looked at the emitted code, saw 'MOVQDU' instruction being used
(it was 'MOVQDA' before that resulted in alignment error), and concluded
that the compiler knows what it's doing :-)
It would be interesting to understand what type of performance you see with
your patch.
If you have specific benchmark in mind, I am willing to run it.
Sasha
