Accelerate Unsafe CAS Intrinsics on Power and X #19991

IBMJimmyk · 2024-08-12T19:18:38Z

Adds support for the following recognized methods:

CompareAndExchangeObject     //JDK11
CompareAndExchangeReference  //JDK17,21
CompareAndExchangeInt        //JDK11,17,21
CompareAndExchangeLong       //JDK11,17,21

Similar to their CompareAndSet counterparts, the JIT acceleration does not support CAE on static fields so the createUnsafeCASCallDiamond function was updated to also work on the CAE methods.

The accelerated CAE code was built on top of the existing accelerated CAS support on both Power and X.

Edit:
X changes are dependent on this OMR PR:
eclipse-omr/omr#7438
Behavior of inlineCompareAndSwapNative and inlineCompareAndSwapObjectNative in J9TreeEvaluator.cpp must match behavior in willBeEvaluatedAsCallByCodeGen in OMRCodeGenerator.cpp

IBMJimmyk · 2024-08-12T20:08:54Z

@hzongaro Is there someone who can help take a look at the X and Common changes? In particular that I am updating alwaysWorthInlining and createUnsafeCASCallDiamond correctly for common changes. For X, everything could use a close look since I don't work on X codegen often. in particular here, a double check that I have the logic right for reference counts on nodes since that caused a few problems.

@zl-wang Could you take a look at the Power codegen changes to make sure there are no problems?

zl-wang · 2024-08-15T19:21:10Z

are we supposed to go around the "public" (not sure about this) Unsafe interface/class and support the internal Unsafe APIs? i.e., do typical developers import jdk.internal.misc.Unsafe? In addition to recognize the former class' APIs, we need to recognize the internal newer ones as well? @tajila @vijaysun-omr what is your take?

vijaysun-omr · 2024-08-15T19:27:45Z

Are you suggesting that there are "public" equivalents of the apis being discussed in this PR (that we already accelerate or plan to accelerate) ? If not, then internal (non-public) or not, it could have a bearing on performance, right ?

zl-wang · 2024-08-15T19:43:11Z

there are two Unsafe classes in JDK ... for example jdk21:
src/jdk.unsupported/share/classes/sun/misc/Unsafe.java
src/java.base/share/classes/jdk/internal/misc/Unsafe.java

APIs in the former class basically use the latter's for implementation. Something like below:

    public final boolean compareAndSwapObject(Object o, long offset,
                                              Object expected,
                                              Object x) {
        return theInternalUnsafe.compareAndSetReference(o, offset, expected, x);
    }

if programmers are expected (if they ever do) to use the former only, it might not be necessary to go behind it and deal with the new names.

IBMJimmyk · 2024-08-15T19:53:06Z

Only these ones exist in sun/misc/Unsafe:

compareAndSwapObject
compareAndSwapInt
compareAndSwapLong

These ones require going through jdk/internal/misc/Unsafe.java:

CompareAndExchangeObject
CompareAndExchangeReference
CompareAndExchangeInt
CompareAndExchangeLong

tajila · 2024-08-15T20:43:53Z

we need to recognize the internal newer ones as well? @tajila @vijaysun-omr what is your take?

Most new applications and the JDK itself have switched to using jdk.internal.misc.Unsafe. sun.misc.Unsafe is still available but will likely go at some point.

One thing to remember is that in JDK8 there is only sun.misc.Unsafe.

zl-wang · 2024-08-15T22:52:43Z

Most new applications and the JDK itself have switched to using jdk.internal.misc.Unsafe.

Thanks for the clarification.

zl-wang · 2024-08-19T19:13:13Z

runtime/compiler/p/codegen/J9TreeEvaluator.cpp

+         {
+         case 4:
+            oldValue = oldVNode->getInt();
+            if (oldValue >= LOWER_IMMED && oldValue <= UPPER_IMMED)


this "if" block is expected to be common to all cases (even for future byte/short CAS support). why not move/common it to after-if?

I can move it outside the switch block.

zl-wang · 2024-08-19T19:50:59Z

runtime/compiler/p/codegen/J9TreeEvaluator.cpp

+
+      case TR::jdk_internal_misc_Unsafe_compareAndExchangeInt:
+         // As above, we only want to inline the JNI methods, so add an explicit test for isNative()
+         if (!methodSymbol->isNative())


is this check only worth of debugging value? i.e. we explicitly don't want to inline/intercept the CAS call for debugging reason (?).

The original problem traces back to this commit: 111f0b0

Going from Java 8 to 11, compareAndSwap[Object|Int|Long] were changed to being wrappers to call Native versions with the same name. So there is both a java and native that matches the same recognized method.

Going from 11 to 17, compareAndSetObject and compareAndExchangeObject were changed from native to Java wrapper that calls the new names compareAndSetReference and compareAndExchangeReference that do the same thing.

That commit I linked to deals with compareAndSwap[Object|Int|Long] and compareAndSetObject. Acceleration for compareAndExchangeObject didn't exist so that case didn't need to be handled.

Based on the comment in the commit, the change explicitly went in to deal with incorrect behavior. But, it doesn't say what it is and I'm not exactly sure what the problem is either.

I copied the same check for the acceleration of compareAndExchange[Reference|Int|Long]. But, those are always native in every JDK level they exist in. So I can remove the check for those cases.

compareAndSet[Reference|Int|Long] is also always native but uses the same recognized methods as compareAndSwap[Object|Int|Long] so I can't remove the check for that case without updating Z and arm code which is currently future work.

I talked to @JamesKingdon and he pointed me towards this issue from around 7 years ago: #321

From the issue the test would hang. The exact reasoning is not listed but somehow it was determined that preventing the non-native wrapped calls of the CAS methods from being turned into accelerated assembly made the problem stop. As a conservative fix, the optimization was limited to just the native methods and to leave it to the inliner to inline the wrapper methods.

The linked issue was create due to an external test that I do not have access to. The issue also includes a simple program which could reproduce the issue but it no longer runs. The is mention in the issue of a dependency on a server that I assume is no longer running. So it does not seem to be possible to reproduce the problem.

I suspect that the original fix was only hiding an issue because it doesn't make much sense that it would have actually fixed the problem. Putting down accelerated assembly should have worked when replacing non-native Unsafe CAS call wrappers. As it would turn out, while creating this PR I encountered an issue with reference counting inside the X fast path generation for Unsafe CAS. While a different path is taken today, 7 years ago compareAndSwapObject, which appeared to cause the problem, went through inlineCompareAndSwapNative and that's where I found the problem with reference counting. It is also possible the problem was something else fixed in the last 7 years. Without being able to run the test, I can't confirm that.

zl-wang · 2024-08-19T19:53:07Z

runtime/compiler/p/codegen/J9TreeEvaluator.cpp

+
+        if ((node->isUnsafeGetPutCASCallOnNonArray() || !TR::Compiler->om.canGenerateArraylets()) && node->isSafeForCGToFastPathUnsafeCall())
+            {
+            static bool disableCAEIntrinsic = feGetEnv("TR_DisableCAEIntrinsic") != NULL;


why not common and move this feGetEnv outside switch statement?

I can do that.

zl-wang · 2024-08-19T19:57:29Z

runtime/compiler/p/codegen/J9TreeEvaluator.cpp

+            resultReg = VMinlineCompareAndSetOrExchange(node, cg, 8, true);
+            return true;
+            }
+         else if ((node->isUnsafeGetPutCASCallOnNonArray() || !TR::Compiler->om.canGenerateArraylets()) && node->isSafeForCGToFastPathUnsafeCall())


i saw great performance value in doing fast-path CAS long in 32bit mode, given the fact that we started to only support 64bit hardware a few years ago.

compareAndExchangeLong was first added in JDK11. I believe OpenJ9 does not support 32bit JDK11 (and later) builds? If not, the 32bit acceleration path for compareAndExchangeLong will never be used even if added in.

hzongaro

Still reviewing, but I thought I’d give some initial feedback.

runtime/compiler/env/j9method.cpp

IBMJimmyk · 2024-08-25T20:36:46Z

I added a few more fixes mostly related to problems on x that showed up after more rigorous testing.

I missed adding jdk_internal_misc_Unsafe_compareAndExchangeObject to one location on x which stopped the method from being converted into inlined assembly so I added that in.

Setting TR_UseOldCompareAndSwapObject would cause compareAndExchange[Object|Reference] to break on x since the older path was not updated to work with these methods. I updated them now.

Setting TR_UseOldCompareAndSwapObject and TR_DisableCASInlining would cause problems, also on x, even without my changes. This is related to hiding object compression from the codegen. I added a fix here so the compression is not hidden if TR_DisableCASInlining is set.

I found another location I missed adding disableCAEIntrinsic to so I added that in.

I got one of the native checks backwards inside alwaysWorthInlining. This check was for natives that already failed the inlinable JNI check so they aren't supposed to return true from alwaysWorthInlining.

IBMJimmyk · 2024-08-27T18:43:41Z

I discovered a problem on x where the accelerated version of CompareAndExchangeObject would making an unexpectedly high number of call outs to jitWriteBarrierStoreGenerationalAndConcurrentMark which hurt performance by around 60% compared to CompareAndSetObject. The two cases were expected to have similar performance.

I eventually tracked down the problem to this line:

openj9/runtime/compiler/x/codegen/J9TreeEvaluator.cpp

Line 10529 in 91b5703

(node->getOpCodeValue()==TR::icall)) {

compareAndSetObject is an icall while compareAndExchangeObject is an acall. This means unsafeCallBarrier is true for compareAndSetObject and false for compareAndExchangeObject. This lead to different code being generated and different performance.

VMwrtbarWithoutStoreEvaluator is used for several different opcodes which include arraycopy, ArrayStoreCHK, write barriers and Unsafe CAS calls (that CAS an object).

To differentiate Unsafe CAS calls from the other cases, there is a check for the node being an icall since the other cases are not icalls. This check is no longer valid with the introduction of support for compareAndExchangeReference. The node in the CAE case is an acall.

The commit I just added changes the check to a generic call check. There is also a check for the call being to a recognized method. This check now checks for specific recognized methods which are:

sun_misc_Unsafe_compareAndSwapObject_jlObjectJjlObjectjlObject_Z //covers compareAndSwapObject, compareAndSetObject, compareAndSetReference
jdk_internal_misc_Unsafe_compareAndExchangeObject
jdk_internal_misc_Unsafe_compareAndExchangeReference

With this new change, the performance has returned to the expected area.

IBMJimmyk · 2024-08-28T18:41:02Z

With the latest change, all the tests that I wrote to try out different edges cases are working as expected. @hzongaro, I know it has only been a few days since my last x related change but have you had a chance to continue your code review?

runtime/compiler/p/codegen/J9TreeEvaluator.cpp

zl-wang

LGTM now

hzongaro · 2024-09-10T19:23:52Z

have you had a chance to continue your code review?

I hadn't had a chance to come back to it. I'll take another look at it now.

hzongaro

I think the changes look good. I have a few stylistic comments, but I will approve your changes and leave it up to you whether you accept none, any or all of the suggestions.

runtime/compiler/optimizer/InlinerTempForJ9.cpp

runtime/compiler/x/codegen/J9TreeEvaluator.cpp

runtime/compiler/p/codegen/J9TreeEvaluator.cpp

IBMJimmyk · 2024-09-12T22:24:45Z

I have some more tests that look like they are failing now. So I'll need to figure out the problem before this can be merged.

IBMJimmyk · 2024-09-13T01:48:03Z

I found the problem.

https://github.com/eclipse/omr/blob/8c233cdf9151d5b097733a426537d4fd6c37051f/compiler/optimizer/VPHandlers.cpp#L5410

isUnsafeCAS() does not pass in a parameter.

https://github.com/eclipse/omr/blob/8c233cdf9151d5b097733a426537d4fd6c37051f/compiler/compile/OMRMethod.hpp#L153

So NULL is passed in as the TR::Compilation *.

https://github.com/IBMJimmyk/openj9/blob/8f7d8c2ce7914c5ae4a80413002fa8221077f7cb/runtime/compiler/env/j9method.cpp#L5545-L5548

This is the temporary platform check that is here until support is added for every platform. It assumed TR::Compilation * c is not NULL which is incorrect.

I will double check these platform checks do not cause any other problems.

IBMJimmyk · 2024-09-17T13:27:41Z

I retested after I added the fix to isUnsafeCAS so it doesn't use a NULL comp object and the tests pass now.

@hzongaro Can you look over the latest changes? If they are good I think this is finally ready to be merged in.

hzongaro

Looks good. I just have one suggestion for a potential clean up item for a follow on pull request.

hzongaro · 2024-09-23T17:46:53Z

runtime/compiler/env/j9method.cpp

+   if (nullptr == c)
+      {
+      c = TR::comp();
+      }


It just seems bizarre to me that isUnsafeCAS had a default value of NULL for c, and it never even used the argument. Looking at the histories of isUnsafeCAS and isUnsafeWithObjectArg, it looks like they've always been that way.

I don't want to delay this change any further, so may I suggest that you open follow up pull requests for OpenJ9 and OMR to change the prototype declarations for isUnsafeCAS and isUnsafeWithObjectArg to either remove the TR::Compilation parameter or to make the parameter no longer optional?

Yes. I can do that as well.

hzongaro · 2024-09-23T18:14:11Z

May I ask you to remove "WIP:" from the titles of this pull request and eclipse-omr/omr#7438?

hzongaro · 2024-09-23T18:20:16Z

Sorry for the late comment. May I ask you to reformat your commit comment so that lines do not exceed 72 characters in length, per https://github.com/eclipse-openj9/openj9/blob/master/CONTRIBUTING.md#commit-guidelines?

There is also a typo in the commit comment: "differtiate" -> "differentiate"

hzongaro · 2024-09-23T18:22:40Z

Jenkins test sanity,sanity.openjdk all jdk8,jdk11,jdk17,jdk21

hzongaro · 2024-09-23T18:38:55Z

Sorry - the testing I initiated will fail because I forgot to include the depends eclipse/omr#7438 clause.

Adds support for the following recognized methods: CompareAndExchangeObject //JDK11 CompareAndExchangeReference //JDK17,21 CompareAndExchangeInt //JDK11,17,21 CompareAndExchangeLong //JDK11,17,21 Similar to their CompareAndSet counterparts, the JIT acceleration does not support CAE on static fields so the createUnsafeCASCallDiamond function was updated to also work on the CAE methods. The accelerated CAE code was built on top of the existing accelerated CAS support on both Power and X. Removed recognized CAS enums from isUnsafePut. They are not Unsafe put methods and these cases could not be triggered. Even before my changes, setting TR_UseOldCompareAndSwapObject and TR_DisableCASInlining would cause a crash on x. It doesn't really make sense to set both at the same time but I fixed it anyways since it was quick. VMwrtbarWithoutStoreEvaluator is used for several different opcdes include arraycopy, ArrayStoreCHK, writeBarrier and Unsafe CAS calls. This is only used for the Unsafe CAS calls that store an object. To differtiate Unsafe CAS calls from the other cases, there is a check for the node being an icall. This check is no longer valid with the introduction of support for compareAndExchangeReference. The node in this case is an acall. This changes the check to a generic call check. There is also a check for the call being to a recognized method. This check now checks for specific recognized methods which are: sun_misc_Unsafe_compareAndSwapObject_jlObjectJjlObjectjlObject_Z jdk_internal_misc_Unsafe_compareAndExchangeObject jdk_internal_misc_Unsafe_compareAndExchangeReference Signed-off-by: jimmyk <[email protected]>

IBMJimmyk · 2024-09-23T19:03:24Z

I fixed the commit message.

hzongaro · 2024-09-23T19:15:48Z

Jenkins test sanity,sanity.openjdk all jdk8,jdk11,jdk17,jdk21 depends eclipse-omr/omr#7438

IBMJimmyk · 2024-09-23T21:55:56Z

The Windows failure looks to be this:

[WS-CLEANUP] Deleting project workspace...
16:39:01  [WS-CLEANUP] Deferred wipeout is disabled by the job configuration...
16:39:19  ERROR: Cannot delete workspace :Unable to delete 'F:\Users\jenkins\workspace\Build_JDK21_x86-64_windows_Personal\openssl\NUL'. Tried 3 times (of a maximum of 3) waiting 0.1 sec between attempts.

I don't think that is related to my change.

hzongaro · 2024-09-24T13:56:00Z

JDK 21 Windows build failure appears to be infrastructure-related
JDK 11 x86-64 macOS sanity.functional failure appears to be infrastructure-related
JDK 17 AIX sanity.openjdk failure appears to be infrastructure-related
JDK 21 x86-64 macOS sanity.functional failure appears to be infrastructure-related
JDK 21 s390x Linux sanity.openjdk test failure appears to be due to known issue OpenJDK java/lang/StrictMath/ExhaustingTests OutOfMemoryError: Java heap space #18034
JDK 21 x86-64 macOS sanity.openjdk test failure appears to be due to known issue OpenJDK java/lang/Thread/virtual/stress/GetStackTraceALotWhenPinned Invalid JIT return address ASSERTION FAILED swalk.c:1629: ((0 )) #18910
JDK 8 x86-32 Windows sanity.functional test failure for SCURLClassLoaderTests_SE80_0 and SCURLClassLoaderNPTests_SE80_0. I didn't find a known problem for this failure.
JDK 8 x86-64 Linux sanity.functional test failures appears to be due to known issue testJitserverArguments, Test SSL success condition - failed to configure SSL ecdh #18599
JDK 8 x86-64 Windows sanity.functional test failure. This also saw a failure for SCURLClassLoaderTests_SE80_1, as well as for J9vmTest_5, testSCCMLTests1_openj9_0, cmdLineTester_ShareClassesSimpleSanity_0. I wasn't able to find known problems for these failures in a quick search.

I will rerun testing for the infrastructure-related failures. @IBMJimmyk, may I ask you to take a closer look at the JDK 8 sanity.functional failures for Windows to verify that they are unrelated to your changes?

hzongaro · 2024-09-24T13:57:24Z

Jenkins test sanity,sanity.openjdk windows jdk21 depends eclipse-omr/omr#7438

IBMJimmyk · 2024-09-24T14:27:26Z

I'll take a look at the sanity.functional failures for Windows.

hzongaro · 2024-09-24T14:44:10Z

Jenkins test sanity,sanity.openjdk win jdk21 depends eclipse-omr/omr#7438

hzongaro · 2024-09-24T14:46:14Z

Jenkins test sanity.functional xmac jdk11,jdk21 depends eclipse-omr/omr#7438

hzongaro · 2024-09-24T14:46:43Z

Jenkins test sanity.openjdk aix jdk17 depends eclipse-omr/omr#7438

hzongaro · 2024-09-24T18:42:38Z

Jenkins test sanity.openjdk aix jdk17 depends eclipse-omr/omr#7438

IBMJimmyk · 2024-10-02T20:59:03Z

All of the JDK8 Windows failures fall into the same pattern. The test workload itself is successful and prints the expected result for the test and shortly afterwards there is a segmentation fault in j9shr29.dll.

Here is an example from SCURLClassLoaderTests_SE80_0

[2024-09-24T02:17:44.442Z] Testing: FindStore.FindExplicit
[2024-09-24T02:17:44.442Z] Test start time: 2024/09/23 22:17:43 Eastern Standard Time
[2024-09-24T02:17:44.442Z] Running command: C:/Users/jenkins/workspace/Test_openjdk8_j9_sanity.functional_x86-32_windows_Personal_testList_0/jdkbinary/j2sdk-image\jre\bin\java.exe  -Xjit -Xgcpolicy:gencon -Xnocompressedrefs    -Xshareclasses:persistent,controlDir=.,name=FindStore,noTimestampChecks -cp .\FindStore\Nothing.jar;.\FindStore\A.jar;.\FindStore\B.jar;.\FindStore\C.jar;.\FindStore\D.jar jnurlcldr.shared.findstore.A_Main
[2024-09-24T02:17:44.442Z] Time spent starting: 0 milliseconds
[2024-09-24T02:17:44.442Z] Time spent executing: 328 milliseconds
[2024-09-24T02:17:44.442Z] Test result: FAILED
[2024-09-24T02:17:44.442Z]  [OUT] CACHED A
[2024-09-24T02:17:44.442Z]  [OUT] CACHED B
[2024-09-24T02:17:44.442Z]  [OUT] CACHED C
[2024-09-24T02:17:44.442Z]  [OUT] CACHED D
[2024-09-24T02:17:44.442Z]  [OUT] Result=3
[2024-09-24T02:17:44.442Z]  [ERR] Unhandled exception
[2024-09-24T02:17:44.442Z]  [ERR] Type=Segmentation error vmState=0x00000000
[2024-09-24T02:17:44.442Z]  [ERR] J9Generic_Signal_Number=00000004 ExceptionCode=c0000005 ExceptionAddress=706141DA ContextFlags=0001007f
[2024-09-24T02:17:44.442Z]  [ERR] Handler1=71625EA0 Handler2=715454D0 InaccessibleWriteAddress=22A56118
[2024-09-24T02:17:44.442Z]  [ERR] EDI=013C2FC8 ESI=227E56D8 EAX=22A55FE8 EBX=2298F2B8
[2024-09-24T02:17:44.442Z]  [ERR] ECX=FFFFFFFF EDX=010D2000
[2024-09-24T02:17:44.442Z]  [ERR] EIP=706141DA ESP=01B4F41C EBP=22FE5538 EFLAGS=00210246
[2024-09-24T02:17:44.442Z]  [ERR] GS=002B FS=0053 ES=002B DS=002B
[2024-09-24T02:17:44.442Z]  [ERR] Module=C:\Users\jenkins\workspace\Test_openjdk8_j9_sanity.functional_x86-32_windows_Personal_testList_0\jdkbinary\j2sdk-image\jre\bin\default\j9shr29.dll
[2024-09-24T02:17:44.442Z]  [ERR] Module_base_address=70610000 Offset_in_DLL=000041da
[2024-09-24T02:17:44.442Z]  [ERR] Target=2_90_20240923_809 (Windows Server 2019 10.0 build 17763)
[2024-09-24T02:17:44.442Z]  [ERR] CPU=x86 (4 logical CPUs) (0x3fff77000 RAM)
[2024-09-24T02:17:44.442Z]  [ERR] ----------- Stack Backtrace -----------
[2024-09-24T02:17:44.442Z]  [ERR] J9VMDllMain+0x31da (0x706141DA [j9shr29+0x41da])
[2024-09-24T02:17:44.442Z]  [ERR] J9VMDllMain+0x9aa (0x706119AA [j9shr29+0x19aa])
[2024-09-24T02:17:44.442Z]  [ERR] ---------------------------------------
[2024-09-24T02:17:44.442Z]  [ERR] JVMDUMP039I Processing dump event "gpf", detail "" at 2024/09/23 22:17:43 - please wait.
[2024-09-24T02:17:44.442Z]  [ERR] JVMDUMP013I Processed dump event "gpf", detail "".
[2024-09-24T02:17:44.442Z] >> Success condition was found: [Output match: Result=3]
[2024-09-24T02:17:44.442Z] >> Failure condition was not found: [Output match: LOCAL]
[2024-09-24T02:17:44.442Z] >> Failure condition was found: [Output match: Unhandled Exception]
[2024-09-24T02:17:44.442Z] >> Failure condition was not found: [Output match: Exception:]
[2024-09-24T02:17:44.442Z] >> Failure condition was not found: [Output match: Error:]

The test successfully prints out Result=3 which is the expected result of a successful test. Shortly afterwards, there is a segfault in j9shr29.dll.

I have tried to reproduce the problem but have not been successful. When the tests were run as a part of this PR, this error occurred about 12 times total. I tried rerunning the tests 5 times each with a build with and without my changes and they all passed.

I stumbled upon this similar looking problem:
#20227

In that issue, there is also a test with a successful result followed by a crash in j9shr29.dll. But, the backtrace isn't quite the same. The problem in that issue was fixed and the change merged in after this build was kicked off. So the testing of my changes does not include the fix.

I think by builds go up to here in OpenJ9:
https://github.com/eclipse-openj9/openj9/commits/16ab797349b9bda5a5de2a9ff27ef2d932a4716a/ (Sept 23)
So it didn't include: https://github.com/eclipse-openj9/openj9/pull/20196/commits (merged sept 24)

IBMJimmyk · 2024-10-03T18:50:50Z

I was able to reproduce the JDK8 Windows failures on a build that excluded both my Unsafe CAS work and the j9shr29.dll crash fix. So I can say those failures are unrelated to my change and also already fixed in newer builds.

@hzongaro Are there any other concerns that need to be addressed?

hzongaro · 2024-10-04T18:00:42Z

Failures are due to known issues. Performing a coordinated merge with eclipse-omr/omr#7438

IBMJimmyk requested a review from dsouzai as a code owner August 12, 2024 19:18

IBMJimmyk mentioned this pull request Aug 12, 2024

Accelerate Unsafe CAS Intrinsics on Power and X eclipse-omr/omr#7438

Merged

zl-wang requested changes Aug 19, 2024

View reviewed changes

hzongaro reviewed Aug 21, 2024

View reviewed changes

runtime/compiler/env/j9method.cpp Outdated Show resolved Hide resolved

runtime/compiler/env/j9method.cpp Outdated Show resolved Hide resolved

runtime/compiler/env/j9method.cpp Show resolved Hide resolved

zl-wang requested changes Sep 4, 2024

View reviewed changes

runtime/compiler/p/codegen/J9TreeEvaluator.cpp Show resolved Hide resolved

zl-wang approved these changes Sep 4, 2024

View reviewed changes

hzongaro approved these changes Sep 11, 2024

View reviewed changes

IBMJimmyk force-pushed the UnsafeCAS branch from 1c9ba0d to 6f77021 Compare September 11, 2024 19:37

IBMJimmyk force-pushed the UnsafeCAS branch from 6f77021 to 39d626b Compare September 15, 2024 21:35

hzongaro approved these changes Sep 23, 2024

View reviewed changes

IBMJimmyk changed the title ~~WIP: Accelerate Unsafe CAS Intrinsics on Power and X~~ Accelerate Unsafe CAS Intrinsics on Power and X Sep 23, 2024

IBMJimmyk force-pushed the UnsafeCAS branch from 39d626b to fda8a6f Compare September 23, 2024 19:02

hzongaro self-assigned this Sep 23, 2024

hzongaro added comp:jit arch:power arch:x86 labels Sep 23, 2024

hzongaro merged commit bfc3936 into eclipse-openj9:master Oct 4, 2024
81 of 87 checks passed

Accelerate Unsafe CAS Intrinsics on Power and X #19991

Accelerate Unsafe CAS Intrinsics on Power and X #19991

Conversation

IBMJimmyk commented Aug 12, 2024 • edited Loading

IBMJimmyk commented Aug 12, 2024

zl-wang commented Aug 15, 2024

vijaysun-omr commented Aug 15, 2024

zl-wang commented Aug 15, 2024

IBMJimmyk commented Aug 15, 2024

tajila commented Aug 15, 2024

zl-wang commented Aug 15, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

hzongaro left a comment

Choose a reason for hiding this comment

IBMJimmyk commented Aug 25, 2024

IBMJimmyk commented Aug 27, 2024

IBMJimmyk commented Aug 28, 2024

zl-wang left a comment

Choose a reason for hiding this comment

hzongaro commented Sep 10, 2024

hzongaro left a comment

Choose a reason for hiding this comment

IBMJimmyk commented Sep 12, 2024

IBMJimmyk commented Sep 13, 2024

IBMJimmyk commented Sep 17, 2024

hzongaro left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

hzongaro commented Sep 23, 2024

hzongaro commented Sep 23, 2024

hzongaro commented Sep 23, 2024

hzongaro commented Sep 23, 2024

IBMJimmyk commented Sep 23, 2024

hzongaro commented Sep 23, 2024

IBMJimmyk commented Sep 23, 2024

hzongaro commented Sep 24, 2024

hzongaro commented Sep 24, 2024

IBMJimmyk commented Sep 24, 2024

hzongaro commented Sep 24, 2024

hzongaro commented Sep 24, 2024

hzongaro commented Sep 24, 2024

hzongaro commented Sep 24, 2024

IBMJimmyk commented Oct 2, 2024

IBMJimmyk commented Oct 3, 2024

hzongaro commented Oct 4, 2024

IBMJimmyk commented Aug 12, 2024 •

edited

Loading