On Fri, 23 Jan 2026 10:51:04 GMT, Daniel Fuchs <[email protected]> wrote:
>> This test has been observed failing intermittently in the CI, either in
>> JTreg timeout, where the test passes successfully after the timeout has
>> fired but while the failure handlers are still executing, or with an
>> `SSLHandshakeException` caused by `"An established connection was aborted by
>> the software in your host machine"`.
>>
>> This test creates 500 clients and relies on the GC to close them (by
>> design), because it wants to catch bugs where clients would be GC'ed too
>> early. However, relying on the GC to close the clients can put pressure on
>> resource allocation on the machine, which we suspect is the cause for the
>> slow down and the test failures. @Michael-Mc-Mahon suggested we could try to
>> relieve the pressure by making explicit calls to `System.gc()`, in the hope
>> to reclaim the abandonned clients earlier.
>>
>> This changes implements the suggestion by making calls to `System.gc()` at
>> random interval from a separate thread, and converts the test to JUnit,
>> making it stop at the first failure (which otherwise has a frustrating
>> tendency to disappear in the JTreg Output Overflow).
>>
>> With that change, I have not been able to observe the test failing again.
>
> Daniel Fuchs has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Review feedback
> Hello Daniel, this looks OK to me. The GC trigger appears a slightly
> involved. Maybe we could have just done the following in that GCTrigger
> thread:
>
> ```java
> while (!stop) {
> ForceGC.waitFor(() -> false, 500); // keep initiating GC
> }
> ```
We don't want this thread to keep on invoking GC in a busy loop - so I'd prefer
to keep the current implementation that triggers the GC a few times. FWIW with
the current setting (the gcinterval of 500ms passed to GCTrigger) and when the
test doesn't encounter unexpected slow downs I see that the System.gc() is
triggerred ~ 4 times in the course of the test execution. Since I wasn't able
to reproduce the test error with that settings I'd say we reached the sweet
spot :-)
-------------
PR Comment: https://git.openjdk.org/jdk/pull/29366#issuecomment-3791028660
