Enable CHTable Opts when Xnojit is set to allow AOT

[KavinSatheeskumar]

Fixes issue:
#17918

Previously, there was an issue that when -Xnojit was set, AOT loads were disabled. This is because -Xnotjit disabled CHTable Ops, which were needed for AOT header validation.

This PR enforces that if -Xnojit is specified, then AOT compilations are prohibited but CHTable optimizations are still enabled. Otherwise if recompilations are disabled for any other reason, we also disable CHTable ops.

This PR borrows a lot from #18543

[mpirvu]

If JIT is enabled, typically recompilation and CHTable opts are enabled.
If recompilation is disabled through options, we need to disable CHTable opts as well (this is today's behavior)

If -Xnojit is present (JIT disabled) then AOT compilations are not possible (to double check). AOT loads are permitted though.
As far as I know, the whole purpose of -Xnojit was to completely eliminate the overhead of the JIT compiler, but still benefit from fast AOT loads.
The SCC can be populated only with JIT enabled. This means that (typically) AOT bodies have both recompilation and CHTableOpts enabled. Today, -Xnojit disables both recompilation and CHTableOpts. The later is what causes the AOT header compatibility check failure.
I feel it's totally normal to disable recompilation for -Xnojit. Without a JIT compiler, no compilations are possible and therefore no recompilations are possible; why not make it official by using "disableRecompilation".
What we can do in this -Xnojit scenario is to allow CHTableOpts, even though we should not. If a body gets invalidated and it needs recompilation, it's going to fail the compilation and the method continues interpreted. This situation can be avoided if the user populates the SCC with a run that uses disableCHOpts.

[mpirvu]

To be clearer the behavior that we want is:

• If -Xnoaot mode ==> disable recompilation, but leave the CHTableOpts enabled (unless they were specifically disabled by the user)
• For all other cases, if the user has disabled recompilation, we also want to disable CHTable opts as well.

[mpirvu]

LGTM

[mpirvu]

Please update the commit message and the description of the PR to match the implementation.

[mpirvu]

jenkins test sanity all jdk25

[mpirvu]

openjdk on x86-64 mac failed jdk_vector_double128_j9_0_FAILED

16:09:18  java.lang.Exception: config failures: 0, test failures: 9
16:09:18  	at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:111)
16:09:18  	at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:63)
16:09:18  	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
16:09:18  	at java.base/java.lang.reflect.Method.invoke(Method.java:571)
16:09:18  	at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138)
16:09:18  	at java.base/java.lang.Thread.run(Thread.java:1485)

I don't see how this PR can cause these failures. AOT is never used in these VectorAPI tests because of:
AOT header validation failed: AsyncCompilation feature mismatch.

[mpirvu]

On Windows there is a failure on jdk_security4_0

TEST RESULT: Failed. Execution failed: `main' threw exception: java.lang.Exception: Timestamp is Mon Dec 15 23:50:50 EST 2025, actual difference 3554 is not 3600

Again, I don't see how this PR can cause this failure.

[KavinSatheeskumar]

On Windows there is a failure on jdk_security4_0

TEST RESULT: Failed. Execution failed: `main' threw exception: java.lang.Exception: Timestamp is Mon Dec 15 23:50:50 EST 2025, actual difference 3554 is not 3600

Again, I don't see how this PR can cause this failure.

For the record this is a known issue
#17749