RFR: 8343789: Move mutable nmethod data out of CodeCache [v9]

Vladimir Kozlov kvn at openjdk.org
Tue Feb 11 23:12:31 UTC 2025


On Tue, 10 Dec 2024 22:39:40 GMT, Boris Ulasevich <bulasevich at openjdk.org> wrote:

>> src/hotspot/share/code/codeBlob.hpp line 108:
>> 
>>> 106: 
>>> 107:   int      _size;                  // total size of CodeBlob in bytes
>>> 108:   int      _relocation_size;       // size of relocation (could be bigger than 64Kb)
>> 
>> For offsets into the external mutable/immutable data, we could reduce codecache footprint further by moving these into a a header section of the external data block.  That also allows those blocks to be self-describing, which could help with error reporting or debugging.
>
> Sounds reasonable. But the downside is that in this case the oops iterator needs an additional load (nmethod->mutable_data->oop_size) to check if the oops list is empty.

Lets not do that. All offsets should be kept in CodeBlob (or nmethod) in CodeCache.
No additional loads and simple code for caching code for Leyden.

>> src/hotspot/share/code/nmethod.cpp line 2152:
>> 
>>> 2150:   delete[] _compiled_ic_data;
>>> 2151: 
>>> 2152:   if (_immutable_data != blob_end()) {
>> 
>> Is this just a name change, or a semantic change?
>
> In several places _immutable_data is set to data_end() "valid not null address" address which was actually the end of the code blob. With this change I remove the _data part of the code blob as well as the data_begin() and data_end() functions. I think blob_end() is a good replacement for data_end() for empty _immutable_data cases.

Yes, `blob_end()` (or `code_end()` which is the same) is fine to use here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21276#discussion_r1951673194
PR Review Comment: https://git.openjdk.org/jdk/pull/21276#discussion_r1951719410


More information about the hotspot-compiler-dev mailing list