On Wed, 10 Feb 2021 17:52:59 GMT, Kevin Walls <[email protected]> wrote:
>> See the bug for most details. A few notes here about some implementation >> details: >> >> In the `PointerLocation` class, I added more consistency w.r.t. whether or >> not a newline is printed. It used to for some address types, but not others. >> Now it always does. And if you see a comment something like the following: >> >> ` getTLAB().printOn(tty); // includes "\n" ` >> >> That's just clarifying whether or not the `printOn()` method called will >> include the newline. Some do and some don't, and knowing what the various >> `printOn()` methods do makes getting the proper inclusion of the newline >> easier to understand. >> >> I added `verbose` and `printAddress` boolean arguments to >> `PointerLocation.printOn()`. Currently they are always `true`. The false >> arguments will be used when I complete >> [JDK-8250801](https://bugs.openjdk.java.net/browse/JDK-8250801), which will >> use `PointerFinder/Location` to show what each register points to. >> >> The CR mentions that the main motivation for this work is for eventual >> replacement of the old clhsdb `whatis` command, which was implemented in >> javascript. It used to resolve DSO symbols, whereas `findpc` did not. The >> `whatis` code did this with the following: >> >> var dso = loadObjectContainingPC(addr); >> if (dso == null) { >> return ptrLoc.toString(); >> } >> var sym = dso.closestSymbolToPC(addr); >> if (sym != null) { >> return sym.name + '+' + sym.offset; >> } >> And now you'll see something similar in the PointerFinder code: >> >> loc.loadObject = cdbg.loadObjectContainingPC(a); >> if (loc.loadObject != null) { >> loc.nativeSymbol = loc.loadObject.closestSymbolToPC(a); >> return loc; >> } >> Note that now that `findpc` does everything that `whatis` used to (and >> more), we don't really need to add a java version of `whatis`, but I'll >> probably do so anyway just help out people who are used to using the >> `whatis` command. That will be done using >> [JDK-8244670](https://bugs.openjdk.java.net/browse/JDK-8244670) > > src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/PointerLocation.java > line 247: > >> 245: stackThread.getStackBase(), >> stackThread.lastSPDbg(), >> 246: >> stackThread.getStackBase().addOffsetTo(-stackThread.getStackSize()), >> 247: stackThread); > > When we print a JavaThread, in the verbose block, > the final argument to tty.format in line 247, I wonder what that prints? > > We then call printThreadInfoOn() which will first print the quoted thread > name, > so maybe we don't need that item. > Or maybe we want the JavaThread.toString()? `stackThread.toString()` ends up in `VMObject.toString()`: public String toString() { return getClass().getName() + "@" + addr; } And here's an example output: hsdb> + findpc 0x0000152f45df6000 Address 0x0000152f45df6000: In java stack [0x0000152f45df8000,0x0000152f45df6580,0x0000152f45cf7000] for thread sun.jvm.hotspot.runtime.JavaThread@0x0000152f3c026f70: "main" #1 prio=5 tid=0x0000152f3c026f70 nid=0x308e waiting on condition [0x0000152f45df6000] java.lang.Thread.State: TIMED_WAITING (sleeping) JavaThread state: _thread_blocked So I think the `stackThread` argument is doing what was intended, and there is no duplication in the output. ------------- PR: https://git.openjdk.java.net/jdk/pull/2111
