RFR: 8323680: SA PointerFinder code can do a better job of leveraging existing code to determine if an address is in the TLAB

[Chris Plummer]

In PointerFinder.java we have some code to determine if a pointer is in a TLAB, but it only executes for the SerialGC. It should work for all GCs, so I moved the code out of the SerialGC block.

I also cleaned up the printing in PointerLocation. java a bit so when not using verbose mode not as much info about the tlab address is printed. This is consistent with other addresses, such as java stack addresses, which is what I modeled this change on.

It's hard to test this change since it is hard to consistently get an address to be in the tlab. I wrote a little test program that just sits in a loop doing allocations. I attached to it with clhsdb and ran the threadcontext command, which does a fincpc on each register. About half the time the main thread was suspended in a frame where some registers where pointing into the tlab, and I confirmed this was the case for both SerialGC and G1. Here's an example of one register with verbose off and verbose on:

rsi: 0x000000008a5d4448: In TLAB for thread "main" sun.jvm.hotspot.runtime.JavaThread at 0x00007ffa24029000

rsi: 0x000000008a5d4448: In TLAB for thread ("main" #1 prio=5 tid=0x00007ffa24029000 nid=25392 runnable [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE
   JavaThread state: _thread_in_java
)  [0x000000008a5d4448,0x000000008ab724b8,0x000000008b0c0250,{0x000000008b0c0490})

For testing I ran all tier1, tier2, and tier5 svc tests (still in progress)

-------------

Commit messages:
 - better tlab support in PointerFinder and PointerLocation

Changes: https://git.openjdk.org/jdk/pull/17494/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17494&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8323680
  Stats: 55 lines in 2 files changed: 26 ins; 21 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/17494.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17494/head:pull/17494

PR: https://git.openjdk.org/jdk/pull/17494