Skip to content
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

Disable TM when generating portable code #16282

Merged
merged 2 commits into from Nov 9, 2022

Conversation

dsouzai
Copy link
Contributor

@dsouzai dsouzai commented Nov 7, 2022

This PR disables the TM feature when generating portable code.

Fixes #16009

J9::CompilerEnv::initializeRelocatableTargetEnvironment()
{
OMR::CompilerEnvConnector::initializeRelocatableTargetEnvironment();
if (J9_ARE_ANY_BITS_SET(javaVM->extendedRuntimeFlags2, J9_EXTENDED_RUNTIME2_ENABLE_PORTABLE_SHARED_CACHE))
Copy link
Contributor Author

@dsouzai dsouzai Nov 7, 2022

Choose a reason for hiding this comment

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

I verified that at the time this is called, the J9_EXTENDED_RUNTIME2_ENABLE_PORTABLE_SHARED_CACHE flag does get set.

@@ -1057,7 +1057,7 @@ TR_SharedCacheRelocationRuntime::checkAOTHeaderFlags(const TR_AOTHeader *hdrInCa
{
bool defaultMessage = true;

if (!TR::Compiler->target.cpu.isCompatible(hdrInCache->processorDescription))
if (!TR::Compiler->relocatableTarget.cpu.isCompatible(hdrInCache->processorDescription))
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Strictly speaking, the target should be a superset of the relocatableTarget, so even if the relocatable target of the code in the SCC wasn't compatible with the relocatable target of the running JVM, but it is compatible with the target of the running JVM, it is ok to run the code. However, we probably don't want to allow such a scenario, so I figure it's probably best to use the relocatable target.

@dsouzai
Copy link
Contributor Author

dsouzai commented Nov 7, 2022

@mpirvu could you please review.

Instead of waiting until createAOTHeader to initialize the
relocatableTarget if running in portable SCC mode, check the the
portable SCC flag when the CompilerEnv object is initialized.

Additionally, use the relocatableTarget in RelocationRuntime for all the
various checks.

Signed-off-by: Irwin D'Souza <dsouzai.gh@gmail.com>
Copy link
Contributor

@mpirvu mpirvu left a comment

Choose a reason for hiding this comment

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

LGTM

@mpirvu
Copy link
Contributor

mpirvu commented Nov 8, 2022

jenkins test sanity plinux,xlinux,zlinux jdk17

Hardware TM is not guaranteed to be available on all machines,
therefore, the compiler should not use said feature when generating
portable code.

Signed-off-by: Irwin D'Souza <dsouzai.gh@gmail.com>
@dsouzai
Copy link
Contributor Author

dsouzai commented Nov 8, 2022

jenkins test sanity plinux,xlinux,zlinux jdk17

@dsouzai
Copy link
Contributor Author

dsouzai commented Nov 9, 2022

@mpirvu should be good to merge

@mpirvu mpirvu merged commit fafe184 into eclipse-openj9:master Nov 9, 2022
@dsouzai dsouzai deleted the fixPortableAOTTM branch April 3, 2024 13:53
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

ppc64le_linux aot_test: AOT header validation failed TM feature mismatch
2 participants