RFR: 8294676: [JVMCI] InstalledCode.deoptimize(false) should not touch address field

Doug Simon dnsimon at openjdk.org
Fri Sep 30 16:42:06 UTC 2022


The ability to make an nmethod non-entrant via an `InstalledCode` object was added by [JDK-8292917](https://bugs.openjdk.org/browse/JDK-8292917). However, the make non-entrant path clears `InstalledCode.address`.
This breaks the connection between an `InstalledCode` object and the nmethod. This makes it impossible to subsequently deoptimize the code via the `InstalledCode` object as shown below:


InstalledCode tier1Code = ...;
// Make tier1Code non-entrant (e.g. it is being replaced by a more optimized version, tier2Code)
// but do not deoptimize it as it is still valid. Let current executions of tier1Code complete.
tier1Code.invalidate(false);

...

// Some assumption used in compiling tier1Code is about to be invalidated
// so it must now be deoptimized.
tier1Code.invalidate(true)


Prior to this PR, the last statement above does nothing which leads to `tier1Code` incorrectly being executed as soon as the assumption in question is invalidated.

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

Commit messages:
 - InstalledCode.invalidate(false) should not clear InstalledCode.address

Changes: https://git.openjdk.org/jdk/pull/10514/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10514&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8294676
  Stats: 312 lines in 8 files changed: 151 ins; 126 del; 35 mod
  Patch: https://git.openjdk.org/jdk/pull/10514.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10514/head:pull/10514

PR: https://git.openjdk.org/jdk/pull/10514


More information about the hotspot-compiler-dev mailing list