OK, here are the results of my testing. I was using http://chemapps.stolaf.edu/jmol/docs/examples-11/sync4.htm
1) load page 2) In java console press "gm" -- garbage, memory 3) load page again 4) loop to (2) Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.11) Gecko/20071127 Firefox/2.0.0.11 memory roughly doubles after the second reload, but after that it does not increase: 21,132K Free: 14,518K (68%) and remains there no matter how many times I load the page. MSIE/6.0/ Windows XP memory remains low no matter how many reloads: Memory: 11,676K Free: 5,246K Opera/8.51/Windows XP memory climbs to 65Mb, then stops climbing. Applets and their associated pages remain registered even though they are long since "history". (That means syncing will be syncing applets on pages that don't show. I don't have any idea what that will do.) Mozilla/5.0 (Macintosh; U; Intel Mac OS X;en-US;rv:1.8.1.9) Gecko/20071025 Firefox/2.0.0.9 memory climbs and climbs sometimes, just levels off other times. Safari/3.0.4(same Mac) memory climbs to 23Mb, then stops climbing none of these pages crashed, although Opera failed to finish loading the applet once.. My conclusion from this is that (a) you should not in general second-guess Java's dynamic memory allocation and garbage collection. Just because it's climbing does not mean that there is a problem and certainly doesn't necessarily mean that there is a problem with Jmol. But the browsers implement Java differently, and that is showing up here. There may be a problem with Mozilla on the Mac, or else Java is taking the memory allotted to it and not releasing it for a while. Opera saves the pages in memory that have been replaced already. This is a problem, actually, because Jmol is using a simple mechanism to see if the page containing the applet is still a valid page, and Opera would be fooling it. Of course if the browser crashes, then there's a problem. Timothy Driscoll wrote: >On Dec 13, 2007, at 12:30 PM, Craig T Martin wrote: > > > >>While we're talking memory allocation, and with respect to: >> >>"And unfortunately the memory of applets whose window/tab was >>closed it not always release " >> >>For the stuff that I'm doing, I've known for some time that after >>loading (and closing) various windows, Jmol eventually stops >>working (Jmol, not the browser, hangs on a subsequent load) and I >>have to restart the browser. This on a Mac running either Safari or >>FireFox (latest everything, but it's been happening for more than a >>year). If I look at the memory allocated to Safari, for example, I >>can see a step increase on every new Jmol applet. So it is clearly >>not releasing memory. >> >> >> >I have investigated this a bit, since I do a lot of development under >OSX/Safari, and it is not clear to me what is going on. > >Safari declares a virtual memory size according to the JVM max >allocation. in my case, allocating 1024 mb to the JVM, Safari gets >1.6g of vmem when it first loads an applet (even an empty applet). >of course, this is unrelated to physical memory - Safari generally >starts with approx 225mb of physmem on my machine. > >loading 4 different 1mb (uncompressed) pdb files into 4 different >applets on a single page increases Safari's physmem usage by 12 mb - >that's 3x the actual combined pdb file sizes. I've been able to >repeat this multiple times with different files. > >the 'extra' physmem remains allocated to Safari as long as the window >with the applets is open (obvious). at least half of it, sometimes >all of it, remains even after the window is closed. closing the >window and clearing the browser cache sometimes causes Safari to drop >back down to its initial 225 mb of physmem; sometimes it does not. >(during all of this time, the vmem does not change from 1.6 gb.) > >I found this on the Web, and it looks like it could be helpful, so >I'll pass it along to those wiser than myself: > ><http://wrapper.tanukisoftware.org/doc/english/properties.html> > >(fair warning: while the link was working 5 minutes ago, it is >currently offline <shrug>) > > > > > >not sure if I helped or not. :-) > >tim > > -- 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
