On Wed, 22 Jul 2026 19:33:53 GMT, Ashay Rane <[email protected]> wrote:
> Hi Thomas, thanks for taking a look! > > Based on my limited understanding of HotSpot's exception handling code, VEH > indeed handles the delivery of signals arising in compiled code but what's > missing is letting Windows know about the code cache, so that the dispatch > mechanism in Windows (which, I believe, is used by stack walking code in > debuggers or profilers) is able to recognize addresses in the code cache. Hmm, I still don't understand. Something must not have worked before, right? Otherwise, you would not have done this patch? What was that Something? The reason I ask is I try to understand it. For SEH, we needed to register the code cache with Windows since SEH works scope-based, so we needed to tell Windows "there is our code, if a fault happens jump to our signal handler". Stuff that normally the C++ compiler does for you. With VEH, my understanding was that it now is a lot more like the UNIX model: We have one central function pointer (?) to the central handler function. That one gets called from wherever in the code a fault occurs, be it in C++ compiled code or in JIT compiled code. So registering the code cache should not be necessary with VEH. Is that not correct? > > I've been trying to demonstrate this using a standalone program, but even if > I am able to make the code cache area contain a crashing program, HotSpot > inserts null checks that are handled using VEH (and not the code introduced > in this patch). So my best option so far has been to invoke > `RtlLookupFunctionEntry()` on a code cache address and show that this patch > makes the return value non-NULL. > With implicit null checks activated, any compiled code that dereferences a null oop should invoke the signal/exception handler in os_windows_xxx.cpp and there it should be handled. Does that work before the patch? If not, how did we handle null references? Trap-based? ------------- PR Comment: https://git.openjdk.org/jdk/pull/31614#issuecomment-5055278095
