RFR: Fix held_monitor_count calculation
Alan Bateman
alanb at openjdk.java.net
Sat Jun 12 17:24:07 UTC 2021
On Sat, 12 Jun 2021 00:26:56 GMT, Hui Shi <hshi at openjdk.org> wrote:
> Problem and fixes includes and we (Tencent team) would like to fixing further related issues.
>
> - C1/C2 locking when deoptimize happen might lost counter inc.
> - increase held monitor count in JIT code slow path runtime method (Runtime1::monitorenter/SharedRuntime::complete_monitor_locking_C_inc_held_monitor_count),
> - JIT code only increases held monitor count only for fastpath.
> - Deoptimization::relock_objects should update count in deoptee thread instead of current rhead.
> - Add missing dec_held_monitor_count in interpreter.
> - Enable assert ion in runtime dec_held_monitor_count and no assert triggers.
> - Assert when Thread assert held_monitor_count should be zero.
> - No assertion happens with above fixes.
Did any of the existing tests trip an assertion? I'm wondering if we need to add more tests here.
-------------
PR: https://git.openjdk.java.net/loom/pull/47
More information about the loom-dev
mailing list