Memory residence

Wed May 25 15:06:00 GMT 2005

Bryce McKinlay writes:
 > Andrew Haley wrote:
 > 
 > >shudo@computer.org writes:
 > > > > 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
OK. I've been getting very conflicting answers about this from
different people.
 > - 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.
It would be good to get some profile data on Eclipse startup so we
know for sure.
 > > > Can it be improved somehow?
 > >
 > >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.
 > > 
 > >
 > 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,
AFAIK it is already resolved with the latest gcc. I wonder if we
could try again.
 > but I doubt this has a significant effect on startup time.
So do I.
Andrew.