Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8365057

Add support for java.util.concurrent lock information to Thread.dump_to_file

XMLWordPrintable

    • Icon: Enhancement Enhancement
    • Resolution: Unresolved
    • Icon: P2 P2
    • None
    • None
    • hotspot
    • None
    • svc
    • 21
    • generic
    • generic

      Thread.dump_to_file supports (as of JDK-8356870) dumping of intrinsic lock (monitor enter/exit) information, but java.util.concurrent (j.u.c) lock information is not included. A way to collect j.u.c lock information and include it in the dump should be provided.

      Concerns have been raised about the additional overhead collecting this information may add. The latency implications of requiring a STW pause and iterating the Java heap mean that inclusion of j.u.c lock information should be an opt-in feature.

      One possible solution would be to add a “-l” option to Thread.dump_to_file. This is analogous to how Thread.print behaves today:
      ===
      $ jcmd Sleeper help Thread.print
      130527:
      Thread.print
      Print all threads with stacktraces.

      Impact: Medium: Depends on the number of threads.

      Syntax : Thread.print [options]

      Options: (options must be specified using the <key> or <key>=<value> syntax)
      -l : [optional] print java.util.concurrent locks (BOOLEAN, false)
      -e : [optional] print extended thread information (BOOLEAN, false)
      ===

      This way, only users who are willing to accept a (possibly significant) latency impact can choose to opt-in. For the default behavior (no j.u.c lock information), there should be no noticeable performance regression. As j.u.c lock information is often needed to troubleshoot completely hung applications, even a large pause will be acceptable for many scenarios.

      Without this information, it is very difficult to identify the root cause of hangs where a VT acquires a j.u.c lock and then unmounts from its carrier thread. Such “lost lock” situations have proven to be very problematic in the past and motivated the addition of j.u.c lock information to platform thread dumps (e.g. Thread.print) during the JDK 5 era (see JDK-5086470). The same motivations / tradeoffs apply here.

            Unassigned Unassigned
            dbuck David Buck
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated: