eliminate gcjh?

Per Bothner per@bothner.com
Wed Mar 10 21:27:00 GMT 2004


Tom Tromey wrote:

> I wasn't very clear, I just meant that it seems like we would still
> need an entry in the method table for these methods, since bytecode we
> load at runtime will refer to them by signature.

True.  One option is to make the bytecode interpreter smart enough
to find the right method, but it might be easiest and/or most efficient
to keep the bridge method in the method table.

However, note there is no need to a native code bridge method: The
method table and vtable entries for the bridge method can just point
to the native code for the real method, since all the bridge method
does is call the native method, and return.

> I still don't understand how we can eliminate the bridge methods.
> Could you explain it?  To me it looks like they are needed for type
> safety.

Note I was talking about bridge methods for covariant return types.
You're talking about how to handle bridge methods for method
parameters with generic code.  I don't understand them well.

One important question: can we map Java generic classes into C++
generic classes in gcjh?  How should we handle generic classes
in gcjh?
-- 
	--Per Bothner
per@bothner.com   http://per.bothner.com/



More information about the Java mailing list