Well, well. What do you know. There was a memory leak in the applet side of Jmol. This is fixed for 11.3.61, and I am VERY happy to report that repeated loading of http://chemapps.stolaf.edu/jmol/docs/examples-11/sync4.htm results in essentially no increase in reported memory use. Whew!
Jmol is a much cleaner operation now, and it is automatically removed from memory as soon as the page closing signal is received. I think there may be some spurious error messages that might come to the Java console just as pages close, but as far as I can tell they all amount to nothing, since the applet is on its way out anyway. Still, we should be on the lookout for that. For the developers out there: As it turns out, for the applet, Jmol was only occasionally being finalized by browsers when pages were reloaded. I did some research and discovered the applet.destroy() method, and sure enough, that appears to be a reliable notification of the closing of the page. (I tested this in Mozilla, MSIE, and Opera on the PC and Mozilla and Safari on Mac OSX.) The trick in this case is that Jmol needed to be notified of a page closure, because only then could it release its mouse listeners that are being used for monitoring dragging and hovering events. I had noticed this with the application some time ago, back when we made language translation dynamic, but I could not until now figure out how to get proper notification that the applet's page had closed, so I hadn't applied that same fix to the applet. Bob Rolf Huehne wrote: >Bob Hanson wrote: > > >>Rolf Huehne wrote: >> >> >> >>>Q: Could a "memory estimation function" be integrated into Jmol that >>>would estimate the memory requirement prior to loading a specific >>>structure file? >>> >>> >>> >>> >>> >>I think "prior to loading" is asking a lot. We've talked before about >>possibly having a loading bar with a cancel option. An applet can know >>how much memory is allocated, but I don't think it can know how much >>overall is available, because as it needs more Java requests more. >> >> >> > >Q: Could at least a good rule of thumb for loading PDB format files be >provided? > (When I looked at a few examples, 20 times the uncompressed file size >seemed to be adequate. But I would guess that it also depends somehow on >the division into models, chains etc.. And it might also change with >Java and OS versions.) > >Since we started processing all ~106,000 PDB files (asymmetric + >biological units) for automatic image generation with Jmol we could >export the memory requirement for each structure and put it into a >database. But of course other users won't benefit from this solution. >And it might be different on different machines and Java versions. >(It takes about 2 days using 20 parallel processes on the machine Bob >would also like to have. But leaving out '1M4X' because it might take 3 >or 4 days alone to run it with the image generation script.) > > > >>>And after requesting a garbage collection within the Java console it >>>changed to the following: >>> >>> 1) context menu >>> 18 MB total >>> 9 MB free >>> 254 MB maximum >>> >>> >>> >>> >>this is runtime.freeMemory(), runtime.totalMemory(), runtime.maxMemory() >> >>That last one is not available in some systems. >> >> >> > >As always, false promises on platform independence, even with really >basic important stuff... > > > > >>>Q: What do you think about storing the memory requirements for each file? >>> >>> >>> >>> >>> >>storing? >> >> >> > >Determine "runtime.totalMemory()" before loading a file (after removing >the previous one if not "load APPEND") and after loading it and store it >in a list variable for all files currently loaded. >But if the values are available one could do this also with scripting. > > > >>>And since file loading is not the only memory consuming thing, it would >>>be good to be able to obtain other memory information too. >>>>From Bob's information about the high memory needs for >>>'antialiasDisplay' it looks like a good candidate for this. >>> >>>Q: Could a "memory estimation function" be integrated into Jmol that >>>would estimate the additional memory requirement prior to 'set >>>antialiasDisplay true'? >>> >>> >>> >>> >>> >>for the application, yes; for the applet, maybe not. >> >> >> >>>Since the "OUTO OF MEMORY" problem not only occurs with very large >>>structures but for example also if a number of applets is started within >>>a single browser session, I think this might be of general interest >>>also to others. >>> >>> >>> >>> >>> >>very difficult in the applet situation, I think. >> >> >> > >Yes, indeed! And if the freezing of our Jmol viewer occurs frequently I >fear users will avoid using it in the future. > >Regards, >Rolf > >------------------------------------------------------------------------- >SF.Net email is sponsored by: >Check out the new SourceForge.net Marketplace. >It's the best place to buy or sell services >for just about anything Open Source. >http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace >_______________________________________________ >Jmol-users mailing list >Jmol-users@lists.sourceforge.net >https://lists.sourceforge.net/lists/listinfo/jmol-users > > -- Robert M. Hanson Professor of Chemistry St. Olaf College Northfield, MN http://www.stolaf.edu/people/hansonr If nature does not answer first what we want, it is better to take what answer we get. -- Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900 ------------------------------------------------------------------------- SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace _______________________________________________ Jmol-users mailing list Jmol-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jmol-users
