java-gnome-hackers

[java-gnome-hackers] release candidate

[Andrew C. <an...@op...>]

I merged a number of pending branches and did a release candidate.
Version 4.0.10-rc1 is up at
http://ftp.gnome.org/pub/gnome/sources/java-gnome/4.0/

As ever,

$ bzr diff -r tag:v4.0.9

is your friend.

AfC
Sydney

Re: [java-gnome-hackers] release candidate

[Serkan K. <se...@ge...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Andrew Cowie yazmış:
> I merged a number of pending branches and did a release candidate.
> Version 4.0.10-rc1 is up at
> http://ftp.gnome.org/pub/gnome/sources/java-gnome/4.0/
> 
> As ever,
> 
> $ bzr diff -r tag:v4.0.9
> 
> is your friend.
> 
> AfC
> Sydney
Portage extracted following warning out of gcc. Can we ignore them?
 * QA Notice: Package has poor programming practices which may compile
 *            fine but exhibit random runtime failures.
 * src/jni/bindings_java_util.c:57: warning: dereferencing type-punned
pointer will break strict-aliasing rules
 * src/jni/bindings_java_util.c:67: warning: dereferencing type-punned
pointer will break strict-aliasing rules

- --
Sincerely,
Serkan KABA
Gentoo/Java
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkmHQ1kACgkQRh6X64ivZaJFbgCfaUR9kIkV6ZSXTgegqER2WHzH
X6cAmwbB9erebnRclJOqNYIwBdO5qajr
=r452
-----END PGP SIGNATURE-----

Re: [java-gnome-hackers] release candidate

[Andrew C. <an...@op...>]

On Mon, 2009-02-02 at 21:02 +0200, Serkan Kaba wrote:
> Portage extracted following warning out of gcc. Can we ignore them?
>  * QA Notice: Package has poor programming practices which may compile
>  *            fine but exhibit random runtime failures.
>  * src/jni/bindings_java_util.c:57: warning: dereferencing type-punned
> pointer will break strict-aliasing rules
>  * src/jni/bindings_java_util.c:67: warning: dereferencing type-punned
> pointer will break strict-aliasing rules

I just did:

moonglow:~/workspace/java-gnome $ rm tmp/objects/bindings_java_util.o 
moonglow:~/workspace/java-gnome $ make 
GCC	src/jni/bindings_java_util.c
moonglow:~/workspace/java-gnome $

No warnings.

So what is Portage doing that a straight up from-source build is not?

As for the lines in question, as far as I can tell those are the correct
idiom for making calls through the JavaVM interface struct.

AfC
Sydney

Re: [java-gnome-hackers] release candidate

[Serkan K. <se...@ge...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Andrew Cowie yazmış:
> I just did:
> 
> moonglow:~/workspace/java-gnome $ rm tmp/objects/bindings_java_util.o 
> moonglow:~/workspace/java-gnome $ make 
> GCC	src/jni/bindings_java_util.c
> moonglow:~/workspace/java-gnome $
> 
> No warnings.
> 
> So what is Portage doing that a straight up from-source build is not?
> 
> As for the lines in question, as far as I can tell those are the correct
> idiom for making calls through the JavaVM interface struct.
> 
> AfC
> Sydney
optimizing for core2 (-march=nocona) reveals the warning.
- --
Sincerely,
Serkan KABA
Gentoo/Java
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkmHzNgACgkQRh6X64ivZaJ61ACfWqRTXdOAGfk8lbNwAkzd4KQw
LigAn1oDWKbDQrCkTRAne7W0EpjkHwvs
=9dmE
-----END PGP SIGNATURE-----

Re: [java-gnome-hackers] release candidate

[Andrew C. <an...@op...>]

On Tue, 2009-02-03 at 06:49 +0200, Serkan Kaba wrote:
> optimizing for core2 (-march=nocona) reveals the warning.

Hm. I just tried that (adding it manually to the CC variable in .config)
and it again compiles here with no warning, sorry.

I wonder what else it might be. 32bit vs 64bit, maybe?

Perhaps if you were to post the full GCC command that your are running
(trying using

$ V=1 make

to see) we might spot something. Mine was:

$ rm tmp/objects/bindings_java_util.o
$ V=1 make
build/faster
GCC	src/jni/bindings_java_util.c
/usr/bin/ccache /usr/bin/gcc -march=nocona -g -Wall -fPIC
-I/opt/sun-jdk-1.6.0.11/include -I/opt/sun-jdk-1.6.0.11/include/linux
-Wno-int-to-pointer-cast -Wno-pointer-to-int-cast
-Werror-implicit-function-declaration -Wfatal-errors -Isrc/jni
-Itmp/include -pthread -I/usr/include/glib-2.0
-I/usr/lib/glib-2.0/include -I/usr/include/gtk-2.0
-I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo
-I/usr/include/pango-1.0 -I/usr/include/pixman-1
-I/usr/include/freetype2 -I/usr/include/libpng12
-I/usr/include/gtk-unix-print-2.0 -I/usr/include/libglade-2.0
-I/usr/include/libxml2 -o tmp/objects/bindings_java_util.o -c
src/jni/bindings_java_util.c
$

AfC
Sydney

Re: [java-gnome-hackers] release candidate

[Serkan K. <se...@ge...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Sorry I was wrong in the initial finding -O2 reveals the issue. I'll
investigate why it does in the evening.

- --
Sincerely,
Serkan KABA
Gentoo/Java
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkmH1UcACgkQRh6X64ivZaKuSgCdFYXDNtDINnvlPrPbe/8HjW/n
S74AnA4xXnec7vd3hqJ0Rgmw9BqKGbby
=k2yQ
-----END PGP SIGNATURE-----

Re: [java-gnome-hackers] release candidate

[Andrew C. <an...@op...>]

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...

AfC
Sydney

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

Re: [java-gnome-hackers] release candidate

[Serkan K. <se...@ge...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Mark Wielaard yazmış:
> 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
Thanks for the remarks and hints. After googling I found 2 solutions.
One[1] being yours and the other[2] being typecasting to a intermediate
void pointer. I tried the latter which at least stops the warning. But
Diego Petteno said that might be just silencing and hiding the real problem)

1: http://osdir.com/ml/java.classpath.patches/2004-08/msg00034.html
2: http://mail.opensolaris.org/pipermail/tools-gcc/2005-August/000048.html
- --
Sincerely,
Serkan KABA
Gentoo/Java

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkmIqmwACgkQRh6X64ivZaIZTQCfW0qvLgpmu2VwaPX0qj3GuL6c
BWwAn0eSpIUWUedlngBdiFeI0MBzdSxN
=pgao
-----END PGP SIGNATURE-----

Re: [java-gnome-hackers] release candidate

[Serkan K. <se...@ge...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> Thanks for the remarks and hints. After googling I found 2 solutions.
> One[1] being yours and the other[2] being typecasting to a intermediate
> void pointer. I tried the latter which at least stops the warning. But
> Diego Petteno said that might be just silencing and hiding the real problem)
> 
> 1: http://osdir.com/ml/java.classpath.patches/2004-08/msg00034.html
> 2: http://mail.opensolaris.org/pipermail/tools-gcc/2005-August/000048.html
I'm attaching a diff to show what I did

- --
Sincerely,
Serkan KABA
Gentoo/Java
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkmJ12gACgkQRh6X64ivZaIdSwCdHd/RnHJJoW7A6xVLXoSiRI67
bE4AmwY1M5Sc+j4QJo7wgwI5MJ6wza6s
=t1ND
-----END PGP SIGNATURE-----

Re: [java-gnome-hackers] release candidate

[Serkan K. <se...@ge...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Serkan Kaba yazmış:
>> Thanks for the remarks and hints. After googling I found 2 solutions.
>> One[1] being yours and the other[2] being typecasting to a intermediate
>> void pointer. I tried the latter which at least stops the warning. But
>> Diego Petteno said that might be just silencing and hiding the real problem)
> 
>> 1: http://osdir.com/ml/java.classpath.patches/2004-08/msg00034.html
>> 2: http://mail.opensolaris.org/pipermail/tools-gcc/2005-August/000048.html
> I'm attaching a diff to show what I did
> 
I'm reattching it as a bundle.


- --
Sincerely,
Serkan KABA
Gentoo/Java
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkmWgPAACgkQRh6X64ivZaJcswCfa/5UTaRZj4ndB/T5KFL2d/GA
OLwAn1wFJ1Ll2aH4RRdxhnlk9SCRppw7
=4/O4
-----END PGP SIGNATURE-----

Re: [java-gnome-hackers] release candidate

[Andrew C. <an...@op...>]

On Tue, 2009-02-03 at 10:16 +0100, Mark Wielaard wrote:

> 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....

I'm sure the way we're using it was copy & pasted from some example in
the book somewhere.

>  But
> there is nothing you can do about that now since it is a standard
> interface definition.

That made me wonder if nonetheless we were doing it wrong.

>   union env_union
>   {
>     void **void_env;
>     JNIEnv **jni_env;
>   };
> 
>   e.jni_env = &env;
>   result = (*cachedJavaVM)->GetEnv (cachedJavaVM,
>                                     e.void_env,
>                                     JNI_VERSION_1_4);


The idea of using a union to hint the compiler is really interesting.
Thanks!

Instead of that, however, can we not just cast? I tried this:

=== modified file 'src/jni/bindings_java_util.c'
--- src/jni/bindings_java_util.c	2009-02-01 14:53:00 +0000
+++ src/jni/bindings_java_util.c	2009-02-04 06:54:56 +0000
@@ -50,11 +50,13 @@
 bindings_java_getEnv()
 {
 	JNIEnv* env = NULL;
+	void* ptr = NULL;
 	JavaVMAttachArgs args = { 0, };
 	static int i = 0; 
 	jint result;
 
-	result = (*cachedJavaVM)->GetEnv(cachedJavaVM, (void **) &env, JNI_VERSION_1_4);
+	result = (*cachedJavaVM)->GetEnv(cachedJavaVM, &ptr, JNI_VERSION_1_4);
+	env = (JNIEnv*) ptr;
 	if (env != NULL) {
 		return env;
 	}
@@ -64,7 +66,8 @@
 		args.version = JNI_VERSION_1_4;
 		args.name = g_strdup_printf("NativeThread%d", i++);
 
-		result = (*cachedJavaVM)->AttachCurrentThreadAsDaemon(cachedJavaVM, (void **) &env, &args);
+		result = (*cachedJavaVM)->AttachCurrentThreadAsDaemon(cachedJavaVM, &ptr, &args);
+		env = (JNIEnv*) ptr;
 		if ((result == JNI_OK) && (env != NULL)) {
 			g_free(args.name);




and the warnings have gone away for me. Any reason that isn't ok? This
sort of casting is, after all, how the entire java-gnome library works.

A bundle with this patch is attached. Give it a try?

AfC
Sydney

-- 
Andrew Frederick Cowie

Operational Dynamics is an operations and engineering consultancy
focusing on IT strategy, organizational architecture, systems
review, and effective procedures for change management: enabling
successful deployment of mission critical information technology in
enterprises, worldwide.

http://www.operationaldynamics.com/

Sydney   New York   Toronto   London

Re: [java-gnome-hackers] release candidate

[Andrew C. <an...@op...>]

Andrew and Serkan's patches were combine and merged to 'mainline' revno
613.

AfC
Sydney