Re: [java-gnome-hackers] release candidate

[Mark W. <ma...@kl...>]

On Tue, 2009-02-03 at 17:47 +1100, Andrew Cowie wrote:
> On Tue, 2009-02-03 at 07:25 +0200, Serkan Kaba wrote:
> 
> > Sorry I was wrong in the initial finding -O2 reveals the issue.
> 
> Yup, I can duplicate it now. Well done.
> 
> Of course I'm none the wiser what that problem means. I wonder what
> we're doing wrong.
> 
> > I'll investigate why it does in the evening.
> 
> Thanks! This is just the sort of thing that can really screw up other
> people, so I'd like to clear it up if we can.
> 
> My guess would be that we're doing the idiom of using the JavaVM pointer
> incorrectly, or are caching it incorrectly, or...

The problem is the definition of GetEnv which takes a (void **) as
second argument, but you are pointing it to a (JNIEnv **). I am not sure
why GetEnv is defined like that. It doesn't seem particular useful. But
there is nothing you can do about that now since it is a standard
interface definition. So, this is triggering alarm bells with gcc, with
-O2 or higher you get:

-fstrict-aliasing
     Allows the compiler to assume the strictest aliasing rules
     applicable to the language being compiled.  For C (and C++), this
     activates optimizations based on the type of expressions.  In
     particular, an object of one type is assumed never to reside at
     the same address as an object of a different type, unless the
     types are almost the same.
     [... more examples in the gcc info and man pages ...]
http://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html#index-fstrict_002daliasing-751

You can help gcc out by telling it "yes, this (void **) and (JNIEnv **)
really point at the same thing" by putting them in a union and accessing
both through that union:

  union env_union
  {
    void **void_env;
    JNIEnv **jni_env;
  };

  e.jni_env = &env;
  result = (*cachedJavaVM)->GetEnv (cachedJavaVM,
                                    e.void_env,
                                    JNI_VERSION_1_4);

Then gcc knows that &env and e.void_env really point to the same thing.

Cheers,

Mark