On Fri, 24 Apr 2026 12:29:02 GMT, Anton Artemov <[email protected]> wrote:
>> Hi, please consider the following changes: >> >> this is a fix for a bug in the `ObjectMonitor::wait()` method introduced by >> [8366659](https://bugs.openjdk.org/browse/JDK-8366659). This bug leads to >> increased failure rate of `ownedMonitorsAndFrames003`, though the test was >> very seldomly failing before >> [8366659](https://bugs.openjdk.org/browse/JDK-8366659). The fix just brings >> the failure rate back to where it used to be. >> >> In short, [8366659](https://bugs.openjdk.org/browse/JDK-8366659) introduced >> a code path where there was no handling of a suspension request until the >> thread goes back to Java, which caused test failures slightly more often. >> >> If `should_post_monitor_waited()` returns false, then a thread, which >> timed-out waiting and got a suspension request, does not have any suspension >> check. >> >> Now the extra condition is removed and a thread in the `TS_RUN` state will >> get its suspension request handled at the right place. >> >> A separate test which triggers the condition is added. >> >> Tested in tiers 1 - 7. >> --------- >> - [x] I confirm that I make this contribution in accordance with the >> [OpenJDK Interim AI Policy](https://openjdk.org/legal/ai). > > Anton Artemov has updated the pull request incrementally with one additional > commit since the last revision: > > 8382088: Addressed reviewer's comments. More test nits. test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorTimedWait/SuspendWithObjectMonitorTimedWait.java line 59: > 57: > 58: public static void main(String args[]) { > 59: int result = new SuspendWithObjectMonitorTimedWait().runIt(); You don't really need to create an instance and call `runit` - all the logic in `runit` could go directly into `main`. test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorTimedWait/SuspendWithObjectMonitorTimedWait.java line 140: > 138: throw new RuntimeException("Grabbed the monitor in total " + > failureCounter + " times out of " + usefulRun + " useful runs, which is more > than 0."); > 139: } > 140: return status; If you throw on failure then you don't need a `status`. ------------- PR Review: https://git.openjdk.org/jdk/pull/30709#pullrequestreview-4178107019 PR Review Comment: https://git.openjdk.org/jdk/pull/30709#discussion_r3144842526 PR Review Comment: https://git.openjdk.org/jdk/pull/30709#discussion_r3144837237
