RFR: 8373794: Move nmethod header from CodeCache [v2]

Mikhail Ablakatov mablakatov at openjdk.org
Fri Feb 20 17:50:12 UTC 2026


On Thu, 19 Feb 2026 10:22:28 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Mikhail Ablakatov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
>> 
>>  - cleanup: remove redundant comments
>>  - Merge branch 'master' at a86a847f57a
>>  - 8373794: Move nmethod header from CodeCache:
>>    
>>    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.
>
> src/hotspot/share/code/codeBlob.cpp line 222:
> 
>> 220:   }
>> 221: }
>> 222: 
> 
> Shouldn't this be handled in a `nmethod::Vptr` method instead of here?

I agree as this logic implements a virtual destructor essentially.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28866#discussion_r2834398327


More information about the serviceability-dev mailing list