[Rev 01] RFR: 8236259: MemoryLeak in ProgressIndicator

[Eric Bresie]

Would it just be better to run some code analysis tools on the code base to hunt for these? Like maybe sonarqube integratedas part of CI build analysis?

Eric Bresie
Ebresie at gmail.com
> On December 19, 2019 at 4:23:14 PM CST, Florian Kirmaier <fkirmaier at openjdk.java.net> wrote:
> On Thu, 19 Dec 2019 19:59:07 GMT, David Grieve <dgrieve at openjdk.org> wrote:
>
> > > Yes, exactly.
> > >
> > > @FlorianKirmaier Proposing to add test class to the test infrastructure would be a reasonable alternative to pulling it in as a third-party dependency. I recommend separating it out into its own enhancement, with a separate JBS issue. I see that it has a dependency on the `jdk.management` module. As long as that dependency only surfaces as a test dependency, that won't be a problem. It would be nice if it were available to all modules, meaning that putting it somewhere in `javafx.base` would be good.
> >
> > I would urge caution about incorporating JMemoryBuddy without seeking out advice from GC experts. I have my doubts that it will work reliably given its reliance on System.gc(). (Opinion is my own, not my employer's).
>
> @dsgrieve
> It's worth mentioning that JavaFX already has many tests based on System.gc().
> An advantage of having a testsuit as an library (or copyied from an library) is, that its stability is regulary verified by the travis builds for different JVMs.
> The alternative would be to not test for memory-leaks at all which is much worse than having slightly unstable tests.
> Maybe it can make sense to seperate these tests for leaks in an own testgroup.
>
> I'm introducing this library in more and more projects. I never had problems with unstable tests.
> I only had this kind of problem when I wrote the WeakReference/System.gc/sleep-logic for every single test.
>
> -------------
>
> PR: https://git.openjdk.java.net/jfx/pull/71