RFR: Fix held_monitor_count calculation

[Hui Shi]

On Sat, 12 Jun 2021 17:21:05 GMT, Alan Bateman <alanb 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 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.

@AlanBateman 

Add "guarantee(this->held_monitor_count() == 0, "java monitor not release before exit");" in code and test with make run-test CONF=release TEST="tier1 tier2 tier3". 

before fix 66 test fails with none-zero held moinitor count. after fix no fail happen. fastdebug might have more failures in some deoptimize a lot test.

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

PR: https://git.openjdk.java.net/loom/pull/47