Bug ID: JDK-8069412 Locks need better debug-printing support

Type: Enhancement
Component: hotspot
Sub-Component: runtime
Affected Version: 9

Priority: P2
Status: Resolved
Resolution: Fixed
OS: generic
CPU: generic

Submitted: 2015-01-20
Updated: 2019-08-16
Resolved: 2015-02-17

JDK 8	JDK 9
8u60Fixed	9 b53Fixed

In a debugging thread stack trace, I get basic information about locks.
I want to know more (bias, etc).  What I get instead is 0x00007fe15e3434fa
Those bits means something, and there should be a print-something method
that decodes that in detail, rather than me picking through the bits myself.

Priority's high because I am spinning my wheels on another bug, I know of
no workaround, and my wheelspinning is 100% reproducible.

And also, if for some reason the VM is in a state where the information might not
be reliable, I don't want to be told I can't see it, I don't want an assert, I just want
to be warned that it might not be reliable -- because otherwise I am looking at it
in the debugger, and it's not any more reliable then, and I'm not even warned (and
on this bug in particular, I have 5 minutes to figure it out before the processes in the
swarm that reproduces it detect non-progress and conspire to take themselves out
in a  circular firing squad of process termination.  I need better logging.)

Are there any plans to make tests for this enhancement?
01-06-2015
Please add the missing functionality that you require.
26-01-2015
I was aware of that code. I made these changes in my area, together with a hacky tie-in to backtrace printing that needs to not be as hacky as what I wrote, plus conditional on "Verbose": void markOopDesc::print_on(outputStream* st) const { - if (is_locked()) { - st->print("locked(" INTPTR_FORMAT ")->", value()); - markOop((markOop)value())->print_on(st); - } else { - assert(is_unlocked() \|\| has_bias_pattern(), "just checking"); - st->print("mark("); - if (has_bias_pattern()) st->print("biased,"); - st->print("hash %#lx,", hash()); - st->print("age %d)", age()); - } + if (is_marked()) { + st->print(" marked(" INTPTR_FORMAT ")", value()); + } else if (is_locked()) { + st->print(" locked(" INTPTR_FORMAT ")->", value()); + if (is_neutral()) { + st->print(" is_neutral"); + if (has_no_hash()) st->print(" no_hash"); + else st->print(" hash=" INTPTR_FORMAT, hash()); + st->print(" age=%d", age()); + } else if (has_bias_pattern()) { + st->print(" is_biased"); + JavaThread* jt = biased_locker(); + st->print(" biased_locker=" INTPTR_FORMAT, p2i(jt)); + } else if (has_monitor()) { + ObjectMonitor* mon = monitor(); + if (mon == NULL) + st->print(" monitor=NULL"); + else st->print(" monitor={count="INTPTR_FORMAT",waiters="INTPTR_FORMAT",recursions="INTPTR_FORMAT"}", + mon->count(), mon->waiters(), mon->recursions()); + } else { + st->print("??"); + } + } else { + assert(is_unlocked() \|\| has_bias_pattern(), "just checking"); + st->print("mark("); + if (has_bias_pattern()) st->print("biased,"); + st->print("hash %#lx,", hash()); + st->print("age %d)", age()); + } } And this is still a problem, it is a problem for me, and nothing has changed. The debugger is not the best option for the bug I am working on; among other things, every process in the test is on the lookout for stuck siblings and takes them out, so all such work is time-limited. I'd like the option to log it, and I want the larger amount of information.
26-01-2015
See Coleen's comment.
26-01-2015
There is a markOop::print_on() function. You can call this from the debugger (if live). If it hangs or crashes, we may need to have some more checks against zero for robustness. void markOopDesc::print_on(outputStream* st) const { if (is_locked()) { st->print("locked(" INTPTR_FORMAT ")->", value()); markOop((markOop)value())->print_on(st); } else { assert(is_unlocked() \|\| has_bias_pattern(), "just checking"); st->print("mark("); if (has_bias_pattern()) st->print("biased,"); st->print("hash %#lx,", hash()); st->print("age %d)", age()); } }
26-01-2015
Yes is_locked is defined as !unlocked; which does cause the marked case to also be pulled in. Dave Dice may be able to shed more light on that specific aspect.
22-01-2015
There's another printing routine in the compiler world where, when I invoke it within the debugger, it hangs. I stepped through and it eventually grounded out in a piece of code that thought it would be a good idea to put the thread "in the right state". Not Very Useful. And the layout is "defined", sort of, in an instruction set for a very slow and flaky processor. As it stands, some of the predicates are willing to lie to you -- for example, is_locked() will return true for a bit pattern that is actually marked (perhaps this is intended behavior -- it's certainly not documented).
21-01-2015
At the risk of stating the obvious the layout of the object header is defined in markOop.hpp Regarding: "And also, if for some reason the VM is in a state where the information might not be reliable, I don't want to be told I can't see it, I don't want an assert, I just want to be warned that it might not be reliable" What specifically are you referring to?
21-01-2015
Right. I was getting this: at blah.blah.blah.net.socket.UdpSocket.send(UdpSocket.java:21) - waiting to lock <0x0000000780967378> (a java.net.DatagramPacket) I've enhanced it all the way up to lockbits= locked(0x00007fe15e3434fa)->?? - waiting to lock <0x00000007b1a77690> (a java.net.DatagramPacket) ?? means it's a bit pattern I have not yet handled. Apparently, it means "ObjectMonitor", which is "a very sensitive and fragile class" that ALSO lacks in sort of useful debug-printing support.
20-01-2015
I'm guessing that you mean Java Locks or Java Monitors and not VM internal locks or monitors.
20-01-2015