change of libgcj soname for gcc-3.2?

Mon Jul 29 20:22:00 GMT 2002

Adam Megacz wrote:
>Bryce McKinlay <bryce@waitaki.otago.ac.nz> writes:
>>>>simple evolution of classes breaks binary compatibility with the 
>>current ABI.
>>>>>>This was a source of much frustration for me early on.
>>I take it that at compile time, virtual method invocations generate a
>CALL(symbol_for_vtable + N * sizeof(void*)) where N is the numerical
>index of the member function being invoked. Of course, small changes
>to .java files can result in N changing
>
Right.
>Have there been any suggestions on how to deal with stuff like this?
>Does the indirect dispatch stuff solve this problem? 
>>
Yes. See http://gcc.gnu.org/ml/java/2001-12/msg00209.html
Right now --indirect-dispatch solves the problem for virtual methods. 
More needs to be done before we fully implement the Java binary 
compatibility rules, for interfaces, fields, static methods, etc.
>If so, I'll start using it; the small decrease in performance would be well worth the
>headaches I'd save.
>
I doubt you'll notice any performance decrease, in fact it seems to 
increase performance on most of the tests I've seen!
>Actually, I wonder if it's feasible to delay writing CALL addresses
>until class initialization time. Are code pages write-protected in
>memory, or could ClassLoader::loadClass() do something similar to what
>ldd does (ie runtime fixups)?
>
Code pages are not typically write protected, however writing to them 
will cause copy-on-write, so you lose the advantages of shared memory 
between different instances of the same application or shared library 
(ie one of the key benefits of GCJ!). Also, there isn't really any 
practical and portable way to modify code at runtime. Note that ldd 
doesn't actually modify code either - PIC calls are indirected through 
the PLT, which is probibly actually less efficient than the indirect 
dispatch technique since it adds an extra branch instruction.
regards
Bryce.