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

[Jon Olson <olson at mmsi dot com>]

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