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.