#362 memory hole: parent Component + Jmol don't get finalized

Applet (71)
Tobias T

Hey guys,

thank you so much for providing Jmol. However, there is
one bug that really bugging me: Jmol has a memory hole,
and this means that by usign Jmol, my client program
has one too :-(

Apparently Jmol somehow stores a reference to itself
and the Component passed to JmolViewer.allocateViewer()
in some place that itself remains referenced forever:
Repeated invocations of allocateViewer() will
continuously increase the memory consumption, until a
java.lang.OutOfMemoryError occurs.

If an empty JPanel is passed as the component, the
memory usage increases by about 32 KBytes per
invocation. The JPanel itself is never finalized even
when the client program stores no references to it; the
JPanel itself is lightweight at less than 1 KByte.

I've attached a JUnit testcase that illustrates the
bug. The memory usage shouldn't increase from the start
to the end of the testcase, but it does increase by
tens of Megabytes (on my computer, using JDK 1.5.0_06
under win32, 1000 iterations yield 32,326,200 bytes lost).

I've overriden the JPanel's finalize() method to
illustrate that the component never gets garbage
collected. Because the JPanel itself doesn't consume
this much memory, and because the Jmol Viewer is the
only thing that stiill has a reference to the panel, it
follows that the Jmol Viewer never gets garbage
collected either.


  • Bob Hanson

    Bob Hanson - 2006-07-18

    Logged In: YES

    Tobias, I'd love to get this fixed. What do you recommend?

    I think I have also noticed that all instances of Jmol
    remain "alive" until the browser application is closed, even
    when the page is abandoned.

    Do you have any references we could look at regarding proper
    finalization upon page exit in a browser?

    Bob Hanson

  • Bob Hanson

    Bob Hanson - 2006-07-18
    • assigned_to: nobody --> migueljmol
  • Bob Hanson

    Bob Hanson - 2006-08-22

    Logged In: YES

    we need help solving this one. Demo pages necessary

  • Bob Hanson

    Bob Hanson - 2006-08-22
    • assigned_to: migueljmol --> egonw
    • milestone: --> v11
    • labels: --> Applet
  • Bob Hanson

    Bob Hanson - 2006-09-16

    Logged In: YES

    Will close this soon if there's no report of it being
    reproduced. Nico, is there an obvious fix to this? Can you
    follow up?

  • Bob Hanson

    Bob Hanson - 2006-09-16
    • assigned_to: egonw --> nicove
  • Nicolas

    Nicolas - 2006-09-16

    Logged In: YES

    Hi Tobias,

    you said that you've attached a JUnit testcase, but I don't
    find it. Could you send it to me?


  • Bob Hanson

    Bob Hanson - 2006-10-01

    Logged In: YES

    Nico, this one's for you. It's a failure to provide a
    general public void destructor() method to Viewer that will
    go turn off the three mouse listeners and the hover watcher.
    Do you know how to add that? (I don't.)
    This would be something we would want to call from the
    applet, as I see that viewer is not being finalized there,


  • Bob Hanson

    Bob Hanson - 2006-10-04
    • assigned_to: nicove --> hansonr
    • status: open --> closed-fixed
  • Bob Hanson

    Bob Hanson - 2006-10-04

    Logged In: YES

    This is fixed. It was an application-only problem; not an
    issue with the applet.

    The mouseManager sets up a hoverWatcher thread and a few
    mouse listeners, all of which had references to viewer. To
    properly clear the viewer (for now), use:

    viewer = null;

    not just

    viewer = null;

    Thank you very much for pointing us to this issue.

    Bob Hanson


Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.

No, thanks