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
> 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?
>> 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
>> 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
>> after disposing. This at least allows the JDialog/JFrame
>> instance to be
>> GC'd (along with any heavier objects they may reference), but
>> 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
>> 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
>> Any suggestions?
>> ~Andy Lee
>> Best regards, Sergey.
> Best regards, Sergey.