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, nice work. Two questions: - is registering the code cache with VEH not a basic thing that should have worked already? Windows+Arm does have a JIT, right, so how does it work now, before the patch? Surely we already get already signals (eg polling page accesses) from compiled code? I may be misunderstanding something. - About Code cache size, could we not just align that to 1MB on windows Arm? ------------- PR Comment: https://git.openjdk.org/jdk/pull/31614#issuecomment-5044561300
