Re: Binary Compatibility: debug info for compiled Java programs

[Tom Tromey <tromey@redhat.com>]

>>>>> "Daniel" == Daniel Jacobowitz <drow@false.org> writes:

>> No, not exactly.  It's possible to insert a class into the inheritance
>> chain or add new fields.

Daniel> That's something you can do while preserving Binary Compatibility, but
Daniel> if we find the loaded copy of the class, its compile-time-generated
Daniel> debug information will describe its fields, right?

Not really.  First, you can read about Java binary compatibility here:

http://java.sun.com/docs/books/jls/second_edition/html/binaryComp.doc.html#44872

However, this is only part of the picture.  The other part is that the
Java runtime environment can differ from the compile-time environment.
In particular, a given class can be loaded into a running virtual
machine any number of times, via different ClassLoaders.  And since
all references used by a class are symbolic, and since a ClassLoader
mediates the name->class lookup, it follows that each separately
loaded instance of such a class can have different superclasses.

I.e., we load class Derived, which inherits from class Base, twice.
We load it once via ClassLoader A and once via ClassLoader B.  Then we
can end up with different versions of Base, that might have different
properties.  E.g., B's Base might have extra private fields.  (Exactly
what changes are valid is what is described in that chapter of the
JLS.)


In our BC ABI, we add a new level of indirection.  So, a field lookup
isn't just *(object+offset), but instead *(object+otable[index]),
where the otable ("offset table") is computed at class initialization
time.

Generating Dwarf that redirects through the otable, like the code
itself does, is tempting.  But is it possible?  I don't see how
something like 'print object' would work -- you would have to look
more closely at all the reflection data to discover all the fields in
a given class.

Tom