RFR: 8369238: Allow virtual thread preemption on some common class initialization paths [v10]
David Holmes
dholmes at openjdk.org
Thu Oct 30 06:21:08 UTC 2025
On Wed, 29 Oct 2025 20:43:24 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:
>> src/hotspot/share/runtime/javaCalls.cpp line 61:
>>
>>> 59: assert(!thread->owns_locks(), "must release all locks when leaving VM");
>>> 60: guarantee(thread->can_call_java(), "cannot make java calls from the native compiler");
>>> 61: assert(!thread->preempting(), "");
>>
>> I'm not sure why this is checked here, and there is no error message to tell me. If we did get here with `preempting` set what would that mean?
>
> This is a safety check since a thread marked as preempted should not be making upcalls to Java. It should be bailing out from methods and returning to the VM entry point. I found we could get here from the exception path (from your other comment below) when there was no `NoPreemptMark` there.
Okay then how about `"Unexpected Java upcall whilst processing preemption"` ?
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2476538796
More information about the hotspot-dev
mailing list