From gbenson at redhat.com Tue Mar 3 08:32:04 2009 From: gbenson at redhat.com (Gary Benson) Date: Tue, 3 Mar 2009 16:32:04 +0000 Subject: Attention Shark hackers Message-ID: <20090303163204.GA3241@redhat.com> Hi all, I'm working on a large change that is going to result in a lot of the code in sharkBlock.* and sharkState.* getting rearranged. If you're working on something in those files then please let me know so we can coordinate commits. Cheers, Gary -- http://gbenson.net/ From gbenson at redhat.com Fri Mar 6 03:50:35 2009 From: gbenson at redhat.com (Gary Benson) Date: Fri, 6 Mar 2009 11:50:35 +0000 Subject: Attention Shark hackers (again) Message-ID: <20090306115035.GB3228@redhat.com> Hi all, I'm currently refactoring SharkCompiler and SharkBuilder. If you're working on something in those then please let me know so we can coordinate. Cheers, Gary -- http://gbenson.net/ From gbenson at redhat.com Tue Mar 10 01:04:51 2009 From: gbenson at redhat.com (Gary Benson) Date: Tue, 10 Mar 2009 08:04:51 +0000 Subject: get_native_u2 & friends In-Reply-To: <200902261545.n1QFjOY3022789@parsley.camswl.com> References: <200902261545.n1QFjOY3022789@parsley.camswl.com> Message-ID: <20090310080450.GA3205@redhat.com> Hi Ed, Sorry I haven't looked into this yet. I filed a bug for it (http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=301) to make sure it doesn't get lost. Cheers, Gary Edward Nevill wrote: > Hi all, > > I think the best thing to do with get_native_u2 and friends is to > let the compiler decide how to access unaligned data. Most modern > compilers have some facility for doing this. In gcc you can use > __attribute__((packed)) as follows. > > typedef union unaligned { > unsigned u; > unsigned short us; > unsigned long long ul; > } __attribute__((packed)) unaligned; > > unsigned short get_native_u2(unaligned *p) > { > return p->us; > } > > unsigned get_native_u4(unaligned *p) > { > return p->u; > } > > unsigned long long get_native_u8(unaligned *p) > { > return p->ul; > } > > Below is the code generated for ARM and X86. Note that in the X86 > case it just does the access since X86 allows unaligned accesses > whereas for ARM it goes ahead and doesbyte loads. > > If on some architechture it is better to test the alignment and then > do word/halfword loads if the pointer is aligned and byte loads > otherwise then hopefully the compiler will know the best code to > generate rarther than us trying to second guess what is best on > individual architectures. > > Also, in many case these functions are called when it is known that > the data is aligned as in this example from _tableswitch... > > CASE(_tableswitch): { > jint* lpc = (jint*)VMalignWordUp(pc+1); > int32_t key = STACK_INT(-1); > int32_t low = Bytes::get_Java_u4((address)&lpc[1]); > int32_t high = Bytes::get_Java_u4((address)&lpc[2]); > > Maybe it is worth having get_Java_u4() and get_Java_u4_unaligned()? > > Regards, > Ed. > > > --- x86.s -------------------------------------------------------- > .file "test.c" > .text > .p2align 4,,15 > .globl get_native_u2 > .type get_native_u2, @function > get_native_u2: > pushl %ebp > movl %esp, %ebp > movl 8(%ebp), %eax > popl %ebp > movzwl (%eax), %eax > ret > .size get_native_u2, .-get_native_u2 > .p2align 4,,15 > .globl get_native_u4 > .type get_native_u4, @function > get_native_u4: > pushl %ebp > movl %esp, %ebp > movl 8(%ebp), %eax > popl %ebp > movl (%eax), %eax > ret > .size get_native_u4, .-get_native_u4 > .p2align 4,,15 > .globl get_native_u8 > .type get_native_u8, @function > get_native_u8: > pushl %ebp > movl %esp, %ebp > movl 8(%ebp), %eax > popl %ebp > movl 4(%eax), %edx > movl (%eax), %eax > ret > .size get_native_u8, .-get_native_u8 > .ident "GCC: (GNU) 4.2.4 (Ubuntu 4.2.4-1ubuntu3)" > .section .note.GNU-stack,"", at progbits > --- arm.s ------------------------------------------------------------- > .arch armv5t > .fpu softvfp > .eabi_attribute 20, 1 > .eabi_attribute 21, 1 > .eabi_attribute 23, 3 > .eabi_attribute 24, 1 > .eabi_attribute 25, 1 > .eabi_attribute 26, 2 > .eabi_attribute 30, 2 > .eabi_attribute 18, 4 > .file "test.c" > .text > .align 2 > .global get_native_u2 > .type get_native_u2, %function > get_native_u2: > @ args = 0, pretend = 0, frame = 0 > @ frame_needed = 0, uses_anonymous_args = 0 > @ link register save eliminated. > ldrb r3, [r0, #1] @ zero_extendqisi2 > ldrb r0, [r0, #0] @ zero_extendqisi2 > orr r0, r0, r3, asl #8 > bx lr > .size get_native_u2, .-get_native_u2 > .align 2 > .global get_native_u4 > .type get_native_u4, %function > get_native_u4: > @ args = 0, pretend = 0, frame = 0 > @ frame_needed = 0, uses_anonymous_args = 0 > @ link register save eliminated. > ldrb r1, [r0, #1] @ zero_extendqisi2 > ldrb r3, [r0, #0] @ zero_extendqisi2 > ldrb r2, [r0, #2] @ zero_extendqisi2 > ldrb r0, [r0, #3] @ zero_extendqisi2 > orr r3, r3, r1, asl #8 > orr r3, r3, r2, asl #16 > orr r0, r3, r0, asl #24 > bx lr > .size get_native_u4, .-get_native_u4 > .align 2 > .global get_native_u8 > .type get_native_u8, %function > get_native_u8: > @ args = 0, pretend = 0, frame = 0 > @ frame_needed = 0, uses_anonymous_args = 0 > @ link register save eliminated. > stmfd sp!, {r4, r5, r6} > ldrb r5, [r0, #1] @ zero_extendqisi2 > ldrb r6, [r0, #5] @ zero_extendqisi2 > ldrb r3, [r0, #0] @ zero_extendqisi2 > ldrb ip, [r0, #2] @ zero_extendqisi2 > ldrb r1, [r0, #4] @ zero_extendqisi2 > ldrb r2, [r0, #6] @ zero_extendqisi2 > ldrb r4, [r0, #7] @ zero_extendqisi2 > ldrb r0, [r0, #3] @ zero_extendqisi2 > orr r3, r3, r5, asl #8 > orr r1, r1, r6, asl #8 > orr r3, r3, ip, asl #16 > orr r1, r1, r2, asl #16 > orr r0, r3, r0, asl #24 > orr r1, r1, r4, asl #24 > ldmfd sp!, {r4, r5, r6} > bx lr > .size get_native_u8, .-get_native_u8 > .ident "GCC: (Ubuntu 4.3.3-1ubuntu1) 4.3.3" > .section .note.GNU-stack,"",%progbits > > -- http://gbenson.net/ From neale at sinenomine.net Thu Mar 26 07:11:25 2009 From: neale at sinenomine.net (Neale Ferguson) Date: Thu, 26 Mar 2009 10:11:25 -0400 Subject: Building zero Message-ID: Hi, Is there a FAQ that can answer questions like: ?What package is reponsible for creating /usr/lib/jvm as .configure looks for SYSTEM_GCJ_DIR?? I?m sure I?m going to have several of these newbie-type questions and don?t want to waste bandwidth of this list with such things if there?s a HOWTO somewhere. [In this instance the gcj command exists but I'm not sure what should be contained within the directory represented by SYSTEM_GCJ_DIR.] Neale From gbenson at redhat.com Thu Mar 26 07:33:01 2009 From: gbenson at redhat.com (Gary Benson) Date: Thu, 26 Mar 2009 14:33:01 +0000 Subject: Building zero In-Reply-To: References: Message-ID: <20090326143300.GA3187@redhat.com> Hi Neale, Neale Ferguson wrote: > Is there a FAQ that can answer questions like: > > ?What package is reponsible for creating /usr/lib/jvm as .configure > looks for SYSTEM_GCJ_DIR?? > > I?m sure I?m going to have several of these newbie-type questions > and don?t want to waste bandwidth of this list with such things if > there?s a HOWTO somewhere. > > [In this instance the gcj command exists but I'm not sure what > should be contained within the directory represented by > SYSTEM_GCJ_DIR.] There's no specific Zero FAQ but there is some generic IcedTea information on http://icedtea.classpath.org/, as well as specific build instructions for a couple of distributions. After today I'm going to be away from email until April 6, but if you have IRC you could join #openjdk on OFTC and ask questions there. You could also join the distro-pkg-dev mailing list and ask there (more people read it than this zero-specific list). It's at http://mail.openjdk.java.net/mailman/listinfo/distro-pkg-dev Cheers, Gary -- http://gbenson.net/ From neale at sinenomine.net Thu Mar 26 07:34:34 2009 From: neale at sinenomine.net (Neale Ferguson) Date: Thu, 26 Mar 2009 10:34:34 -0400 Subject: Linux on zSeries Message-ID: I note that the wiki page states that zSeries is a supported Linux environment. I also note that the zeroJDK needs LLVM. Does zSeries just use the portable C backend? Neale -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/zero-dev/attachments/20090326/dfde3f61/attachment.html From gbenson at redhat.com Thu Mar 26 07:46:15 2009 From: gbenson at redhat.com (Gary Benson) Date: Thu, 26 Mar 2009 14:46:15 +0000 Subject: Linux on zSeries In-Reply-To: References: Message-ID: <20090326144615.GB3187@redhat.com> Neale Ferguson wrote: > I note that the wiki page states that zSeries is a supported Linux > environment. I also note that the zeroJDK needs LLVM. Does zSeries > just use the portable C backend? LLVM is only required if you're building Shark. That won't work on zSeries, at least until someone writes a native LLVM JIT for it. You'll be fine so long as you don't specify --enable-shark in your ./configure options. Cheers, Gary -- http://gbenson.net/ From xerxes at zafena.se Sat Mar 28 15:08:16 2009 From: xerxes at zafena.se (=?ISO-8859-1?Q?Xerxes_R=E5nby?=) Date: Sat, 28 Mar 2009 23:08:16 +0100 Subject: [patch] Shark reroute LLVM atomic intrinsics to Zero Message-ID: <49CE9FD0.6030202@zafena.se> Greetings, This patch will make shark reroute LLVM atomic intrinsics to the existing atomic operations implemented in Zero. This patch are both platform and arch independent. I have tested this patch on Shark compiled for X86, PPC and ARM. The benefit from a porters point of view is that once the atomic operation are implemented in Zero you get the atomic operations needed for Shark for free without having to extend LLVM. I did this mainly because LLVM lacked atomic intrinsics in the ARM backend. Cheers and have a great day! Xerxes -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: icedtea6_sharkBuilder_atomic_reroute_2_zero.patch Url: http://mail.openjdk.java.net/pipermail/zero-dev/attachments/20090328/64385744/attachment.ksh From neale at sinenomine.net Sat Mar 28 20:08:54 2009 From: neale at sinenomine.net (Neale Ferguson) Date: Sat, 28 Mar 2009 23:08:54 -0400 Subject: Message-ID: This is my first attempt building zero and am making it to this point before bombing out: ANT_OPTS=-Djava.io.tmpdir='/home/neale/icedtea-1.9/openjdk-ecj/build/linux-s 390x/langtools/build/ant-tmp' ant -Djdk.version=1.7.0_0 -Dfull.version='1.7.0_0-b50' -Drelease=1.7.0_0 -Dbuild.number=b50 -Djavac.debug=true -Djavac.target=5 -Dboot.java.home=/home/neale/icedtea-1.9/bootstrap/jdk1.6.0 -Djavac.executable=/home/neale/icedtea-1.9/bootstrap/jdk1.6.0/bin/javac -Dbuild.dir=/home/neale/icedtea-1.9/openjdk-ecj/build/linux-s390x/langtools/ build -Ddist.dir=/home/neale/icedtea-1.9/openjdk-ecj/build/linux-s390x/langtools/d ist build Buildfile: build.xml -def-check: -check-boot.java.home: -def-pcompile: [mkdir] Created dir: /home/neale/icedtea-1.9/openjdk-ecj/build/linux-s390x/langtools/build/toolcl asses [javac] Compiling 2 source files to /home/neale/icedtea-1.9/openjdk-ecj/build/linux-s390x/langtools/build/toolcl asses [javac] ---------- [javac] 1. ERROR in /home/neale/icedtea-1.9/openjdk-ecj/langtools/make/tools/CompileProperties/C ompileProperties.java (at line 1) [javac] /* [javac] ^ [javac] The type java.lang.Object cannot be resolved. It is indirectly referenced from required .class files [javac] ---------- [javac] 2. ERROR in /home/neale/icedtea-1.9/openjdk-ecj/langtools/make/tools/CompileProperties/C ompileProperties.java (at line 1) : : ... A total of 100 errors in all. I?m sure this is a newbie problem but can someone lend me a clue? I'm using the IBM 1.6 JDK. Neale From xerxes at zafena.se Sun Mar 29 08:45:40 2009 From: xerxes at zafena.se (=?ISO-8859-1?Q?Xerxes_R=E5nby?=) Date: Sun, 29 Mar 2009 17:45:40 +0200 Subject: In-Reply-To: References: Message-ID: <49CF97A4.40406@zafena.se> The error you experience are probably related to the version of javac you are using. Could you please post the output from /home/neale/icedtea-1.9/bootstrap/jdk1.6.0/bin/javac -version I would recommended you to try compile Icedtea6-1.4.1 (openjdk 6) before trying to compile icedtea-1.9 (openjdk 7) Icedtea6 are more easy to compile and don't require the latest and greatest compilers. Icedtea6 are also more tested and stable thus it is the version most people prefer and are the version shipped with most linux distributions today. http://icedtea.classpath.org/download/source/icedtea6-1.4.1.tar.gz Cheers Xerxes Neale Ferguson skrev: > This is my first attempt building zero and am making it to this point before > bombing out: > > ANT_OPTS=-Djava.io.tmpdir='/home/neale/icedtea-1.9/openjdk-ecj/build/linux-s > 390x/langtools/build/ant-tmp' ant -Djdk.version=1.7.0_0 > -Dfull.version='1.7.0_0-b50' -Drelease=1.7.0_0 -Dbuild.number=b50 > -Djavac.debug=true -Djavac.target=5 > -Dboot.java.home=/home/neale/icedtea-1.9/bootstrap/jdk1.6.0 > -Djavac.executable=/home/neale/icedtea-1.9/bootstrap/jdk1.6.0/bin/javac > -Dbuild.dir=/home/neale/icedtea-1.9/openjdk-ecj/build/linux-s390x/langtools/ > build > -Ddist.dir=/home/neale/icedtea-1.9/openjdk-ecj/build/linux-s390x/langtools/d > ist build > Buildfile: build.xml > > -def-check: > > -check-boot.java.home: > > -def-pcompile: > [mkdir] Created dir: > /home/neale/icedtea-1.9/openjdk-ecj/build/linux-s390x/langtools/build/toolcl > asses > [javac] Compiling 2 source files to > /home/neale/icedtea-1.9/openjdk-ecj/build/linux-s390x/langtools/build/toolcl > asses > [javac] ---------- > [javac] 1. ERROR in > /home/neale/icedtea-1.9/openjdk-ecj/langtools/make/tools/CompileProperties/C > ompileProperties.java (at line 1) > [javac] /* > [javac] ^ > [javac] The type java.lang.Object cannot be resolved. It is indirectly > referenced from required .class files > [javac] ---------- > [javac] 2. ERROR in > /home/neale/icedtea-1.9/openjdk-ecj/langtools/make/tools/CompileProperties/C > ompileProperties.java (at line 1) > : > : > ... A total of 100 errors in all. > > I?m sure this is a newbie problem but can someone lend me a clue? I'm using > the IBM 1.6 JDK. > > Neale > > > From aph at redhat.com Sun Mar 29 09:45:19 2009 From: aph at redhat.com (Andrew Haley) Date: Sun, 29 Mar 2009 17:45:19 +0100 Subject: [patch] Shark reroute LLVM atomic intrinsics to Zero In-Reply-To: <49CEACD7.8040203@gmx.net> References: <49CE9FD0.6030202@zafena.se> <49CEACD7.8040203@gmx.net> Message-ID: <49CFA59F.4030509@redhat.com> Robert Schuster wrote: > Xerxes R?nby schrieb: >> Greetings, >> This patch will make shark reroute LLVM atomic intrinsics to the >> existing atomic operations implemented in Zero. >> >> This patch are both platform and arch independent. >> I have tested this patch on Shark compiled for X86, PPC and ARM. > I would make this rerouting optional depending on the architecture. > LLVM has atomic intrinsic fucntion support for x86(-64), powerpc (32,64) > and alpha. On those architectures you really want to use what LLVM > provides. > > E.g. on x86 the function is converted into a series of machine > instructions and no function call. Definitely; we really don't want a function call just do do an atomic cmpxchg. This is really just a workaround for an llvm bug, and hopefully it'll soon go away. Andrew. From theBohemian at gmx.net Sat Mar 28 16:03:51 2009 From: theBohemian at gmx.net (Robert Schuster) Date: Sun, 29 Mar 2009 00:03:51 +0100 Subject: [patch] Shark reroute LLVM atomic intrinsics to Zero In-Reply-To: <49CE9FD0.6030202@zafena.se> References: <49CE9FD0.6030202@zafena.se> Message-ID: <49CEACD7.8040203@gmx.net> Hi Xerxes, Xerxes R?nby schrieb: > Greetings, > This patch will make shark reroute LLVM atomic intrinsics to the > existing atomic operations implemented in Zero. > > This patch are both platform and arch independent. > I have tested this patch on Shark compiled for X86, PPC and ARM. I would make this rerouting optional depending on the architecture. LLVM has atomic intrinsic fucntion support for x86(-64), powerpc (32,64) and alpha. On those architectures you really want to use what LLVM provides. E.g. on x86 the function is converted into a series of machine instructions and no function call. > The benefit from a porters point of view is that once the atomic > operation are implemented in Zero you get the atomic operations needed > for Shark for free without having to extend LLVM. > > I did this mainly because LLVM lacked atomic intrinsics in the ARM backend. Yes, MIPS, ARM and IA64 would clearly benefit from this and should use the rerouting. Regards Robert -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 260 bytes Desc: OpenPGP digital signature Url : http://mail.openjdk.java.net/pipermail/zero-dev/attachments/20090329/8b0bbdcd/attachment.bin From xerxes at zafena.se Sun Mar 29 18:17:44 2009 From: xerxes at zafena.se (=?ISO-8859-1?Q?Xerxes_R=E5nby?=) Date: Mon, 30 Mar 2009 03:17:44 +0200 Subject: [patch] Shark reroute LLVM atomic intrinsics to Zero In-Reply-To: <49CFA59F.4030509@redhat.com> References: <49CE9FD0.6030202@zafena.se> <49CEACD7.8040203@gmx.net> <49CFA59F.4030509@redhat.com> Message-ID: <49D01DB8.9050007@zafena.se> Andrew Haley skrev: > Robert Schuster wrote: > > >> Xerxes R?nby schrieb: >> >>> Greetings, >>> This patch will make shark reroute LLVM atomic intrinsics to the >>> existing atomic operations implemented in Zero. >>> >>> This patch are both platform and arch independent. >>> I have tested this patch on Shark compiled for X86, PPC and ARM. >>> >> I would make this rerouting optional depending on the architecture. >> LLVM has atomic intrinsic fucntion support for x86(-64), powerpc (32,64) >> and alpha. On those architectures you really want to use what LLVM >> provides. >> >> E.g. on x86 the function is converted into a series of machine >> instructions and no function call. >> > > Definitely; we really don't want a function call just do do an atomic > cmpxchg. This is really just a workaround for an llvm bug, and hopefully > it'll soon go away. > > Andrew. > I have done a small investigation to see how large the cost is to use the reroute patch on PPC. The test machine is a PowerBook G4 1.333Ghz with F10 installed. I used Caffeine Mark 3.0 for this benchmark, why? It is a quick benchmark and it includes some graphics tests so it is quite fun to benchmark with. And not to mention it is fun to see large scores since it is a rather old test. To my surprise one test, the image test, actually performed a little better with the atomic reroute patch applied. The nice attached pdf and ods report contains all hard data with nice graphs and build instructions. For fun I have also attached two screen shots with the output of CM30 running on F10/PPC zero and my PPC shark build. It are nice to see that float performance have increased 14x using shark compared to pure zero :) Cheers and have a great day! Xerxes -------------- next part -------------- A non-text attachment was scrubbed... Name: zero-PPC-F10.png Type: image/png Size: 8869 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/zero-dev/attachments/20090330/56fc6218/attachment.png -------------- next part -------------- A non-text attachment was scrubbed... Name: shark-PPC-F10.png Type: image/png Size: 8606 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/zero-dev/attachments/20090330/56fc6218/attachment-0001.png -------------- next part -------------- A non-text attachment was scrubbed... Name: SharkRerouteToZeroCost.ods Type: application/vnd.oasis.opendocument.spreadsheet Size: 43994 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/zero-dev/attachments/20090330/56fc6218/attachment.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: SharkRerouteToZeroCost.pdf Type: application/pdf Size: 174780 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/zero-dev/attachments/20090330/56fc6218/attachment.pdf From aph at redhat.com Mon Mar 30 02:23:28 2009 From: aph at redhat.com (Andrew Haley) Date: Mon, 30 Mar 2009 10:23:28 +0100 Subject: [patch] Shark reroute LLVM atomic intrinsics to Zero In-Reply-To: <49D01DB8.9050007@zafena.se> References: <49CE9FD0.6030202@zafena.se> <49CEACD7.8040203@gmx.net> <49CFA59F.4030509@redhat.com> <49D01DB8.9050007@zafena.se> Message-ID: <49D08F90.8020904@redhat.com> Xerxes R?nby wrote: > Andrew Haley skrev: >> Robert Schuster wrote: >> >>> Xerxes R?nby schrieb: >>> >>>> Greetings, >>>> This patch will make shark reroute LLVM atomic intrinsics to the >>>> existing atomic operations implemented in Zero. >>>> >>>> This patch are both platform and arch independent. >>>> I have tested this patch on Shark compiled for X86, PPC and ARM. >>>> >>> I would make this rerouting optional depending on the architecture. >>> LLVM has atomic intrinsic fucntion support for x86(-64), powerpc (32,64) >>> and alpha. On those architectures you really want to use what LLVM >>> provides. >>> >>> E.g. on x86 the function is converted into a series of machine >>> instructions and no function call. >> >> Definitely; we really don't want a function call just do do an atomic >> cmpxchg. This is really just a workaround for an llvm bug, and hopefully >> it'll soon go away. > > I have done a small investigation to see how large the cost is to use > the reroute patch on PPC. > The test machine is a PowerBook G4 1.333Ghz with F10 installed. > > I used Caffeine Mark 3.0 for this benchmark, why? It is a quick > benchmark and it includes some graphics tests so it is quite fun to > benchmark with. And, perhaps unsurprisingly, it doesn't use java.lang.concurrent.* at all. :-) Really, the use of lock-free in Java is only just beginning; in the future I expect it'll be the obvious way to do things. Andrew. From xerxes at zafena.se Mon Mar 30 03:25:19 2009 From: xerxes at zafena.se (=?ISO-8859-1?Q?Xerxes_R=E5nby?=) Date: Mon, 30 Mar 2009 12:25:19 +0200 Subject: [patch] Shark reroute LLVM atomic intrinsics to Zero In-Reply-To: <49D08F90.8020904@redhat.com> References: <49CE9FD0.6030202@zafena.se> <49CEACD7.8040203@gmx.net> <49CFA59F.4030509@redhat.com> <49D01DB8.9050007@zafena.se> <49D08F90.8020904@redhat.com> Message-ID: <49D09E0F.40802@zafena.se> Andrew Haley skrev: > Xerxes R?nby wrote: > >> Andrew Haley skrev: >> >>> Robert Schuster wrote: >>> >>> >>>> Xerxes R?nby schrieb: >>>> >>>> >>>>> Greetings, >>>>> This patch will make shark reroute LLVM atomic intrinsics to the >>>>> existing atomic operations implemented in Zero. >>>>> >>>>> This patch are both platform and arch independent. >>>>> I have tested this patch on Shark compiled for X86, PPC and ARM. >>>>> >>>>> >>>> I would make this rerouting optional depending on the architecture. >>>> LLVM has atomic intrinsic fucntion support for x86(-64), powerpc (32,64) >>>> and alpha. On those architectures you really want to use what LLVM >>>> provides. >>>> >>>> E.g. on x86 the function is converted into a series of machine >>>> instructions and no function call. >>>> >>> Definitely; we really don't want a function call just do do an atomic >>> cmpxchg. This is really just a workaround for an llvm bug, and hopefully >>> it'll soon go away. >>> >> I have done a small investigation to see how large the cost is to use >> the reroute patch on PPC. >> The test machine is a PowerBook G4 1.333Ghz with F10 installed. >> >> I used Caffeine Mark 3.0 for this benchmark, why? It is a quick >> benchmark and it includes some graphics tests so it is quite fun to >> benchmark with. >> > > And, perhaps unsurprisingly, it doesn't use java.lang.concurrent.* > at all. :-) > > Really, the use of lock-free in Java is only just beginning; in the > future I expect it'll be the obvious way to do things. > > Andrew. > > I agree that it is a rather stupid benchmark to use yet I dont have any benchmark that i know specifically tests for concurrency. My thinking was to use a benchmark with some gui parts since AWT internally are multi-threaded AFAIC just to see if i could measure any effect at all from the use of the reroute. Ok, in order to check my sanity i did a small test to see if running the CM30 benchmarks triggered any rerouting of atomic intrinsics at all. I added a printf to the rerouted functioncalls printing one char each like this: extern "C" { jint zero_cmpxchg_int_fn(volatile jint *ptr, jint *oldval, jint *newval) { printf("1"); return Atomic::cmpxchg((jint) newval, (volatile jint *) ptr, (jint) oldval); } intptr_t* zero_cmpxchg_ptr_fn(volatile void *ptr, intptr_t *oldval, intptr_t *newval) { printf("0"); return (intptr_t *) Atomic::cmpxchg_ptr((void *) newval, (volatile void *) ptr, (void *) oldval); } }; And then i ran the CM30 using the appletviewer: logs can be found here: http://labb.zafena.se/shark-testing/cm30_useof_atomic.log 3537613 bytes http://labb.zafena.se/shark-testing/cm30_useof_atomic.log2 3493084 bytes I am happy to see that the reroute at least did get used during the test 3.5million times. If someone know of a better benchmark that tests concurrency throughfully i would be happy to hear about it. Cheers Xerxes From neale at sinenomine.net Tue Mar 31 10:13:24 2009 From: neale at sinenomine.net (Neale Ferguson) Date: Tue, 31 Mar 2009 13:13:24 -0400 Subject: Problems building on System z Message-ID: I?m building the OpenJDK6 & 7 by way of the zeroJDK mechanism and am running into problems. Using gij with icedtea6 I get: + CLASSPATH=/home/neale/ecj-3.4.1.jar + /usr/bin/gij org.eclipse.jdt.internal.compiler.batch.Main -1.5 -nowarn -g -d lib/hotspot-tools -source 1.5 -sourcepath hotspot-tools:openjdk/jdk/src/share/classes:openjdk/jdk/src/solaris/classes: openjdk/langtools/src/share/classes:openjdk/jaxp/src/share/classes:openjdk/c orba/src/share/classes:openjdk/jaxws/src/share/classes:/home/neale/icedtea6- 1.4.1/generated:/home/neale/icedtea6-1.4.1/rt -bootclasspath ''\'''\''' @hotspot-tools-source-files.txt incorrect classpath: '' ---------- 1. ERROR in /home/neale/icedtea6-1.4.1/openjdk/jdk/src/share/classes/java/lang/Double.ja va (at line 0) /* ^ Internal compiler error java.lang.NullPointerException at java.lang.Double.parseDouble(libgcj.so.7) at java.lang.Double.valueOf(libgcj.so.7) Using gij with icedtea9 I get: /usr/bin/gcj -g -O2 -Wl,-Bsymbolic -findirect-dispatch -o native-ecj \ --main=org.eclipse.jdt.internal.compiler.batch.Main /home/neale/ecj-3.4.1.jar org/eclipse/jdt/internal/compiler/apt/dispatch/BatchAnnotationProcessorManag er.java: In class 'org.eclipse.jdt.internal.compiler.apt.dispatch.BatchAnnotationProcessorMana ger': org/eclipse/jdt/internal/compiler/apt/dispatch/BatchAnnotationProcessorManag er.java: In method 'org.eclipse.jdt.internal.compiler.apt.dispatch.BatchAnnotationProcessorMana ger.discoverNextProcessor()': org/eclipse/jdt/internal/compiler/apt/dispatch/BatchAnnotationProcessorManag er.java:110: error: verification failed at PC=251: String, int, or float constant expected org/eclipse/jdt/internal/compiler/apt/dispatch/BatchAnnotationProcessorManag er.java:110: error: verification failed at PC=260: incompatible type on stack org/eclipse/jdt/internal/compiler/apt/dispatch/BatchAnnotationProcessorManag er.java:152: confused by earlier errors, bailing out This is with gcc 4.1.2 should I be using a later version? When I use the IBM 1.6 JDK with icedtea6 I get: [mkdir] Created dir: /home/neale/icedtea6-1.4.1/openjdk-ecj/control/build/linux-s390x/langtools/b uild/toolclasses [javac] Compiling 2 source files to /home/neale/icedtea6-1.4.1/openjdk-ecj/control/build/linux-s390x/langtools/b uild/toolclasses [javac] ---------- [javac] 1. ERROR in /home/neale/icedtea6-1.4.1/openjdk-ecj/langtools/make/tools/CompilePropertie s/CompileProperties.java (at line 1) [javac] /* [javac] ^ [javac] The type java.lang.Object cannot be resolved. It is indirectly referenced from required .class files [javac] ---------- [javac] 2. ERROR in /home/neale/icedtea6-1.4.1/openjdk-ecj/langtools/make/tools/CompilePropertie s/CompileProperties.java (at line 1) [javac] /* [javac] ^ [javac] The type java.lang.String cannot be resolved. It is indirectly referenced from required .class files [javac] ---------- : : For a total of 100 errors. For icedtea9 I got exactly the same results. Does any of this look familiar to anyone? Also, when using the JDK I have build problems with both 6 & 9: make[2]: Entering directory `/home/neale/icedtea6-1.4.1/openjdk-ecj/jdk/make' common/Release.gmk:662: Extraneous text after `else' directive common/Release.gmk:664: *** only one `else' per conditional. Stop. And after fixing that I get with 6... common/Release.gmk:731: Extraneous text after `else' directive common/Release.gmk:735: *** only one `else' per conditional. Stop. Which is also easily fixed. Neale -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/zero-dev/attachments/20090331/7e20395a/attachment.html