CFP: USENIX Java Virtual Machine Symposium

Per Bothner
Wed Oct 18 23:54:00 GMT 2000

Bryce McKinlay <> writes:

> This happens if an interface is changed and recompiled but the class
> implementing it is not. Its also the major problem with the way this
> is implemented in gcj: new methods can only safely be added to the
> end of an existing interface if you want to maintain binary
> compatibility. If methods are removed or inserted, the offsets
> compiled into existing call sites will be wrong. Of course, this is
> also a problem with gcc's current C++ vtable dispatch also.

Gcj dispatch tables (for both virtual and interface calls) follow the
same approach as C++, in that if a library class is changed (except
for internals of non-inlined methods), then you generally have to
re-compile client code.  This is just the way traditional C++ as well
as Gcj works.  These "binary compatibility" requirements are quite a
bit stricter than the JLS ones, but that is basically because in
.class files all field and methods references are by name, not offset.
Once you compile to native code it is much more efficient to generate
offsets that are embedded in the compiled code.

Now it if quite possible to come up with conventions (either ABI
conventions or programmer conveptions or both) that reduce or
eliminate these re-compilation requirements.  There have been a number
or proposals, papers, and even products that do this for C++ code.  I
can't say I have much knowledge of this field.  From the point of view
of open-source users and advocates, there is something to be said for
shipping source code, and letting people re-compile it as needed, in
which case it isn't a big issue.  (Or you can ship .class files, and
letting your users recompile to native.)  From the point of view of
embedded systems, binary compatibility should also be a non-issue, I

That is not to say that library binary compatibility is an
unimportant issue.  I also think it may be worth exploring strategies
that do not hard-wire in offsets etc, perhaps by having the offsets
be resolved at link time.  But to me the empashis on Gcj is to
implement Java using conventional techniques (as used for C and C++),
betting good predictable performance in a reasonable amount of space.
(I buy the argument that JIT/Hotspot techniques can in theory generate
more efficient code than an ahead-of-time compiler - but at what
space and time overhead?)
	--Per Bothner

More information about the Java mailing list