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. 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. ------------- PR Comment: https://git.openjdk.org/jdk/pull/31614#issuecomment-5050587062
