On Wed, Oct 11, 2017 at 12:29 AM, Kirk Pepperdine <[email protected]> wrote:
> Not at all off topic… first, thread dumps lie like a rug… and here is why…
>
> for each thread {
> safe point
> create stack trace for that thread
> release threads from safe point
> }
>
> And while rugs may attempt to cover the debris that you’ve swept under
> them, that debris leaves a clearly visible lump that suggests that you have
> a congestion problem on locks in both sun.security.provider.Sun and
> java.lang.Class…. What could possibly go wrong?
>
Interesting. I remember investigating this back in the Java 6 days and at
that time 'jstack -l' caused a global safepoint before iterating over the
threads, and then only resumed upon completion (implemented by
VM_ThreadDump in vm_operations.cpp). It appears that in JDK 7 this was
switched over to the behavior that you describe.
Either way, I'm looking at about 10 stack traces taken over a period of 3
minutes and they have 100% identical "java-level deadlock" output. So I
suppose it's possible that they are live-locked on the same sets of locks
in the exact same threads but seems fairly unlikely.
As for the congestion problem, I did find this JDK bug the other day:
https://bugs.openjdk.java.net/browse/JDK-8133070 which aims to reduce
contention, but no mention of a deadlock. We'll probably ask the customer
to bump to a newer JDK with this fix and see if it magically goes away.
-Todd
--
You received this message because you are subscribed to the Google Groups
"mechanical-sympathy" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
