On Tue, 5 Dec 2023 23:36:46 GMT, Serguei Spitsyn <sspit...@openjdk.org> wrote:
>> This is a trivial fix 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 > > Serguei Spitsyn has updated the pull request incrementally with one > additional commit since the last revision: > > fixed trailing whitespace src/hotspot/share/prims/jvmtiThreadState.cpp line 561: > 559: // it is an important optimization to create JvmtiThreadState objects > lazily. > 560: // This optimization is disabled when watchpoint capabilities are > present. It is to > 561: // work around a bug with virtual thread frames which can be not > deoptimized in time. Suggestion: "This optimization is *also* disabled when ..." The phrase "which can be not deoptimized in time." is unclear. Are we racing with deoptimization? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16961#discussion_r1416579588
