Done with Gcj? Send us a link or a story!

Wed Jun 28 13:59:00 GMT 2000

Here's one of the more unusual applications in which we're using
`gcj' on an embedded StrongARM processor to control autonomous
trucks in mining haulage systems:
	http://www.mmsi.com/modular/trucks/index.html
Note that I'm not using libgcj, but rather an in-house runtime that
I wrote. I'm still using the original posted version of `gcj' from September
1998 compiling byte code produced by `javac'. I started working with
`gcj' about January 1999, got a pretty reliable embedded runtime
working by late Spring of 1999.
My main problems with `gcj' have been:
 1) The exception mechanism needed alot of rework. The code generated
 by `sjlj' exceptions is buggy and pregnant. I now have a very
 lightweight exception mechanism which also collapses all the monitor
 entry/exit exception ranges. The only thing I'd still like to do is
 good integration between C++ exceptions and Java exceptions.
 2) My version doesn't support compiling inner classes. Guavac proved far
 too buggy and couldn't properly compile source modules which contained
 circular dependencies. Jikes generated alot of dead code and produced
 very poor byte code. The only byte code compiler that produces good
 enough code for `gcj' is Sun's javac.
 In JDK 1.2, Sun changed the order in which fields and methods get emitted
 into class files. JDK 1.1 and earlier used declaration order; JDK 1.2
 decided to change it to lexical order. This causes big compatibility
 problems code compiled using JDK 1.2 javac now shuffles all the vtables
 and fields around. Since Java states that VMs cannot make any assumptions
 on class file ordering `gcj' really needs some way to impose a
 deterministic ordering when compiling bytecode.
 3) The class metadata weighs in at about half the total size of the compiled
 binary. In a disk based system with gigs of space, this is unimportant
 but in an embedded system, a Java binary is double the size of the
 equivalent software written in C++.
 Much of this overhead could be recovered by designing a compressed
 metadata format which the runtime only decompresses when a Java
 application first needs to perform introspection.
-- 
Jon Olson, Modular Mining Systems
	 3289 E. Hemisphere Loop
	 Tucson, AZ 85706
INTERNET: olson@mmsi.com
PHONE: (520)746-9127
FAX: (520)889-5790