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

[Patricio Chilano Mateo]

On Wed, 29 Oct 2025 06:19:07 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   add const to references
>
> 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.

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

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