This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Re: eliminate gcjh?
Tom Tromey wrote:
"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?
For the traditional ABI we should generate exactly the same native code
as G++ does for a simple virtual method with (simple, non-adjusting)
covariant return - unless there is a good reason to do something else!
In we can do that, we don't have to modify g++, and the output from
gcjh (with the bridge method deleted) matches the C++ a human would
expect.
This does mean we have to duplicate the g++ mangling etc for covariant
methods. For the case we care about, we don't have to handle the
complicated (return-adjusting) cases.
It also means that bytecode-to-native should likewise skip the bridge
method.
For the binary-compatible ABI I'll bow to the experts on that, but
gcjh should still ignore the bridge method.
Don't we run into problems when interpreting bytecode that refers to
these methods we're deleting?
We're not deleting them in bytecode, only in native code and in gcjh
(and I assume reflection).
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.
That basically means teaching g++ the binary compatible ABI.
--
--Per Bothner
per@bothner.com http://per.bothner.com/