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

[Vladimir Kozlov]

On Thu, 20 Feb 2025 22:11:21 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Boris Ulasevich has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:
>> 
>>  - Address review comments: cleanup, move fields to avoid padding, fix CodeBlob purge to call os::free, fix nmethod::print, update Layout description
>>  - add a separate adrp_movk function to to support targets located more than 4GB away
>>  - Force the use of movk in combination with adrp and ldr instructions to address scenarios
>>    where os::malloc allocates buffers beyond the typical ±4GB range accessible with adrp
>>  - Fixing TestFindInstMemRecursion test fail with XX:+StressReflectiveCode option:
>>    _relocation_size can exceed 64Kb, in this case _metadata_offset do not fit into int16.
>>    Fix: use _oops_size int16 field to calculate metadata offset
>>  - removing dead code
>>  - a bit of cleanup and addressing review suggestions
>>  - rework movoop for not_supports_instruction_patching case: correcting in ldr_constant and relocations fixup
>>  - remove _code_end_offset
>>  - update jvm.hotspot.code.CodeBlob class
>>  - update: mutable data for all CodeBlobs with relocations
>>  - ... and 2 more: https://git.openjdk.org/jdk/compare/e1d0a9c8...6c3370be
>
> Also, it seems like there are two kinds of code density we should be concerned about:
> 
> 1. not poluting icache lines with data
> 2. maximizing near calls in the codecache
> 
> For 1), aligning embedded data on cache line boundaries would help, but for 2) we probably would want to put any nearby DataBlobs in their own codecache segment.

@dean-long this is good idea but for separate RFE . @bulasevich please file one.

For now I agree with moving oops data back to nmethod blob.  Metaspace (klass*, method*) and relocation data are more stable: mostly updated during nmethod publishing.

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

PR Comment: https://git.openjdk.org/jdk/pull/21276#issuecomment-2672806878