OK Benjamin Chain Department of Immunology and Molecular Pathology Windeyer Institute of Medical Sciences UCL, 46 Cleveland St. London W1T 4JF Fax 00 44 20 7679 9301
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: 13 December 2007 18:29 To: [email protected] Subject: Jmol-users Digest, Vol 19, Issue 22 Send Jmol-users mailing list submissions to [email protected] To subscribe or unsubscribe via the World Wide Web, visit https://lists.sourceforge.net/lists/listinfo/jmol-users or, via email, send a message with subject or body 'help' to [EMAIL PROTECTED] You can reach the person managing the list at [EMAIL PROTECTED] When replying, please edit your Subject line so it is more specific than "Re: Contents of Jmol-users digest..." Today's Topics: 1. Re: Jmol-users Digest, Vol 19, Issue 21 (Craig T Martin) 2. Re: Exploring the limits (Rolf Huehne) 3. Re: Jmol-users Digest, Vol 19, Issue 21 (Craig T Martin) 4. Re: Jmol-users Digest, Vol 19, Issue 21 (Rolf Huehne) 5. Re: memory allocation (Timothy Driscoll) ---------------------------------------------------------------------- Message: 1 Date: Thu, 13 Dec 2007 12:30:52 -0500 From: Craig T Martin <[EMAIL PROTECTED]> Subject: Re: [Jmol-users] Jmol-users Digest, Vol 19, Issue 21 To: [email protected] Cc: Rolf Huehne <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> Content-Type: text/plain; charset="us-ascii" 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 think I've seen this discussed here before, but with no real answer. Is there a way to insure that when an applet closes, it releases its memory? Or is there a way to manually do so? Is this just a problem for me or do others see this? Perhaps I'm doing some sort of call wrong? An implementation is at: <http://www.chem.umass.edu/people/cmartin/Jmol/WingedHelixII> You need to open and close maybe a half dozen times to see the effect. Thanks, Craig On Dec 13, 2007, at 9:43 AM, [EMAIL PROTECTED] wrote: > Message: 3 > Date: Thu, 13 Dec 2007 14:56:34 +0100 > From: Rolf Huehne <[EMAIL PROTECTED]> > Subject: Re: [Jmol-users] Exploring the limits > > Timothy Driscoll wrote: >> On Dec 13, 2007, at 6:28 AM, Rolf Huehne wrote: >>> Because an "OUT OF MEMORY" error freezes Jmol and the standard user >>> most ... > > The problem with this is that there is no "standard java memory > allocation". In my experience it differs largely between operating > systems and also between Java versions. > > Another problem is that even if you could apply some rule of thumb > (e.g.: 20 times uncompressed file size + minimum requirement for the > applet) this would only apply if a single applet was started. > But I would rather expect that often a user will explore several > structures one after the other. And unfortunately the memory of > applets > whose window/tab was closed it not always released. > > Another problem is the applet size. Since the user can set the size > freely this might also drastically change the memory required. > > So I would really prefer a more situation-specific solution. > > Regards, > Rolf -------------- next part -------------- An HTML attachment was scrubbed... ------------------------------ Message: 2 Date: Thu, 13 Dec 2007 18:44:25 +0100 From: Rolf Huehne <[EMAIL PROTECTED]> Subject: Re: [Jmol-users] Exploring the limits To: [email protected] Message-ID: <[EMAIL PROTECTED]> Content-Type: text/plain; charset=ISO-8859-1 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 ------------------------------ Message: 3 Date: Thu, 13 Dec 2007 13:12:41 -0500 From: Craig T Martin <[EMAIL PROTECTED]> Subject: Re: [Jmol-users] Jmol-users Digest, Vol 19, Issue 21 To: [email protected] Cc: Rolf Huehne <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> Content-Type: text/plain; charset="us-ascii" > 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. Sorry for the addendum - to be clear, simply reloading the page for the same applet leads to the stepwise increase in browser memory. Does NOT require multiple applets. Craig -------------- next part -------------- An HTML attachment was scrubbed... ------------------------------ Message: 4 Date: Thu, 13 Dec 2007 19:26:25 +0100 From: Rolf Huehne <[EMAIL PROTECTED]> Subject: Re: [Jmol-users] Jmol-users Digest, Vol 19, Issue 21 To: [email protected] Message-ID: <[EMAIL PROTECTED]> Content-Type: text/plain; charset=ISO-8859-1 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 think I've seen this discussed here before, but with no real answer. > Is there a way to insure that when an applet closes, it releases its > memory? Or is there a way to manually do so? Is this just a problem for > me or do others see this? Perhaps I'm doing some sort of call wrong? > > An implementation is at: > <http://www.chem.umass.edu/people/cmartin/Jmol/WingedHelixII> > > You need to open and close maybe a half dozen times to see the effect. > I experimented a bit with loading Craig's example either sequentially or in parallel before closing it. And while doing this I noticed that I was mistaken about the meaning of the total amount of memory: I thought it was the total memory used but appearently it is the total amount of memory allocated currently to the whole JavaVM. I believe this because the total amount increased from 18 MB up to 70 MB after sequential/parallel loading and closing (even if a single applet was left over). After requesting a garbage collection it dropped to 64 MB and eventually to 53 MB after clicking onto the reload button of the browser. But strangely the amount of resident memory displayed for the JavaVM in the process list (Linux "top" command) never dropped down to a lower value. But I didn't observe an increase in memory requirement for the browser (Firefox 2.0.0.10, OpenSuSE 10.2, Java 1.4_2_16) even after a dozen sequential load and close processes. Regards, Rolf ------------------------------ Message: 5 Date: Thu, 13 Dec 2007 13:29:04 -0500 From: Timothy Driscoll <[EMAIL PROTECTED]> Subject: Re: [Jmol-users] memory allocation To: [email protected] Message-ID: <[EMAIL PROTECTED]> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed 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 -- Timothy Driscoll em: [EMAIL PROTECTED] Virginia Bioinformatics Institute ph: 540-231-3007 Bioinformatics I: M-1 im: molvisions Washington St., Blacksburg, VA 24061 04-16-07. We will not forget you. ------------------------------ ------------------------------------------------------------------------- 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 [email protected] https://lists.sourceforge.net/lists/listinfo/jmol-users End of Jmol-users Digest, Vol 19, Issue 22 ****************************************** ------------------------------------------------------------------------- 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 [email protected] https://lists.sourceforge.net/lists/listinfo/jmol-users
