RFR: 8246381: VM crashes with "Current BasicObjectLock* below than low_mark"
Jamsheed C M
jamsheed.c.m at oracle.com
Wed Jul 15 22:16:11 UTC 2020
(Thank you Dean, adding serviceability team as this issue involves JVMTI
features PopFrame, EarlyReturn features)
JBS entry: https://bugs.openjdk.java.net/browse/JDK-8246381
(testing: mach5, tier1-5 links in JBS)
On 15/07/2020 21:25, Jamsheed C M wrote:
> 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)
> 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
> Request for review.
> Best regards,
>  https://bugs.openjdk.java.net/browse/JDK-8246727
>  https://bugs.openjdk.java.net/browse/JDK-8221207
More information about the hotspot-runtime-dev