big project ported

[Steven Ashe]

Just finished porting a fairly large java project to run under gcj
compilation.  It is an image processing and acquisiton program that
includes a Python-like interpretive language that controls it.
It has lots of C code too, and now has #ifdef CNI / #ifdef JNI
on all the native interfaces.
It required working around some gcj-2.95.1 problems, but they weren't too
bad.  We have a java preprocessor (no macros, but it does have #ifdef),
so the gcj specific changes, like getting rid of the System.load calls,
were easy.
The good news is that it works.  The bad news is how fast it (doesn't) run.
Since the project includes an interpretive language fully implemented in Java,
running tests on that language pound on java pretty severely, especially
because it's 'memory' is all associative.  When running the standard
benchmark which consists of some 100000 loops of some arithmetic, conversion
to String and storage (in the outer language), I got
ibm-jvm for linux 1.1.8  2.36 sec
gcj -O2 compiled 2.95.1  7.43 sec
(The libgcj is built with no threads.) This, boys and girls, is more than a few
percentage points difference!
We also have unrelated gc weirdness.  Since we can run GC from the outer
language, we can look at what's happening: 1) When making huge arrays and
discarding them, the Boehm GC collects everything the jvm does (good news).
2) Sometimes, when manually forcing gc, it takes an unacceptably long time
(many seconds) for the Boehm GC to run; 3) sometimes running the gc
back-to-back causes the second run of gc to 'consume' 2 Mb out of
no-where (weird).

A lot of effort went into making this a gcj-compiled executable, and I'd
really like to continue along this path, rather than revert to Toba, or
shell out big-big-$ for TowerJ.
--> If you gcj folks can suggest some additional tests, maybe I can help
find out what's awry.

-Steve Ashe