On Tue, 2 Jun 2026 23:14:37 GMT, Chris Plummer <[email protected]> wrote:
>> 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.
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.)
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/31355#discussion_r3346913026
