This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Re: eliminate gcjh?
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/