RFR: 8330253: Remove verify_consistent_lock_order [v7]

Axel Boldt-Christmas aboldtch at openjdk.org
Mon Apr 29 13:52:23 UTC 2024


On Mon, 29 Apr 2024 13:40:29 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 when deoptimization occurs on a monitorenter bytecode. The locking may be in a transitional state. Because the correct solution is still not obvious and this test is currently only causing false positives, remove the verification for now.
>> 
>> Redo this verification in [JDK-8331307](https://bugs.openjdk.org/browse/JDK-8331307).
>
> Axel Boldt-Christmas has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Revert verification
>  - Revert "repro for JDK-8330253"
>    
>    This reverts commit 10d70ea18c5bad0627b9eaae88fa8c96e436cb3b.

There were some additional issues with 10d70ea that has to be resolved before this could go in. And multiple engineers in this area agree that the bytecode filter  is probably not the way to solve this. [JDK-8331307](https://bugs.openjdk.org/browse/JDK-8331307) has been created to redo `verify_consistent_lock_order`. 

Because this issue is creating false positives in testing I propose that we first remove the verification so it can be redone. 

Reverted the test and removed the verification logic.

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

PR Comment: https://git.openjdk.org/jdk/pull/18782#issuecomment-2082798633


More information about the hotspot-dev mailing list