On Tue, 28 Jul 2026 15:54:33 GMT, Ashay Rane <[email protected]> wrote:
>> This patch fleshes out the `os::register_code_area()` function on >> Windows/ARM64, largely mimicking the code for the Windows/x64 port with >> some key ARM64-specific changes. Specifically (and similar to the >> Windows/x64 port), this patch registers a single handler for the entire >> dynamically generated code region, generating `.pdata` records (that >> correspond to the `RUNTIME_FUNCTION` struct) and `.xdata` records (that >> correspond to the `UNWIND_INFO` struct). Together, these records enable >> Windows to correctly dispatch exceptions when Vectored Exception >> Handling bails out (i.e. when `topLevelExceptionFilter()` returns >> `EXCEPTION_CONTINUE_SEARCH`). >> >> However, there are several differences in the Windows/ARM64 >> implementation compared to that for Windows/x64. First, `.pdata` >> records on Windows/ARM64 store metadata information for functions that >> are at most 1MB in size. Since the HotSpot code cache area could be >> larger than 1MB, we create as many `.pdata` records as necessary to span >> the entire code cache area. >> >> Each `.pdata` record points a `.xdata` record, which (also) stores the >> size of the function (although not the address), so we make multiple >> `.pdata` records point to a shared `.xdata` record. The slight caveat >> here is that the code cache area may not be a perfect multiple of 1MB, >> so we create _two_ `.xdata` records: (a) one record for all N-1 records >> that store the metadata for the 1MB regions of the code cache and (b) a >> second record for the trailing size left over after dividing the code >> cache area size into 1MB chunks. >> >> Due to the variable number of `.pdata` and `.xdata` records, we allocate >> them just after the unwind record so that all these records have the >> same lifetime and so that they don't need to be managed separately. >> >> Finally, since the Windows/ARM64 port uses Vectored Exception Handling, >> any recoverable exceptions should have already been handled, so the >> exception handling function introduced in this patch reports the >> exception to the console. >> >> --------- >> - [x] I confirm that I make this contribution in accordance with the >> [OpenJDK Interim AI Policy](https://openjdk.org/legal/ai). > > Ashay Rane has updated the pull request incrementally with one additional > commit since the last revision: > > Use `InterceptOSException` to demonstrate utility of patch I still feel we understand too little of the underlying mechanics. In fact, it may break debugging (see below). (Whenever I write "exception" I mean the Windows machine exception, not java exception, unless explicitly stated otherwise) Back in the day, on x86 (32bit), we needed to register the code cache on Windows since we could only use stack-based exception handling: exceptions bubbling up from the code cache would lead to the process aborting since Windows did not know where to route the exception to. In C++ code, we'd use `__try`/`__except`, but that was not possible in JIT compiled code. With x64, we got VEH. We continued to use SEH, though, since it was there and it worked. With ARM, we started to use VEH. With VEH, exceptions are being routed to our topLevelExceptionFilter(signal handler) correctly without having to tell Windows where the code cache is. This already works: otherwise, the Windows ARM port would not be functional. `InterceptOSException` was introduced with https://github.com/openjdk/jdk/pull/15955 . It's a Windows-only flag, and I have not found any documentation beyond "Start debugger when an implicit OS exception happens" usage text in globals.hpp. Name and text are a bit misleading. There are no "implicit OS exceptions". Julian likely meant "OS exceptions that would lead to implicit java exceptions like NPEs". It also does not intercept anything, does not start the debugger. Instead, it disables the hotspot signal handling - for all exceptions - by immediately returning from it. This in turn causes immediate crashes. These result in processes vanishing, or DrWatson Popups, or Windows minidumps, depending on how your Windows machine is set up. Julians intent was likely to have the machine set up such that a debugger would automatically start when a process crashes. @TheShermanTanker ? (Side note, we also have the preexisting Windows-only `UseOSErrorReporting` which seems to do exactly the same. We should investigate whether we need two switches for the same thing.) Now, your example: a) without your patch and `+InterceptOSExceptions` we get a native crash b) with your patch and `+InterceptOSExceptions` we end up in the hotspot crash handler. In both cases, we bypass the main signal handler `topLevelExceptionFilter`, but in (b) we still end up in hotspot signal handling. Likely because there is a second `topLevelUnhandledExceptionFilter` that is further up the exception filter hierarchy. But I am not sure how this is better? Arguably, this is worse: If the point of `InterceptOSExceptions` was to disable hotspot crash handling in order to invoke whatever Windows does with native crashes, then (a) behaves correctly, and (b) does not. (Side note: I think that invoking that second `topLevelUnhandledExceptionFilter` may be an error and a leftover from SEH. It is needed in SEH to guard sections that are not covered by `__try/__except`. But I don't think we need it in VEH mode? What for? There are no uncovered sections with VEH.) ------------- PR Comment: https://git.openjdk.org/jdk/pull/31614#issuecomment-5237877122
