On Tue, 7 Oct 2025 04:03:40 GMT, David Holmes <[email protected]> wrote:
>> Yes, except if the monitor is also used in the context of a carrier thread. >> Currently there are only very few such cases and we disable preemption for >> them (e.g. `interruptLock`), so it’s likely not needed. With the upcoming >> changes to preempt on klass initialization, we could also have this >> situation if a class can be initialized both in the context of a carrier and >> a vthread. Since code executed in the context of the carriers is limited to >> library code there will also be very few cases of this, but I’ve seen at >> least one such case with `LockSupport`. > > So you are saying the current code is insufficient and could still deadlock? If there’s a monitor that is used both in the context of a virtual thread and the carriers then potentially yes. But this should almost never happen, and for the very few special cases we identified we currently disable preemption. So this is mostly to cover for the upcoming changes in case there is a class that can be initialized in the context of both a virtual thread and the carriers. Again this should also be a rare case but I’ve seen at least one case. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27597#discussion_r2411545770
