This is the mail archive of the
mailing list for the Java project.
Re: Memory residence
Andrew Haley wrote:
> > Generally speaking, AOT compilers like GCJ are known to be
> > advantageous to JVMs which interpret and/or compile Java bytecode.
> Also in start-up time of an application.
> I measured the time to start up Eclipse 3.1M6 with Sun JDK, IBM JDK
> and GCJ 4.0 on a linux computer. GCJ 4.0 and a compiled version of
> Eclipse is part of development version of Fedora Core 4.
> Sun JDK 1.5.0_03: a little over 11 sec.
> IBM JDK 1.4.2 SR1a: 15 sec.
> GCJ 4.0: 27 sec.
> Note that IBM JDK provides a single JVM (and JIT) optimized for both
> throughput and start-up time while Sun offers HotSpot Server VM and
> Client VM for each goal. The way IBM took is more challenging.
> Anyway, GCJ-compiled native binary took much time to start up.
For what it's worth, we haven't been able to duplicate this. Our
tests have shown the startup time of Eclipse under gcj to be good.
Unfortunately, Eclipse startup isn't all that good in our experience -
as you noticed, it is significantly slower than Sun's JVM. I think we
can do better. A lot of the startup time is spent in ld.so symbol
resolution, which should be drastically reduced once remaining ABI
issues are resolved and we can switch to using mostly private symbols.
> Can it be improved somehow?A few key .jars in Fedora Core 4's native eclipse are still run
interpreted (not natively compiled) due to a miscompilation bug - we'd
expect performance to improve once this is resolved, but I doubt this
has a significant effect on startup time.
I suspect so, yes. We're soon to be investigating profile data of gcj
runtime with a view to doing some tuning.
> Or, does gij run in much part of Eclipse?
Possibly, but I doubt it. Have a look at /proc/PID/maps to be sure.