Hi Martin
There's a good chance COWAL access to the array can be optimized as you suggest using VarHandles. Write using release; read using acquire, or plain if holding the lock. I am not very sure, setRelease only ensures the ordering or has the effect that update the writing data to the memory immediately? If it only ensures the ordering, we may still need to volatile writing for this case CopyOnWriteArrayList… Doesn't buy much on x86 but performance improvement should be measurable on ppc. Oh, I realized there is no memory barrier for my volatile reading code on x86. Anyway there is performance benefit if we replace volatile writing with setRelease or releaseFence on x86. I would look for the scenarios in the library. We expect some potential performance benefit from keeping minimal memory access constraint in theory, but because the overhead of MethodHandle we may not take VarHandle api in some cases for the performance. Thanks YC On Wed, Apr 24, 2019 at 10:33 PM Frank Yuan <[email protected] <mailto:[email protected]> > wrote: > > 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" <[email protected] <mailto:[email protected]> > > > À: "Aleksey Shipilev" <[email protected] <mailto:[email protected]> > > > Cc: "core-libs-dev" <[email protected] > > <mailto:[email protected]> > > > 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
