On Wed, 23 Oct 2024 11:39:26 GMT, Stefan Karlsson <stef...@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. This pull request has now been integrated. Changeset: 3c5db12b Author: Stefan Karlsson <stef...@openjdk.org> URL: https://git.openjdk.org/jdk/commit/3c5db12bbe4d1155ab874c2862005621c6b8541d Stats: 46 lines in 3 files changed: 23 ins; 13 del; 10 mod 8342857: SA: Heap iterator makes incorrect assumptions about TLAB layout Reviewed-by: cjplummer, rkennke, lmesnik ------------- PR: https://git.openjdk.org/jdk/pull/21662
