It found and downloaded some items. As soon as it did that, the size GREW to 106M and the thread count started climbing: from 80 to 105 or more. Meanwhile, network activity dropped to a quarter of its previous level and the UI hung. After a minute, it recovered and the stats were: 105M, 79 threads. So it temporarily created 15 threads and allocated 1MB to do some lengthy computation that had nothing to do with handling UI events and nothing to do with handling network events -- in other words, had nothing to do with its job. Frivolous extra activity "on the side" that doesn't obviously relate to stated software function makes me smell the distinct odour of spyware -- or at least some kind of embedded, unnecessary garbage that steals resources away from actually doing the work the user wants done. No bundled software, eh? I suppose if the secondary, hidden functions of the software are built right in rather than separate apps that get co-installed, then there's technically "no bundled software", but there still seems to be crudware embedded in Limewire. Say it ain't so, or I'm ditching Limewire and Zonealarm and using Gnucleus.

Subsequently, it spat an "internal error" box at me after getting a couple more files.

After another download completed, it hung again, grew to 106M and over 90 threads, and then reverted to normal after a few seconds.

Same after another, only it went up to 105 threads that time.

At this point, everything left was "Awaiting sources" or busy with 22 items in the download list so I shut down and restarted Limewire. Closed the window, right clicked the tray icon, choose Exit. It took over two minutes for the "javaw" process to disappear from Task Manager.

Miraculously, the next session inherited the old download list. When it showed "Sharing 9433 files" and all green bars, process size 100M, 88 threads. Not 105M. So, 5 of the megs at the end of the last session were the result of it leaking memory. That was after an hour or so online. Also, 22 download items adds 5 megs, so I can say this about Limewire's memory usage now, assuming the base application size is around 30M, in keeping with other large network apps -- the process size is:

* 30M base application size plus
* 6500 bytes per shared file plus
* 256K per pending download plus
* 5M per hour left running w/typical
activity.

Also, I can say that it starts to slow down and experience UI freezes and network performance issues once the process size reaches about 100M, begins to display internal errors starting around 105, and just plain hangs, chokes, quits functioning correctly, or otherwise blows up when it gets to around 120. All without regard for how much memory the system as a whole has -- it seems to confine itself to 120 or so MB even if that means it crashes or otherwise malfunctions! It incorrectly detects available memory or something. This is clearly a bug, and I'd call it a showstopper. Sharing thousands of files will eat up most of that 120M quickly, at 6500 resident bytes per shared file, and letting it run for hours will do the rest. Running it overnight for, say, nine hours means 45 megs leaked, at the rate determined above; add that to say 5000 shared files and you can bet it's hung or otherwise gone on the blink come the morn. Basically, the only way to get acceptable performance out of limewire is to share few files, pop on to get files rather than leave Limewire running, and in short basically be a freeloader.

The bug detecting correctly the available memory may be avoidable but the means of avoiding it carry too high a price. Yet not avoiding it also does, since a host that crashes, keeps having to be restarted, and is generally slow and wonky is not a good contribution to the p2p network either! It's for this reason that I'm characterizing this bug as a showstopper.

As a side note, if it really does think there's only 128MB in this ****ing box, then the strange hangs and spasms of thread creation actually could be the garbage collector -- the GC may think it's genuinely running out of memory and do some kind of slow lengthy compacting operation, even with hundreds of physical megs free! In that case, I'd suspect the particular syndrome of LW hanging right after a download could mean that downloads completing call System.gc(). Also, the priority overriding event-handling is then a VM problem, unless there's a way to change the GC behavior with VM settings...

A quick Google reveals that Sun's VM does have commandline options to affect GC behavior and the initial amount of memory it uses -- the problem being that Limewire on Windows comes as its own executable, with no (documented) command line options, and no clear way to change the options passed to the VM. So, we're stuck with whatever options Limewire's installer configures it to use by default, since they're not in any user-editable file I've been able to find. (That's with searching for all registry keys with "Limewire" in the name somewhere and all files with "Limewire" in the path using regedit and Agent Ransack. And I'm not sure I'd call a registry key "user editable" anyway.) If the GC is the cause of the app locking up and dropping connections, it needs to be made less aggressive, and the problems of Limewire not detecting correctly the amount of installed memory (underestimating mine by around a factor of eight), leaking, and using way too much memory per shared file (6500 bytes) and pending download (256K!) must be addressed in v4.0.6. If the 3 memory problems indicated above are not fixed in a publicly-released upgrade by close of business next Tuesday (1700h Eastern time) I'm switching to Gnucleus and to hell with ever buying Limewire Pro.