eliminate gcjh?

Tue Mar 9 19:13:00 GMT 2004

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/