RFR: 8321219: runtime/jni/FastGetField: assert(is_interpreted_frame()) failed: interpreted frame expected

[Serguei Spitsyn]

On Tue, 5 Dec 2023 04:41:29 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> The fix is for a regression caused by:
>>  [8308614](https://bugs.openjdk.org/browse/JDK-8308614) Enabling JVMTI ClassLoad event slows down vthread creation by factor 10
>> 
>> The fix of 8308614 just triggered a known issue:
>>   [8316283](https://bugs.openjdk.org/browse/JDK-8316283) field watch events are not always posted with -Xcomp option
>>   
>> The fix is just a work around with the extra checks with the `JvmtiExport::should_post_field_access()` and `JvmtiExport::should_post_field_modification()`.
>> 
>> Testing:
>> - The test `runtime/jni/FastGetField/FastGetField.java` does not fail anymore with this fix
>> - In progress: Test with tiers 1-6
>
> src/hotspot/share/prims/jvmtiThreadState.cpp line 562:
> 
>> 560:   if (JvmtiThreadState::seen_interp_only_mode() ||
>> 561:       JvmtiExport::should_post_field_access() ||
>> 562:       JvmtiExport::should_post_field_modification()){
> 
> The comment needs updating to explain the extra checks.
> 
> Can't say I see the connection with [8316283](https://bugs.openjdk.org/browse/JDK-8316283) as no `-Xcomp` is involved in the current failures AFAICS.

Thank you for the suggestion. I'll add a comment.
The `-Xcomp` flag is not a root cause but a trigger. There is a general issue that a frame can be not deoptimized. The `-Xcomp` is a stress that helps to reproduce the issue as the `-Xcomp` option and `interp_only_mode` works in opposite directions.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16961#discussion_r1415125933