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 Andrew, thanks for your comment. Now that I know about `InterceptOSException` as an easy way to make VEH route the exception dispatch to Windows, I was able to write a standalone program to demonstrate the effect of this patch. I've added a version of this as a test. Here is the standalone program: public class test { static class Box { int value; } static int get(Box box) { return box.value; } public static void main(String[] args) { System.out.println(get(null)); System.out.println("unreachable"); } } When I run it with the old build (with `InterceptOSException` set), the JVM silently terminates (since Windows abruptly terminate the program). >_ ./build-old/images/jdk/bin/java -XX:+InterceptOSException >-XX:CompileCommand=compileonly,test::get -XX:-CreateCoredumpOnCrash >../test.java CompileCommand: compileonly test.get intx compileonly = 1111 >_ echo $env.LAST_EXIT_CODE -1073741819 Whereas with the changes in this patch, we now see a HotSpot message along with a core dump, if requested: >_ ./build-new/images/jdk/bin/java -XX:+InterceptOSException >-XX:CompileCommand=compileonly,test::get -XX:-CreateCoredumpOnCrash >../test.java CompileCommand: compileonly test.get intx compileonly = 1111 # # A fatal error has been detected by the Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x0000022b713c50ec, pid=45716, tid=44920 # # JRE version: OpenJDK Runtime Environment (28.0) (fastdebug build 28-internal+0-adhoc.spur) # Java VM: OpenJDK 64-Bit Server VM (fastdebug 28-ea, mixed mode, sharing, tiered, compressed oops, compact obj headers, g1 gc, windows-aarch64) # Problematic frame: # j test.get(Ltest$Box;)I+1 # # CreateCoredumpOnCrash turned off, no core file dumped # # An error report file with more information is saved as: # E:\raneashay\openjdk-jdk\hs_err_pid45716.log [2.450s][warning][os] Loading hsdis library failed # # ------------- PR Comment: https://git.openjdk.org/jdk/pull/31614#issuecomment-5106431580
