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();
Advertising
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.
