RFR: 8330253: Skip verify_consistent_lock_order when deoptimizing from monitorenter bytecode. [v5]
Axel Boldt-Christmas
aboldtch at openjdk.org
Mon Apr 22 05:36:41 UTC 2024
> The verification added in [JDK-8329757](https://bugs.openjdk.org/browse/JDK-8329757) will not work then deoptimization occurs on a monitorenter bytecode. The locking may be in a transitional state. This patch will skip the verification when this occurs.
>
> Currently have only seen this reproduce with JVMTI when deoptimization occurs while a java thread is waiting on a contended monitor. However this could potentially be triggered from a VM entry slow path, so simply checking `current_pending_monitor` could be flaky as well. So instead simply avoid verification.
>
> Tested Tier 1-8 + Stress testing reproducers.
Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision:
Use raw bytecode read for previous bytecode
-------------
Changes:
- all: https://git.openjdk.org/jdk/pull/18782/files
- new: https://git.openjdk.org/jdk/pull/18782/files/10d70ea1..8d815e9f
Webrevs:
- full: https://webrevs.openjdk.org/?repo=jdk&pr=18782&range=04
- incr: https://webrevs.openjdk.org/?repo=jdk&pr=18782&range=03-04
Stats: 6 lines in 1 file changed: 5 ins; 0 del; 1 mod
Patch: https://git.openjdk.org/jdk/pull/18782.diff
Fetch: git fetch https://git.openjdk.org/jdk.git pull/18782/head:pull/18782
PR: https://git.openjdk.org/jdk/pull/18782
More information about the hotspot-dev
mailing list