JDK-8193241 : [Graal] implement missing intrinsics
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 10,11
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2017-12-08
  • Updated: 2018-06-28
  • Resolved: 2018-06-28
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 11
11Fixed
Related Reports
Blocks :  
JDK-8200196 - [Graal] implement Object.notify/notifyAll intrinsics
Blocks :  
JDK-8202616 - [Graal] implement missing Unsafe intrinsics
Blocks :  
JDK-8202209 - [Graal] implement Double.doubleToLongBits and Float.floatToIntBits intrinsics
Relates :  
JDK-8198251 - [Graal] compiler/intrinsics/bmi/verifycode tests fail with Graal on macos
Relates :  
JDK-8202533 - [Graal] Implement StringUTF16.compress & StringLatin1.inflate
Description
Graal is not yet implementing all the intrinsics C2 does. The state of Graal's intrinsic coverage is documented in CheckGraalIntrinsics[1].

[1] https://github.com/oracle/graal/blob/472f853b33d26bcf83b7a02aea3f2f9eafd6c7c1/compiler/src/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/CheckGraalIntrinsics.java#L58-L63
Comments
Targeted intrinsics, except for StringUTF16.compress & StringLatin1.inflate (see JDK-8202533) have been integrated. These are now targeted for JDK12.
28-06-2018
Remaining intrinsics targeted but not included in JDK11 found in JDK-8202533.
28-06-2018
The LDADD instruction has been added to AArch64. The getAndAdd*() intrinsic implementations for AAch64 are up for review. Those leverage LDADD if the hardware supports it, and uses regular load acquire exclusive and store release exclusive if not available. The implementation of the SWP instruction & AtomicReadAndWriteOp for AArch64 are also up for review.
17-05-2018
I'm also looking the intrinsics related support on AArch64 and after some investigation, I'd like to add the optimized version of Round intrinsics (such as ceil, floor, rint) to AArch64 platform.
15-05-2018
I've implemented the CAS instruction for AArch64, so that should be used by those intrinsics that call to CompareAndSwapOp for AArch64 (assuming the architecture has support for it.) I will focus on adding LDADD instruction support and getAndAdd* intrinsics for AArch64 platform, as those are not defined for this platform but are for Intel.
23-04-2018
In order to implement intrinsics for AArch64 (e.g., CAS support), there is work to be done on the OpenJDK side to pass the AArch64 CPU Features and Flags through JVMCI. I am currently working on implementing this for AArch64, in order to properly ascertain whether the current CPU is even capable of atomics.
28-03-2018
[~adinn] and [~aph] may be able to comment on the state of JVMCI AArch64 in jdk/hs in terms of any features missing for the intrinsics you are trying to implement.
22-03-2018
I'll try to trace the propagation through to make sure the AArch64 flags are getting through.
22-03-2018
I'm not sure about the AArch64 support when running Graal on HotSpot. I do know ISA/CPU features are exported via JVMCI for X86 and SPARC when running on HotSpot. Having a quick look in the HotSpot code it seems to be the case that there is no support implemented in order to propagate (via JVMCI) the HWCAPs detected on AArch64. I don't think that it should be too much work to add the support needed. @dnsimon Doug will have to fill in on the subject for any other VM than HotSpot (or possible AArch64 changes in the pipe).
22-03-2018
I looked through your implementation of incrementExact & decrementExact, and they were done exactly the way I had done them locally. So I felt good about my understanding of that part of the code. It appears most of the other intrinsics (getAnd[Set|Add] & CompareAndSwap) rely on atomic access. So I was thinking of starting by implementing some of the low-level AArch64 instructions (CAS, LDADD) which are required for the intrinsics to use. I didn't see those implemented anywhere in Graal. I don't know how Graal determines at runtime which features it is allowed to use, but I see the references to the AArch64.CPUFeature class in the AArch64MacroAssemblerTest.java. I would assume there is/will be a test to determine if an AArch64 system has 8.1, 8.2, or 8.3 extensions?
16-03-2018
Thanks for the info. It just wasn't clear looking at the Graal github site if the Oracle agreement was required there.
15-03-2018
To contribute to either Graal or OpenJDK, it���s necessary to sign the OCA.
15-03-2018
Is signing the Oracle Contributor Agreement required in order to contribute to this project? Asking for my legal team.
15-03-2018
Any work on AArch64 is most certainly appreciated by the community. I'm working on String.* parts to begin with, leaving most of the "issue" open for you to work on the other parts as you see fit. (Posting messages here should be enough to synchronise work.)
12-03-2018
https://github.com/oracle/graal/pull/312/files
11-03-2018
I should have also said that I am interested in the intrinsics that are either architecture independent or AArch64 dependent, as AArch64 is my focus.
07-03-2018
I was thinking of starting with the incrementExact and decrementExact as a way of getting started in Graal. Those were listed as trivial, which maps nicely to my experience level in Graal.
07-03-2018
You are more than welcome to help out! You should coordinate with [~phedlin] as I believe he is already working on some of these. How about you list the ones you are interested in as a comment here.
07-03-2018
Are these available to be worked on, or are they currently being implemented within Oracle? I think some of these would be a good way to allow me to get started in Graal.
07-03-2018
Starting with the missing intrinsic for StringUTF16.compress is important as it should resolve JDK-8194313.
19-01-2018
The following compiler intrinsics should be simple to implement while offering some performance improvements: // should be trivial to implement because we already have existing nodes "java/lang/Math.decrementExact(I)I", "java/lang/Math.decrementExact(J)J", "java/lang/Math.incrementExact(I)I", "java/lang/Math.incrementExact(J)J", // should be easy to implement as we already have an implementation for int and long "jdk/internal/misc/Unsafe.getAndAddByte(Ljava/lang/Object;JB)B", "jdk/internal/misc/Unsafe.getAndAddShort(Ljava/lang/Object;JS)S", // should be easy to implement as we already have an implementation for int, long, and Object "jdk/internal/misc/Unsafe.getAndSetByte(Ljava/lang/Object;JB)B", "jdk/internal/misc/Unsafe.getAndSetShort(Ljava/lang/Object;JS)S", "jdk/internal/misc/Unsafe.compareAndSetByte(Ljava/lang/Object;JBB)Z", "jdk/internal/misc/Unsafe.compareAndSetShort(Ljava/lang/Object;JSS)Z", // should be easy to implement as it seems to match the logic that is already // implemented in ValueCompareAndSwapNode. On the high-level, we would need // something similar to UnsafeCompareAndSwapNode but with a different result type "jdk/internal/misc/Unsafe.compareAndExchangeByte(Ljava/lang/Object;JBB)B", "jdk/internal/misc/Unsafe.compareAndExchangeInt(Ljava/lang/Object;JII)I", "jdk/internal/misc/Unsafe.compareAndExchangeLong(Ljava/lang/Object;JJJ)J", "jdk/internal/misc/Unsafe.compareAndExchangeObject(Ljava/lang/Object;JLjava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;", "jdk/internal/misc/Unsafe.compareAndExchangeShort(Ljava/lang/Object;JSS)S", // should be fairly easy to implement - C2 intrinsifies these to use "v != v" to // check for NaN instead of looking at the bit pattern "java/lang/Double.doubleToLongBits(D)J", "java/lang/Float.floatToIntBits(F)I", // HotSpot MacroAssembler-based intrinsic "java/lang/String.compareTo(Ljava/lang/String;)I", "java/lang/String.indexOf(Ljava/lang/String;)I", // Just a runtime call (the called C code has a better fast path) "java/lang/Object.notify()V", "java/lang/Object.notifyAll()V",
10-01-2018