This is the mail archive of the java-patches@gcc.gnu.org mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [BC] Patch: RFC: indirect dispatch on our own fields


Bryce McKinlay writes:
 > Tom Tromey wrote:
 > 
 > >Suppose you have this:
 > >
 > >  class base { public static final Object CONSTANT = ""; }
 > >  class derived extends base {
 > >    public Object method() { return CONSTANT; }
 > >  }
 > >
 > >In this situation, the Eclipse java compiler will generate
 > >"getstatic derived.CONSTANT".  This may seem strange, but it is
 > >perfectly valid (and in fact arguably more correct than what gcj
 > >does right now -- though in this situation the difference is merely
 > >pedantic).
 > >
 > >When compiling derived.class, gcj tries to emit a direct reference to
 > >the field `CONSTANT'.  This is wrong, as this field is inherited, not
 > >declared in our class.  Instead we must refer to it via our atable.
 > >
 > >This patch fixes the problem by adding another condition to the
 > >already ugly conditional in build_static_field_ref().  I'm not
 > >completely sure about it, but I looked at all the uses of
 > >DECL_ARTIFICIAL in gcj and I think this is safe.
 > >  
 > >
 > Perhaps we should consider just removing the condition and always access 
 > static fields via the atable?

Sounds good.

Up to this point, whenever I've come across compatibility problems
like this I've resorted to using gcj's runtime linker to fix up
references.  We know it will always work.

 > It probably doesn't make a whole lot of difference to optimize for
 > the local static field case (after all, we always load instance
 > fields via the otable, and that is far more common than static
 > field loads).

That's true.

Andrew.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]