John M. Gabriele wrote:
Thanks for the reply Bryce. I used much of it to update the
beginning of:
http://gcc.gnu.org/wiki/How%20to%20BC%20compile%20with%20GCJ
Great, thanks for doing this.
It sounds like, to be able to mix interpreted and natively
compiled code at runtime, you need to have compiled your .jars
with the -findirect-dispatch option, right?
If you want to be able to call interpreted code from native code, yes.
The other way around works fine regardless of the ABI.
If so, why isn't -findirect-dispatch simply the default
compilation mode?
Mostly because its not finished yet. The major blockers are CNI, because
the C++ compiler does not yet understand the BC ABI, and the bug(s)
affecting -findirect-dispatch when used for source code compilation.
Certainly, the goal is to make BC the default ABI as soon as the issues
are resolved.
There is also a performance hit from the BC-ABI - the tests I have done
show this to be relatively small (<= 10%) for most applications, but it
would be good to have more data.
[snip]
On the other
hand, if you compile an application using the old style "C++ ABI", it
will break as soon as any changes to the public APIs of dependent class
libraries are made.
Right -- since the Java runtime should be smart enough to use
the lib as long as the signatures of the methods _it wants to
use_ match up, correct?
Right. The old ABI will break code in many situations, such as the order
of fields or methods in a class changing. This is, obviously,
unacceptable for Java.
What does it mean to compile code with the "old style 'C++ ABI'"?
(Is that referred to as the "standard ABI"?) Does that just simply
mean to *not* use the -findirect-dispatch option?
Correct.
Bryce
