[Rev 01] RFR: 8236259: MemoryLeak in ProgressIndicator

Kevin Rushforth kcr at openjdk.java.net
Tue Feb 4 23:19:24 UTC 2020

On Mon, 27 Jan 2020 15:26:48 GMT, Florian Kirmaier <fkirmaier at openjdk.org> wrote:

>> The use of static analysis tools to catch certain types of problems is orthogonal to a regression test to validate a bug fix of a specific memory leak.
>> @FlorianKirmaier as mentioned previously, please file a new JBS Enhancement to propose adding a test utility for memory leak test. You can then start a discussion on the openjfx-dev mailing list.
>> As for fixing this memory leak, I recommend one of the following two approaches:
>> 1. Modify the PR without relying on any new utilities (meaning you would create yet-another adhoc test for memory leaks).
>> 2. Close this PR, wait for memory leak test utility to be integrated, and then resubmit the PR for this leak using that utility.
>> Obviously, approach 1 would get the fix in faster. You could then modify the test to use the new utility as part of implementing the utility.
> A little bit late ...
> I have now removed unit-test and it's dependency.
> I will add a ticket about adding them again.

Rather than removing the test, I was suggesting that you create a test for memory leaks using the same ad hoc approach that our other memory leak tests use. This could later be modified to use the new GC test utility as part of creating that utility. The pattern used in, for example, [TabPaneHeaderLeakTest.java](https://github.com/openjdk/jfx/blob/master/tests/system/src/test/java/test/javafx/scene/control/TabPaneHeaderLeakTest.java), works well enough, even though it repeats a fair amount of boilerplate code.


PR: https://git.openjdk.java.net/jfx/pull/71

More information about the openjfx-dev mailing list