RFR 8155258: VarHandle implementation improvements

Paul Sandoz paul.sandoz at oracle.com
Tue May 3 18:35:06 UTC 2016


> On 3 May 2016, at 06:11, Aleksey Shipilev <aleksey.shipilev at oracle.com> wrote:
> 
> 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.
> 
> MethodHandleNatives:
> 
> *) Not sure I "dig" the change here (apart from old code apparently
> blows the capacity estimate):
> 

Right, blows the estimate and i did some extra fiddling to remove the dependency on StringBuilder at the same time.


> 469     static String getVarHandleMethodSignature(MethodType mt) {
> 470         char[] sig = new char[mt.parameterCount() + 2];
> 471
> 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());
> 478
> 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().
> 

Good point, reverted.


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

Reverted.


> X-VarHandle.java.template:
> 
> *) 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?
> 

Ah, that is a left-over from a previous experiment, before i realised the return value can be dropped. Removed.

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/>

Thanks,
Paul.


More information about the hotspot-dev mailing list