performance impact of JNI GetCritical*
Y. Srinivas Ramakrishna
Y.S.Ramakrishna at Sun.COM
Thu Mar 18 12:18:58 PDT 2010
On 03/18/10 11:49, Y. Srinivas Ramakrishna wrote:
>>>> lets say I have a short java array of length 12. Should I copy it to a
>>>> direct NIO buffer and use the buffer as vehicle, use
>>>> or something else?
>>> For very short arrays this is quite likely beneficial (at least if
>>> you're on JDK7, at least older JDK6 releases do get/releasecritical +
>>> memcpy in jni code).
> Right; this is a fact that I learnt much to my delight recently.
> I requested that this improvement be backported to JDK 6, but
> I do not know if/when that might happen.
Let me clarify/correct my comment a bit.
What I meant to say was that NIO performance/behaviour improved a lot
in JDK 7 because it stopped using JNI CS, using unsafe instead.
(This also had the pleasant side-effect of working around a particularly
egregious CMS bug related to JNI CS recently discussed on this alias,
and still unfortunately not fixed, which is what initially brought this
change to my attention.)
As regards Michael's original question on whether NIO or JNI CS
is better suited for short arrays, at the risk of stating the obvious,
I think the answer is that how much better NIO is (in JDK 7) would likely
depend on the frequency of copying and size of these arrays: If JNI CS
are very short-lived and infrequent and the arrays are as small as 12 bytes,
the difference would likely be negligible. As frequency of use (and degree
of concurrent use) and/or array size increases, NIO would likely become
increasingly better than JNI CS (in JDK 7 at least). At least that's my hunch.
More information about the hotspot-gc-use