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

[Sergey Bylokhov]

On 19.09.16 23:02, Andy Lee wrote:
> 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.

Can you place the code which uses JFrame somewhere? It seems that some 
of the related bugs were not backported, like:
https://bugs.openjdk.java.net/browse/JDK-8156116

I will check which one.

>
> 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 <mailto: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>
>         <mailto: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>
>                 <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.
>
>


-- 
Best regards, Sergey.