Testing hotspot's Atomic::cmpxchg(jbyte*) ?
Aleksey Shipilev
aleksey.shipilev at gmail.com
Fri Aug 19 07:40:35 UTC 2016
On 08/19/2016 10:13 AM, David Holmes wrote:
>> 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 ??
@HotSpotIntrinsicCandidate marks Java methods that are declared in
vmSymbols.hpp, and the VM code checks it. So, removing @HSIC without
modifying vmSymbols.hpp would blow up like that.
Anyway, I think you have to leave @HSIC methods untouched, because C2
would intrinsify them directly. To cater for the unsafe.cpp slow path,
do a separate method:
@HotSpotIntrinsicCandidate
public final byte compareAndExchangeByteVolatile(Object o, long offset,
byte expected,
byte x) {
compareAndExchangeByte0(o, long, expected, x);
}
public final native byte compareAndExchangeByte0(...);
...and then do an entry point for it in unsafe.cpp.
Thanks,
-Aleksey
More information about the core-libs-dev
mailing list