Java shared memory
paul.sandoz at oracle.com
Wed Jun 1 14:17:24 UTC 2016
> On 31 May 2016, at 12:44, Radek <rsmogura at gmail.com> wrote:
> Dear Paul and Adrew,
> Indeed I’ve messed up with a coping long. I don’t know why I have done it, as my first approach actually involved buff.getLong(). I’ve took, as well, closer look at my tests and right now I use JDK9 build 120, as a reference points.
> There is a performance gain (build 120 vs custom slow debug) but right now it’s 12%, not so huge. Maybe after code polishing and additional optimisation I could get 15-20%.
I am still skeptical, sorry.
I strongly recommend writing JMH benchmarks, and also run with the perfasm option to produce the hot parts of the generated benchmarked code. Otherwise it’s hard to trust the results. But it’s hard to trust *any* performance results :-) using JMH makes it easier to evaluate.
> I don’t know if in such a case my work could be interesting.
My suggestion is to look more closely at Panama, there might be some synergy and reuse of what you are learned in HotSpot.
> Best regards,
> PS Attached please find latest results, the MappedByteBuffer case uses for (int i=0; i < mbuff.limit(); i+=8) loop.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
More information about the hotspot-compiler-dev