GCJ for eCos

[Andrew Haley]

Boris Kolar writes:
 > I think it would be a good idea to split java (the language) from libraries.
 > That would make gcj suitable for embedded systems. C compiles HelloWorld
 > application to 5K,--

gcc -hello.c 
-rwxr-xr-x    1 aph      other       13064 Jun  6 11:22 ./a.out*

g++ -O2 hello.cc 
-rwxr-xr-x    1 aph      other       14804 Jun  6 11:29 ./a.out*

gcj Hello.java --main=Hello
-rwxr-xr-x    1 aph      other       16152 Jun  6 11:20 ./a.out*

Not much difference there.  

gcc -O2 hello.c -static; strip a.out
-rwxr-xr-x    1 aph      other      373340 Jun  6 11:38 a.out*

g++ -O2 hello.cc -static; strip a.out
-rwxr-xr-x    1 aph      other      863156 Jun  6 11:38 a.out*

gcj Hello.java --main=Hello -O2 -static; strip a.out
-rwxr-xr-x    1 aph      other     2165112 Jun  6 11:39 a.out*

So, statically linked java is bigger than C++, but only by about a
factor of two.

 > while java still produces static executables of over 1M size
 > (tested for mingw).

For what it's worth, I would support a scheme to build subsets of
libgcj for embedded use.  It requires careful design and a good deal
of thought, but I'm sure that it's quite possible.  The trouble at
present is that when we link statically we have a bunch of random
bugs, not a well-designed solution.

An embedded Java subset need not even have garbage collection, for
example.  Reflection support can be removed, and therefore reflective
data can be removed also.  But the gc uses reflection metadata, so if
you want garbage collection some of that information must stay.  The
real issue is how to design a Java subset that will be useful for
anyone.  Javasoft(tm) already have some models that we might follow.

It's a big project, but an interesting one.

Andrew.