Support Accelerating ArraysSupport.vectorizedMismatch for OffHeap #21097
Conversation
|
The code mimics |
|
The code probably needs reformatting, since I'm not sure whether I should move some code to J9TransformUtil.cpp |
|
Issue: #16717 |
|
FYI @zl-wang |
luke-li-2003
force-pushed
the
OffHeapVectorizedMismatch
branch
from
a98a3d7 to
d4ec9e4
Compare
Support the acceleration of vectorizedMisMatch for OffHeap implementation by adding a block of code to calculate the address of the arrays, while accounting for null values. Signed-off-by: Luke Li <[email protected]>
luke-li-2003
force-pushed
the
OffHeapVectorizedMismatch
branch
from
d4ec9e4 to
304b76d
Compare
| @@ -467,8 +467,169 @@ void J9::RecognizedCallTransformer::process_jdk_internal_util_ArraysSupport_vect | |||
| TR::Node::create(node, TR::lxor, 2, mask, TR::Node::lconst(node, -1))); | |||
|
|
|||
| TR::Node* mismatchByteIndex = TR::Node::create(node, TR::arraycmplen, 3); | |||
| // TODO: replace the following aladd's with generateDataAddrLoadTrees when off-heap memory changes come in | |||
| // See OpenJ9 issue #16717 https://github.com/eclipse-openj9/openj9/issues/16717 | |||
| #if defined(J9VM_GC_SPARSE_HEAP_ALLOCATION) | |||
There was a problem hiding this comment.
do we need to go through this complicated transformation for offheap? i.e. can we simplify it somewhat? i guessed we need to answer a couple questions before it is cleared up:
- if
a & bare non-NULL, could they not be array objects? i.e. can we assume they are arrays? - should we treat
aOffset & bOffsetin the same manner as in Unsafe.get/put()? I think so from language intention perspective.
when both answers are yes, the transformation for offheap should simplify to (foraas an example):
(a == NULL)? aOffset : (a.DataAddr + aOffset)
@Spencer-Comin please chime in for your opinion ...
There was a problem hiding this comment.
- As outlined in Disable vectorizedMismatch transformation for OffHeap #20008 (comment), the jdk does not assert them to be arrays. I double-checked and that was indeed the case, so I was working from that assumption.
There was a problem hiding this comment.
ah ... it sounds similar to Unsafe.copyMemory() then. @rmnattas can share with you much more details.
There was a problem hiding this comment.
When vectorizedMismatch is called for array objects the offset includes the array header size (i.e. the offset is from the beginning of the object, not from the address of the first index), so to compensate the correct transformation when a is an offheap array would be a.DataAddr + aOffset - arrayHeaderSize
There was a problem hiding this comment.
FYI @Spencer-Comin : no need. in offheap mode, ArrayBaseOffset is defined to be zero already.
Support the acceleration of vectorizedMisMatch for OffHeap implementation by adding a block of code to calculate the address of the arrays, while accounting for null values.