Hi David,
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
features.
Yes, proposed fix doesn't. Fix doesn't plan to address JVMTI feature
related issues.
Added just to keep everyone in the loop.
Best regards,
Jamsheed
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
