Does 'intrinsify' means that source code of JVM is somewhat 'conservative', but the JIT compiler can do some optimization when the JVM warms up? For example,
UNSAFE_ENTRY(void, Unsafe_SetOrderedObject(JNIEnv *env, jobject unsafe, jobject obj, jlong offset, jobject x_h))
UnsafeWrapper("Unsafe_SetOrderedObject");
oop x = JNIHandles::resolve(x_h);
oop p = JNIHandles::resolve(obj);
void* addr = index_oop_from_field_offset_long(p, offset);
OrderAccess::release();
if (UseCompressedOops) {
oop_store((narrowOop*)addr, x);
} else {
oop_store((oop*)addr, x);
}
OrderAccess::fence(); <==There is a full memory barrier to ensure visibility which is NOT strictly required
UNSAFE_END
the putOrderedObject is not required to ensure immediate visiblity
, but we can see that there is a full memory barrier attached the store to a specified object, so I said the JVM is conservative
, but a JIT compiler can optimize this memory barrier out during runtime, this is what so called instrinsify
, am I right?
JVM intrinsics are methods in the JDK for which the JITs emit specialized sequences of machine instructions which can be directly inlined into the caller. For example on x86 Integer.bitCount(int)
can be replaced with the POPCNT
instruction.
The pure java implementation is likely too complex to be recognized by peephole optimizations - unlike emulate-rotation-with-shifts for example - and JNI overhead would kill any performance gains from using hand-crafted assembly for a single operation.
Many unsafe methods are also intrinsified so that those method calls are not black boxes for the optimizer (as JNI methods would be), which, yes, allows it to be less conservative. But that's just a sub-property of intrinsification.
(those are basically the top google results for "hotspot intrinsics")
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With