Eclipse java compiler

[tin]

Hi everyone,

I've read a few rumours on the web about ejc, a natively build version
of the Eclipse compiler. Apparently, someone managed to compile the
eclipse compiler using GCJ and it runs really fast:

http://sources.redhat.com/ml/rhug-rhats/2003-07/msg00008.html

Has anyone managed to repeat this?

It appears that this compiler is distributed with some Linux versions.
A new fast compiler would be great as Jikes is no longer being
maintained and the world is drifting towards Java 1.5, unsupported by
jikes. If the native Eclipse compiler indeed is super fast and
compiling on various platforms is possible, I would like to make it
publicly available on many platforms under the Eclipse open source
licence.

Anyway, has anyone managed to repeat this? So far, I have managed to
pull out all the compiler source code and compile it into normal java
bytecodes. As it is, this runs slightly slower than javac and
significantly slower than jikes. As far as native compilation goes, the
program compiles but crashes. I believe it has something to do with
dynamic loading of resources (normally done from the CLASSPATH). I have
no experience with GCJ or native Java compilation so I may be missing
out a step (compiling the resources maybe?)

the command i am using (on Windows) is

gcj ejc.jar --main=org.eclipse.jdt.internal.compiler.batch.Main -o
ejc.exe

(where ecj.jar contains the required CLASS files + the resource files)

If anyone has managed to compile and run the compiler successfully or
is interested in helping out with this, any help would be appreciated.

Cheers
Tin

 

[Roedy Green]

I've read a few rumours on the web about ejc, a natively build version
of the Eclipse compiler. Apparently, someone managed to compile the
eclipse compiler using GCJ and it runs really fast:

Jet is also supposedly able to natively compile it. See
http://mindprod.com/jgloss/jet.html

 

[tin]

Yes, I have managed to compile it using JET but this resulted in no
performance improvement. Maybe in this case there is no performance
improvement with native compilation, or maybe JET doesn't do the job
well.

Has anyone actually used eclipse-ecj, which comes with some linux
distros? Is it fast?

Cheers
Tin

 

[Roedy Green]

Yes, I have managed to compile it using JET but this resulted in no
performance improvement. Maybe in this case there is no performance
improvement with native compilation, or maybe JET doesn't do the job
well.

Surely it started up faster??

 

[Luc The Perverse]

Jet is also supposedly able to natively compile it. See
http://mindprod.com/jgloss/jet.html

Would perhaps some benevolent individual who already has Jet be willing to
share the natively compiled version?

 

[tin]

Surely it started up faster??

I ran a few experiments and javac ran faster in all of them. I wouldn't
call it a thorough investigation but it was fairly convincing. It is
hard to measure how much of the time is startup and how much is
compilation. Perhaps the bought version of JET performs better. I used
the trial version.

 

[Roedy Green]

I ran a few experiments and javac ran faster in all of them. I wouldn't
call it a thorough investigation but it was fairly convincing. It is
hard to measure how much of the time is startup and how much is
compilation. Perhaps the bought version of JET performs better. I used
the trial version.

you mean java.exe. Jet used Javac.exe to prepare the class files.

Did you have a lot of dynamic loading of classes not known to jet at
compile time?

 

[tin]

no, i mean javac.exe. it compiles code faster than the eclipse compiler
compiled with JET. as far as I know, there are no dynamically loaded
classes, although some resources are loaded through the class loader.

 

[Roedy Green]

no, i mean javac.exe. it compiles code faster than the eclipse compiler
compiled with JET. as far as I know, there are no dynamically loaded
classes, although some resources are loaded through the class loader.

Compilation speed of an optimising compiler is generally not a metric
of interest. You only do it as part of major builds and use the
standard compiler for rapid compile/debug cycles (e.g. in Eclipse).
What you care about his how fast the generated code runs.

 

[ChrisWSU]

Compilation speed of an optimising compiler is generally not a metric
of interest. You only do it as part of major builds and use the
standard compiler for rapid compile/debug cycles (e.g. in Eclipse).
What you care about his how fast the generated code runs.

Amen!

 

[tin]

I think you guys have misunderstood my question. I will try to be more
clear. I am looking for a very fast compiler. Jikes used to do the job
well but does not support 1.5.

Javac and the eclipse compiler are good compilers but are too slow (I
am dealing with a lot of source code needing to be compiled), so I am
looking for a fast alternative. My idea was to compile the eclipse
compiler natively in order to improve its speed. Apparently this is
possible and has been done before.

 

[Roedy Green]

I think you guys have misunderstood my question. I will try to be more
clear. I am looking for a very fast compiler. Jikes used to do the job
well but does not support 1.5.

Are you using ANT? If not that, that should drastically speed up your
javac compiles since it loads javac only once no matter how many
modules you compile. Most of the time of a Javac compile is lost
loading Javac. Once it gets loaded, it whips along quite fast.

see http://mindprod.com/jgloss/ant.html

 

[Luc The Perverse]

Are you using ANT? If not that, that should drastically speed up your
javac compiles since it loads javac only once no matter how many
modules you compile. Most of the time of a Javac compile is lost
loading Javac. Once it gets loaded, it whips along quite fast.

see http://mindprod.com/jgloss/ant.html

Cool

This could help as well

http://www.newegg.com/Product/Product.asp?Item=N82E16819103558

Keep your code in a RAMDISK, and try to keep as much ram as possible to
prevent anything from using virtual memory.

 

[Roedy Green]

Keep your code in a RAMDISK, and try to keep as much ram as possible to
prevent anything from using virtual memory.

Have you tried that? I would think it would be counterproductive. The
compiler could probably better use the extra ram for workspace --
symbol tables and the like.

 

[Luc The Perverse]

Have you tried that? I would think it would be counterproductive. The
compiler could probably better use the extra ram for workspace --
symbol tables and the like.

I have never had enough ram to try that But I figure if you have 4 Gbs
of RAM or maybe more under a 64 bit OS it could be feasable.

In the spirit of my original post, if one is spending cerca 1000$ for a
processor to increase compilation speed, spending the extra money for a few
extra gigs of ram or some SCSI hard disks would likely make sense too.

For me I'm usually working with a small piece of code, then I try to compile
and it fails with errors. Then I correct an error and repeat. The amount
of disk space for my needs would be very small - perhaps I will try it

I use a windows XP OS - I wonder . . . I wonder if there is some way to
tell Windows to favor caching of the files used in the compilation . . .

 

[Alex Buell]

I use a windows XP OS - I wonder . . . I wonder if there is some way
to tell Windows to favor caching of the files used in the compilation

Try using Eclipse on Linux instead.

 

[Luc The Perverse]

Try using Eclipse on Linux instead.

.. . .

Ok - though this has not aided my wonderment

 

[Missaka Wijekoon]

Has anyone actually used eclipse-ecj, which comes with some linux
distros? Is it fast?

Yes and it was different enough (or broken) that I had a hard time
making it do anything useful. I uninstalled it and downloaded Java 1.5
+ Eclipse and everything works well now. BTW, my old computer ran Linux
+ Eclipse + Sun JDK 1.4 on a 1Ghz PIII with 1 Gig RAM. It was not
slow...so I am not sure how much gain ECJ will get on a modern day machine.

Honestly I find that JIT works really well once the app is loaded and
running. Frankly, Eclipse compiles Java faster than a C compiler
compiles C...it's all perspective I suppose.

-Misk