Skip HCR guards for inlining intrinsifiable methods

[nbhuiyan]

For callees annotated with @IntrinsicCandidate, we shoud ignore any later redefinition as these methods are meant to have special handling for performance reasons. This annotation is only used in JCL code.

[nbhuiyan]

@vijaysun-omr, @hzongaro I'd appreciate a review from either one of you.

@IntrinsicCandidate methods are currently treated as always worth inlining if no special handling for them is implemented.

In #18794, we had some methods annotated with @IntrinsicCandidate get special handling where they are replaced with simple loads (and no HCR guards), making later redefinition of such methods impossible. I am not sure whether it is possible to redefine intrinsifiable methods in Reference Implementation, so I will test that out.

[hzongaro]

I've found an issue that was reported against OpenJDK in 2013 — https://bugs.openjdk.org/browse/JDK-8013579 — that seems to discuss the question of whether a JVM must take into account the possibility that an @IntrinsicCandidate method might be redefined. The issue is still unresolved, so I think that means it would be safe for the OpenJ9 compiler to skip HCR guards for any "intrinsifiable" method, barring some future decision to the contrary.

[hzongaro]

I think this change looks good. Thanks!

[vijaysun-omr]

Thanks @hzongaro for your thoroughness in looking that up, much appreciated

[hzongaro]

Jenkins test sanity,sanity.openjdk zlinux,alinux64,aix,win,win32 jdk8,jdk11,jdk17,jdk21

[vijaysun-omr]

I approved but will let Henry merge it after testing etc.

[nbhuiyan]

5X Grinder of the failed test target jdk_security4_1 seen in the jdk11 aarch64 test job reproduces 1/5 times. Not sure if this failure is related to this change.

[hzongaro]

5X Grinder of the failed test target jdk_security4_1 seen in the jdk11 aarch64 test job reproduces 1/5 times. Not sure if this failure is related to this change.

I don't think it's related. I saw 2/5 failures in a Grinder run using a nightly build without your change.

[hzongaro]

• zLinux JDK 21 sanity.openjdk test failure is due to issue OpenJDK java/lang/Thread/virtual/stress/GetStackTraceALotWhenPinned timeout #18908
• Windows x86-64 JDK 21 sanity.openjdk test failures and Power AIX failureshttps://openj9-jenkins.osuosl.org/job/Test_openjdk21_j9_sanity.openjdk_ppc64_aix_Personal/23/ look like they were due to a mismatch between the version of openj9-openjdk-jdk21 used to build the JDK and the version of the tests used for sanity.openjdk - it looks like the latter included commit 00fbde4449 but the former did not:

19:46:53  C:\Users\jenkins\workspace\Test_openjdk21_j9_sanity.openjdk_x86-64_windows_Personal_testList_2\aqa-tests\openjdk\openjdk-jdk\test\jdk\jdk\internal\util\ReferencedKeyTest.java:66: error: cannot find symbol
19:46:53      static void mapTest(boolean isSoft, Supplier<Map<ReferenceKey<Long>, String>> supplier) {
19:46:53                                                       ^
19:46:53    symbol:   class ReferenceKey
19:46:53    location: class ReferencedKeyTest

All test failures are unrelated to this change. Merging.