eliminate gcjh?

Tom Tromey tromey@redhat.com
Tue Mar 9 18:42:00 GMT 2004

>>>>> "Per" == Per Bothner <per@bothner.com> writes:

Per> The right thing is for gcjh to ignore the synthetic "bridge" methods.

Suppose we ignore a method that appears in the .class file.  Won't g++
generate invalid code, since in essence we haven't told it about a
vtable slot?

Per> Also, when generating native code from class files we should eliminate
Per> the bridge methods, at least when generating the traditional C++ ABI
Per> (assuming this is what the C++ ABI specifies for "simple" covariant
Per> returns).

Don't we run into problems when interpreting bytecode that refers to
these methods we're deleting?

The situation seems less clear to me for the traditional ABI, since we
never really guaranteed runtime type safety there.  I'm more
interested in the binary compatibility ABI though.  We still want CNI
to work there.


More information about the Java mailing list