On Fri, 20 Dec 2019 13:26:05 GMT, Kevin Rushforth <k...@openjdk.org> wrote:
>> I highly doubt that a code analysis tool will find such memoryleaks. > > I agree. Static analysis tools are quite limited in this regard, and are in > now way a substitute for regression testing. > > So the question is how best to test fixes for memory leaks at runtime. Our > current approach can be best characterized as "ad hoc", and is not all that > robust (although works well enough in most cases and is still much better > than doing no testing at all). I would welcome discussion of a more robust > approach for testing, but it should be decoupled from this bug fix, and > discussed as a separate JBS Enhancement request. 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. ------------- PR: https://git.openjdk.java.net/jfx/pull/71
