gcj producing bad code

gcj producing bad code

[Nic Ferrier]

I've been doing some more work trying to get GCJ to compile my
servlet engine, Paperclips.

I've got it compiling now, but the code GCJ produces is causing
verifier errors under Sun's VM.

I'm using a fairly recent branch of GCJ (on a PowerMac linux system)
and unfortunately I don't have time to investigate these problems
right now.


My question is: do you guys want a report of the problems? Or would
you prefer that I left this until after the next release?


Nic

Re: gcj producing bad code

[Bryce McKinlay]

Nic Ferrier wrote:

>I've been doing some more work trying to get GCJ to compile my
>servlet engine, Paperclips.
>
>I've got it compiling now, but the code GCJ produces is causing
>verifier errors under Sun's VM.
>
>I'm using a fairly recent branch of GCJ (on a PowerMac linux system)
>and unfortunately I don't have time to investigate these problems
>right now.
>
>
>My question is: do you guys want a report of the problems? Or would
>you prefer that I left this until after the next release?
>

It would be very good to have a bug report in GNATS, expecially if you 
can come up with a test case. Unfortunately, the source->bytecode 
compilation is probably the buggiest part of GCJ at present.

regards

Bryce.

Re: gcj producing bad code

[Nic Ferrier]

Bryce McKinlay <bryce@waitaki.otago.ac.nz> writes:

> It would be very good to have a bug report in GNATS, expecially if you  
> can come up with a test case. Unfortunately, the source->bytecode  
> compilation is probably the buggiest part of GCJ at present. 

I thought it would be tricky to replicate the problem (the Paperclips
code is quite complex at this point) but in fact the problem is quite
simple to define.

GCJ is not compiling method calls quite right... it seems that all
super invocations are done through invokespecial. invokespecial
cannot be used when the target needs to be called through virtual
dispatch however.

I've submitted a bug with some example code. I'm sorry I don't have
the time to commit to fixing it myself.



Nic

Re: gcj producing bad code

[Eric Blake]

Nic Ferrier wrote:
> 
> GCJ is not compiling method calls quite right... it seems that all
> super invocations are done through invokespecial. invokespecial
> cannot be used when the target needs to be called through virtual
> dispatch however.

I'm not quite sure you said that right.  Any call to super.method() is
required to compile to invokespecial (unless method is static, in which
case invokestatic is appropriate).  By the way, in the case of
EnclosingClass.super.method(), it may require the assistance of an
accessor method to use invokespecial while still obeying access rules. 
Consider this example, from the point of view of class C:

class A { void m() {} }
class B extends A {}
class C extends B { void foo() { super.m(); } }
class D extends C { void m() {} }

Here, the compiler must output the bytecode in class C for invokespecial
B.m(), and the VM is required to be able to resolve that at runtime to
be A.m().  If the compiler were to use invokevirtual in class C, you
would mistakenly invoke D.m(), not A.m().  And if the compiler were to
output invokespecial A.m() instead of B.m(), then recompiling B with an
added method m would fail binary compatibility rules.

-- 
This signature intentionally left boring.

Eric Blake             ebb9@email.byu.edu
  BYU student, free software programmer

Re: gcj producing bad code

[Nic Ferrier]

Eric Blake <ebb9@email.byu.edu> writes:

> Nic Ferrier wrote: 
> >  
> > GCJ is not compiling method calls quite right... it seems that all 
> > super invocations are done through invokespecial. invokespecial 
> > cannot be used when the target needs to be called through virtual 
> > dispatch however. 
>  
> I'm not quite sure you said that right.  Any call to super.method() is 
> required to compile to invokespecial (unless method is static, in which 
> case invokestatic is appropriate).  By the way, in the case of 
> EnclosingClass.super.method(), it may require the assistance of an 
> accessor method to use invokespecial while still obeying access rules.  
> Consider this example, from the point of view of class C: 

The case I'm referring to is a metjod invocation on a property of the
super class, thus:

  class A
   X x;
   public X getX() { return x; }


  class B extends A
   public Y getY() { return super.getX().getY(); }


The method B::getY() must compile to call getY() through a virtual
dispatch even though X is in super.

That's how Sun's compiler compiples such code anyway.


Nic

   

Re: gcj producing bad code

[Per Bothner]

Nic Ferrier wrote:
>>>GCJ is not compiling method calls quite right... it seems that all 
>>>super invocations are done through invokespecial. invokespecial 
>>>cannot be used when the target needs to be called through virtual 
>>>dispatch however. 
>>
>> 
>>I'm not quite sure you said that right.  Any call to super.method() is 
>>required to compile to invokespecial (unless method is static, in which 
>>case invokestatic is appropriate).  By the way, in the case of 
>>EnclosingClass.super.method(), it may require the assistance of an 
>>accessor method to use invokespecial while still obeying access rules.  
>>Consider this example, from the point of view of class C: 
> 
> 
> The case I'm referring to is a metjod invocation on a property of the
> super class, thus:
> 
>   class A
>    X x;
>    public X getX() { return x; }
> 
> 
>   class B extends A
>    public Y getY() { return super.getX().getY(); }
> 
> 
> The method B::getY() must compile to call getY() through a virtual
> dispatch even though X is in super.

The getY() isn't a super invocation - it's the same as
   (super.getX()).getY()
or even:
   X t = super.getX();
   return t.getY();

If we're emitting invokespecial to call getY, then I don't think
the flaw in actually in the bytecode-generation, but more likely
the front-end (resolve_qualified_expression_name in parse.y)
incorrectly setting CALL_WITH_SUPER.

I suspect the problem is that the variable 'from_super' isn't
being reset in resolve_qualified_expression_name.  Alex?
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/per/

Re: gcj producing bad code

[Bryce McKinlay]

Per Bothner wrote:

> The getY() isn't a super invocation - it's the same as
>   (super.getX()).getY()
> or even:
>   X t = super.getX();
>   return t.getY();
>
> If we're emitting invokespecial to call getY, then I don't think
> the flaw in actually in the bytecode-generation, but more likely
> the front-end (resolve_qualified_expression_name in parse.y)
> incorrectly setting CALL_WITH_SUPER. 


Yes, there is definately a problem here. super.getX().getY() produces a 
different result to x = super.getX(); x.getY(). We need to fix this for 3.1.

regards

Bryce.

Java patch: Re: gcj producing bad code

[Bryce McKinlay]

[-- Attachment #1: Type: text/plain, Size: 647 bytes --]

Per Bothner wrote:

> I suspect the problem is that the variable 'from_super' isn't
> being reset in resolve_qualified_expression_name.  Alex?

Right. resolve_qualified_expression_name iterates through each element 
in a WFL, setting the from_super flag if it sees a "super.". But in the 
case of a "super" qualified method call it forgets to clear the flag 
before it is done, so in the case of:

super.getX().getY()

the getY() is treated as if it were a "super" call also, and is emitted 
as a non-virtual call when it should not be.

The patch below fixes the problem. I'm testing it now. OK to commit 
assuming no problems?

regards

Bryce.


[-- Attachment #2: java-fromsuper.patch --]
[-- Type: text/plain, Size: 675 bytes --]

2002-04-07  Bryce McKinlay  <bryce@waitaki.otago.ac.nz>

	* parse.y (resolve_qualified_expression_name): Clear "from_super" flag
	after using it to patch CALL_EXPR.

Index: parse.y
===================================================================
RCS file: /cvs/gcc/egcs/gcc/java/parse.y,v
retrieving revision 1.370
diff -u -r1.370 parse.y
--- parse.y	1 Apr 2002 08:46:07 -0000	1.370
+++ parse.y	7 Apr 2002 03:08:24 -0000
@@ -9462,6 +9462,7 @@
 	  *where_found = patch_method_invocation (qual_wfl, decl, type,
 						  from_super,
 						  &is_static, &ret_decl);
+	  from_super = 0;
 	  if (*where_found == error_mark_node)
 	    {
 	      RESTORE_THIS_AND_CURRENT_CLASS;

Re: Java patch: Re: gcj producing bad code

[Alexandre Petit-Bianco]

Bryce McKinlay writes:

> The patch below fixes the problem. I'm testing it now. OK to commit
> assuming no problems?

I think this patch is fine. Please check it in.

Thanks,

./A