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

[Jamsheed C M]

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.

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.

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