On Wed, 2005-03-09 at 15:04 +0000, Andrew Haley wrote: >Ziga Mahkovec writes: > > On Wed, 2005-03-09 at 14:44 +0000, Andrew Haley wrote: > > > Ziga Mahkovec writes: > > > > On Wed, 2005-03-09 at 14:08 +0000, Andrew Haley wrote: > > > > > Ziga Mahkovec writes: > > > > > > Thanks Andrew, I put the steps and log files here: > > > > > > http://www.bootchart.org/misc/ecj/ecj-native.html > > > > > > > > > > You didn't try > > > > > -Dgnu.gcj.precompiled.db.path=/usr/lib/eclipse/eclipse.db without > > > > > jdtcore.jar.so. > > > > > > > > Updated page. I guess this is the same as running interpreted, since > > > > most of the class lookups fail. > > > > > > It is: it seems that you don't have a precompiled version of > > > /usr/share/java/jdtcore.jar in your eclipse.db. Either that, or the > > > corresponding precompiled library isn't readable. > > > > The corresponding library > > is /usr/lib/eclipse/plugins/org.eclipse.jdt.core_3.1.0/jdtcore.jar.so > > right? > >I would guess so, but I don't know. > > > I do have it in eclipse.db, but for the last two tests I renamed it, in > > order to force tools.jar to not use the gcjlib:// class loader. > >I see. Of course, I have no idea why tools.jar is attempting to use >the gcjlib:// class loader, or why it is so slow when it does. It >really should not explicitly use this class loader. > I doesn't any more. We were doing that to avoid having to always add jdtcore.jar to the classpath. I also have no idea why it's so slow but I did notice a significant performance hit when compared to interpreted mode. Ziga, you can get the sources for java-gcj-compat from sources.redhat.com: cvs -d :pserver:anoncvs@xxxxxxxxxxxxxxxxxx:/cvs/rhug co java-gcj-compat I've removed gcjlib:// loading in favour of using the database, so when everything's set up properly ecj should run natively using jdtcore.jar.so. Tom
