8u144 hotspot fails to reach safepoint due to compiler thread - VM frozen

[dean.long at oracle.com]

On 11/3/17 6:05 AM, Vitaly Davidovich wrote:

>
> On Thu, Nov 2, 2017 at 10:03 PM <dean.long at oracle.com 
> <mailto:dean.long at oracle.com>> wrote:
>
>      From a quick search, this sounds similar to 8085965.  I wonder if
>     another circularity in the siblings list has been created
>     somehow.  Can
>     you check for that with gdb?
>
> Hi Dean,
>
> Yes it does sound like that bug, although that’s marked as fixed in 
> 8u72.  I guess the implication is that it’s not actually fixed or this 
> is a different codepath/circumstance that ends up in the same blackhole.
>
> I’ll see if my colleagues can dig around in the core file.  It’s a 
> product build so not sure how easy it will be to make sense of it 
> without debug symbols.
>

I'm not an expert with jhsdb/clhsdb/hsdb, but I believe it can attach to 
a core file and give you some information even with a product build.

dl

> Thanks
>
>
>
>     dl
>
>
>     On 10/31/17 11:08 AM, Vitaly Davidovich wrote:
>     > Hi guys,
>     >
>     > I have some colleagues who appear to be running into
>     > https://bugs.openjdk.java.net/browse/JDK-8059128 on Oracle JDK 8u144
>     > (Linux, x86-64).  Naturally, there's no reproducer but they've seen
>     > this happen several times in the last couple of months.
>     >
>     > The symptom is the JVM becomes unresponsive - the application is not
>     > servicing any traffic, and jstack doesn't work without the force
>     > option.  jstack output (with native frames) captured some time apart
>     > shows the compiler thread either in Parse::do_all_blocks ->
>     > do_one_block -> do_one_bytecode -> ...
>     > InstanceKlass::has_finalizable_subclass ->
>     > Dependencies::find_finalizable_subclass or <same as the previous
>     one>
>     > ... Dependencies::has_finalizable_subclass() ->
>     Klass::next_sibling()
>     >
>     > I see that 8059128 was closed as Incomplete, but it does look like
>     > there's a real issue here.  Has anyone looked into this further
>     or has
>     > any new thoughts/ideas?
>     >
>     > My understanding is the working theory is it's related to some data
>     > race between class unloading and the compiler thread observing an
>     > inconsistent (corrupt?) type hierarchy.  I see
>     > https://bugs.openjdk.java.net/browse/JDK-8114823 is also noted as
>     > possibly related - the app we're having trouble with is using
>     G1, but
>     > class unloading isn't disabled of course.  Is there some work around
>     > to reduce the likelihood of having the compiler thread and GC cross
>     > paths like this?
>     >
>     > Let me know if you need more info.
>     >
>     > Thanks
>
> -- 
> Sent from my phone

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20171103/8ec6514d/attachment.html>