VarHandle instance methods performance

Frank Yuan frank.yuan at oracle.com
Thu Apr 25 05:32:14 UTC 2019


> 
> Hi Frank,
> a VarHandle is a glorified integer value that correspond to the number of bytes from a pointer to a field address,
> so you give it a reference and you have access to the field at the address: reference + shift, given that the shift value is the same for all the
> instances of the same class,

I know, but I thought they were ready once the VarHandle instance was constructed...

Actually, I was looking up some way to improve library performance by VarHandle API. 
For example, CopyOnWriteArrayList uses a volatile variable referring to Object[] array, the writing procedure updates the volatile variable once it makes a new array completely, and then the reading procedure can read the new array by the volatile variable. Here, I think in theory, we can replace the volatile reading by getOpaque, which only requires the program does read the variable from the memory.

But the actual performance of getOpaque is not better than volatile reading due to the overhead(with using static VH instance), I have to hold on my idea now. 

Thanks
YC


> it should be declared static (and final so it's a constant for the VM).
> 
> Rémi
> 
> ----- Mail original -----
> > De: "Frank Yuan" <frank.yuan at oracle.com>
> > À: "Aleksey Shipilev" <shade at redhat.com>
> > Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>
> > Envoyé: Mercredi 24 Avril 2019 12:11:11
> > Objet: RE: VarHandle instance methods performance
> 
> >> On 4/24/19 11:51 AM, Frank Yuan wrote:
> >> > My test code is as below:
> >> > ...
> >> >     final VarHandle vhf;
> >> >     final VarHandle vhvf;
> >> > ...
> >>
> >> Make these two "static final", initialize them in class initializer, then try
> >> again.
> >>
> >> VarHandle (like Atomic*FieldUpdaters, MethodHandle, etc), have internal checks
> >> that can only be
> >> folded away when the VH/MH/A*FU instance is constant.
> >>
> >
> > Thank you, it works!
> >
> > YC
> >
> > > -Aleksey



More information about the core-libs-dev mailing list