In JDK 9 the problem seems to be partially fixed; only the most recently closed JFrame leaks (ie, a temporary leak). I was unable to get Visual VM to connect to the Java 9 process so I'm not exactly sure what was preventing the last JFrame from being GC'd.
The Java 9 behavior would be sufficient to solve most of our major issues, but it will be quite some time before it becomes feasible to move our application to Java 9 so it doesn't really help us. On Mon, Sep 19, 2016 at 2:51 PM, Sergey Bylokhov <sergey.bylok...@oracle.com > wrote: > On 19.09.16 19:13, Andy Lee wrote: > >> Yes, I just tried my test case on JDK 8u112 and I can still reproduce >> the JFrame leak. >> > > And what about the latest jdk9? > https://jdk9.java.net/download > > >> On Mon, Sep 19, 2016 at 11:26 AM, Sergey Bylokhov >> <sergey.bylok...@oracle.com <mailto:sergey.bylok...@oracle.com>> wrote: >> >> Hi, Andy. >> I suggest to check the latest jdk9 and jdk8. Do you able to >> reproduce this bug on jdk8u112? >> >> >> On 19.09.16 17:19, Andy Lee wrote: >> >> Not sure if this is the best place to ask, but I'm looking for >> good way >> to prevent the JFrame/JDialog memory leaks caused >> by https://bugs.openjdk.java.net/browse/JDK-8029147 >> <https://bugs.openjdk.java.net/browse/JDK-8029147> >> >> The best solution I've found so far is to use reflection to dig >> in and >> null out the 'target' fields on the LWComponentPeer and >> CPlatformWindow >> after disposing. This at least allows the JDialog/JFrame >> instance to be >> GC'd (along with any heavier objects they may reference), but >> isn't >> optimal since ultimately the LWComponentPeer and CPlatformWindow >> instances still end up leaking. Another problem with this >> approach is >> that we have hundreds of uses of JFrames/JDialogs across our >> codebase >> and this workaround would require each one of them to be >> modified to add >> this special cleanup logic; I'd like to avoid that if at all >> possible~ >> >> Any suggestions? >> >> ~Andy Lee >> >> >> >> -- >> Best regards, Sergey. >> >> >> > > -- > Best regards, Sergey. >