[15] RFR: 8246381: VM crashes with "Current BasicObjectLock* below than low_mark"

[David Holmes]

Hi Jamsheed,

On 16/07/2020 8:16 am, Jamsheed C M wrote:
> (Thank you Dean, adding serviceability team as this issue involves JVMTI 
> features PopFrame, EarlyReturn features)

It is not at all obvious how your proposed fix impacts the JVM TI features.

> JBS entry: https://bugs.openjdk.java.net/browse/JDK-8246381
> 
> (testing: mach5, tier1-5 links in JBS)
> 
> Best regards,
> 
> Jamsheed
> 
> On 15/07/2020 21:25, Jamsheed C M wrote:
>>
>> Hi,
>>
>> Async handling at method entry requires it to be aware of 
>> synchronization(like whether it is doing async handling before lock 
>> acquire or after)
>>
>> This is required as exception handler rely on this info for 
>> unlocking.  Async handling code never had this special condition 
>> handled and it worked most of the time as we were using biased locking 
>> which got disabled by [1]
>>
>> There was one other issue reported in similar time[2]. This issue got 
>> triggered in test case by [3], back to back extra safepoint after 
>> suspend and TLH for ThreadDeath. So in this setup both PopFrame 
>> request and Thread.Stop request happened together for the test 
>> scenario and it reached java method entry with pending_exception set.
>>
>> I have done a partial fix for the issue, mainly to handle production 
>> mode crash failures(do not unlock flag related ones)
>>
>> Fix detail:
>>
>> 1) I save restore the "do not unlock" flag in async handling.

Sorry but you completely changed the fix compared to what we discussed 
and what I pre-reviewed! What happened to changing from JRT_ENTRY to 
JRT_ENTRY_NOASYNC? It is going to take me a lot of time and effort to 
determine that this save/restore of the "do not unlock flag" is actually 
correct and valid!

>>
>> 2) Return for floating pending exception for some cases(PopFrame, 
>> Early return related). This is debug(JVMTI) feature and floating 
>> exception can get cleaned just like that in present compiler request 
>> and deopt code.

What part of the change addresses this?

Thanks,
David
-----

>>
>> webrev :http://cr.openjdk.java.net/~jcm/8246381/webrev.02/
>>
>> There are more problems in these code areas, like we clear all 
>> exceptions in compilation request path(interpreter,c1), as well as 
>> deoptimization path.
>>
>> All these un-handled cases will be separately handled by 
>> https://bugs.openjdk.java.net/browse/JDK-8249451
>>
>> Request for review.
>>
>> Best regards,
>>
>> Jamsheed
>>
>> [1]https://bugs.openjdk.java.net/browse/JDK-8231264 
>> <https://bugs.openjdk.java.net/browse/JDK-8231264>
>>
>> [2] https://bugs.openjdk.java.net/browse/JDK-8246727
>>
>> [3] https://bugs.openjdk.java.net/browse/JDK-8221207
>>