RFR: 8342857: SA: Heap iterator makes incorrect assumptions about TLAB layout

[Chris Plummer]

On Wed, 23 Oct 2024 11:39:26 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> When testing Lilliput we found a failure in `serviceability/sa/ClhsdbJstackWithConcurrentLock.java` test when running with C1-only.
> 
> The test uses the SA's thread printing feature to print the threads *and* the "concurrent locks" / AbstractOwnableSynchronizers. It then verifies that the expected lock is listed in the section for "Locked ownable synchronizers".
> 
> When we turned on Lilliput's -XX:+UseCompactObjectHeaders this stopped working, and we got nothing reported in that section:
> 
> 
> "Thread-0" #31 prio=5 tid=0x00007a708c259ad0 nid=1480533 waiting on condition [0x00007a706fefe000]
>    java.lang.Thread.State: TIMED_WAITING (sleeping)
>    JavaThread state: _thread_blocked
>  - java.lang.Thread.sleepNanos0(long) @bci=0 (Interpreted frame)
>  - java.lang.Thread.sleepNanos(long) @bci=33, line=497 (Interpreted frame)
>  - java.lang.Thread.sleep(long) @bci=25, line=528 (Interpreted frame)
>  - LingeredAppWithConcurrentLock.lockMethod(java.util.concurrent.locks.Lock) @bci=13, line=38 (Interpreted frame)
> 	- locked <0x00000000ffd32d88> (a java.util.concurrent.locks.ReentrantLock)
>  - LingeredAppWithConcurrentLock.lambda$main$0() @bci=3, line=46 (Interpreted frame)
>  - LingeredAppWithConcurrentLock$$Lambda+0x00007a7023001000.run() @bci=0 (Interpreted frame)
>  - java.lang.Thread.runWith(java.lang.Object, java.lang.Runnable) @bci=5, line=1589 (Interpreted frame)
>  - java.lang.Thread.run() @bci=19, line=1576 (Interpreted frame)
> 
> Locked ownable synchronizers:
>     - None
> 
> 
> It should be saying:
> 
> Locked ownable synchronizers:
>     - <0x00000000ffd32d88>, (a java/util/concurrent/locks/ReentrantLock$NonfairSync)
> 
> 
> The problem lies within the code that searches for objects in the heap. It collects a bunch of regions and searches them for objects. However, the code that describes the TLAB regions are stale and doesn't match the C++ implementation in the JVM. When Lilliput shrinks the headers the SA code is broken enough to cause the TLAB regions to be reported as overlapping. This has ripple effects that the object iterators stop working.
> 
> I can get this test to pass, with and without compact object headers, by fixing the code in  `ThreadLocalAllocBuffer::hard_end()`.
> 
> This is a reproducer of the problem:
> 
> make -C ../build/fastdebug test TEST=serviceability/sa/ClhsdbJstackWithConcurrentLock.java JTREG="JAVA_OPTIONS=-XX:TieredStopAtLevel=2 -XX:+UnlockExperimentalVMOptions -XX:+UseCompactObjectHeaders"
> 
> 
> I've tested this by running all 'serviceability' tests in our tier1-9 testing.

Changes requested by cjplummer (Reviewer).

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/VM.java line 443:

> 441: 
> 442:        Type collectedHeap = db.lookupType("CollectedHeap");
> 443:        CIntegerType sizeType = (CIntegerType) db.lookupType("size_t");

I think you can use getSizet() here.

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

PR Review: https://git.openjdk.org/jdk/pull/21662#pullrequestreview-2390075171
PR Review Comment: https://git.openjdk.org/jdk/pull/21662#discussion_r1813440444