RFR: 8323680: SA PointerFinder code can do a better job of leveraging existing code to determine if an address is in the TLAB [v2]
Chris Plummer
cjplummer at openjdk.org
Fri Feb 2 20:44:04 UTC 2024
On Fri, 26 Jan 2024 21:20:04 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)
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
>
> Get rid of inTLAB field. Not needed
Thanks for the reviews Kevin and Seguei!
-------------
PR Comment: https://git.openjdk.org/jdk/pull/17494#issuecomment-1924667202
More information about the serviceability-dev
mailing list