On Wed, 8 Jul 2026 21:54:40 GMT, Patricio Chilano Mateo
<[email protected]> wrote:
>> src/hotspot/share/prims/jvmtiEnvBase.cpp line 2469:
>>
>>> 2467: vframeStream vfst(_target_jt);
>>> 2468: Method* m = vfst.method();
>>> 2469: if (is_async_unsafe_method(m)) {
>>
>> I assume `m` is the current Java method. Simply checking if that method is
>> unsafe seems inadequate as we may be in the VT code but calling a method of
>> another class when we process the async-exception. Doesn't this need to be
>> an actual walk of the stack to look for any unsafe method?
>
> 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.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/31759#discussion_r3548359816
