On Tue, 5 Dec 2023 04:41:29 GMT, David Holmes <dhol...@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
