RFR: 8316694: Implement relocation of nmethod within CodeCache [v15]

Chad Rakoczy duke at openjdk.org
Thu Jul 24 19:00:12 UTC 2025


On Wed, 28 May 2025 17:37:54 GMT, Tom Rodriguez <never at openjdk.org> wrote:

>> 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.

This change was removed as JVMCI nmethods with a mirror are currently excluded ([JDK-8357926](https://bugs.openjdk.org/browse/JDK-8357926))

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23573#discussion_r2229321074


More information about the hotspot-compiler-dev mailing list