On Wed, 29 Oct 2025 20:40:14 GMT, Patricio Chilano Mateo <[email protected]> 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
