Re: [Jmol-users] Serious Memory Issue in Jmol/JTAT

[<ha...@st...>]

> Dear Bob and Angel and others,
>
>
> What I have seen indicates that some portion of memory from "dead and
> gone" Jmols fails to be freed for reuse, and that this continues to
> add up throughout each browser session. The only way I know to free
> all the java memory for new molecular views is to close/quit the
> browser, thereby quitting java. When you start a new browser session,
> the memory is cleared.

I tested this recently on MSIE/Windows, Firefox/Windows+Mac,
Opera/Windows, and all did a fine job of clearing memory for applets on
pages that had been  closed. This is not something you can easily test for
yourself. If you can give me some test pages, I can look at it with tools
that I have. There was an issue dating way back to at least 10.0, but
11.3.61 should have fixed that.


>
> I hope there are other ways that I don't yet know about!
>
> Bob wrote:
>>Or, alternatively, use code to deactivate applet divs that are not
>>in use.
>
> What code is that?
>

something like clearing the divs using
document.getElementById("theDiv").innerHTML = "<img
src=appletPlaceHolder.jpg>"

> Here's what I am doing in JTAT currently. Please tell me how I can improve
> it.
>
> A. I have an HTML div for Jmol (id="jmolAppletsDiv") at the outset,
> and it remains in place throughout the JTAT session. Jmol.js is
> loaded at the outset.
>
> B. Before writing the first jmol object tag into the division, I
> execute (one time only)
>    jmolInitialize(...);
>    jmolSetCallback(); //for messageCallback
>    jmolSetDocument(0); // because I gather HTML generated by Jmol.js
> functions into strings.
>
> C. Object tag HTML for Jmol(s) is gathered into a string variable
> jhtml using calls to
>    jmolApplet( [s_jwidth, s_jheight], readySpt, jNameSuffix);
>
> D. The Jmol(s) are written into jmolAppletsDiv in this manner:
>    document.getElementById("jmolAppletsDiv").innerHTML = jhtml;
>

all the above looks terrific.

> E. The initial script specified in jmolApplet() messages a
> recognizable token. When this token is seen in the messageCallback
> stream, I assume that the corresponding Jmol has loaded and is ready
> for action. (IS THERE A BETTER WAY TO DETECT JMOL READINESS?)

that's the way to do it.

>
> F. I then use jmolScript() to send a script to each Jmol that starts
> with a load command, and then renders, colors, etc. producing the
> initial molecular view.

You could also use the javaScript command to send a message yourself
anywhere in a script.

>
> SO FAR SO GOOD. We now have the first molecular display showing. I am
> generally using small coordinate sets, so I haven't used much java memory
> yet.
>
> G. Now, the user presses a button to display a different molecular view.
>
>   - If the new view uses the same PDB file(s) (coordinates), and the
> same number of Jmols (1-4), only a new rendering script(s) is sent to
> the EXISTING Jmol(s).
>
>   - If the new view uses different PDB file(s), but the same number
> of Jmols, the scripts start with a "load" command, loading new
> coordinates into the EXISTING Jmol(s).
>
> IT WOULD BE EASY TO PUT IN A ZAP HERE IF THAT WOULD HELP. Although
> the Jmol documentation is not explicit about what "load 1d66.pdb"
> does, I assume this does an implicit zap, replacing the previous
> coordinates with the new ones. If not, shouldn't it do an implicit zap?

right -- it does a zap so that if the file load fails, the warning message
is on a blank window.

>
>   - If the new view uses a different number of Jmols, new object HTML
> is generated using jmolApplet() call(s), and it is written into the
> existing jmolAppletsDiv.innerHTML SIMPLY REPLACING THE OBJECTS
> (JMOLS) THAT WERE THERE BEFORE. IS THERE SOME MORE EFFECTIVE WAY TO
> CLEAR OUT THE OLD JMOLS?

It could be that the applets are not properly unloaded in such a case. I
have not tested that. I could imagine that some browsers have problems
with that. Be sure none of your global JavaScript variables make reference
to an applet that might have been destroyed this way. For example, if you
keep

var theApplet = document.getElementById("jmolApplet0")

or something like that, there might be a problem unloading that applet
without unloading the page.



>
> H. When moving to a new chapter, a new chapter.htm file is loaded
> into the existing browser window, entirely replacing the old
> chapter.htm. This starts the entire process over again, from loading
> Jmol.js, setting up jmolAppletsDiv, to filling it with jmol
> object(s), and when they message their readiness, having them load
> PDB files and then scripting those coordinates.

My testing suggests that this totally unloads from memory all applets on
the replaced pages. Not so prior to 11.3.61, though.

>
> SHOULD I ZAP OR DO SOME OTHER JMOL CLEAN UP PROCESS BEFORE LOADING A
> NEW HTML DOCUMENT INTO THE WINDOW?

this should not be necessary. I'm not sure you can reliably check that a
page is unloading and then do these zaps.

>
> Currently, the links to new chapters are simple HTML links. If there
> is some memory-clearing housekeeping I can do before loading the new
> chapter.htm, it would be easy enough to make the chapter links run
> javascript functions.

really should not be necessary.

>
> Bob wrote:
>>You can save loads of memory just by using ZAP when a
>>model's  use is over.
>
> It would be no problem at all to send "zap" to all existing Jmol
> applets (up to 4) when a new molecular view button is pressed, before
> loading new coordinates, or writing new Jmol object tag(s) into the
> division. But generally I am just replacing the old coordinates with
> new ones ("load 1d66.pdb"). If I have loaded .jvxl/.iso surface data
> files, is their memory freed when I do a "load 1d66.pdb"? Again, the
> question of an implicit zap comes up. If I need to do an explicit
> zap, no problem.

you shouldn't see any memory issues in such cases. No need for ZAP.

>
>
> Bob wrote:
>>Another idea would be to make sure that on page loading the applets are
>>NOT loading full models. This is very inefficient of resources.
>
> I'm not sure what you mean by a "not full model". I'm using e.g.
> "load 1d66.pdb".

I thought maybe you had a page with 10 applets, all loading structures all
at once. From your description, this isn't an issue.

>
> Bob wrote:
>>Java does this automatically, as needed. Don't go there. Basically, get
>>rid of unnecessary memory-consuming objects, especially large molecular
>>systems, cartoons, isosurfaces, etc.
>
> I'm not sure what you mean by "get rid of". I am generally not
> loading more data than I need for a given molecular view. If there is
> some way to "get rid of" these data before I set up a new molecular
> view, please tell me!

I thought maybe you had a page with 10 applets, of which the user might
only be able to view one. But from what you describe, no need for this.

>
> Bob wrote:
> I have taken great pains to
>>make sure that Jmol does not persist with objects that you think are
>> gone.
>>If they are gone, they are gone.
>
> OK, it seems that I need to improve my understanding on how to make
> them be "gone"!

What you are doing should take care of it.



>
> Thanks, -Eric
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Jmol-users mailing list
> Jmo...@li...
> https://lists.sourceforge.net/lists/listinfo/jmol-users
>