Deja Vu: multiple definition of `java::lang::String::length()'?
Bryce McKinlay
bryce@waitaki.otago.ac.nz
Fri Mar 15 17:22:00 GMT 2002
Tom Tromey wrote:
>>>>>>"Bryce" == Bryce McKinlay <bryce@waitaki.otago.ac.nz> writes:
>>>>>>>>Bryce> Maybe we should consider dropping the gcjh
>Bryce> inlining/decompilation altogether. I don't think it is really
>Bryce> very useful. It is problematic for binary compatibility, and
>Bryce> within libgcj we can just access the fields directly in the
>Bryce> cases where it matters.
>>I'm reluctant to remove it.
>>I do think that binary compatibility is an important feature for us
>moving forward. I'm inclined to go with your proposal on that basis
>alone, especially given that there aren't any good counter-arguments :-)
>
Well the counter-argument is that we need to go through the libjava code
and find all the performance-critical calls to the inline functions and
replace them with field accesses. Some fields (like String's count
field) will need to be made package-private so that random CNI methods
can get at them. However, I suspect this would be a lot easier than
changing gcjh to put an "inline" flag on each inline method declaration.
regards
Bryce.
More information about the Java
mailing list