What you're seeing at the end is the program "unpack200" unpacking LimeWire's jar files. We build the installer with highly compressed files that allow the installer size to be a half of what it used to be. Unpack200 is somewhat resource and CPU intensive, so it may appear as if things have stalled while it is unpacking the files.

If you go to the directory C:\Program Files\LimeWire while LimeWire is installing, you'll see it initially places a bunch of "<name>.jar.gz" files, and during the "Finishing installation" phase, these get erased and turned into "<name>.jar" files.

Does the installer stall for you after all the files have been converted from .gz to .jar, or during that process? Also, does the progressbar in the 'Finishing Installation' ever move forward?

We'd like to solve any problems with the new installer. Thanks very much for letting us know about this. Any help you can give would be great.

I am currently running a modified LimeWire from CVS that uses the basic UI for the progress bars (quite ugly) and I will see if the memory stays constant. With my current downloads.dat I always have seen the memory grow without bounds. I will report what happens.

Well, I did let it run for a while and it still grows. So this guess was false.

Thanks for trying, Jens. Any other ideas?

Well, I am at a loss at the moment.

Maybe this here can help:
PID COMMAND %CPU TIME #TH #PRTS #MREGS RPRVT RSHRD RSIZE VSIZ
6850 java 1.8% 37:42.59 39 886 358 204M+ 6.71M 195M+ 806M
6839 Acquisitio 6.1% 54:44.87 8 135 318 10.9M 18.7M 18.5M 213

(Yes, I use Acquisition, it is still the most usable program out there, but LimeWire is the one, here I do support - I gave up supporting Acq, because the Programmer doesn't open up his own code and doesn't have that nice a character).

111 inactive downloads and 3 connections.

Isn't there a problem in your custom settings of the JVM for your Mac: it seems that the standard Java garbage collector thread is not running on your host. It may be caused by some tweaks for MacOSX, that are there to preload some Java components and keep them indefinitely in memory, notably the precompiled native code. I'm not an expert at MacOSX tweaking options.

Keeping the native code compiled from classes is interesting only to accelerate parts of the MacOSX GUI (which is based on Java too, and uses a single shared VM for all Java apps, including the desktop interface).

I have been told that some IRC/chat applications for MacOSX do not free up their GUI resources, and cause leakage of resources. May be all these megabytes are not allocated by Limewire itself.

I suggest you try listing the running threads in the main JavaVM. It's possible that the garbage collector is disabled, so Java never frees memory used by dead/unreferenced objects. The Java VM on Mac may contain various platform-specific switches or options to control in which mode the GC runs. One of this mode for example is to not perform incremental garbage collection, but only collection when memory is effectively exhausted. Other options control the maximum memory the VM is allowed to allocate: as long as this threshold is not reached, the GC will not run.

Note that Limewire does not invoke itself the GC to force it to operate. In addition, some VM invokation flags may be incorrectly set in the Acquisition program, or it has a bug that locks the GC indefinitely. So this may be a bug of Acquisition itself. Do you have the same experience with the genuine Limewire for MacOSX?

But it's true that LimeWire's core could be further optimized to reduce the number of temporary it allocates, or to reuse them as much as possible instead of discarding them and reallocating them later (notably the many temporary String or bytes-array instances, created when parsing incoming messages, where this parsing could share the same storage instead of copying temporary fragments). This is lot of code to change in the core, to allow in-place parsing of messages. But it could be progressively improved.

Profiling classes allocating the most important number of objects or Strings or arrays would reveal the most interesting optimization. the JDK includes such a tool that allows tracing all the stack traces where allocation is performed, and the status (active/dead) of these instance. If one trace shows more than 99% of dead objects for a huge total of memory, this is certainly the first class to consider for optimization. Saving a few bytes per class will not be as much useful as true profiling.

My custom settings are in fact quite standard, as recommended by Apple in their documentation. I do not turn off the garbage collector or other strange things, and I do use the standard executable stub to execute the java program (the java or javaw frontend on other platforms).

The shared code preloading mechanism is there, but it is only for the system classes as it is done at system boot, for all the other code the system does the same as on other platforms, namely dynamically compiling code. Indeed the caching of compiled system code appears to be popular lately, Sun did introduce in Java 1.5 the changes Apple did develop.

You are misinformed here, the OS X Gui is not based on Java, it is based on Obejctive C, which is a variant of C with some Smalltalkish extensions for dynamic dispatching and the like.

Also OS X does not use a shared VM for all the system, it starts as on other systems each Java program in it's own process. If the user does not explicetely start a Java program, no VM runs by default.

This means the only thing that is loosing memory in the process is LimeWire. The problem can be in the LimeWire code itself, in the JVM, or in the Swing implementation Apple did for it's Aqua GUI.

As I use the standard stub (the same that LimeWire uses), I do have any special code that would turn off garbage collection or other such ilk. Aquisition is quite different as it is a standalone application that uses a JVM with the LimeWire Java code as subroutine library. This is an entirely different kettle of fish.

I did already already do profiling and listing threads, and the threads do not appear to be special in any way. The memory usage was always enormous, an most of the massive amounts of memory in use did point to the LimeWire connection code. the part responsible for interpreting and processing Gnutella messages.

The problem with this is that it depends on the type of files you search or have incomplete and the clould of the network your are connected to. For example the exact same setup that did grow a few days ago does not grow the last two days.

Unfortunately my OS X machine is a bit slow and underpowered memory wise to do any extensive profiling. I do normaly do my development using Eclipse on a better equipped Windows XP box, but I always run LimeWire on the OS X box.