Memory Leak issue

First of all I seriously doubt Idea uses internal frames. Where would it be using it? What frame in Idea can you drag around within another window?

By "windows" look and feel do you mean the "Idea" look and feel (the default)? Or do you actually mean the windows look and feel?

Kirk

Hezekiel wrote:

A question to IDEA Developers:
Does IDEA use InternalFrames?

No. IDEA doesn't use internal frames

Have you profiled the IDEA and noticed the memory leak?

Periodically we are profiling IDEA and found memory leaks in Swing. In
general we are fixing it by ourself (leflection, workaronuds, etc).

> Have you contacted SUN or submitted a bug report?

Of course, we are posting bug to SUN but actually it's useless.
Personally I've posted about 10 bug and no one has been fixed yet.

Best regards,
Vladimir Kondratyev
_____________________
JetBrains

This seems very frustrating to me. We are supposed to implement windows applications with Java and even the basic functionality is broken.

Here's an example of SUN code that clearly shows one of the bugs. (It's still not fixed)

 public class WindowsDesktopManager extends
> DefaultDesktopManager implements java.io.Serializable
> {
>   /* The frame which is currently selected/activated.
>    * We store this value to enforce MDI's single-selection
> model.
>    */
>   JInternalFrame currentFrame;
>   JInternalFrame initialFrame;	  
> 
>   public void activateFrame(JInternalFrame f)
>   {
>     try
>     {
>       super.activateFrame(f);
>       if (currentFrame != null && f != currentFrame)
>       {
>         // If the current frame is maximized,transfer that 
>         // attribute to the frame being activated.
>         if (currentFrame.isMaximum() &&
>             (f.getClientProperty("JInternalFrame.frameType") !=
> 		    "optionDialog") )
>         {
>           currentFrame.setMaximum(false);
>           f.setMaximum(true);
>         }
>         if (currentFrame.isSelected())
>         {
>           currentFrame.setSelected(false);
>         }
>       }
> 
>       if (!f.isSelected())
>       {
>         f.setSelected(true);
>       }
>       currentFrame = f;
>     } 
>     catch (PropertyVetoException e) {}
>   }
> }
> ]]>

Notice that the currentFrame variable is never cleared! Even if you close/dispose/destroy/whatever the InternalFrame the Desktop component will have a reference to it. So it's never GC:d.

There are lots of other bugs too. I know this becouse I tried to overcome this problem by using reflection to null that currentFrame reference after the InternalFrame was disposed. Still the only way to run our app which uses internal frames is to use Java look and feel + this code snippet in overridden dispose method of InternalFrame

 ((ActionMap)UIManager.getLookAndFeelDefaults().get
> ("InternalFrame.actionMap")).remove( "showSystemMenu" );
> ]]>

Any updates?

Hello JameelH 

This thread is quite old and refers to a Swing bug in the Windows Look & Feel implementation of JDK 1.4 (specifically WindowsDesktopManager + JDesktopPane/JInternalFrame). IntelliJ IDEA itself has never used JInternalFrames in its UI, so this particular leak never affected the IDE directly.

In modern IntelliJ-based IDEs, the underlying Swing implementation in the JetBrains Runtime (the bundled JDK) has also been updated, so closed internal frames are eligible for garbage collection and the concrete leak shown in the original code snippet no longer exists.

If you are seeing memory growth in a current IDE version, it’s very likely a different issue; please create a new support request with logs (Help | Collect Logs and Diagnostic Data) and, if possible, a heap dump, attach the zip file via our secure upload site https://uploads.jetbrains.com/, and share the uploadID so we can investigate that specific case.