WIP: Adjust arguments to transformed UnsafeAPI calls when offheap is enabled

[midronij]

During recognizedCallTransformer and unsafeFastPath, Unsafe.getAndAdd() or Unsafe.getAndSet() can be transformed into an atomicFetchAndAdd/atomicSwap helper call. For the UnsafeAPI methods, the destination address is passed in as two separate values: a base object address and an offset. When they are transformed into atomic helper calls, these values are added together and passed in as a single destination address value. However, this does not account for the differing shape of array objects under offheap/balanced GC policy (as opposed to the default, gencon).

Thus, this contribution includes the following changes

• For both recognizedCallTransformer and unsafeFastPath, if the object is an array, the dataAddr pointer is loaded and used as the base address.
• For recognizedCallTransformer, an array check is added to the series of runtime tests performed before calling the atomic helper, to ensure that dataAddr is only used if the object is indeed an array.

[midronij]

@zl-wang here is the Unsafe.getAndAdd()/getAndSet() fix! Marked as a WIP since I am still finalizing the unsafeFastPath changes (the last two commits)

[zl-wang]

how can you do aladd before you know if it is an array or not? it is unclear to me what purpose this aladd is for.

[zl-wang]

directload opcode is for static field i think ... this code looks contradictory to where the addressing is from.

[midronij]

I believe this is consistent with other areas where runtime array checks are performed, such as with Unsafe.get/put():

TR::Node *objLoad = TR::Node::createWithSymRef(unsafeAddress,
                                       comp()->il.opCodeForDirectLoad(unsafeAddress->getDataType()), 0,
                                       newSymbolReferenceForAddress);
TR::Node *vftLoad = TR::Node::createWithSymRef(TR::aloadi, 1, 1, objLoad,
                                       comp()->getSymRefTab()->findOrCreateVftSymbolRef());
.
.
.
TR::Node *testIsArrayFlag = comp()->fej9()->testIsClassArrayType(vftLoad);
TR::Node *isArrayNode = TR::Node::createif(TR::ificmpne, testIsArrayFlag, TR::Node::create(TR::iconst, 0), NULL);

(from genCodeForUnsafeGetPut())

[zl-wang]

don't understand this either: you seemed assuming the previous directload result as an object. at the same time, you look up the opcode through a table (while you know the datatype already).

[ianguo]

During recognizedCallTransformer and unsafeFastPath, Unsafe.getAndAdd() or Unsafe.getAndSet() can be transformed into an atomicFetchAndAdd/atomicSwap helper call. For the UnsafeAPI methods, the destination address is passed in as two separate values: a base object address and an offset. When they are transformed into atomic helper calls, these values are added together and passed in as a single destination address value. However, this does not account for the differing shape of array objects under offheap/balanced GC policy (as opposed to the default, gencon).

Thus, this contribution includes the following changes

• For both recognizedCallTransformer and unsafeFastPath, if the object is an array, the dataAddr pointer is loaded and used as the base address.
• For recognizedCallTransformer, an array check is added to the series of runtime tests performed before calling the atomic helper, to ensure that dataAddr is only used if the object is indeed an array.

During the running period of our application, from the thread stack, it has been "staying" at AtomicReferenceArray#getAndSet. A phenomenon similar to livelock has occurred. As a result, the thread is blocked and the application is seriously unrecoverable. I am not sure if it is related to your problem？ @midronij @zl-wang

thread stack：
"pool-EventCacheMessageHandler-thread-1" Id=21859 RUNNABLE
at sun.misc.Unsafe.getAndSetObject(Unsafe.java:1165)
at java.util.concurrent.atomic.AtomicReferenceArray.getAndSet(AtomicReferenceArray.java:164)
at com.fasterxml.jackson.core.util.BufferRecycler.allocCharBuffer(BufferRecycler.java:159)
at com.fasterxml.jackson.core.io.IOContext.allocTokenBuffer(IOContext.java:270)
at com.fasterxml.jackson.core.JsonFactory.createParser(JsonFactory.java:1164)
at com.fasterxml.jackson.databind.ObjectMapper.readValue(ObjectMapper.java:3629)
at com.fasterxml.jackson.databind.ObjectMapper.readValue(ObjectMapper.java:3597)

java version：
openjdk version "1.8.0_422"
IBM Semeru Runtime Open Edition (build 1.8.0_422-b05)
Eclipse OpenJ9 VM (build openj9-0.46.0, JRE 1.8.0 Linux amd64-64-Bit Compressed References 20240802_1004 (JIT enabled, AOT enabled)
OpenJ9 - 1a6f612
OMR - 840a9adba
JCL - a75ff73ce5 based on jdk8u422-b05)