RFR: 8296919: Make system tests that detect memory leaks more robust by using JMemoryBuddy utility [v4]

Lukasz Kostyra lkostyra at openjdk.org
Fri May 5 06:33:24 UTC 2023


On Thu, 4 May 2023 15:30:20 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> tests/system/src/test/java/test/javafx/embed/swing/SwingNodeMemoryLeakTest.java line 80:
>> 
>>> 78:         });
>>> 79: 
>>> 80:         SwingUtilities.invokeAndWait(() -> Util.sleep(500));
>> 
>> Sleeping on either the JavaFX Application thread or the Swing EDT (as in this case) is not generally desirable. What is the sleep trying to achieve? Is there a better way, possibly sleeping on the test thread and then doing a `SwingUtilities.invokeAndWait` (maybe with a no-op runnable? not sure)?.
>
> I can't believe I missed that!
> I wonder if we could use CountDownLatch instead here and use Util.await(CountDownLatch) or something like that.

This is something that came from the original patch - I'm no Swing expert so I originally figured I should leave it here. My only guess was that it (among other `Thread.sleep()`-s in this patch) is trying to let the other threads run for a bit and chew through the resources to make sure they're collectable.

Upon closer inspection it looks like JMemoryBuddy is already doing those sleeps, so I'll remove them - tests should work fine without those.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1121#discussion_r1185739169


More information about the openjfx-dev mailing list