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

Stefan Karlsson stefank at openjdk.org
Thu Oct 24 19:09:42 UTC 2024


> 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.

Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:

  Cleanups

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21662/files
  - new: https://git.openjdk.org/jdk/pull/21662/files/3f50944e..adc7d755

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21662&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21662&range=02-03

  Stats: 41 lines in 1 file changed: 17 ins; 18 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/21662.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21662/head:pull/21662

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


More information about the hotspot-gc-dev mailing list