8u144 hotspot fails to reach safepoint due to compiler thread - VM frozen
dean.long at oracle.com
dean.long at oracle.com
Fri Nov 3 16:56:42 UTC 2017
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.
> 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
> > ... Dependencies::has_finalizable_subclass() ->
> > 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