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.