Using gcj as a JIT Compiler

[Jeff Sturm]

On 9 Jan 2003, Tom Tromey wrote:
>
> Jeff> I've been using Ant as my testbed for -fno-assume-compiled.  I'd
> Jeff> like to simply do:
> Jeff> gcj -c -fno-assume-compiled optional.jar
> Jeff> and have it produce something.  Currently optional.jar depends
> Jeff> on a lot of third-party class libraries.
>
> Some parts of Ant require things like com.sun.tools, don't they?

Yes, and other third-party tools that normal users won't have in their
CLASSPATH.  Tools like Ant rely on lazy class resolution, as with either
Sun's java or gij.

> For
> those you'll need visible dummy definitions even with
> -fno-assume-compiled.

Maybe not.  When compiling (for instance) B.class which depends on
A.class, the bytecode verifier in gcj doesn't need to load A.class, so
why does the compiler?  (I _know_ why, but don't think it's a good
reason.)  I want to look at this again, eventually.

> Maybe you could look at my latest assume-compiled patch and explain
> the test I don't understand?
>
>     http://gcc.gnu.org/ml/java-patches/2003-q1/msg00054.html

I like your patches.  I think the code was wrong, and should be checking
super.  I hadn't seen this problem myself yet because I had only tested
-fno-assume-compiled with no arguments at all.

I'm testing with:

==> A.java <==
public class A {

==> B.java <==
public class B extends A {

This works:

$ gcj -C A.java
$ gcj -fno-assume-compiled B.java --main=B -o b
$ ./b
OK

With your patches, I also tried:

$ gcj -c -fno-assume-compiled=A B.java
$ gcj B.o --main=B -o b
B.o(.data+0x64): undefined reference to `A::test()'

If I make `test' a static member, it works again.  So this is progress,
but more work is needed.

Jeff