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.
-------------
Commit messages:
- 8342857: SA: Heap iterator makes incorrect assumptions about TLAB layout
Changes: https://git.openjdk.org/jdk/pull/21662/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21662&range=00
Issue: https://bugs.openjdk.org/browse/JDK-8342857
Stats: 13 lines in 3 files changed: 11 ins; 0 del; 2 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
