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