Please try downloading the latest version of java - 1.5.0 beta 2. It is still in beta, but is very stable and much faster than previous versions.

You can find it at http://javashoplm.sun.com/ECom/docs/...actionId=noreg

I let the garabage collecter patch with jum350 and the zab/kapsi .bsh (thanks all) run for 20 hrs this weekend , but the VM still grew to 1.12 GB. The good news is that real memory looked lower (61 MB).

Activity monitor showed 5 hangs--probably during the 20 mins or so it took to refresh the gui in the morning.

If anyone wants the stats, I'll zip and send them.

New report: The CVS version of monday night is using 186 meg RAM today (tuesday) morning. 3 active uploads, no downloads at all.

http://cmt.homeip.net/documents/memlw.zip

Sadly for MacOSX, Java 1.5 isn't avaible yet.

unable to rename
 

in the Library view, I'm no longer able to rename files. I used to be able to select and hover to make the filename become editable. That was workable but hardly intuitive, but now there's nothing?

We've removed the ability to rename files while we ponder a way to make it work better. As it was, too many people accidentally renamed files and became confused.

It's good, that they are no longer editable. I often very closely avoided losing my files through strange renaming...

There's a new update available to Apple ADC members (through a free registration online on their website) that fixes numerous regression bugs found in the current release of Java 1.4.2_01 for Mac OSX.

It was advertized by Apple on its ADC News Letter #414:

The release note for this version is not very verbose. But ADC members may consult the various bugs listed and corrected listed in the Apple Bug Database. This new "Final Candidate" version should show these version strings when running "java -version" from a console window:
For now, Apple will probably not publish any 1.5 version before Sun releases a final version of Java 1.5, code-named "Tiger" (for Windows and Linux) with all its support documents.

The main interest of Java 1.5 on Windows is that it's the first version that integrates a part of the previously Apple-specific code sharing between VMs, at least for the Client VM (the Sun Server VM currently still does not share the core library instances, and I won't recommand it for production as it still has various bugs/limitation that greatly impact the performance of perfectly legal Java classes; the main perfromance issues in Sun Java 1.5 Server VM is with the runtime HotSpot JIT compiler, which fails to compile the bytecode into native code, due to too strict limitations which are hardcoded with fixed-size static structures for method calls; Sun apparently does not want to change this, although this is a regression of something that worked in Java 1.4 Server and Client VM, or even in the Java 1.5 Client VM); it is apparently too late for the newcoming official release of Java 1.5 on Windows and Linux.

So the performance benefit of Java 1.5 on Windows will probably not be as effective on MacOSX where some of the new features of Sun Java 1.5 are natively supported in the Apple's port of Java 1.4 for MacOSX.

I think that Apple will need to make its own tuning for the Client and Server VM on MacOSX before releasing Java 1.5, as Sun does not support the HotSpot JIT compiler on MacOSX or on other PowerPC-based systems (Both Apple and IBM are concerned, as well as those using Linux/PowerPC).

The QRP Empty column tells how many bits in the QRP routing sent by the remote client are zero. In LimeWire, these QRP tables are 64 Kbits, with 1 bit set per searchable keyword found in the shared files. If this table is empty (0%) there are no searchable keyword on this host (or no QRP table sent from it, if the QRP table size is shown 0KB, which means that this servent accept all queries and filters them itself before replying).

Generally, the higher the "empty" value, the best your UltraPeer will behave, as it will be able to not forward many queries to that remote leaf node. If a leaf node has a QRP table filled at 70% or more (30% empty or less), most queries will be forwarded to it, so QRP is not as much effective to limit the traffic to that remote host.

Note that for UP-to-UP connections, that now send each other a QRP table for the last hop, the QRP Empty level will grow with the number of leaf nodes that the remote UP supports and the total of files they share. It's not uncommon to see remote UP connected to you with the "QRP Table Empty" rate below 50%; this means that the QRP filtering optimization is not as effective as with higher values (commonly found with Leaf connections), but this still helps reducing the unneeded outgoing traffic (notably because most DSL and cable connections are asymetric and have a more limited available bandwidth for this outgoing traffic, and even a reduction of 10% will be helpful to maintain a lower usage for more responsiveness of your host).

QRP filtering is most effective for leaf-to-UP connections, simply because most leaf nodes do not share a lot of files, so they have a low percentage of QRP table filled (meaning a high percentage of QRP table empty). Previously this column was showing the *fill* level rather than the *empty* level now.

Thanks for the analysis.