RFR: 8369238: Allow virtual thread preemption on some common class initialization paths [v10]

[Richard Reingruber]

On Wed, 29 Oct 2025 20:40:14 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> src/hotspot/share/utilities/exceptions.cpp line 350:
>> 
>>> 348:     // the exception is propagated we might make an upcall to
>>> 349:     // Java to initialize the object with the cause of exception.
>>> 350:     NoPreemptMark npm(thread);
>> 
>> Could you explain the control flow in more detail here please. I'm unclear both how we get here and exactly what the affect of the NoPreemptMark is.
>
> We can get here from a preemptable path if initialization of the klass failed: https://github.com/pchilano/jdk/blob/c7d6f5c5220a93653dea37488d238a76e2ad627d/src/hotspot/share/oops/instanceKlass.cpp#L1292
> Also from here at linking step: https://github.com/pchilano/jdk/blob/c7d6f5c5220a93653dea37488d238a76e2ad627d/src/hotspot/share/oops/instanceKlass.cpp#L970.
> The klass of the exception might need to be initialized, so without this `NoPreemptMark` the thread could be preempted while trying to initialize it. The problem is that this method is called here https://github.com/pchilano/jdk/blob/c7d6f5c5220a93653dea37488d238a76e2ad627d/src/hotspot/share/utilities/exceptions.cpp#L372, which will continue executing and possibly make an upcall to Java. We could potentially change these methods to identify a `PreemptedException` and use the `CHECK` macros to return, but I think it is simpler to disable preemption for these cases.

I'm a correct that at line 348 "the *exception* is propagated we might make an upcall to" you are referring to an `PreemptedException`? You could change the comment to distinguish this one with the exception being created better.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2476701445