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

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

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

dean.long
 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?

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

Reply | Threaded
Open this post in threaded view
|

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

Vitaly Davidovich
On Thu, Nov 2, 2017 at 10:03 PM <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

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

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

>
> On Thu, Nov 2, 2017 at 10:03 PM <[hidden email]
> <mailto:[hidden email]>> 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