Skip to content

Update CRC32C acceleration for off-heap #21852

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
May 20, 2025

Conversation

VermaSh
Copy link
Contributor

@VermaSh VermaSh commented May 12, 2025

The acceleration was initially disabled because it added array header size to the array object, which was required to reach the elements. However, this is unnecessary for off-heap mode. As a result, the evaluator has been updated to add the array header size exclusively for non-off-heap mode, while in off-heap mode, it now retrieves the data element address directly from the array header, enabling acceleration in off-heap mode.

@VermaSh
Copy link
Contributor Author

VermaSh commented May 12, 2025

Marking this WIP while I launch a personal test build.
cc: @r30shah @zl-wang @Spencer-Comin

@VermaSh
Copy link
Contributor Author

VermaSh commented May 12, 2025

launched personal build for verification.

@Spencer-Comin
Copy link
Contributor

Do you mean CRC32C?

@VermaSh VermaSh changed the title WIP: Update CRC32 acceleration for off-heap WIP: Update CRC32C acceleration for off-heap May 12, 2025
@VermaSh
Copy link
Contributor Author

VermaSh commented May 12, 2025

ah, dang, missed the C. I'll update the commit

@VermaSh VermaSh force-pushed the enableCRC32 branch 3 times, most recently from 3794477 to 5111063 Compare May 14, 2025 18:03
@VermaSh VermaSh changed the title WIP: Update CRC32C acceleration for off-heap Update CRC32C acceleration for off-heap May 15, 2025
@VermaSh VermaSh marked this pull request as ready for review May 15, 2025 14:25
@VermaSh
Copy link
Contributor Author

VermaSh commented May 15, 2025

This PR is ready, @Spencer-Comin , @r30shah Can I please get a review?

Comment on lines 2237 to 2248
if (TR::Compiler->om.isOffHeapAllocationEnabled())
{
// Load first data element address
generateRXInstruction(cg,
TR::InstOpCode::getLoadOpCode(),
node,
array,
generateS390MemoryReference(array, cg->comp()->fej9()->getOffsetOfContiguousDataAddrField(), cg));

// Since the first data element address is retrieved from the array header, the offset is set to 0
offsetToDataElements = 0;
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this work for the updateDirectByteBuffer as well?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have just updated the if condition. From what I understand directByteBuffer is supposed to be a contiguous memory off heap so we should be good using the passed in address without doing anything special in off-heap mode. @amicic Can you please confirm?

Copy link
Contributor

@amicic amicic May 16, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not expert, but yes DBB probably has an explicit pointer to the memory. DBB has nothing to do with Java Arrays, hence no dataAddr awareness (but I guess, onцe you reach the memory, you are free to apply some of array specific optimizations).

Copy link
Contributor

@r30shah r30shah left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Minor nitpick.

Comment on lines 2234 to 2235
// Offset to be added to array object pointer to get to the data elements
int32_t offsetToDataElements = isDirectBuffer ? 0 : TR::Compiler->om.contiguousArrayHeaderSizeInBytes();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
// Offset to be added to array object pointer to get to the data elements
int32_t offsetToDataElements = isDirectBuffer ? 0 : TR::Compiler->om.contiguousArrayHeaderSizeInBytes();
// Offset to be added to array object pointer to get to the data elements
int32_t offsetToDataElements = isDirectBuffer ? 0 : static_cast<int32_t>(TR::Compiler->om.contiguousArrayHeaderSizeInBytes());

@r30shah
Copy link
Contributor

r30shah commented May 16, 2025

Jenkins test sanity zlinux jdk11,jdk21

@r30shah
Copy link
Contributor

r30shah commented May 16, 2025

@VermaSh Please wait for the tests to finish before you apply minor nitpick change

@VermaSh
Copy link
Contributor Author

VermaSh commented May 16, 2025

Don't think the failure is related to my changes. It looks similar to the stack trace in other failures due to #21720

12:57:30  ----------- Stack Backtrace -----------
12:57:30  _ZN24TR_J9ByteCodeIlGenerator14getReceiverForEPN2TR15SymbolReferenceE+0x56 (0x0000020014A20D66 [libj9jit29.so+0x320d66])
12:57:30  _ZN24TR_J9ByteCodeIlGenerator21genInvokeWithVFTChildEPN2TR15SymbolReferenceE+0x1e (0x0000020014A35FCE [libj9jit29.so+0x335fce])
12:57:30  _ZN24TR_J9ByteCodeIlGenerator18genInvokeInterfaceEi+0x450 (0x0000020014A36620 [libj9jit29.so+0x336620])
12:57:30  _ZN24TR_J9ByteCodeIlGenerator6walkerEPN2TR5BlockE+0x2230 (0x0000020014A3A6E8 [libj9jit29.so+0x33a6e8])
12:57:30  _ZN24TR_J9ByteCodeIlGenerator18genILFromByteCodesEv+0x4ba (0x0000020014A104C2 [libj9jit29.so+0x3104c2])
12:57:30  _ZN24TR_J9ByteCodeIlGenerator5genILEv+0xb6 (0x0000020014A12636 [libj9jit29.so+0x312636])
12:57:30  _ZN3OMR20ResolvedMethodSymbol5genILEP11TR_FrontEndPN2TR11CompilationEPNS3_20SymbolReferenceTableERNS3_12IlGenRequestE+0x2a4 (0x0000020014E0A594 [libj9jit29.so+0x70a594])
12:57:30  _ZN3OMR11Compilation7compileEv+0x1fe (0x0000020014DEAF96 [libj9jit29.so+0x6eaf96])
12:57:30  _ZN2TR28CompilationInfoPerThreadBase7compileEP10J9VMThreadPNS_11CompilationEP17TR_ResolvedMethodR11TR_J9VMBaseP19TR_OptimizationPlanRKNS_16SegmentAllocatorE+0x4de (0x000002001489A846 [libj9jit29.so+0x19a846])
12:57:30  _ZN2TR28CompilationInfoPerThreadBase14wrappedCompileEP13J9PortLibraryPv+0x3fe (0x000002001489B9BE [libj9jit29.so+0x19b9be])
12:57:30  omrsig_protect+0x3d8 (0x000002000FEB1AC8 [libj9prt29.so+0x31ac8])
12:57:30  _ZN2TR28CompilationInfoPerThreadBase7compileEP10J9VMThreadP21TR_MethodToBeCompiledRN2J917J9SegmentProviderE+0x402 (0x0000020014898FD2 [libj9jit29.so+0x198fd2])
12:57:30  _ZN2TR24CompilationInfoPerThread12processEntryER21TR_MethodToBeCompiledRN2J917J9SegmentProviderE+0x13c (0x000002001489955C [libj9jit29.so+0x19955c])
12:57:30  _ZN2TR24CompilationInfoPerThread14processEntriesEv+0x402 (0x0000020014897FE2 [libj9jit29.so+0x197fe2])
12:57:30  _ZN2TR24CompilationInfoPerThread3runEv+0xac (0x00000200148984D4 [libj9jit29.so+0x1984d4])
12:57:30  _Z30protectedCompilationThreadProcP13J9PortLibraryPN2TR24CompilationInfoPerThreadE+0x94 (0x000002001489856C [libj9jit29.so+0x19856c])
12:57:30  omrsig_protect+0x3d8 (0x000002000FEB1AC8 [libj9prt29.so+0x31ac8])
12:57:30  _Z21compilationThreadProcPv+0x196 (0x00000200148989AE [libj9jit29.so+0x1989ae])
12:57:30  thread_wrapper+0xf6 (0x000002000FF88C8E [libj9thr29.so+0x8c8e])
12:57:30  start_thread+0xea (0x000002000F608312 [libpthread.so.0+0x8312])
12:57:30   (0x000002000F88E232 [libc.so.6+0x10e232])
12:57:30  ---------------------------------------

The acceleration was initially disabled because it added array header
size to the array object, which was required to reach the elements.
However, this is unnecessary for off-heap mode. As a result, the
evaluator has been updated to add the array header size exclusively
for non-off-heap mode, while in off-heap mode, it now retrieves the
data element address directly from the array header, enabling
acceleration in off-heap mode.

Signed-off-by: Shubham Verma <[email protected]>
@VermaSh
Copy link
Contributor Author

VermaSh commented May 20, 2025

@r30shah I have updated the PR with your suggestion.

@r30shah
Copy link
Contributor

r30shah commented May 20, 2025

jenkins test sanity zlinux jdk21

@r30shah r30shah merged commit 5714fe6 into eclipse-openj9:master May 20, 2025
6 checks passed
@VermaSh VermaSh deleted the enableCRC32 branch May 20, 2025 21:16
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants