Hi, Andy.
You code lack of Frame.dispose(), so the frames are shown forever. You can update the test by these lines:
        frm.setVisible(true);
+        try {
+            Thread.sleep(1000);
+        } catch (InterruptedException e) {
+            e.printStackTrace();
+        }
+        frm.dispose();

And it will pass after some period of time on jdk8u112, and fails on jdk8u101. Can you please double check?

On 20.09.16 15:43, Andy Lee wrote:
Here is my test code that demonstrates the
leak: http://bonuslord.github.io/misc/FrameLeakDemo.java

In JDK 8 the output indicates 3 frames remaining even after closing all
of the JFrames.
In JDK 9 the output usually reports 1 frame remaining after closing all
of the frames, although sometimes all 3 JFrames get properly GC'd and
the output reports 0.

On Mon, Sep 19, 2016 at 4:08 PM, Sergey Bylokhov
<sergey.bylok...@oracle.com <mailto:sergey.bylok...@oracle.com>> wrote:

    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
    <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.bylok...@oracle.com <mailto:sergey.bylok...@oracle.com>
        <mailto:sergey.bylok...@oracle.com
        <mailto: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>
        <mailto:sergey.bylok...@oracle.com
        <mailto:sergey.bylok...@oracle.com>>
                <mailto:sergey.bylok...@oracle.com
        <mailto:sergey.bylok...@oracle.com>

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




--
Best regards, Sergey.

Reply via email to