Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Critical Critical
    • Resolution: Cannot Reproduce
    • Affects Version/s: current
    • Fix Version/s: milestone 1
    • Component/s: www
    • Labels:
      None
    • Environment:

      Operating System: All
      Platform: All

    • Issuezilla Id:
      23

      Description

      After having solved a number of memory leaks in my application, I suddenly had
      one again after introducing jModalFrame.

      It is my impression that JMF registers itself with KeyboardFocusManager. KFM is
      a singleton, and registering an object as a PropertyChangeListener, but never
      unregistering, means that the listener is never garbage collected.

      After resolving a number of KeyboardFocusManager related memory leaks, I often
      resorted to the "middle man" approach. An middle man object registers itself to
      the KFM and has a soft/weak link to the actual listener (JMF in this case). If
      an event comes it, the middle man checks the link. If not null, it will forward
      the event. If null, it will deregister itself from the KFM, thus allowing for
      full garbage collection.

        Activity

        Hide
        jjasper added a comment -

        Which version are you using?

        The only object that registers itself with the KeyboardFocusManager is a
        singleton also.

        Which objects are causing the memory leak? Because I have tested your middle man
        approach to see if the JModalFrames themselves get garbage collected and they do.

        Show
        jjasper added a comment - Which version are you using? The only object that registers itself with the KeyboardFocusManager is a singleton also. Which objects are causing the memory leak? Because I have tested your middle man approach to see if the JModalFrames themselves get garbage collected and they do.
        Hide
        tbee added a comment -

        I have a master frame with a menu and on each menu action I open a new frame
        containing some GUI stuff. In my tests I opened 5 frames and then closed them
        again.

        If I extend JFrame, run a GC then a memory dump and profile it, I see 1
        instance of my frame; the reference is being held in the main window (it
        shouldn't, but it is correct according to the code).

        If I extend JModalFrame and do the same, the dump still contains all 5
        instances. When I profiled it, it appeared as though the PropertyChangeListener
        of the KFM was still referencing. And that is correct, I have had those
        memoryleaks myself.
        If you register a frame as a PCL to the KFM, it will keep a strong reference
        until it is deregistered. Since KeyboardFocusManager never goes out of scope...

        Hm.

        Or maybe in my system it doesn't. It could very well be that I keep a reference
        to the KFM at some other location, in order to be able to deregister. That
        reference would keep the KFM alive, which in turn would keep all listeners
        alive.

        So it may very well be that this is a bit of a special situation, maybe you
        could try that too. It shouldn't be too hard to create a static reference to
        the KFM and see if the GC then cleans up. I have reimplemented the application
        without JModalWindow by now, so testing would be a bit complex.

        Never the less, I do not think that relying on there nowhere being a reference
        to the KFM as a strong anti-memoryleak setup. I'd still suggest using a
        middleman, so even if there is a reference, it still gets cleaned up.

        Show
        tbee added a comment - I have a master frame with a menu and on each menu action I open a new frame containing some GUI stuff. In my tests I opened 5 frames and then closed them again. If I extend JFrame, run a GC then a memory dump and profile it, I see 1 instance of my frame; the reference is being held in the main window (it shouldn't, but it is correct according to the code). If I extend JModalFrame and do the same, the dump still contains all 5 instances. When I profiled it, it appeared as though the PropertyChangeListener of the KFM was still referencing. And that is correct, I have had those memoryleaks myself. If you register a frame as a PCL to the KFM, it will keep a strong reference until it is deregistered. Since KeyboardFocusManager never goes out of scope... Hm. Or maybe in my system it doesn't. It could very well be that I keep a reference to the KFM at some other location, in order to be able to deregister. That reference would keep the KFM alive, which in turn would keep all listeners alive. So it may very well be that this is a bit of a special situation, maybe you could try that too. It shouldn't be too hard to create a static reference to the KFM and see if the GC then cleans up. I have reimplemented the application without JModalWindow by now, so testing would be a bit complex. Never the less, I do not think that relying on there nowhere being a reference to the KFM as a strong anti-memoryleak setup. I'd still suggest using a middleman, so even if there is a reference, it still gets cleaned up.
        Hide
        tbee added a comment -

        Oh, right, the latest version.

        Show
        tbee added a comment - Oh, right, the latest version.
        Hide
        jjasper added a comment -

        Only the JModalHelper registers itself with the KFM. No JModalFrames are
        registered with the KFM.

        Running GC once is no guarantee that the objects are garbage collected. Force
        garbage collection several times to see if objects stay put.

        Do you still have the memory dump and how could I profile it? Or could you
        attach a screenshot.

        Thanks in advance.

        Show
        jjasper added a comment - Only the JModalHelper registers itself with the KFM. No JModalFrames are registered with the KFM. Running GC once is no guarantee that the objects are garbage collected. Force garbage collection several times to see if objects stay put. Do you still have the memory dump and how could I profile it? Or could you attach a screenshot. Thanks in advance.
        Hide
        tbee added a comment -

        This is how I profile my memory:

        http://dev.eclipse.org/blogs/memoryanalyzer/2008/04/21/immortal-objects-or-how-
        to-find-memory-leaks/

        Unfortunately all the dumps have been deleted. I can see if I can quickly
        reverse the changes, but I'm not sure.

        Show
        tbee added a comment - This is how I profile my memory: http://dev.eclipse.org/blogs/memoryanalyzer/2008/04/21/immortal-objects-or-how- to-find-memory-leaks/ Unfortunately all the dumps have been deleted. I can see if I can quickly reverse the changes, but I'm not sure.

          People

          • Assignee:
            Unassigned
            Reporter:
            tbee
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: