RFR: 8303431: [JVMCI] libgraal annotation API [v7]
Joe Darcy
darcy at openjdk.org
Mon Apr 17 15:51:38 UTC 2023
On Fri, 17 Mar 2023 15:38:49 GMT, Doug Simon <dnsimon at openjdk.org> wrote:
>> This PR extends JVMCI with new API (`jdk.vm.ci.meta.Annotated`) for accessing annotations. The main differences from `java.lang.reflect.AnnotatedElement` are:
>> * All methods in the `Annotated` interface explicitly specify requested annotation type(s). That is, there is no equivalent of `AnnotatedElement.getAnnotations()`.
>> * Annotation data is returned in a map-like object (of type `jdk.vm.ci.meta.AnnotationData`) instead of in an `Annotation` object. This works better for libgraal as it avoids the need for annotation types to be loaded and included in libgraal.
>>
>> To demonstrate the new API, here's an example in terms `java.lang.reflect.AnnotatedElement` (which `ResolvedJavaType` implements):
>>
>> ResolvedJavaMethod method = ...;
>> ExplodeLoop a = method.getAnnotation(ExplodeLoop.class);
>> return switch (a.kind()) {
>> case FULL_UNROLL -> LoopExplosionKind.FULL_UNROLL;
>> case FULL_UNROLL_UNTIL_RETURN -> LoopExplosionKind.FULL_UNROLL_UNTIL_RETURN;
>> ...
>> }
>>
>>
>> The same code using the new API:
>>
>>
>> ResolvedJavaMethod method = ...;
>> ResolvedJavaType explodeLoopType = ...;
>> AnnotationData a = method.getAnnotationDataFor(explodeLoopType);
>> return switch (a.getEnum("kind").getName()) {
>> case "FULL_UNROLL" -> LoopExplosionKind.FULL_UNROLL;
>> case "FULL_UNROLL_UNTIL_RETURN" -> LoopExplosionKind.FULL_UNROLL_UNTIL_RETURN;
>> ...
>> }
>>
>>
>> The implementation relies on new methods in `jdk.internal.vm.VMSupport` for parsing annotations and serializing/deserializing to/from a byte array. This allows the annotation data to be passed from the HotSpot heap to the libgraal heap.
>
> Doug Simon has updated the pull request incrementally with one additional commit since the last revision:
>
> [skip ci] formatting fixes
src/java.base/share/classes/jdk/internal/vm/VMSupport.java line 419:
> 417: * @param <X> type of the object representing a decoded error
> 418: */
> 419: public interface AnnotationDecoder<T, A, E, X> {
I think it would be better to include some bound on the type parameters to better capture their intention
A extends java.lang.Annotatoin
E extends java.lang.Enum
etc.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/12810#discussion_r1168933556
More information about the core-libs-dev
mailing list