Re: Patch to enable libgcj.dll for MinGW

[Andrew Haley <aph at redhat dot com>]

TJ Laurenzo writes:
 > > Why?  It's a simple optimization that works perfectly well on most
 > > platforms.  We could have a target-specific diable for this.

 > I don't see any place in libgcj where this is being used (I haven't
 > done an exhaustive search) outside of natLogger.cc, which is where I
 > was experiencing the problem.

OK.

 > In any case, inlining virtual methods like this doesn't seem right.
 > What if I wanted to override the getter in a subclass.

Here's a test case:

public class a
{
  int foo = 9;

  public int getFoo() { return foo; }
}

public class b extends a
{
  int bar = 3;

  public int getFoo() { return bar; }
}

public class f
{
  static native int getFoo (a anInstance);

  public static void main (String[] s) throws Throwable
  {
    a anInstance = new a();
    System.out.println(anInstance.getFoo());
    System.out.println(getFoo(anInstance));
    anInstance = new b();
    System.out.println(anInstance.getFoo());
    System.out.println(getFoo(anInstance));
  }
}

and some native code:

#include <f.h>
#include <a.h>

jint f::getFoo (::a *anInstance)
{
  return anInstance->getFoo();
}

Running it returns:

9
9
3
3

This is because the function getFoo is declared virtual:

class a : public ::java::lang::Object
{
public:
  virtual jint getFoo () { return foo; }

even though an inline body is provided.  If the C++ compiler can prove
that an object is an instance of a and not one of its subclasses, it
can inline the body.  If it can't prove that, it won't do the
inlining.

Andrew.