RFR: 8330253: Skip verify_consistent_lock_order when deoptimizing from monitorenter bytecode. [v2]
Daniel D. Daugherty
dcubed at openjdk.org
Wed Apr 17 16:49:43 UTC 2024
On Wed, 17 Apr 2024 05:41:26 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:
>> 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.
>>
>> Running JVMTI reproducer. Starting full testing soon.
>
> Axel Boldt-Christmas has updated the pull request incrementally with two additional commits since the last revision:
>
> - Handle previous bc being monitorenter
> - Remove implicit conditions
Please clarify what pre-integration testing is being done. As far as I can
tell, this failure only shows up in Tier8 so that should be part of your mix.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/18782#issuecomment-2061745571
More information about the hotspot-dev
mailing list