Like C1 and C2, the Graal compiler implements compilation pragmas expressed as Java annotations. For example, Graal supports the jdk.internal.vm.annotation.ForceInline and jdk.internal.vm.annotation.DontInline annotations. It does so by reading the method flags these annotations are converted to by HotSpot’s class file parser[1].
Truffle also defines similar pragmas as annotations (e.g. TruffleBoundary[2]). Ideally, the Truffle compiler extensions within libgraal would simply use the existing ResolvedJavaMethod.getAnnotations() and ResolvedJavaMethod.getAnnotation(Class<T> annotationClass) methods to read such annotations. However, that would involve reifying arbitrary Annotation objects in libgraal which is not possible for a number of reasons:
- The way annotation parsing is implemented in the JDK, all annotations on a method are instantiated as soon as one annotation is requested. This is not possible for libgraal as it does not know all possible annotation types used by Truffle guest languages ahead of time.
- Even if all types were known, it would mean including sun.reflect.annotation.AnnotationParser and friends in libgraal, bloating its size.
The current solution is for libgraal to call (via JNI) back into Truffle runtime support code running in Java which invokes ResolvedJavaMethod.getAnnotations() and serializes the result back across the JNI boundary. This necessitates loading and execution of JVMCI code in the HotSpot heap which is contrary to the goal ofJDK-8298099. It also means *all* annotations of a method are instantiated, not just those of interest to libgraal. This, in turn, means potentially executing class initializers for enum types used in the annotations.
The proposed remedy for this is to add support in java.base for loading select annotations and encoding them in a format usable by libgraal.
[1] https://github.com/openjdk/jdk/blob/2fb1e3b7e72cf7836a9ffd9c6a5b09a6eef3c01b/src/hotspot/share/classfile/classFileParser.cpp#L2069-L2092
[2] https://github.com/oracle/graal/blob/c2e5c2c9d28ea4a26b439545e048fbb9ff9ef5ef/truffle/src/com.oracle.truffle.api/src/com/oracle/truffle/api/CompilerDirectives.java#L282
Truffle also defines similar pragmas as annotations (e.g. TruffleBoundary[2]). Ideally, the Truffle compiler extensions within libgraal would simply use the existing ResolvedJavaMethod.getAnnotations() and ResolvedJavaMethod.getAnnotation(Class<T> annotationClass) methods to read such annotations. However, that would involve reifying arbitrary Annotation objects in libgraal which is not possible for a number of reasons:
- The way annotation parsing is implemented in the JDK, all annotations on a method are instantiated as soon as one annotation is requested. This is not possible for libgraal as it does not know all possible annotation types used by Truffle guest languages ahead of time.
- Even if all types were known, it would mean including sun.reflect.annotation.AnnotationParser and friends in libgraal, bloating its size.
The current solution is for libgraal to call (via JNI) back into Truffle runtime support code running in Java which invokes ResolvedJavaMethod.getAnnotations() and serializes the result back across the JNI boundary. This necessitates loading and execution of JVMCI code in the HotSpot heap which is contrary to the goal of
The proposed remedy for this is to add support in java.base for loading select annotations and encoding them in a format usable by libgraal.
[1] https://github.com/openjdk/jdk/blob/2fb1e3b7e72cf7836a9ffd9c6a5b09a6eef3c01b/src/hotspot/share/classfile/classFileParser.cpp#L2069-L2092
[2] https://github.com/oracle/graal/blob/c2e5c2c9d28ea4a26b439545e048fbb9ff9ef5ef/truffle/src/com.oracle.truffle.api/src/com/oracle/truffle/api/CompilerDirectives.java#L282
- relates to
-
JDK-8306581 JVMCI tests failed when run with -XX:TypeProfileLevel=222 after JDK-8303431
-
- Resolved
-
- links to
-
Commit openjdk/jdk/48fd4f2b
-
Review(master) openjdk/jdk/12810