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

[Doug Simon]

On Tue, 29 Apr 2025 01:35:03 GMT, Dean Long <dlong at openjdk.org> wrote:

>> src/hotspot/share/code/nmethod.cpp line 1505:
>> 
>>> 1503:     CHECKED_CAST(_oops_size, uint16_t, align_up(code_buffer->total_oop_size(), oopSize));
>>> 1504:     uint16_t metadata_size = (uint16_t)align_up(code_buffer->total_metadata_size(), wordSize);
>>> 1505:     JVMCI_ONLY(CHECKED_CAST(_jvmci_data_size, uint16_t, align_up(compiler->is_jvmci() ? jvmci_data->size() : 0, oopSize)));
>> 
>> This cast is lossy in that `jvmci_data->size()` returns an int. It caused a `double free or corruption (out)` crash in Graal in the case where a `JVMCINMethodData` had a very long name. We've fixed this by [limiting the length of the name](https://github.com/openjdk/jdk/pull/24753) but I'm wondering if there was some special reason for this cast? If so, can you please add extra logic preventing this code from running off the end of allocated memory:
>> 
>> #if INCLUDE_JVMCI
>>     if (compiler->is_jvmci()) {
>>       // Initialize the JVMCINMethodData object inlined into nm
>>       jvmci_nmethod_data()->copy(jvmci_data);
>>     }
>> #endif
>> 
>> If not, please remove the cast.
>
> The cast was added by 8331087, which reduced the supported JVMCI data size to uint16_t.  I don't remember this issue with long names coming up during that review, so I guess we all missed it.  @dougxc please file a bug so we can track this.  It seems like JVMCINMethodData::copy should do something like truncate long names rather than blindly assuming it has enough space.  If uint16_t is unreasonably small for JVMCI nmethod data we could revert that change and make it 32 bits again.

I think in 8331087, I think only `_jvmci_data_offset` was subject to the [narrowing cast](https://github.com/openjdk/jdk/pull/18984/files#diff-c345a29edc19eb49f833e007143e00f897bb762b0f451a202e1d2f5304ed2308R1496).
I've opened https://bugs.openjdk.org/browse/JDK-8355896.

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

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