8u144 hotspot fails to reach safepoint due to compiler thread - VM frozen
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?
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
> 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...
More information about the hotspot-gc-dev