RFR: 8246381: VM crashes with "Current BasicObjectLock* below than low_mark"
Jamsheed C M
jamsheed.c.m at oracle.com
Wed Jul 15 15:55:44 UTC 2020
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 
There was one other issue reported in similar time. This issue got
triggered in test case by , 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)
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.
There are more problems in these code areas, like we clear all
exceptions in compilation request path(interpreter,c1), as well as
All these un-handled cases will be separately handled by
Request for review.
More information about the hotspot-runtime-dev