Re: Memory residence

[Andrew Haley <aph at redhat dot com>]

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.