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

Vitaly Davidovich vitalyd at gmail.com
Fri Nov 3 13:05:04 UTC 2017


On Thu, Nov 2, 2017 at 10:03 PM <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.

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


More information about the hotspot-runtime-dev mailing list