On Wed, 22 Jul 2026 04:26:21 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. >> >> 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 with a new target base due to a merge > or a rebase. The incremental webrev excludes the unrelated changes brought in > by the merge/rebase. The pull request contains four additional commits since > the last revision: > > - Merge branch 'main' into JDK-8387032-code-cache-exceptions > - Shorten exception message in test and add JBS issue ID > - Compile libCodeCacheRuntimeFunctionTableTest.c only on Windows/ARM64 > - Generate EH-only unwind info for code cache area on Windows/ARM64 > > 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. > > 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 records 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. Sorry about the delayed response; I had to read more about VEH before responding. > So registering the code cache should not be necessary with VEH. It's true that the changes in this patch are not required for basic exception handling in the presence of VEH. However, VEH may decide to not handle the exception (e.g. when `topLevelExceptionFilter()` returns `EXCEPTION_CONTINUE_SEARCH` like when `InterceptOSException` is set). As I understand, Windows would then continue with the table-drive exception dispatch and if the address that caused the exception was in HotSpot-generated code, then without this patch, Windows wouldn't have the .xdata and .pdata records to find the the function metadata. A debugger may then incorrectly conclude that there is no function entry for the address that caused the exception. There are a few other situations when `topLevelExceptionFilter()` returns `EXCEPTION_CONTINUE_SEARCH` besides just `InterceptOSException` being set, but I don't fully understand the circumstances. But broadly, the goal of the changes in this patch is to bring the Windows/ARM64 implementation of `os::register_code_area()` at parity with the Windows/x64 implementation of the same function. > 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? Indeed, that part isn't changed by this patch and it works without this patch as well. This patch is for making the exception metadata visible to Windows not for null-check handling. ------------- PR Comment: https://git.openjdk.org/jdk/pull/31614#issuecomment-5097621843
