RFR: 8316694: Implement relocation of nmethod within CodeCache [v15]
Tom Rodriguez
never at openjdk.org
Wed May 28 17:41:06 UTC 2025
On Thu, 8 May 2025 21:21:11 GMT, Erik Österlund <eosterlund at openjdk.org> wrote:
>> Chad Rakoczy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 54 additional commits since the last revision:
>>
>> - Fix null check
>> - Remove unnecessary include
>> - Add nullptr check to relocate
>> - Fix JVMCI nmethod data
>> - Unexclude JVMCI methods
>> - Add relocate_nmethod_mirror
>> - Only hold NMethodState_lock when needed
>> - Exclude JVMCI nmethods
>> - Remove StressNMethodRelocation
>> - Fix branch_range revert
>> - ... and 44 more: https://git.openjdk.org/jdk/compare/4976a8f3...9ca3563a
>
> src/hotspot/share/jvmci/jvmciRuntime.cpp line 858:
>
>> 856:
>> 857: JVMCIEnv* jvmciEnv = nullptr;
>> 858: HotSpotJVMCI::InstalledCode::set_address(jvmciEnv, nmethod_mirror, (jlong)(nm));
>
> What's the sync story here? Any lock protecting this? If not, I wonder if readers are okay with inconsistencies. I haven't checked.
In the current implementation the fields of InstalledCode are initialized to valid values from the nmethod* during code installation. Those fields only ever transition to 0 as part of nmethod invalidation. Hosted methods may read `InstalledCode.entryPoint` and dispatch to it if it's non-null. So a transition of these values should be safe if they moved from a non-null value to another non-null value and the existing nmethod stayed alive until the next safepoint in the normal nmethod reclamation cycle. Currently writes to those fields by the VM are done in make_not_entrant or at a safepoint so we might want to perform more explicit locking to support transfer of these values.
We might consider revisiting the design of InstalledCode itself now that Graal is aligned with the JDK. Backward compatibility precluded that in the past. That might simplify the whole thing.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/23573#discussion_r2112428990
More information about the hotspot-compiler-dev
mailing list