eliminate gcjh?

[Per Bothner]

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/