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 Hi, wow that change of mine was from so long ago. I actually did not introduce InterceptOSException, it had already been there before I enabled permissive- for HotSpot. What I did was simply rewire the if statement it was in to check for the negated value and move the logic that should run if InterceptOSException was false into the if statement; Before, the implementation of InterceptOSException simply jumped over the code that should run if InterceptOSException was false to the end of the method. This caused conformant compilers, gcc in my case, as I use gcc to compile on Windows, to explode when compiling that method, as C++ forbids you from jumping over the initialization of a local for some reason. Did the permissive- change break anything? I sure hope I didn't end up breaking the JDK for the 1000th time, but I'll see if I can do anything if I did break anything. Sorry for the trouble! ------------- PR Comment: https://git.openjdk.org/jdk/pull/31614#issuecomment-5238063015
