Re: change of libgcj soname for gcc-3.2?

[Bryce McKinlay <bryce at waitaki dot otago dot ac dot nz>]

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.