BC ABI (was "Re: [fedora-java] Re: Java OpenGL on FC4")

[Mark Wielaard]

Hi John,

On Thu, 2005-08-18 at 14:01 -0700, John M. Gabriele wrote:
> What we've been discussing, and what you're talking about here,
> is when, at runtime, a natively compiled app wants to load/use
> an actual jar file. What in blazes does it matter whether or not
> my app was natively compiled with -findirect-dispatch? Nobody's
> trying to use ClassLoader.defineClass() to load my app's classes.

Maybe it helps if you think about the non -findirect-dispatch case as
doing direct-dispatch. In the old abi the code would try to Directly
jump to the compiled code of the other class. In the new BC
(-findirect-dispatch) abi case it jumps to the code of the other class
Indirectly which means that (among other things) it first checks whether
or not there is a native version of the class to jump to or if there is
not it falls back on the interpreted version.

People will probably cry about the above explanation, the real technical
details can be found in ftp://gcc.gnu.org/pub/gcc/summit/2004/GCJ%20New%
20ABI.pdf (and are about making sure that certain kinds of binary
compatibility rules are followed by native code with the above as nice
side-effect)

What Andrew tried to explain is that in the old case you could still
call interpreted code "indirectly" if you didn't refer to the actual
class names in your natively compiled source code. You could compile
against interfaces, then load some jar dynamicly and call the
interpreted classes through the interface methods (assuming those
classes implemented them).

Note that the interpreted code was always using "indirect-dispatch"
meaning that interpreted code would automatically call either the byte
code or native version depending on what was availble.

One thing that is somewhat confusing is that .class files can both be
seen as defining the API you are compiling agains, actual (byte) code
that can be interpreted or as (byte code) source that can be compiled to
native code. When using the --classpath=/path/to/mystuff.jar switch to
gcj you are only using the jar as "header files" defining an api to
compile against. But in the old case the native code would assume that
those classes would be native at runtime.

Hope this helps and isn't more confusing.

Cheers,

Mark
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/java-devel/attachments/20050819/2d976110/attachment.bin