On Tue, 2 Jun 2026 20:26:24 GMT, Chris Plummer <[email protected]> wrote:
> Most SA tests rely on the debuggee basically being idle and not doing things > like triggering a GC. Unfortunately this cannot be 100% guaranteed. One issue > is with LingeredApp.main(), which wakes up from sleep every second to touch > the lock file. This could generate a small amount of garbage which could > trigger a GC. This normally never happens, but we were seeing a case where it > did if CDS was disabled. Forcing a GC before the loop seems to fix the issue. > > Tested with svc CI testing in all tiers. Also ran SA tests a large number of > times with and without the fix, and it seems to be reliable. > > --------- > - [x] I confirm that I make this contribution in accordance with the [OpenJDK > Interim AI Policy](https://openjdk.org/legal/ai). test/lib/jdk/test/lib/apps/LingeredApp.java line 647: > 645: } > 646: // Force a GC now to reduce the risk of one happening > during the loop below. > 647: System.gc(); 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. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/31355#discussion_r3344580036
