Testing hotspot's Atomic::cmpxchg(jbyte*) ?
Aleksey Shipilev
aleksey.shipilev at gmail.com
Fri Aug 19 09:37:01 UTC 2016
On 08/19/2016 12:26 PM, David Holmes wrote:
> On 19/08/2016 5:40 PM, Aleksey Shipilev wrote:
>> 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.
>
> Okay that was the easy part.
>
> Now where do I find out the conditional compilation syntax for the
> X-VarHandle.java.template file?
The template itself is driven by Spp preprocessor, the same one used
thorough JDK. It is called during build via
./jdk/make/gensrc/GensrcVarHandles.gmk.
But why do you need to change VH templates? VH implementations call
Unsafe, see:
@ForceInline
static $type$ compareAndExchange(FieldInstanceReadWrite handle,
Object holder, $type$ expected, $type$ value) {
return
UNSAFE.compareAndExchange$Type$Volatile(Objects.requireNonNull(handle.receiverType.cast(holder)),
handle.fieldOffset,
{#if[Object]?handle.fieldType.cast(expected):expected},
{#if[Object]?handle.fieldType.cast(value):value});
}
...so once you do the Unsafe part above, everything should be linked
together. The jtreg tests exercise VH byte ops, so you can run them.
Thanks,
-Aleksey
More information about the core-libs-dev
mailing list