RFR 8155258: VarHandle implementation improvements

Aleksey Shipilev aleksey.shipilev at oracle.com
Tue May 3 13:11:36 UTC 2016

On 05/03/2016 01:18 AM, Paul Sandoz wrote:
>   http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8155258-vhs-impl-improvements-jdk/webrev/ <http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8155258-vhs-impl-improvements-jdk/webrev/>
>   http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8155258-vhs-impl-improvements-hotspot/webrev/ <http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8155258-vhs-impl-improvements-hotspot/webrev/>

I remember testing this before, so it definitely helps performance in
pathological use cases for CompareAndExchange.


*) Not sure I "dig" the change here (apart from old code apparently
blows the capacity estimate):

 469     static String getVarHandleMethodSignature(MethodType mt) {
 470         char[] sig = new char[mt.parameterCount() + 2];
 472         int i = 0;
 473         for (; i < mt.parameterCount(); i++) {
 474             sig[i] = getCharType(mt.parameterType(i));
 475         }
 476         sig[i] = '_';
 477         sig[i + 1] = getCharType(mt.returnType());
 479         return String.valueOf(sig);

With Compact Strings, it's beneficial to use StringBuilder instead of
char[], because StringBuilder will concat in Latin1 form. char[] code
would need to re-compress to byte[] during String.valueOf().


 *) Only imports are changed. Revert? Otherwise next runner up would
change the imports back, ad nauseam.


 *) There's compareAndExchangeVolatile_V, but there is no
compareAndExchange{Acquire,Release}_V, etc. Shouldn't we have the "void"
entries for every method that returns a value? Or,
compareAndExchangeVolatile_V is redundant, and does not participate the
new mechanics?


More information about the hotspot-dev mailing list