RFR: 8285503: SwingNodeDnDMemoryLeakTest::testSwingNodeMemoryLeak fails sometimes

[Kevin Rushforth]

On Thu, 10 Nov 2022 12:01:53 GMT, Ajit Ghaisas <aghaisas at openjdk.org> wrote:

> Root cause: The test unreliability comes from the 250ms sleep between `System.gc()` calls.
> Other system tests such as `TabPaneHeaderLeakTest`, `AccordionTitlePaneLeakTest` and `ShapeViewOrderLeakTest` etc sleep for 500ms between `System.gc()` calls.
> 
> Fix:
> - Increased the sleep time to 500ms between `System.gc()` calls.
> - Reduced the number of SwingNodes by half as an additional step towards making the test lighter.
> 
> Testing: This test used to fail on my macBook all the time if ran as part of a full system test run. I executed full test runs 5 times with above changes and no failure was observed.

I left a comment inline recommending to revert one part of your change.

I verified that the test always fails on my Mac without your fix, and passes with your fix (I ran it in a loop 20 times with the number of swing nodes reverted back to 10). So this simple fix is fine, and as you note, brings this test in line with other tests that manually check for leaks. I still think we could make _all_ of our memory leak tests more robust by using JMemoryBuddy. Can you file a follow-up bug to do that?

tests/system/src/test/java/test/javafx/embed/swing/SwingNodeDnDMemoryLeakTest.java line 52:

> 50: public class SwingNodeDnDMemoryLeakTest {
> 51: 
> 52:     final static int TOTAL_SWINGNODE = 5;

I don't think this change is necessary. The test will take no more time with 10 nodes than it will with 5, since the GC loop with the sleep is not dependent on the number of nodes.

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

PR: https://git.openjdk.org/jfx/pull/946