Skip to content

Conversation

@mikabl-arm
Copy link
Contributor

@mikabl-arm mikabl-arm commented Dec 17, 2025

nmethod objects in the CodeCache have the following layout:

| CodeBlob header | NMethod header | Constants | MainCode | StubCode | Data/oops | 

Although mutable and immutable metadata have already been moved out of the code cache by JDK-8343789 and JDK-8331087 respectively, the embedded nmethod header fields still occupy ~160 B (with the CodeBlob header adding another 64 B). In JDK25 the total header footprint is 224 B. This space is reserved inside executable memory, which decreases overall executable code density.

This patch relocates the nmethod header to a C-heap-allocated structure and keeps only 8-byte pointer to that header in the CodeCache. The resulting layout is:

| CodeBlob header | Ptr to NMethodHeader | Constants | MainCode | StubCode | Data/oops | 

This change reduces the size of the CodeCache-resident header from 224 B to 72 B (64 B CodeBlob header + 8 B pointer), achieving roughly a 3x reduction in header footprint.

This change follows the direction established by JDK-7072317, JDK-8331087 and JDK-8343789.

Testing

The patch has passed tier1-3 and hotspot_all tests on AArch64 and x86_64.


Progress

  • Change must be properly reviewed (1 review required, with at least 1 Reviewer)
  • Change must not contain extraneous whitespace
  • Commit message must refer to an issue

Issue

  • JDK-8373794: Move nmethod header from CodeCache (Enhancement - P4)

Contributors

  • Mikhail Ablakatov <mablakatov@openjdk.org>

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/28866/head:pull/28866
$ git checkout pull/28866

Update a local copy of the PR:
$ git checkout pull/28866
$ git pull https://git.openjdk.org/jdk.git pull/28866/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 28866

View PR using the GUI difftool:
$ git pr show -t 28866

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/28866.diff

Using Webrev

Link to Webrev Comment

nmethod objects in the CodeCache have the following layout: | CodeBlob header | NMethod header | Constants | MainCode | StubCode | Data/oops | Although mutable and immutable metadata have already been moved out of the code cache by JDK-8343789 and JDK-8331087 respectively, the embedded `nmethod` header fields still occupy ~160 B (with the `CodeBlob` header adding another 64 B). In JDK25 the total header footprint is 224 B. This space is reserved inside executable memory, which decreases overall executable code density. This patch relocates the `nmethod` header to a C-heap-allocated structure and keeps only 8-byte pointer to that header in the CodeCache. The resulting layout is: | CodeBlob header | Ptr to NMethodHeader | Constants | MainCode | StubCode | Data/oops | This change reduces the size of the CodeCache-resident header from 224 B to 72 B (64 B `CodeBlob` header + 8 B pointer), achieving roughly a 3x reduction in header footprint. This change follows the direction established by JDK-7072317, JDK-8331087 and JDK-8343789.
@bridgekeeper
Copy link

bridgekeeper bot commented Dec 17, 2025

👋 Welcome back mablakatov! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

@openjdk
Copy link

openjdk bot commented Dec 17, 2025

❗ This change is not yet ready to be integrated.
See the Progress checklist in the description for automated requirements.

@openjdk openjdk bot added serviceability serviceability-dev@openjdk.org hotspot hotspot-dev@openjdk.org labels Dec 17, 2025
@openjdk
Copy link

openjdk bot commented Dec 17, 2025

@mikabl-arm The following labels will be automatically applied to this pull request:

  • hotspot
  • serviceability

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing lists. If you would like to change these labels, use the /label pull request command.

@openjdk openjdk bot added the rfr Pull request is ready for review label Dec 17, 2025
@mikabl-arm
Copy link
Contributor Author

/author set bkilambi

@mikabl-arm
Copy link
Contributor Author

/contributor add mablakatov

@openjdk
Copy link

openjdk bot commented Dec 17, 2025

@mikabl-arm Only Committers are allowed to issue the author command.

@openjdk
Copy link

openjdk bot commented Dec 17, 2025

@mikabl-arm
Contributor Mikhail Ablakatov <mablakatov@openjdk.org> successfully added.

@mlbridge
Copy link

mlbridge bot commented Dec 17, 2025

Webrevs

@fg1417
Copy link

fg1417 commented Dec 17, 2025

/author set bkilambi

@openjdk
Copy link

openjdk bot commented Dec 17, 2025

@fg1417 Only the pull request author (@mikabl-arm) is allowed to issue the author command.

Copy link
Contributor

@plummercj plummercj left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The SA changes look ok, but you'll need to do some testing by hand. The existing SA tests don't do a good job of testing compiler support. Specifically, you should run the clhsdb "livenmethods" and "dumpcodecache" commands and make sure the output looks reasonable. Note you may see an issue with "dumpcodecache" getting stuck after producing some output. You can ignore that. I just filed JDK-8373933 for it.

exceptionOffsetField = type.getCIntegerField("_exception_offset");
deoptHandlerEntryOffsetField = type.getCIntegerField("_deopt_handler_entry_offset");
origPCOffsetField = type.getCIntegerField("_orig_pc_offset");
stubOffsetField = type.getCIntegerField("_stub_offset");
scopesPCsOffsetField = type.getCIntegerField("_scopes_pcs_offset");
scopesDataOffsetField = type.getCIntegerField("_scopes_data_offset");

sun.jvm.hotspot.types.Field f = type.getField("_speculations_offset", false, false);
if (f != null) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is there a need for a null check here?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

_speculations_offset is present only when JVM is compiled with JVMCI enabled, see https://github.com/openjdk/jdk/pull/28866/files/bbb3711df942ec48b0b0a6eeb287f5364afa9098#diff-ccbdfe031dfc301041cac88f76f8eb2dcacff1b9f81c50073de5c6eaeb8b8223R256 . type.getCIntegerField("_speculations_offset") will throw an exception if the field is missing.

Though, if the SA can't be used at all with JVMCI disabled, this check can be omitted as redundant. Please let me know if that's the case.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Though, if the SA can't be used at all with JVMCI disabled, this check can be omitted as redundant. Please let me know if that's the case.

I know of no reason why SA won't work with JVMCI disabled, but I'm also not sure if we test that so there could be bugs.

@dean-long
Copy link
Member

Wouldn't it be better to move the whole CodeBlob header out of the code cache? Instead of nmethod having a _hdr pointer, CodeBlob would be in malloc space and have a _code pointer into the CodeCache.

@mikabl-arm
Copy link
Contributor Author

Wouldn't it be better to move the whole CodeBlob header out of the code cache? Instead of nmethod having a _hdr pointer, CodeBlob would be in malloc space and have a _code pointer into the CodeCache.

It might be possible to move both CodeBlob and nmethod data to the C-heap. We'd still need something like an _hdr pointer, since JVM resolves a CodeBlob from a method/stub entry point using CodeBlob* CodeCache::find_blob(void* start). So if we move every member field to the C-heap, we store a pointer to that data right before a method/stub entry point in the CodeCache and that's it. A _code pointer pointing from the C-heap into the CodeCache may not be necessary at all.

That said, this would require moving data for other CodeBlob subclasses (AdapterBlob, ExceptionBlob, etc.) to the C-heap, which would significantly broaden the scope of this patch.

@Bhavana-Kilambi , what do you thing? Is this something you've considered?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

hotspot hotspot-dev@openjdk.org rfr Pull request is ready for review serviceability serviceability-dev@openjdk.org

5 participants