<AWT Dev> Best workaround for OSX Window leak? (JDK-8029147)

[Andy Lee]

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.Bylokhov at 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.Bylokhov at oracle.com <mailto:Sergey.Bylokhov at 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20160919/9b38034d/attachment.html>