Per Bothner wrote:
> For example, let is call this option -femit-jni. First, note that
> G++ already has the concept that certain classes have the "Java
> property". (In practice, thes are the classes that inherit from
> java::lang::Object.) If the compiler sees a field reference
> VAL->FIELDNAME
> *and* -femit-jni has been specified *and* the type of VAL is a
> pointer to a class that has the Java property, *then* the compiler
> instead generates (code *as if* it had seen):
> static jfieldID f1 =
> (*__jnienv)->GetFieldID(__jnienv, CLS, "FIELDNAME", ...);
> (*__jnienv)->GetObjectField(__jnienv, VAL, f1);
I think it rules out method that inits all field/method references at
class init and then all other methods just use them ? Of course gcc
could translate it to
static jfieldID f1;
if (!f1)
f1 = (*__jnienv)->GetFieldID(__jnienv, CLS, "FIELDNAME", ...);
but this way it would not be shared between various methods.
I'm not sure how big speed problem it is - considering JNI slowness, but
certainly there should be some way of caching - if (!f1) in worst case.
BTW, what with String and Character classes - I suppose that both java
and native parts would be totally different ? String handling in gcj is
very different from what normal JVM can do, and it would be better to
not go native through JNI for every simple call like length() or
charAt().
Same for Character - I suppose that cost of JNI switch is greater that
doing all decoding in java.
Artur
