LimeWire 4.1.5 Beta
 

The LimeWire 4.1.5 beta has been released. Pro users can download it from their personal download page. The free version is available at the LimeWire Beta Page.

LimeWire 4.1.5 adds the ability for Linux users using Java 1.5 (now in beta) to use the GTK look and feel.

Windows users may notice that the "LimeWireWin.exe" installers (both English & International) are now signed by "Lime Wire LLC." You shouldn't use any installer that doesn't have that digital signature. The signatures guarantee that they are the installers we created and are free of any bundled software or spyware.

In addition, LimeWire 4.1.5 contains numerous bugfixes and memory optimizations. These include:
- Vastly reduced memory requirements of LimeWire. LimeWire will use less memory when running as an Ultrapeer or a Leaf.
- Fixed saving metadata on OGG files when using Windows.
- The default shared library name for iTunes sharing now contains the current user's name.
- Many bug fixes/optimizations related to FW-FW transfers.

LimeWire 4.2 is very close to release. We have a few more bugs to iron out, and then you'll see LimeWire 4.2 available for download!

We owe a huge thanks to all open source contributors for their continued help in developing LimeWire, as well as a huge thanks to all the beta testers who report bugs and request features.

Thanks!
- The LimeWire Team

Re: LimeWire 4.1.5 Beta
 

Compared to what? If I compare the memory usage to what was used by versions approximately 2 months ago then the current version uses much more. It is that bad that I cannot let it run on my OS X machine if I want to do anything else.

Previously I left LimeWire running all the time and it was not that bad.

Compared to 4.1.4? Yes, it is bad that you can't leave it running. That is something we'd like to fix for OSX. Unfortunately, it's hard to track down. I've kept LimeWire running as an Ultrapeer on Windows for days on end and it works fine (hovering around 80MB usage).

Yes it's definitly an os x issue. As I told you in another thread, the problems arose with apple's java 1.4.2_05 developer preview 3 (DP3). The released version is less bad, but still sucks. I couldn't reproduce the problem on windows xp as well.

À+

Oh well, I also installed that update as it appeared on the Software Update Server. It could well be that it started with that update. Meanwhile I got a tip from Roger Kapsi to force the Java garbage collection regularly, and indeed that appears to help. I added this to my LimeWire.bsh file:

Is that normal that with the latest CVS version running as UP I have 12(!!) Bearshare connections? Also starting as a leaf yielded no connections attemps, I had to enable UP to get connections.

Ciao

hi all, good to see another changelog and beta to play with.

et voilà--FWIW--I disabled UP and the official beta 4.1.5 did connect as a leaf, but a bit more slowly. Went back to UP, which connected quickly as usual. However, no BearShare peers connected which is usual here.

The only connection oddity noted is that Quality = "Turbocharged" took much longer than usual (~5 minutes into the startup, and about 4 minutes after an incoming peer connected. Incoming leafs usually show up after the first minute.

Anyway, here are various notes on the beta--sorry I don't have time to organize them better.

Sam, could you explain more about What the "QRP Empty" column tells? I'm wondering if it's a way to get a feel for who is sharing/ freeloading. With the great growth in the network over the past few months, I expect to see more freeloaders (new users getting started). Sometimes the column is blank, as in the #4 (LimeWire/4.0.7) example

1. Leaf LimeWire/4.0.7 2:46:44 1.37% / 64KB 413 / 1023
2. Leaf morph410 4.1.1.252 (GnucDNA 1.0.2.6) 2:47:37 0.18% / 64KB 901 / 1016
3. Leaf giFT-Gnutella/0.0.10-cvs 2:48:33 0.37% / 512KB 6466 / 8189
4. Leaf LimeWire/4.0.7 2:49:06 0% / 0KB
5. Leaf LimeWire/4.0.5 (Pro) 2:49:13 5.89% / 64KB 17 / 1024
6. Leaf LimeWire/4.0.7 2:50:40 0% / 64KB 891 / 893
7. Leaf LimeWire/4.0.6 2:50:46 0% / 64KB 891 / 893
8. Leaf LimeWire/4.0.8 2:50:47 15.38% / 64KB 0 / 1024

I'm still exploring the keyboard changes such as the copy/paste additions, and quite like what I find. Any chance that copying an array can also add the column headers as a first row? This would help reduce screenshot clutter in the forum :) One oddity is that results separate nicely when pasted into a spreadsheet, but paste as a single object into TextEdit unless the document is made plain text. Java/platform behaviour?

Using the delete key to clear download entries is excellent--could it be extended to the Monitor entries too?

The warning message before deleting a file in the library is VERY welcome--thanks!--but calling up the dialog the first time spins the beach ball while the HD thrashes away for 10 or so seconds. This used to be a similar problem with other dialogs/windows such as choosing "About", but that one now opens much better.

Will Susheel Daswani be moving to the "former" category in the "About" credits? I noted that he's thanked as a former employee on the team web page. I'll miss reading his posts: had to learn to read them twice to enjoy the irreverence.

Small (e.g., 47k) quick downloads were faster than stats would report. Tooltips showed 0 time and 0 KB/s.

A table of keyboard shortcuts would also be a welcome addition to the Help menu, or TOTD.

Speaking of TOTD, the "Did You Know? Thank you for supporting LimeWire! We hope you enjoy LimeWire Pro." message might make more sense if it showed "Did You Know? LimeWire's development is mostly supported by Pro subscriptions! We hope you enjoy your LimeWire Pro and help spread the word."

A specific searching for content that is likely to have multiple sources looks good, and the results filter and sort quite quickly and smoothly (checked by searching for results for this month's version of "serial box mm.yyyy"). A search for "limewire" still triggers too many spurious results (1221/1,361 were .mp3's). "Rare" searches, though, have been disappointing recently (checked by searching for the latest ".#jum###) . No results were found searching for '5jum350', but the magnet worked. Is this related to Greg Bildson's comments on the GDF that "rare" file searching might be getting less effective as the network grows?

For magnets, The Alfie_Zappacosta_Start_Again.mp3 from magnetmix worked just fine (av dl speed from 3 hosts 161 KB/s, 260KB/s peak), and it smootlhly went to iTunes.

With iTunes integration, the other computer's iTunes playlist "LimeWire" showed the fresh download, so that part worked well here. I don't understand the iTunes Library->Shared Music very well though: I see a LimeWire playlist and also a "What's New" nested under a playlist called "stief's LimeWire" in iTunes and wondered if it's supposed to draw from the LW "What's New"? Gonna have to look more closely at whether I'm causing a recursion problem by sharing my Music folder in LimeWire, and setting iTunes for sharing too. Still, the "What's New" hints at something seriously cool for music lovers (but it opens a desire for photo lovers like me to have the same for iPhoto . . . ) ;)

Browse host is puzzling. Sometimes a browsed host will begin to display results, then the tab closes. Rarely are any of the hosts in Monitor browsable, and none in Connections. Is browse host being phased out?

Well--no time to check out more stuff like LAN transfers and HTML pages. Congrats to all once again--obviously many people were much more productive than I was this summer. :)

Thanks too to jum and Roger for the GC memory work--I'll try it out with the jum build this weekend after letting the offical version use the memory tonight.

The "What's New" playlist shows your recently downloaded songs.

Importing and Sharing overlap a bit and if you share your Music directory you will have a slight chaos and a recursion. I recommend to disable one option (importing of course :D ).

Sharing iPhoto Photolists (I have a patent on that new term! :D ) is planned but it has a very low priority at the moment as I have to recover from the productive summer.

Jum is probably already on the Baltic Sea towards Sweden (lucky jum) a small fix for the workaround. Well, you can set the interval to 60 seconds (60*1000 instead of 10*1000) to reduce the CPU load. Oh and honor to whom honor is due for figuring out this workaround: Zab! :)

Ah! Danke

I've sent Sam the screenshots/stats. Let me know if they're of use to anyone else.

I think the resources thing shoud be a priority, as Limewire is written in Java. For people with a slow/old computer, using such a program can get very annoying sometimes. It takes up very much time to load and you can do hardly anything when it's running.

Ivan
In the dark we make a brighter light

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.

Note about the new Limewire signature:
the current version LimeWire is exempt from spywares or bundled softwares, whatever "PestPatrol" says.

I won't recommand using "PestPatrol" to fight spywares, but use instead "SpyBot S&D" or "Ad-Aware" to clean your PC from Spywares. The later two do not report any problem in Limewire, unlike PestPatrol that makes many false assumptions. In addition, PestPatrol is not a free tool, and owned now by ComputerAssociates who bought it; this tool is outdated and lacks a serious support, whatever ComputerAssociates says now. It is many months late face to Ad-Aware and SpyBot S&D, which have a much more reactive support.

PestPatrol causes lots of problems because it has many false alarms and even removes core components of Windows, such as DLLs needed to support Wireless connections (the "Windows Zero Config" DLL that it falsely identifies as a spyware), or the handler for magnet handlers (that it falsely claims is a part of Kazaa). PestPatrol causes many softwares to fail, and in some cases, it also make your Windows installation unbootable as it destroys some DLLs needed by some device drivers.

In the past, Microsoft recommanded using PestPatrol as well as "SpyBot S&D" or "Ad-Aware", but now the reference to PestPatrol has been removed. PestPatrol needs serious corrections, and support by ComputerAssociates before it becomes reliable again. ITS CURRENT VERSION MUST NOT BE USED WITH Windows XP Service Pack 2 or on any PC with WiFi 802.11b/54g adapters. If you've got various connection problems in LimeWire, try uninstalling PestPatrol and using another anti-spyware instead... Then reinstall LimeWire to make it functional again.

BTW I'm using the developper connection apple java. There are still hangs. 1 gigs of virtual memory used after 36 hours of uploading. RAM usage seems lightier.

Ciao

Likewise I've been wondering of late about LW's use of ram, etc. Admittedly this is LW 4.0.4 but still, after about 12 hrs use it was using 414.6 MB RAM & 1.21 GB VM & the ram use seemed to still be increasing. (I gave up on 4.1.4 b/c it didn't seem to like the Macosx & Java update, & I haven't as yet utilised 4.1.5 though I installed it yesterday.) I could actually watch the ram use increase in tenths of MB every couple mins or so/less.

Could you please indicate on which system you see this increase of RAM usage, and where you detect it?
Virtual memory usage is not an issue if this is only "virtual" memory.

What is really significant is the amount of "committed" memory, i.e. the one that really takes space in the physical memory or on the disk swap.
What the Java VM does here to allocate ranges of virtual pages is not very important, as Java places a very low priority to the garbage collector, notably if you've got plenty of physical RAM and there's no other stress on the system where Java would be unable to complete a memory allocation without collecting unused memory.

But if this is an issue on your system, we need complete system identification:
i.e. the OS and the Java version you use. You can get these informations in the Options dialog, in Bug Report, see an Example button.

I don't see this issue on my Windows XP installation. So I suppose this is MacOSX specific (and knowing which Java version you use may help tuning the VM usage on that platform; it may be difficult to adjust on MacOSX if Java is already configured to use shared memory across multiple VMs, such as the MacOSX Java desktop or your browsers; note that the shared VM is specific to Macs, and it stores precompiled classes for future use, until there's an low priority event that indicates to the VM manager to free up some unused space or classes).

Please be precise if you want help from the relevant people.

Philippe, look in page 1 of this thread:)

Are you asking me or et voilà l'invité for xtra details? After just opening 4.1.5: LimeWire version 4.1.5
Java version 1.4.2_05 from Apple Computer, Inc.
Mac OS X v. 10.3.5 on ppc
Free/total memory: 7900304/21303296
That's a g4 733mHz (single proc) 1.5 GB ram, 2 x 120 GB HDD's.
I'll see how 4.1.5 goes over the next 12 hrs or so. By the way I have snapshots of previous cpu, ram & vm readings. I also recently created a thread Limewire's cpu & ram requirements?

If it was not me u were asking xtras details from then ignore these.

I also saw much RAM-usage. So much, that I had 1GB of free disk space before starting up limeWire, and after one night I had nothing left and my system complained, that it didn't have any space left.

I use OSX 10.3.5 With java version "1.4.2_05"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_05-141.3)
Java HotSpot(TM) Client VM (build 1.4.2-38, mixed mode)

80GB Disk, 1,25Ghz G4, 768 MB Ram.

In OSX no DiskSpace is quite critical, since the whole system slows down, when it has less than 500MB free and begins to crawl, when it has no space left (I'm used to having at least 5 or 6 Programs open at the same time).

I can't provide Active/Passive Ram stats at the mom.

Since I can't add images if I edit my post, the images below are an example of LW's heavy needs for osx & its ram climbing habit. LW 4.1.5 is the above image. Something else I've noticed that's odd yesterday & today is that 2 files get the 'Awaiting Sources' status despite I haven't forced resume anything (I rarely do.) It's happened 4 days in a row with the same 2 files.

where's windows(international) LW 4.1.5 beta?
 

I was using LW 4.0.8 for windows 98 SE and barely enough 128MB RAM.

I switch to 4.1.4 Beta few weeks back... then I noticed 4.1.5 beta and download it.... but until today I seems to download 4.1.4 beta although the web site are showing the 4.1.5 beta....

Just would like to know if LimeWire 4.1.5 beta of Windows (International) version available currently? and if yes is it cost more RAM than 4.1.4 beta (International) ?

Note that the Windows "English only" and "international" versions are both in fact equally internationalized for the LimeWire application itself.

The only difference is in the installer:
- the English only version uses an installer with English messages only.
- the International version uses an alternate larger installer that allows you to select first the language shown during the installation, and it also provides the international installation of the Java JRE toolkit.

If you already have installed Java 1.4.* or 1.5 on Windows using the Sun download site or the JRE update tool, or if you already have installed a previous version of LimeWire and want to upgrade, you probably don't need the International installer to install LimeWire. Just use the shorter English installer and it will let you run LimeWire in your language (the localization of Limewire at run-time is identical in both installations, and both installations will show the "Change language" menu option if you later decide to change the user interface language).

More generally, I recommand that you install Java separately from the Sun website or with the JRE Java update tool (look into your Control panel if it is not running in your system tray), and then install LimeWire "English only": it will detect your existing installation of Java and will not need to install it before proceeding with the installation of the application itself.

Thanks for this detail: I understand from your issue that the 1GB of virtual memory allocated is *committed*, because it takes space on disk. It seems that Java on Mac OSX has fogotten the distinction between virtual uncommitted memory and virtual committed memory (that just takes space in the virtual memory map of a single process to map virtual memory pages to uncommited pages or committed pages in real memory or on disk).

I looked into the Windows VM statistics and Java 1.4 and 1.5 DO USE uncommitted memory, and there's also a background thread that frees the unused committed pages in virtual memory to reduce the virtual memory space left unused. Something gets wong on MacOSX's Java ported runtime, as this thread may not be running as expected (probably because it runs only with a idle priority).

Note that the garbage collector will only free dead objects in the VM, to keep them out of the "Real" live memory or swapped memory. However the heap in which these objects were allocated wil remain committed, meaning that the swap space on disk will not be freed until the application memory heap is effectively reduced:

I suspect that the application memory heap can't be shortened due to a few small locked objects that can't be relocated in the process virtual memory map. Could it be desktop/shell objects related to the iTunes integration? Do you experiment the same growing VM if iTunes integration is disabled? If so, there may be a bug in LimeWire where some temporary references to native objects are not freed after use. (native objects can't be freed by the Java gargage collector and remain in locked, committed, state until explicitely deleted by the application)

There are a few other desktop/shell native integration objects in the MacOSX installation that may produce a highly fragmented VM with many pages locked by small locked, leaked, native objects. LimeWire MacOSX developers may need to look at this issue.

Well I know that my LW has iTunes support unactivated, DAAP and LW mp3 player are also unactivated but still experiencing the memory problem. Is seems lika an Apple issue though.

Ciao

I don't know if this is related, but Sun has confirmed to me that the Windows version of the Java Client VM runtime contains some leakage within the components that interface Java with local filesystem. Notably when there are security objects associated to a file or directory. There's a system-specific hook in the filesystem core-class which uses a native function through JNI, implemented in C, and that returns data structures allocated by the OS API or by native calls to the C/C++ heap. Then the native security structures are converted to fields in some Java security object, but the Java JNI interface requires several calls to the JNI method implementation to specify when we are finished with the temporary objects.

If there's an exception in a thread, that causes a thread to be aborted, the thread will die with dead Java objects that will be reclaimed in the Java VM garbage collector, but native security objects will remain allocated and not freed (a finalizer is supposed to call a cleaner method, but finalizers do not run fast enough in the ClientVM).

May be the GC thread patch tried before may also try to call finalizers before performing the GC. I suspect that class finalizers are never called as long as LimeWire is running, probably because these classes are still active and have other active instances. In Java 1.4 or 1.5, Finalizers run in a dedicated Finalizer thread, but with very long delays and low priority.

Calling Runtime.runFinalization() within the GC thread patch indicated in a previous message may help...

A comment from Sun about finalization is shown in old Bug id #4026510(not a bug, will not be fixed):
The way and frequency at which finalizers are implemented and run in Apple's version of the VM may make the difference (on Windows we have a dedicated background thread, but is it true on MacOSX?).

Note that I have not seen any use of finalizers in LimeWire classes. But finalizers are frequent in internal implementation core classes bundled with the JVM that perform integrtion with the native host system.

The English version, which is displayed in Spanish in my PC, is only about 40% translated. The other 60% is still in English.

Besides, it doesn't use the same word for the same thing in two different places. For instance, if I download from one user, it says "descargando de una máquina", when I download from two it says "descargando de 2 usuarios" (or the other way round, I don't remember), and when it can't download it says "need more sources".

Ivan
In the dark we make a brighter light

The title "English installer" and "International installer" is somewhat misleading -- the only difference between them is that the English installer uses InstallShield and does not require that Java 1.3 is used, whereas the International installer uses InstallAnywhere and installs Java 1.3 (and enforces that LimeWire use it). You'll actually see better performance if you install an international JRE of Java 1.4 or higher and use the English installer. We're exploring ways to update the international installer.

You can help us improve the translations by going to http://limewire.org/translate.shtml and seeing how to submit newer translations. The Spanish translation is only 65.22% complete right now -- any help we can get to raise that number would be much appreciated.

Note that the international support is much better in Java 1.4 or even better in the new Java 1.5 Release Candidate. With the "international LimeWire installer", Java 1.3 is installed in a "jre" subdirectory of the LimeWire installation folder.
I personnally don't use or need the international InstallAnywhere installer. Additionally, its larger size does not come from the international translations of LimeWire (which is also present in the English-only InstallShield installer), but only from the fact that it bundles Java 1.3 with its international charsets support.
So install Java 1.4 or 1.5 separately, with its international version.
Then just download Limewire with its english-only InstallShield-based installer, and you'll get the same language options in Limewire.

We have just renewed the "Help internationalize LimeWire" page with a script that automatically refreshes the translation status of LimeWire messages bundles. It no longer needs manual editing. If you look at it, you'll see that Spanish is effectively now below the quality level that users would expect. Translators are welcome to improve the translation and add the few new missing items, or to suggest enhancements.
See my signature below.

It's good to see www.limewire.org back online again. Aubrey has been busy and I like the new look.

I hope http://www.limewire.org/awards.shtml will be updated soon too (it's been a year).

So what will you work on next Philippe (NIO?), and did slashdot ever review your sha optimizations?

BTW, you do point to http://www.guox.de/gwebcache/
for information on web caches. I once tried to convince the author of this page to include my Java Servlet
based version into his list, but he did not listen.

--searching for "rare" files has been pretty poor lately. I search for the latest jum . . .

any type "5jum352"

or variations thereof and only get 60 of those spam .wmv and .jpg results, which give too many IP's to block.
(the http and magnet links are successful--it's just the LW searching that won't find it).

--Anyone else seeing odd result for popular files in tooltips? Although >1000 sources are discovered, the file only downloads (slowly) from 3. Blame the spammers?

I like it too. Aubrey's work on graphic design for the web site and even on LimeWire client's look and feel is appreciated. She's probably very busy because we waited for that work since long.
Thanks also to Sam for working on the script to refresh the translation status page, and more generally to the LimeWire team to make limewire.org live again after the migration of servers and tools.
Gregorio Roper should be the next one, in my opinion. I think this is the opinion of other LimeWire crew members.
I don't know. I've been busy and not connected very often on the Internet since last June. May be I'll have more time in the next weeks. For now I just review some code and test it, but I have not developed serious things on LimeWire since 4 months.
I don't know. I just informed them about this code (on http://www.rodage.org/pub/java/security/) as well as Sun. This was also used by Sun because it revealed a bug in the HotSpot compiler of the Java Server VM (this bug normally does not affect LimeWire as it uses the Client VM), as well as some other performance issues. I've received various responses from Sun about it. For now, Sun will not change its implementation, as it is busy working on the 1.5 release coming soon, and its feature list is now closed. Sun is also working on porting and checking its core library to support generic types (a concept similar to C++ template types), and there are still some compiler quirks to solve with the new language definition and reference implementation. Also Apple is still finalizing its port of Java 1.4.2. Other JCE rity providers have received a copy of my version. They will do what they want with this code. But my search on this subject helped me to reveal how HotSpot works and where performance bottlenecks appear (these areas are not covered in the Java Language specification, and not even in the Java VM specification). I have tested this code with other VMs and it's interesting to see that my optimizations benefit to all of them, even if their implementation is very different, or they work with distinct platforms/processors.

I have discovered when working on this code that the Java VM HotSpot compiler uses internal fixed-size static structures to compile the Java Bytecode, and that this has a great impact on performance due to arbitrary limits that are documented nowhere in the Java language and VM specifications. This is certainly a place for improvement in future VM versions (I consider that these arbitrary limits are a bug, Sun considers this is rather a RFE, even if my code also solves a few possibly critical security issues in multithreaded environments; anyway, my code is now included in the Sun Java VM regression tests used by its developers, as the current limits in HotSpot are not coherent between phases C1 and C2 of this runtime compiler).

Thanks for the info. Yes, Greg Bildson has kept the project going through lots of changes in people, and making the opensourcers (both hired and volunteer) an important part of the team sure looks like it works. I too like his contributions (i.e his current work with torrents), and I expect that Jens-Uwe Mager and Roger Kapsi will be recognized on the .org page too.

[OT]I don't code, but your remark that the java VM HotSpot compiler uses internal fixed-size static structures reminded me of some Console messages I've been seeing lately on OS X
"stiefs-iBook kernel: resize: max chain len 40, new table size 8192" Any chance this is related?[/OT]

If you're looking at the code, I'd be interested in what you find about 'browse host' and 'ethernet' transfers :)

The "internal fixed-size structures" in the Java HotSpot compiler is not related to this message. It is related to the way methods calls and method entries are encoded, with strange limitations on the supported method signatures (the count and types of parameters).

These limits on supported method calls are really not intuitive and they way they can be fixed is opposed to the normal OOB programming philosophy of Java:
- sometimes this requires creating temporary work classes to pass these method parameters.
- sometimes some large methods need to be splitted in the source code by the programmer into smaller sub-methods even if the method size is below the threshold of about 4KB of bytecode.
- some small methods fail when HotSpot try to inline them in the compiled native code, or will run much slower if they are not inlined manually directly in the source code.
- the methods profiling performed by HotSpot to determine which methods should be inlined is based on a threshold number of past calls. But this counting does not work for all calls, so some methods may never reach this threshold, even if they are used extremely often. These small methods are nearly never compiled to native code and run slower.
- more generally, the rationale of these limits is not clear, and one needs to profile the application in its critical code parts to see which coding style will work best.

You can diagnose the cases where methods will not be compiled to native code at run-time by HotSpot (and then will run in a much slower interpreted mode) with some undocumented flags on the "java" command-line or set by the JVM instanciation program (such as limewire.exe on Windows): it displays "COMPILATION SKIPPED" messages on the console.

[removed odd link to picture]

Hash not working correctly?
 

new bug--can anyone else confirm?

-I searched for DSCF0025.jpg in "Any Type", and most of the results incorrectly showed the green "checkmark" icon.

details
-jum 352
-I had two pics of different sizes with the same name already (1 shared, 1 in the unshared download folder) downloaded
-search returned ~200 results, 169 unique files ranging from a few KB up to 4 MB from about 8 different vendors

btw--searching for home collections of digital camera shots is a fun way to either discover the next Anselm Adams, or else to make you feel good about your own abilities :p

The green checkmark isn't based solely on hash -- if a file exists by the same name, it'll mark it also.

can the checkmark be easily made to reflect the hash? I'm assuming results are grouped based on hash . . .

OpenGL or incorrect display of icons.
 

With the recent changes to support Plastic themes, I experiment now problems when displaying some icons: they are unstable, sometimes the wrong icon is displayed for buttons, and the selected icon changes sporadicly. In a row of graphic buttons (for example tabs at the top, or the row of action buttons for the search results), it happens that all these buttons are showing the same icon, and then they change without user action, or when the mouse cursor passes over it.
However this never happens for the small icons of media selectors, or for file icons.

I think that this is related to the new message I see on the console when starting LimeWire:

OpenGL pipeline enabled for default config on screen 0

(this message appears as the first line of output, before any other debug output generated by LimeWire itself, after that Java VM has been created but still when LimeWire is loading).

Is it possible that the recent Microsoft patch for GDI+ in Windows XP has changed the behavior of Java2D for JPEGs, but possibly too for GIFs and PNGs?
(Note: I see that with the most recent version of the JDK 1.5-beta2)

Is it a bug of Java, or Windows, or of the Plastic Theme integration?
I don't see this message in other Swing apps with the same VM on the same host. I can't see why LimeWire would need OpenGL here, or what can cause Java2D to enable it. Apparently the display bug looks very much like a synchronization issue in the management of the graphic renderer (would it use a pipeline which does not work properly with OpenGL?).

I tried with the Java 1.4.1 JRE, and I have the same display problem (but not the OpenGL message above). Is this bug within the new PlasticTheme library? Does it use OpenGL?

Try adding "-Dsun.java2d.opengl=false" to the parameter for starting java. I've noticed at home that openGL is enabled by default on Java5 and basically made LimeWire look like a blob of splattered paint.

Yeah, the checkmark can be made to reflect only the hash -- but it wasn't intended to be a 100% exact match. It's designed to let you know you probably have this file -- hashes are a surefire way, but the filename is also a pretty good way. Perhaps the filename should also include a size check, ensuring that the two are similar sizes? Or maybe a blue instead of green checkmark for the filename matches. Grouping is still done only by hash.

Salut Sam, I was thinking about hash and files and got a little idea. Often you get results of files with the same size and same name but different sha1. An optimisation would be that once you download one file LW gets the tiger tree of the other files with same size same name: if some trees correspond, LW downloads from both files (more sources). The tigers that differ are only downloaded on the the file selected to dl by user. Of course you don't add sources with different sha1 in the download mesh.

I had another idea for uploads but I forgot it today;)