RFR: 8323680: SA PointerFinder code can do a better job of leveraging existing code to determine if an address is in the TLAB
Kevin Walls
kevinw at openjdk.org
Fri Jan 26 17:08:24 UTC 2024
On Thu, 18 Jan 2024 22:54:26 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:
> 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)
Looks good to me.
(Not critical, but maybe PointerLocation doesn't need the boolean inTlab. It could use that its tlab is not null, like the isInHeap/stack/metadata checks that something is not null.)
-------------
Marked as reviewed by kevinw (Committer).
PR Review: https://git.openjdk.org/jdk/pull/17494#pullrequestreview-1846152245
More information about the serviceability-dev
mailing list