On Thu, 23 Jul 2026 06:41:03 GMT, Thomas Stuefe <[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. >> >> 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. >> >> I hadn't thought of changing the code cache size. I can see how it would >> simplify the creation of the `.xdata` record, but I worry that since >> `InitialCodeCacheSize` and `ReservedCodeCacheSize` are a user-specified >> parameters, subtly changing the code cache size might not be desirable. Let >> me know what you think. > >> 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? @tstuefe @theRealAph Do you have any questions about this change that I can answer? Are there additional changes that you would like to see? ------------- PR Comment: https://git.openjdk.org/jdk/pull/31614#issuecomment-5220955266
