On Thu, 20 Nov 2025 05:38:21 GMT, David Holmes <[email protected]> wrote:
> Maintaining the event order is problematic as, with the fix to the deadlock > issue, we only allow suspension during reentry, and that would mean the > `monitor_waited` event would be posted whilst the thread is still suspended. > To be clear(er) in the old code we would do: > > ``` > wait -> suspend if needed -> resumed -> post monitor_waited -> renter monitor > ``` > > whereas the new code, if we kept the placement of the event, would do > > ``` > wait -> post monitor_waited -> reenter monitor -> suspend if needed and drop > monitor -> resumed -> reenter monitor > ``` > > and what the proposed code actually does is > > ``` > wait -> reenter monitor -> suspend if needed and drop monitor -> resumed -> > reenter monitor -> post monitor_waited > ``` > > Given the lack of specificity in the JVM TI spec around these different > events I think any assumptions in a TCK test could be challenged, but it > would still be a change in behaviour. @dholmes-ora I have done a bit of refactoring and introduced a private method `post_waited_event()`, which we can call in different places depending on the scenario. For instance, for the timed-out case, the sequence of events is now unchanged, i.e.: `wait -> waited -> contended enter -> contended entered` For notified case, using your extended notation, it is now behaving like this: `wait -> reenter monitor -> suspend if needed and drop monitor -> resumed -> post monitor_waited -> reenter monitor` I think this is what we eventually want. @sspitsyn could you confirm/refute that it does not change thread state bits? The JVMTI tests pass, the extended testing is in progress. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27040#issuecomment-3558649501
