another compiler better than gcj ?

Sat Oct 20 22:54:00 GMT 2001

magnus persson wrote:
>check out this compiler:
>> http://www.cs.vu.nl/manta/
>>it is for java, parallell execution on several nodes, has awt and many libraries. It seems very fast...
>
I had a play with this today. I was impressed. It didn't manage to 
correctly run all the benchmarks I tried, but for those that did work it 
generated some very slick code, blowing away both GCJ and the IBM JDK at 
nearly everything I tried (mostly numerical tests), except for Hans's 
GCTest.
Here's some numbers. GCJ is version 3.1 20011016 with "-O2 
--no-bounds-checks". IBM is "J2RE 1.3.0 IBM build cx130-20010626". Manta 
is version 0.1 with no special options given. All results on Linux 
RedHat 7.1, 650Mhz mobile P3.
Sieve.java (Iterations/sec, bigger is better):
IBM: 3511
GCJ: 4551
Manta: 6100
SciMark 2.0 numerical benchmark composite score, bigger is better:
IBM: 56.51
GCJ: 103.00
Manta: 117.68
GCBench time (smaller is better):
Manta: 20140ms
GCJ: 11985ms
IBM: 6438ms
ShellSort 1000000 (time, smaller is better)
Manta: 3485 ms (!!)
IBM: 7582 ms
GCJ: 18741 ms
jBYTEmark failed to run correctly on Manta.
In principle it works pretty similar to GCJ. They have a libruntime.so 
and a libjava.so which compiled binaries link against. It looks like the 
compiler generates an .s file and then calls gcc to assemble and link 
it, but there are some other interesting things going on too (what are 
the .jac files?). The compiler has separate front-end/back-end 
architechture like GCC, theres a C front end and back ends for several 
platforms, though it seems only x86 is complete/supported.
Their class libraries are a mixture of kaffe and classpath (I spotted 
some of my collections code in there...), and they have AWT which looks 
like Kaffe's with some javax.swing stuff added. My AWT test app worked 
but it was a bit glitchy, not refreshing the window properly sometimes.
It seemed to have no problem compiling any of the java source I threw at 
it, though it did seem to have an annoying habit of trying to parse 
random .java files from the current directory/classpath, and error 
messages seemed non-intuitive.
Also on the downside, the compiler itself is quite slow (I estimate it 
took at least twice as long to build the class libraries as it takes to 
build the entire gcc tree...), and the binaries it produces average 
around 2 - 3 times larger than GCJ's (Hello world is about 80K vs. 20K 
for GCJ). Start up cost of their runtime is also a lot higher, Hello 
world taking >500ms to run vs <100ms for GCJ. There is no apparant easy 
debugging option, as the symbols they use arn't a standard mangling that 
GDB understands. Its a PITA to use too, having to run the compiler 
separately for each file you want to compile, with "-c" for each class 
that isn't the main class: wheres the --main option?
It has -no_cast_checks and -no_bounds_checks options. When I modified 
Sieve.java so that it would trigger an ArrayIndexOutOfBoundsException, 
Manta failed to throw even with bounds checks enabled, yet it worked for 
a trivial test case - so it may be doing some bogus optimizations.
Bryce.