On Fri, 23 Jan 2026 21:56:06 GMT, Damon Nguyen <[email protected]> wrote:
> This failing test has been untouched for years and has recently started > failing with OOME. In addition, the test is failing pretty frequently and > causing a lot of noise. It failed on multiple different machines as well. > > There seems to be a lot of byte arrays that looks like is causing the issue. > To increase stability, I have gone ahead and reduced the `endTime` duration > from 10 seconds to 5 seconds, which should be enough. > > I have run the test on all OS's with 100 repeats after the changes and the > test passed on all runs. FWIW I asked a couple of VM/GC people about this as soon as it was observed because nothing changed in Swing around this time. The upshot is that although one G1 fix might have pushed things over the edge, this test was already tottering on the brink. The GC folks noted that if you increased the time, then it would OOM even before the G1 change and that OOME was also observed parallel GC also could cause an OOME. The obvious issue is that we generate a lot of byte[] data and that contributes to it but I think there's a more pertinent reason. Also they pointed out that there are a LOT of sun.awt.EventQueueItems. I took a look and so far as I can tell, this isn't a "leak", its just how JFileChooser works. This is because JFileChooser has FileLoader create file system events when JFileChooser is created. It is batched but even so there's lots of them when you see that the test also serializes / deserializes so it is done multiple times per iteration.I observed about 70 such events for each loop iteration. It seems the EventQueue can't process these events as fast as they are generated, so a back log builds up. And gets worse over time. Eventually because these haven't been processed, they can't be GC'd and we get OOME. Hundreds of thousands, or even millions of JFileChooser instances in a few seconds is not a real scenario. So I think it is quite legitimate to reduce the running time to reduce the likelihood of OOME. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29395#issuecomment-3801244484
