RFR: 8247514: Improve clhsdb 'findpc' ability to determine what an address points to by improving PointerFinder and PointerLocation classes

[Chris Plummer]

On Wed, 10 Feb 2021 17:52:59 GMT, Kevin Walls <kevinw at openjdk.org> 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 at 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