need help on virtual method compilation

[Bryce McKinlay]

Dachuan Yu wrote:

>I want to test a new scheme of statically compiling
>Java souce files by hacking GCJ. Basicly we
>introduce another level of indirection for each
>method invocation. At compile time, each class is
>compiled to have an "offset table" as well as the
>traditional vtable. While at runtime, these offset
>tables gets filled in somehow by the dynamic linker.
>In this scheme each method invocation would go
>through the offset table first to get back an offset
>to the vtable. Then it goes through the vtable by
>the offset to get to the method body.
>

This sounds like a very cool project!

IMO the most severe flaws with using GCJ for developing "real" desktop
applications is that making any kind of binary object compatibility is
near impossible due to the C++ virtual tables design. The problem of
course is that any change to the set of virtual methods in a library
class will result in breaking anything compiled against older versions
of that class. By laying out the vtables at runtime, and resolving the
offsets symbolically at runtime, we could achieve something that is much
closer to Java bytecode binary compatibility.

Ideally this would be implemented as a compile-time option so that it
would be easy to measure the performance penalty.

BTW, I dont think you'd need to make any linker changes to implement
this. You can have the runtime generate the vtables and offset tables
during classloading. We already do this for interface dispatch tables -
see libjava/java/lang/natClass.cc. I can certainly help with
implementing the runtime side of things.

One compilication is that you'd also need to modify the C++ compiler to
understand the new dispatch mechanism when calling into Java code. That
shouldn't be particularly difficult - in the past I've found the C++
front end code, although larger, to generally be easier to understand
than the Java stuff.

>First of all I have to find out how "jc1" generates
>the vtable for each class and how this is written
>into the target .s file of the compilation. 
>

A good place to start would be gcc/java/class.c. This contains most of
the code for laying out java class objects, and in particular
get_dispatch_table() and get_dispatch_vector().

If you're new to GCC internals and the "tree" representation, I suggest
reading the section on trees from the GCC manual:

http://gcc.gnu.org/onlinedocs/gcc-3.0.1/gcc.html

Another good overview of how GCC works is "writing a compiler front end" at:

http://cobolforgcc.sourceforge.net/cobol_14.html#SEC48

>BTW: parse.c and parse-scan.c seem to have lots of
>debug information which refers to the absolute path
>"/nfs/gandalf/u2/mitchell/gcc-3.0/gcc-3.0/gcc/java/...".
>Is this because they are generated from the .y
>files? 
>

I'm not sure. I havn't seen this problem, but I compile GCC myself...

regards

Bryce.