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