[BC ABI] gcj-abi-2-dev-branch created

Andrew Haley aph@redhat.com
Tue Apr 20 09:39:00 GMT 2004


Bryce McKinlay writes:
 > Andrew Haley wrote:
 > 
 > >We need to output assertions so that we detect when an incompatible
 > >change has occurred.
 > >
 > >For example, say we call a method with type T.  We need to make sure
 > >that whatever we pass to that method really is compatible with T.  
 > >
 > >Like this
 > >
 > >   Foo f = new Bar();
 > >
 > >is legal because Bar extends (or implements) Foo.  But if at runtime
 > >Bar no longer implements Foo, we have to signal an error.
 > 
 > Good point, I hadn't considered this. I think this should be
 > relatively simple to do. It should be sufficient to have the
 > compiler emit a table of with entries of the form "X is assignable
 > to Y". Each time an implicit class type conversion occurs, we just
 > add an entry to the table. The runtime reads this table during
 > class linking and throws the appropriate exception - VerifyError
 > according to JLS 13.4.4 - if any of the assertions don't hold.

Yeah.  :-)

This is pretty easy, and it's already on the list of things to do.
The compiler on the branch emits warnings where we would need to push
assertions into the output file.

 > > > >* We need to fix mangling so we can use generics.
 > > > >  
 > > > >
 > > > This one should probably be in the "beyond 3.5" category. It will be a 
 > > > little while before we have to worry about generics.
 > >
 > >I disagree.  generics will be in bytecode files Real Soon Now.
 > 
 > OK, you might be right. With the BC-ABI, the mangling isn't really
 > all that important since the symbols will be private, the compiler
 > could call them whatever it likes since the runtime can do all the
 > linking.

Exactly.

 > As for the standard ABI, instead of actually changing the mangling
 > format I think it should be sufficient to add something like
 > "$$return_type" to a method name in the cases where conflicts
 > occur. This should allow us to keep generating .h files for CNI
 > without having to dramatically alter either CNI or the C++
 > compiler.

We need to change the mangling anyway, if only for the benefit of the
debugger.  In each compilation unit we should emit unique symbols.

Andrew.



More information about the Java mailing list