RFR: 8336489: Track scoped accesses in JVMCI compiled code [v3]

Gilles Duboscq gdub at openjdk.org
Fri Jul 26 07:48:31 UTC 2024


On Thu, 25 Jul 2024 16:56:09 GMT, Carlo Refice <duke at openjdk.org> wrote:

>> I think there's something I'm missing here. I'm trying to extend `TestResolvedJavaMethod.java` to test the new method, but I can't get `isScoped()` to return true for methods with the `@Scoped` annotation such as `jdk.internal.misc.ScopedMemoryAccess#loadInternal()`.
>> 
>> At first I thought it was a problem with my implementation, but I also can't get `HotSpotResolvedJavaMethod#hasReservedStackAccess()` to return true for a method like the following:
>> 
>> @jdk.internal.vm.annotation.ReservedStackAccess
>> private static void methodWithReservedStackAccess() {}
>> 
>> 
>> The `loadInternal()` method above also has a `ForceInline` annotation, and for that one `HotSpotResolvedJavaMethod#isForceInline()` does return true.
>> 
>> The only difference I can see between these flags is that `isForceInline()` is stored in `Method::_flags` whereas `loadInternal()` and `hasReservedStackAccess()` are stored in `ConstMethod::_flags`. Could it be that const method flags are not being propagated properly in tests (or elsewhere)?
>> 
>> Here's a snippet of the test in question that I'm trying to add,
>> in `compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TestResolvedJavaMethod.java`:
>> 
>>     @jdk.internal.vm.annotation.ReservedStackAccess
>>     private static void methodWithReservedStackAccess() {
>>     }
>> 
>>     @Test
>>     public void isScopedTest() throws NoSuchMethodException {
>>         ResolvedJavaMethod rsaMethod = metaAccess.lookupJavaMethod(getClass().getDeclaredMethod("methodWithReservedStackAccess"));
>> 
>>         // Fails
>>         assertTrue(rsaMethod.toString(), ((HotSpotResolvedJavaMethod)rsaMethod).hasReservedStackAccess());
>> 
>>         ResolvedJavaMethod scopedMethod = metaAccess.lookupJavaMethod(ScopedMemoryAccess.class.getDeclaredMethod("loadInternal", MemorySessionImpl.class, long.class, boolean.class, long.class));
>>         // Succeeds
>>         assertTrue(scopedMethod.toString(), ((HotSpotResolvedJavaMethod)scopedMethod).isForceInline());
>> 
>>         //Fails
>>         assertTrue(scopedMethod.toString(), ((HotSpotResolvedJavaMethod)scopedMethod).isScoped());
>>     }
>
> Nevermind, looks like the issue with `hasReservedStackAccess` was the fact that the holding class has to be loaded by the boot class loader for the annotation to be picked up. Back to the drawing board...

FYI those internal annotations are meaningful only for boot/platfrom-loaded classes as well as hidden classes loaded with the `java.lang.invoke.MethodHandleNatives.Constants#ACCESS_VM_ANNOTATIONS` flag. See https://github.com/openjdk/jdk/blob/7f11935461a6ff1ef0fac800fb4264a519e21061/src/hotspot/share/classfile/classFileParser.cpp#L1916-L1919.
The javadoc that just says that it's about the method having this annotation is a bit misleading.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20256#discussion_r1692649182


More information about the hotspot-compiler-dev mailing list