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

[Carlo Refice]

On Wed, 24 Jul 2024 09:46:06 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> I think JVMCI is already very much JDK-specific so the question is rather whether it's need by any VM that'd try to interact with this JDK implementation. But i don't want to derail this PR, this can be moved up when/if that's needed.
>
> I also agree that this should be moved up to `ResolvedJavaMethod` as the annotation itself is not HotSpot specific and so could easily be relevant for any other VM using the JDK classes (e.g. SVM).
> 
> Note that this means you'll need to update `TestResolvedJavaMethod.java` to test the new method but that should be straightforward.

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)?

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

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