Re: Another Experience using GCJ as an embedded compiler

[Geetha Manjunath <geetham@india.hp.com>]

Thanks for the feedback.

>   Synchronized methods now just require a single call
> to enter the monitor and another call to exit the monitor.  Period.  No setjmp/
> longjmp or exception tables required.

BTW, I think synchronized methods are not implemented in GCJ - or is it a bug in the alpha
version we are using? It doesn't generate the monitorEnter-monitorExit code for sync
methods. According to JVM Spec, the monitor of the 'this' object for instance methods and
'current class' object for static methods need to be used for implementing sync methods.
However, synchronized statement seems to be handled.
We haven't looked at this problem yet - to solve it.

> Similarly, try/catch blocks generated enormous volumes of code using setjmp/
> longjmp, and in-line manipulation of the exception stack.  Now, there's
> just a single __catch call at the start of a try block, a single __catch_pop
> at the end of a try block, and an single exception table for all catch
> blocks.  Really shrunk the code big time and decreased the stack requirements
> alot.
>

We do not use the exception table at all - reduces code size too. But it will be good to see
your changes.

> >
> >* Automating the list of classes:
> >    I've been considering such a tool but with Java it seems that it might produce
> poor results.  Problem is that with polymorphism, you don't know what method
> is really getting called.  For example, if anybody anywhere references anything
> that calls object->toString(), then all toString methods must get included.
> And Java is FULL of toString() methods that are useless except for debugging
> purposes.

There are two steps in which we do this - first statically find the classes referenced,
next execute the application on a host environment to find a trace of all dynamically used
classes. Note that the 'closed compilation' requirement of GCJ will require a closure of
class references w.r.t to static references on the traced classes too.

> In linking up a Java library, it seems that the Java API is full of gratuitous
> cross references that prevent meaningful subsetting of the API.  For example,
> String.valueOf(anything).  In my opinion, String shouldn't require the Double
> class or 64-bit Long class to run, but in Java it does.  Bad design in my
> opinion.

A nice extension to our approach would be to find all the 'used' methods of the Java API,
and strip these classes off the unused ones. We can then do a closure on the remaining
methods of the class. This will surely remove some of the unnecessary classes - however,
unused paths in used methods will still cause additional classes to be loaded.

> I assume that you're doing the dependencies with the .class files and not
> on the compiled binaries...
>

Yes, we do a dependency check on the .class file.

> Works better to just run the compiler to build a binary on demand.
> In this way, gcj on the host just becomes a fancy class loader, although
> the modules traveling across the network become native code.

Is this approach something similar to the 'Fajita' effort?

Regards
Geetha

--

               *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
              / "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
***************************************************************************