On Wed, 29 Oct 2025 06:19:07 GMT, David Holmes <[email protected]> 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
