Patch to enable libgcj.dll for MinGW

Tue Sep 6 17:27:00 GMT 2005

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.