8387032: Windows/ARM64 does not register the code cache with the OS function table#31614
8387032: Windows/ARM64 does not register the code cache with the OS function table#31614raneashay wants to merge 3 commits into
Conversation
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.
|
👋 Welcome back arane! A progress list of the required criteria for merging this PR into |
|
❗ This change is not yet ready to be integrated. |
|
@raneashay The following label will be automatically applied to this pull request:
When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing list. If you would like to change these labels, use the /label pull request command. |
|
The total number of required reviews for this PR has been set to 2 based on the presence of this label: |
Webrevs
|
|
@raneashay |
This patch fleshes out the
os::register_code_area()function onWindows/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
.pdatarecords (thatcorrespond to the
RUNTIME_FUNCTIONstruct) and.xdatarecords (thatcorrespond to the
UNWIND_INFOstruct). Together, these records enableWindows to correctly dispatch exceptions.
However, there are several differences in the Windows/ARM64
implementation compared to that for Windows/x64. First,
.pdatarecords 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
.pdatarecords as necessary to spanthe entire code cache area.
Each
.pdatarecord points a.xdatarecord, which (also) stores thesize of the function (although not the address), so we make multiple
.pdatarecords point to a shared.xdatarecord. The slight caveathere is that the code cache area may not be a perfect multiple of 1MB,
so we create two
.xdatarecords: (a) one record for all N-1 recordsthat 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
.pdataand.xdatarecords, we allocatethem 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.
Progress
Issue
Reviewing
Using
gitCheckout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/31614/head:pull/31614$ git checkout pull/31614Update a local copy of the PR:
$ git checkout pull/31614$ git pull https://git.openjdk.org/jdk.git pull/31614/headUsing Skara CLI tools
Checkout this PR locally:
$ git pr checkout 31614View PR using the GUI difftool:
$ git pr show -t 31614Using diff file
Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/31614.diff
Using Webrev
Link to Webrev Comment