On Tue, 2 Jun 2026 21:39:07 GMT, Leonid Mesnik <[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. 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. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/31355#discussion_r3345000108
