Another Experience using GCJ as an embedded compiler

Tue Mar 30 22:07:00 GMT 1999

Hello Mr. Olson,
 Incidently, even we have been working on this GCJ code for the past couple of months
- part time only. We do have certain similar observations. The embedded platform we use
is an NS486 based board running vxWorks. I would first like to join you in thanking the
people who made the GCJ compiler. It is really useful!
Our focus in this experiment. however, has been a little different from yours:
 Firstly, we tried to measure the performance gain by compiling classes using GCJ. We
integrated the GCJ output with our JVM runtime . This needed some changes to the
class/method meta data structure and bulding of the dispatch table, etc. This was
required in order to align the classes that were dumped with the structures used by our
runtime - specially due to some new class loaders that we support in our JVM.
As I had written in Dec 98, the Embedded Caffeine benchmark figures were very
impressive! We obtained a 27x improvement in ECM figures with Cygnus compilation!
After this, we looked at the following issues:
* Exception handling:
 As you had very rightly pointed out, the sjlj approach to exception handling in
GCJ needed modification. However, instead of modifying the data structure as you did, we
took the approach of expanding the code generated after every catch of an exception to
check for exception type and rethrow if required. This also eliminated the second jmpbuf
required for the finally clause.
* Automating the list of classes:
 I noticed a discussion on this list some time ago about the difficulties in
deciding all the classes to compile natively. We have developed a tool to find all the
static/dynamic class references from an application and invoke the GCJ on these classes
to generate a library. Here we modified a tool that we already had and it takes care of
the classes loaded through 'forName' too.
* Dynamic loading of Java classes: (GCJ + JAVA)
 Co-existance of native code and Java code was our next focus. While the 'closed
compilation' of classes required by Cygnus is good and produces efficient code, we loose
the dynamic loading capability of Java that is specially required for embedded systems
that would act as application servers. To bring in this, we enhanced on the GCJ front
end with a "-CJI" or "-java" option. CJI for Cygnus Java Interface. This option is used
by GCJ to generate heavier code at calling points (invoke interface and invoke virtual).
We now have an environment that takes a set of classes that are gcj compiled and works
working well even if the classes loaded thru' forName() are NOT GCJ compiled.
* Exception handling in mixed environment:
 Currently, we are testing the exception handling in this mixed environment.
Trying to catch an exception in Native code that is thrown by Java code and vice versa,
with multiple nested calls intersperced, etc
 Our immediate future plan is to break the 'closed compilation' requirement of the
GCJ approach - and allow selective compilation of classes. We have the design for this
and plan to take up the implementation after the above step. Even though this will
result in a loss of performance to some extent, we beleive that there is a need for a
compromise between speed and dynamic nature of the application.
 Comments are most welcome.
 Are there any more such efforts??
Regards
Geetha
Jon Olson wrote:
> For about the past 4 months I've been working with, on, and underneath
> the hot new GCJ frontend for compiling Java class files to native code.
> Before I enumerate its current weaknesses, let me thank the people at
> cygnus for this wonderful tool. I've used this compiler to build an
> entire Java run-time environment and, even though I'm still using the
> original 980906 alpha version, have found it to produce quite reliable
> and efficient code.
>> For an embedded environment, GCJ currently has numerous deficiencies.
> I've overcome most of these with quite nice implementations and hope
> that sometime in the future these changes can be integrated into the
> released version of GCJ.
>> 1) Lightweight exceptions
> ...
> 2) Write barriers
> ....
> 3) JVM `jsr' instructions
> ....
> 4) 64-bit code
> ....
> 5) Size of compiled metadata
> .....
> 6) Interface calling mechanism
> ......

> Is anybody currently considering or working on such an implementation???

> If not, this is my next project for GCJ.
>> --
> Jon Olson, Modular Mining Systems
> 3289 E. Hemisphere Loop
> Tucson, AZ 85706
> INTERNET: olson@mmsi.com
> PHONE: (520)746-9127
> FAX: (520)889-5790

--
 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
 / "IT IS WONDERFUL TO BE ABLE TO SEE!!" \
 \\\\ / PLEDGE YOUR EYES TODAY \ \\|//
 /. .\ / AND \ /O O\
 \ - / / GIVE LIGHT TO TWO PEOPLE \ \ v /
***************************************************************************
Geetha Manjunath, Fax: (91)(80)220-0196
Hewlett-Packard India Tel: (91)(80)225-1554 (Off)
Software Operation Pvt. Ltd. Voice Mail: 773-2467
29, Cunningham Road, E-Mail: geetham@india.hp.com
Bangalore - 560 052. Telnet: 847-1042
***************************************************************************