jdk icon indicating copy to clipboard operation
jdk copied to clipboard

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

Open stefank opened this issue 4 months ago • 4 comments

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.


Progress

  • [x] Change must be properly reviewed (1 review required, with at least 1 Reviewer)
  • [x] Change must not contain extraneous whitespace
  • [x] Commit message must refer to an issue

Issue

  • JDK-8342857: SA: Heap iterator makes incorrect assumptions about TLAB layout (Bug - P4)

Reviewers

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/21662/head:pull/21662
$ git checkout pull/21662

Update a local copy of the PR:
$ git checkout pull/21662
$ git pull https://git.openjdk.org/jdk.git pull/21662/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 21662

View PR using the GUI difftool:
$ git pr show -t 21662

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/21662.diff

Webrev

Link to Webrev Comment

stefank avatar Oct 23 '24 11:10 stefank