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

Well I know that my LW has iTunes support unactivated, DAAP and LW mp3 player are also unactivated but still experiencing the memory problem. Is seems lika an Apple issue though.

Ciao

__________________
Liens d'intérêt /Links of interest:
Gnutellaforums en français /The House's rules you have to respect / First search the forum, then create a thread / Free software alternatives! - Logiciels alternatifs gratuits!/

I don't know if this is related, but Sun has confirmed to me that the Windows version of the Java Client VM runtime contains some leakage within the components that interface Java with local filesystem. Notably when there are security objects associated to a file or directory. There's a system-specific hook in the filesystem core-class which uses a native function through JNI, implemented in C, and that returns data structures allocated by the OS API or by native calls to the C/C++ heap. Then the native security structures are converted to fields in some Java security object, but the Java JNI interface requires several calls to the JNI method implementation to specify when we are finished with the temporary objects.

If there's an exception in a thread, that causes a thread to be aborted, the thread will die with dead Java objects that will be reclaimed in the Java VM garbage collector, but native security objects will remain allocated and not freed (a finalizer is supposed to call a cleaner method, but finalizers do not run fast enough in the ClientVM).

May be the GC thread patch tried before may also try to call finalizers before performing the GC. I suspect that class finalizers are never called as long as LimeWire is running, probably because these classes are still active and have other active instances. In Java 1.4 or 1.5, Finalizers run in a dedicated Finalizer thread, but with very long delays and low priority.

Calling Runtime.runFinalization() within the GC thread patch indicated in a previous message may help...

A comment from Sun about finalization is shown in old Bug id #4026510(not a bug, will not be fixed):
The way and frequency at which finalizers are implemented and run in Apple's version of the VM may make the difference (on Windows we have a dedicated background thread, but is it true on MacOSX?).

Note that I have not seen any use of finalizers in LimeWire classes. But finalizers are frequent in internal implementation core classes bundled with the JVM that perform integrtion with the native host system.

__________________
LimeWire is international. Help translate LimeWire to your own language.
Visit: http://www.limewire.org/translate.shtml

The English version, which is displayed in Spanish in my PC, is only about 40% translated. The other 60% is still in English.

Besides, it doesn't use the same word for the same thing in two different places. For instance, if I download from one user, it says "descargando de una máquina", when I download from two it says "descargando de 2 usuarios" (or the other way round, I don't remember), and when it can't download it says "need more sources".

Ivan
In the dark we make a brighter light

__________________
Gnutella Forums en Español!

The title "English installer" and "International installer" is somewhat misleading -- the only difference between them is that the English installer uses InstallShield and does not require that Java 1.3 is used, whereas the International installer uses InstallAnywhere and installs Java 1.3 (and enforces that LimeWire use it). You'll actually see better performance if you install an international JRE of Java 1.4 or higher and use the English installer. We're exploring ways to update the international installer.

You can help us improve the translations by going to http://limewire.org/translate.shtml and seeing how to submit newer translations. The Spanish translation is only 65.22% complete right now -- any help we can get to raise that number would be much appreciated.

Note that the international support is much better in Java 1.4 or even better in the new Java 1.5 Release Candidate. With the "international LimeWire installer", Java 1.3 is installed in a "jre" subdirectory of the LimeWire installation folder.
I personnally don't use or need the international InstallAnywhere installer. Additionally, its larger size does not come from the international translations of LimeWire (which is also present in the English-only InstallShield installer), but only from the fact that it bundles Java 1.3 with its international charsets support.
So install Java 1.4 or 1.5 separately, with its international version.
Then just download Limewire with its english-only InstallShield-based installer, and you'll get the same language options in Limewire.

We have just renewed the "Help internationalize LimeWire" page with a script that automatically refreshes the translation status of LimeWire messages bundles. It no longer needs manual editing. If you look at it, you'll see that Spanish is effectively now below the quality level that users would expect. Translators are welcome to improve the translation and add the few new missing items, or to suggest enhancements.
See my signature below.

__________________
LimeWire is international. Help translate LimeWire to your own language.
Visit: http://www.limewire.org/translate.shtml

It's good to see www.limewire.org back online again. Aubrey has been busy and I like the new look.

I hope http://www.limewire.org/awards.shtml will be updated soon too (it's been a year).

So what will you work on next Philippe (NIO?), and did slashdot ever review your sha optimizations?

BTW, you do point to http://www.guox.de/gwebcache/
for information on web caches. I once tried to convince the author of this page to include my Java Servlet
based version into his list, but he did not listen.

--searching for "rare" files has been pretty poor lately. I search for the latest jum . . .

any type "5jum352"

or variations thereof and only get 60 of those spam .wmv and .jpg results, which give too many IP's to block.
(the http and magnet links are successful--it's just the LW searching that won't find it).

--Anyone else seeing odd result for popular files in tooltips? Although >1000 sources are discovered, the file only downloads (slowly) from 3. Blame the spammers?

Attached Images

untitled 1.png (10.9 KB, 396 views)

I like it too. Aubrey's work on graphic design for the web site and even on LimeWire client's look and feel is appreciated. She's probably very busy because we waited for that work since long.
Thanks also to Sam for working on the script to refresh the translation status page, and more generally to the LimeWire team to make limewire.org live again after the migration of servers and tools.
Gregorio Roper should be the next one, in my opinion. I think this is the opinion of other LimeWire crew members.
I don't know. I've been busy and not connected very often on the Internet since last June. May be I'll have more time in the next weeks. For now I just review some code and test it, but I have not developed serious things on LimeWire since 4 months.
I don't know. I just informed them about this code (on http://www.rodage.org/pub/java/security/) as well as Sun. This was also used by Sun because it revealed a bug in the HotSpot compiler of the Java Server VM (this bug normally does not affect LimeWire as it uses the Client VM), as well as some other performance issues. I've received various responses from Sun about it. For now, Sun will not change its implementation, as it is busy working on the 1.5 release coming soon, and its feature list is now closed. Sun is also working on porting and checking its core library to support generic types (a concept similar to C++ template types), and there are still some compiler quirks to solve with the new language definition and reference implementation. Also Apple is still finalizing its port of Java 1.4.2. Other JCE rity providers have received a copy of my version. They will do what they want with this code. But my search on this subject helped me to reveal how HotSpot works and where performance bottlenecks appear (these areas are not covered in the Java Language specification, and not even in the Java VM specification). I have tested this code with other VMs and it's interesting to see that my optimizations benefit to all of them, even if their implementation is very different, or they work with distinct platforms/processors.

I have discovered when working on this code that the Java VM HotSpot compiler uses internal fixed-size static structures to compile the Java Bytecode, and that this has a great impact on performance due to arbitrary limits that are documented nowhere in the Java language and VM specifications. This is certainly a place for improvement in future VM versions (I consider that these arbitrary limits are a bug, Sun considers this is rather a RFE, even if my code also solves a few possibly critical security issues in multithreaded environments; anyway, my code is now included in the Sun Java VM regression tests used by its developers, as the current limits in HotSpot are not coherent between phases C1 and C2 of this runtime compiler).

__________________
LimeWire is international. Help translate LimeWire to your own language.
Visit: http://www.limewire.org/translate.shtml