Information request - assume-compiled and indirect-dispatch

[Jeff Sturm]

On Fri, 6 Jun 2003, steve wrote:
> I have heard that these fabled switches are an effort to get compiled
> and non-compiled code to work in the same app.  Can someone direct me to
>    some documents or provide information on what they do and how they
> work.  I need to know to see if they solve the perticular problems I am
> having.

(Aren't these switches documented anywhere?  Oh dear.)

To experiment with -fassume-compiled you'll need a 3.4 checkout or
snapshot.  It doesn't work at all in any release, nor is it finished on
mainline.

Try this example:

$ cat Super.java
class Super {
  void run() {
    System.out.println("run");
  }
}
$ cat Sub.java
public class Sub extends Super {
  public static void main(String[] args) {
    new Sub().run();
  }
}
$ gcj -C Super.java Sub.java
$ gcj Sub.java --main=Sub
/tmp/ccyKHnOM.o: In function `Sub::Sub[in-charge]()':
/tmp/ccyKHnOM.o(.text+0x53): undefined reference to
`Super::Super[in-charge]()'
/tmp/ccyKHnOM.o(.data+0x64): undefined reference to `Super::run()'
/tmp/ccyKHnOM.o(.data+0x90): undefined reference to `Super::class$'
collect2: ld returned 1 exit status

Here, trying to link the subclass without a natively-compiled superclass
fails due to unresolved symbols.

Among other things, -fno-assume-compiled eliminates symbolic references to
classes that are not known to be natively compiled, deferring the
class/method resolution to run time:

$ gcj -fno-assume-compiled Sub.java --main=Sub
$ ./a.out
run

This time, Super.class is loaded and interpreted by the bytecode
interpreter.

It should be possible to selectively enable/disable this feature by class
or package, e.g.

$ gcj -c -fno-assume-compiled=Super Sub.java
$ gcj Sub.o --main=Sub
$ ./a.out
run

(A bug in options processing currently prevents the compile/link from
being combined into one command.)  In this example, all classes are
assumed to be native except Super.  (-fassume-compiled is the default.)

Jeff