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

[Bryce McKinlay]

John M. Gabriele wrote:

>1. What is the "new binary compatibility ABI" and why would it matter to
>   me (J. Random Java Hacker)? Does it refer to linking with code that
>   was natively compiled with an older (or newer?) version of GCJ?
>
>2. Exactly why would I want to "treat GCJ as a kind of caching JIT"?
>   Doesn't the libgcj runtime already do something like that?
>
>3. The 3rd sentence says, "The original application remains unchanged".
>   What is being discussed? What's the original application?
>
>4. The 4th sentence says, "However, defineClass() is modified to find
>   the executable form of the class in a shared library." Where's this
>   defineClass() method defined? Why would it be in my code? Did I write
>   it?
>
>5. It goes on to talk about a ".db" file. Is a database involved here?
>  
>

John,

Some Java applications make assumptions about their runtime environment 
that made it very difficult to run them natively compiled without 
significant source code modifications. Specifically, these applications 
contain their own code to read bytecode streams and load them as classes 
using the ClassLoader.defineClass() method. The Eclipse IDE is a 
well-known example in which virtually the entire application is loaded 
in this manner.

The "kind of caching JIT" (aka: gcj-dbtool) model described here is 
GCJ's solution to this problem. When defineClass() is called, the 
bytecode passed is matched, using the map contained in the ".db" file, 
against shared libraries containing the classes compiled in advance to 
native code.

More typical applications that do not utilize custom classloaders do not 
need to worry about this at all. The BC-ABI (that is, the 
-findirect-dispatch option to gcj) can be used independently of 
gcj-dbtool to generate a binary that should continue to work despite 
changes to libgcj and other dependent class libraries. 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. In the past, as you can imagine, this was a 
significant limitation and an impediment to more widespread adoption of GCJ.

I agree with you that GCJs documentation could use a significant 
spruce-up, specifically in the area of entry-level, explanatory, and 
HOWTO type stuff. Let me assure you that any contributions to this 
effort will be gratefully received by the GCJ maintainers and quickly 
reviewed/applied.

Regards

Bryce