RFR: 8246381: VM crashes with "Current BasicObjectLock* below than low_mark"
Jamsheed C M
jamsheed.c.m at oracle.com
Thu Jul 16 00:01:21 UTC 2020
On 16/07/2020 05:20, David Holmes wrote:
> 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
Yes, proposed fix doesn't. Fix doesn't plan to address JVMTI feature
Added just to keep everyone in the loop.
>> JBS entry: https://bugs.openjdk.java.net/browse/JDK-8246381
>> (testing: mach5, tier1-5 links in JBS)
>> Best regards,
>> 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.
> 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?
>>> 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