Recognize and inline VarHandle memory fence methods

[0xdaryl]

Since JDK9, the VarHandle class has provided static methods to perform memory fence operations:

• fullFence
• acquireFence
• releaseFence
• loadLoadFence
• storeStoreFence

These methods should be recognized by the JIT and each backend should issue the appropriate machine instructions to implement the corresponding fence semantics.

Currently, these methods are implemented by calling methods in the Unsafe class. The JIT relies on these methods being inlined to expose the underlying Unsafe calls. Since Unsafe is due to be deprecated and it is easy enough to recognize the VarHandle methods directly then it should be done that way.

[0xdaryl]

The inliner presently generates fence IL opcodes for recognized Unsafe fence calls. Each backend already supports the fence opcodes, so perhaps the proper way to do this is to have the inliner transform the VarHandle fence calls into IL directly.

[Akira1Saitoh]

There are 3 IL opcodes for fence operations now:

• TR::fullFence
• TR::loadFence
• TR::storeFence

Currently, the both acquireFence and loadLoadFence are transformed into TR::loadFence. Also the both releaseFence and storeStoreFence are transformed into TR::storeFence. However, by definition, loadLoadFence is weaker than acquireFence, storeStoreFence is weaker than releaseFence.
Thus, separate IL opcodes for those 5 fence operations are desired.
In some architectures, those fences can be implemented by different memory barrier instructions. (e. g. dmb ish for releaseFence and dmb ishst for storeStoreFence on aarch64)