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
