Hi Aleksey, On 19/08/2016 4:31 PM, Aleksey Shipilev wrote:
On 08/19/2016 08:15 AM, David Holmes wrote:I need to test the jbyte version of Atomic::cmpxchg in the VM, but so far it doesn't seem to be the case that any library code will actually invoke it. At the top Java level there is no AtomicByte class. Unsafe defines compareAndSwapByte variants but implements them using compareAndSwapInt and isolating the byte of interest. VarHandles seems to have direct *SwapByte operations but I can't figure out what they map to - there are VM intrinsics but again I can't the actual implementation to see if it uses Atomic::cmpxchg(jbyte*).VarHandles byte CAS/CAE map to Unsafe. Therefore they will use the Java-ish compareAndExchangeByte from Unsafe, without touching Atomic::cmpxchg(jbyte). In retrospect, we did that before Atomic::cmpxchg(jbyte) was available.
We did? I thought the VM jbyte version was old, while the Unsafe version was new ??
Anyway ...
Now it might be cleaner to ditch Java version from Unsafe, and make
native entry points like Unsafe_CompareAnd{Exchange,Swap}{Byte,Short}
which would call relevant Atomic::cmpxchg-s.
I tried commenting out the Java-ish version and defining one that would call Atomic::cmpxchg from unsafe.cpp in the VM. However something is complaining about the intrinisics - I removed the HotspotIntrinsicCandidate annotation as I don't want any intrinisics, but I get a build error:
Compiler intrinsic is defined for method [jdk.internal.misc.Unsafe.compareAndSwapByte(Ljava/lang/Object;JBB)Z], but the method is not annotated with @HotSpotIntrinsicCandidate. Exiting.
No idea where this is coming from or how I can disable it ?? Thanks, David
Then, regular jdk/test/java/lang/invoke/varhandles and hotspot/tests/compiler/unsafe tests would exercise that path, as they run in interpreter too. Thanks, -Aleksey
