On Thu, 9 Jul 2026 01:57:44 GMT, David Holmes <[email protected]> wrote:
>> The intention was to fix the reported case, and only as best-effort try to >> cover other potential ones. That’s why `is_async_unsafe_method` simply >> checks for any `VirtualThread` method at the top. It covers the known >> problematic cases that could lead to the reported crash >> (`yieldContinuation`, `VirtualThread$VThreadContinuation$1.run`, and the >> ones marked as `@JvmtiMountTransition`), while possibly covering other >> unsafe cases. Walking the stack like that would take it a step further. We >> could do that if you prefer, we would just have to exclude checking for >> methods `VirtualThread.run` and `VirtualThread$VThreadContinuation$1.run` >> (except at the top) as they are always present. > > I'm okay with expanding coverage in a follow-up RFE, but I think we need to > document what our notion of safe/unsafe is more clearly. Simply avoiding > specific crashes is a bit too whack-a-mole for me: we are just trying to fix > a specific test case. How about expanding the comment to: "Throwing from a `VirtualThread` method might leave the virtual thread in an inconsistent state. The current implementation simply checks the top method, which is enough to fix known issues where transition bits could be left in an invalid state and trigger assertion failures. A more thorough approach would be to walk the stack and check for `VirtualThread` methods further up (excluding `VirtualThread.run` and `VirtualThread$VThreadContinuation$1.run` which are always present).” >> Yes, but this is executed inside the handshake which already provides the >> required synchronization. > > Okay, the fact we rely on that should be documented at the accessor. I don't > think there is a way to assert it directly - maybe check `is_handshake_safe`? Added `is_handshake_safe_for` assert in `at_no_async_entry_count()`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/31759#discussion_r3554366330 PR Review Comment: https://git.openjdk.org/jdk/pull/31759#discussion_r3554377678
