Quote:
Originally posted by verdyp
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.
|
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.
Quote:
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.
|
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.
Quote:
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?
|
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.
Quote:
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. |
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.