View Single Post
  #31 (permalink)  
Old September 17th, 2004
verdyp's Avatar
verdyp verdyp is offline
LimeWire is International
 
Join Date: January 13th, 2002
Location: Nantes, FR; Rennes, FR
Posts: 306
verdyp is flying high
Default

Quote:
Originally posted by arne_bab
I also saw much RAM-usage. So much, that I had 1GB of free disk space before starting up limeWire, and after one night I had nothing left and my system complained, that it didn't have any space left.
Thanks for this detail: I understand from your issue that the 1GB of virtual memory allocated is *committed*, because it takes space on disk. It seems that Java on Mac OSX has fogotten the distinction between virtual uncommitted memory and virtual committed memory (that just takes space in the virtual memory map of a single process to map virtual memory pages to uncommited pages or committed pages in real memory or on disk).

I looked into the Windows VM statistics and Java 1.4 and 1.5 DO USE uncommitted memory, and there's also a background thread that frees the unused committed pages in virtual memory to reduce the virtual memory space left unused. Something gets wong on MacOSX's Java ported runtime, as this thread may not be running as expected (probably because it runs only with a idle priority).

Note that the garbage collector will only free dead objects in the VM, to keep them out of the "Real" live memory or swapped memory. However the heap in which these objects were allocated wil remain committed, meaning that the swap space on disk will not be freed until the application memory heap is effectively reduced:

I suspect that the application memory heap can't be shortened due to a few small locked objects that can't be relocated in the process virtual memory map. Could it be desktop/shell objects related to the iTunes integration? Do you experiment the same growing VM if iTunes integration is disabled? If so, there may be a bug in LimeWire where some temporary references to native objects are not freed after use. (native objects can't be freed by the Java gargage collector and remain in locked, committed, state until explicitely deleted by the application)

There are a few other desktop/shell native integration objects in the MacOSX installation that may produce a highly fragmented VM with many pages locked by small locked, leaked, native objects. LimeWire MacOSX developers may need to look at this issue.
__________________
LimeWire is international. Help translate LimeWire to your own language.
Visit: http://www.limewire.org/translate.shtml

Last edited by verdyp; September 17th, 2004 at 03:49 AM.