RFR: 8336489: Track scoped accesses in JVMCI compiled code

[Carlo Refice]

On Mon, 22 Jul 2024 07:25:05 GMT, Gilles Duboscq <gdub at openjdk.org> wrote:

>> This PR adds JVMCI support to scoped access tracking introduced in #20158.
>> 
>> In this PR:
>> * The `Method::is_scoped` flag is now exposed in JVMCI as `HotSpotResolvedJavaMethod.isScoped()`, and serialized to / deserialized from the JVMCI compiled code stream as a boolean flag.
>> * To determine whether a compiled method has a scoped access, we simply check `HotSpotResolvedJavaMethod.isScoped()` returns `true` for the root method or any of the methods that were inlined in the compilation.
>> * The above check is implemented as the method `HotSpotCompiledNMethod.hasScopedAccess()`, instead of as an explicit flag set in a the constructor of `HotSpotCompiledNMethod`. This keeps the change isolated to JVMCI, without requiring coordinated changes to the Graal compiler. No other changes in the compiler are necessary to benefit from the optimization.
>
> src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/hotspot/HotSpotResolvedJavaMethod.java line 66:
> 
>> 64:      * @return true if Scoped annotation present, false otherwise
>> 65:      */
>> 66:     boolean isScoped();
> 
> Why not add this to `ResolvedJavaMethod`? If it is about compatibility you could add it as a default method that throws a `UnsupportedOperationException`.

I don't know how much sense it makes to expose a flag that is only relevant for an optimization in HotSpot (and that exposes the presence of an annotation used only internally by the jdk) to non-hotspot methods

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

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