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