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

Tue Apr 20 01:06:00 GMT 2004

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.
> > >* 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. 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.
As an aside, I'm not really sure that we need to keep the "covariant 
bridge methods" at all when generating .o output. I haven't discovered a 
situation yet where the bridge methods generated by the compiler do 
anything more than call the real method? It seems they are just there 
for JVM compatibility.
Eg: given:
 static class Foo
 {
 Foo create() {return this;}
 }
 static class Bar extends Foo
 {
 Bar create() {return this;}
 }
We get the bytecode:
Method name:"create" Signature: ()CoVar$Bar
Attribute "Code", length:26, max_stack:1, max_locals:1, code_length:2
 0: aload_0
 1: areturn
Attribute "LineNumberTable", length:6, count: 1
 line: 10 at pc: 0
Method name:"create" Signature: ()CoVar$Foo
Attribute "Code", length:29, max_stack:1, max_locals:1, code_length:5
 0: aload_0
 1: invokevirtual <Method CoVar$Bar.create ()CoVar$Bar>
 4: areturn
Attribute "LineNumberTable", length:6, count: 1
 line: 8 at pc: 0
Attribute "Synthetic", length:0
Attribute "Bridge", length:0
Assuming the runtime knows whats up, why can't we can't just drop the 
second "create" method here? Under what circumstances would it do 
anything more than call through to CoVar$Bar?
Regards
Bryce