Skip to content

8385723: Intermittent failure of serviceability/sa/ClhsdbInspect.java #31355

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
plummercj wants to merge 1 commit into
base: master
Choose a base branch
from
+2 −0
Open

8385723: Intermittent failure of serviceability/sa/ClhsdbInspect.java #31355

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 2 additions & 0 deletions test/lib/jdk/test/lib/apps/LingeredApp.java
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -643,6 +643,8 @@ public static void main(String args[]) {
crasher.run();
}
}
// Force a GC now to reduce the risk of one happening during the loop below.
System.gc();
Copy link
Copy Markdown
Member

@lmesnik lmesnik Jun 2, 2026 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The fix looks correct.
There are few comments to consider:

  1. Wouldn't it makes a to try to test if issue is reproducible with other GC?
  2. Does it makes to don't it makes sense to start app with '-XX:-DisableExplicitGC'?
  3. Run GC several times to try to push object into old generation.
  4. Re-write loop to create less number of object to minimize GC triggering.

Like

File theLockFile = <file from theLockFileName>;
System.gc();
while (Files.exists(path)) {
          // Touch the lock to indicate our readiness
          theLockFiles.etLastModified(theLockFile, epoch());
          isReady = true;
          Thread.sleep(spinDelay);
      }
}

These are just fix to consider, I am ok to first try to push your fix and improve it only we still these failures.

Copy link
Copy Markdown
Contributor Author

@plummercj plummercj Jun 2, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  1. I did run CI testing that I believe includes using different GCs.
  2. Are you suggesting that we don't run the test if -XX:-DisableExplicitGC is used? I don't think it is a goal to have tests defend against all possible flags that might disrupted it.
  3. I actually started with 3 GCs. That worked, so I tried just one and it worked just as well. I'm not a GC expert, so I'm not really sure of the full impact these forced GCs have on the java heap. Maybe @albertnetymk can answer.
  4. I think the real issue is that without a forced GC, we might end up on the edge of doing a GC when entering the loop, so could easily trigger one with a few small allocations. With a GC done first, I don't see this loop ever producing enough garbage to trigger another GC. The test will time out first.

Copy link
Copy Markdown
Member

@albertnetymk albertnetymk Jun 3, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In this context, one System.gc() should be enough to dodge the disturbing GC btw two consecutive debugger commands. (Using WB_FullGC would guard ourselves from XX:-DisableExplicitGC, but this workaround is good enough, IMO.)

while (Files.exists(path)) {
// Touch the lock to indicate our readiness
setLastModified(theLockFileName, epoch());
Expand Down