> 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
