>>>>> "Chip" == Chip Turner <cturner@xxxxxxxxxx> writes: Chip> I think at best the jury is still out on how fast gcj is Chip> vs a hotspot-optimizing jvm for "real world" use. Best performance depends on a lot of factors, not just your application but also how you plan to deploy it. For instance, using gcj to build shared libraries may be a winner when you expect to be reusing that library in several running processes, even if the generated code looks marginally slower. gcj and hotspot-like JITs have different optimization opportunities available to them. Another factor is how you compile your code with gcj; the new binary compatibility ABI provides flexibility at the cost of some performance. The usual answer is "try your program and see". On smaller-than-real-applications benchmarks, gcj fares pretty well against the best JITs (especially considering how few gcj-specific optimizations we've added to gcc, e.g. we still haven't implemented array bounds check removal). The 1.5 release from Sun looks like it pulled ahead a little bit, though you can still construct tests where gcj does better. I would expect some bounce from gcc in the 4.1 time frame, though, as more high-level optimizations are written. As a practical matter touching on Fedora, gcj remains the "best" way to deliver java applications on a free system. In my opinion, other free VMs have unacceptable performance, unacceptable platform coverage, or both. Tom
