From gbenson at redhat.com Fri Nov 6 03:39:38 2009 From: gbenson at redhat.com (Gary Benson) Date: Fri, 6 Nov 2009 11:39:38 +0000 Subject: [patch] rfc: shark overloaded intrinsic suffix fix In-Reply-To: <4ACB52C0.10609@zafena.se> References: <4ACB52C0.10609@zafena.se> Message-ID: <20091106113938.GA3745@redhat.com> Push away :) Cheers, Gary Xerxes R?nby wrote: > I was toying with adding some optimization passes and verify passes to > speed up and more runtime checks to shark, while doing so then one of > the verify passes found at least one oddity in the shark sourcecode. > The attached patch fixes this verifier issue. > > verifier output: > Overloaded intrinsic has incorrect suffix: '.i32'. It should be '.i32.p0i32' > i32 (i32*, i32, i32)* @llvm.atomic.cmp.swap.i32 > Broken module found, compilation aborted! > Stack dump: > 0. Running pass 'Module Verifier' on function > '@"java.io.BufferedReader::readLine"' > Avbruten (SIGABRT) > > http://llvm.org/docs/LangRef.html#int_atomics > > Ok to push? > > Cheers > Xerxes > > Index: icedtea6/ports/hotspot/src/share/vm/shark/sharkBuilder.cpp > =================================================================== > --- icedtea6.orig/ports/hotspot/src/share/vm/shark/sharkBuilder.cpp 2009-10-06 12:37:23.000000000 +0200 > +++ icedtea6/ports/hotspot/src/share/vm/shark/sharkBuilder.cpp 2009-10-06 12:54:11.000000000 +0200 > -402,7 +402,7 @@ > #ifdef ARM > (address) zero_cmpxchg_int, > #else > - "llvm.atomic.cmp.swap.i32", > + "llvm.atomic.cmp.swap.i32.p0i32", > #endif // ARM > "Iii", "i"); > } > -422,7 +422,7 @@ > #ifdef ARM > (address) zero_cmpxchg_ptr, > #else > - "llvm.atomic.cmp.swap.i" LP64_ONLY("64") NOT_LP64("32"), > + "llvm.atomic.cmp.swap.i" LP64_ONLY("64") NOT_LP64("32") ".p0i" LP64_ONLY("64") NOT_LP64("32"), > #endif // ARM > "Xxx", "x"); > } -- http://gbenson.net/ From xerxes at zafena.se Sat Nov 7 13:30:54 2009 From: xerxes at zafena.se (=?ISO-8859-1?Q?Xerxes_R=E5nby?=) Date: Sat, 07 Nov 2009 22:30:54 +0100 Subject: [patch] rfc: shark llvm2.7 r84651 SharkMemoryManager fix. Message-ID: <4AF5E70E.7040501@zafena.se> The LLVM JITMemoryManager changed a little in r84651 and by using the attached patch re-enables Shark to be build-able using the latest LLVM svn trunk. http://llvm.org/viewvc/llvm-project?view=rev&revision=84651 Clear to push? Cheers and have a great day! Xerxes -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: shark-llvm2.7-r84651.patch Url: http://mail.openjdk.java.net/pipermail/zero-dev/attachments/20091107/21c423cc/attachment.ksh From mvfranz at gmail.com Sun Nov 8 15:46:24 2009 From: mvfranz at gmail.com (Michael Franz) Date: Sun, 8 Nov 2009 18:46:24 -0500 Subject: What is the status of Zero on OpenJDK 7 Message-ID: Hi, I notice that most of the documentation talks about OpenJDK 6, does Zero/Shark currently compile with OpenJDK 7? Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/zero-dev/attachments/20091108/86d8f175/attachment.html From gnu_andrew at member.fsf.org Sun Nov 8 15:49:46 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Sun, 8 Nov 2009 23:49:46 +0000 Subject: What is the status of Zero on OpenJDK 7 In-Reply-To: References: Message-ID: <17c6771e0911081549j36e06285j6645a8c56e2a774@mail.gmail.com> 2009/11/8 Michael Franz : > Hi, > > I notice that most of the documentation talks about OpenJDK 6, does > Zero/Shark currently compile with OpenJDK 7? > > Michael > Yes. In fact, Zero has been accepted upstream for OpenJDK7: http://gbenson.net/?p=166 http://blog.fuseyism.com/index.php/2009/10/15/zero-assembler-port-upstream/ http://blog.fuseyism.com/index.php/2009/11/01/halfway-there/ which means it should appear in the bsd-port repository when they update to b76/milestone 5, but will need some porting work to run on that platform. Shark builds but can't currently bootstrap itself. -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From mvfranz at gmail.com Sun Nov 8 15:55:30 2009 From: mvfranz at gmail.com (Michael Franz) Date: Sun, 8 Nov 2009 18:55:30 -0500 Subject: What is the status of Zero on OpenJDK 7 In-Reply-To: <17c6771e0911081549j36e06285j6645a8c56e2a774@mail.gmail.com> References: <17c6771e0911081549j36e06285j6645a8c56e2a774@mail.gmail.com> Message-ID: So, I should be able to build on Fedora 11? I am currently getting errors when NOT use bsd. g++ -DLINUX -D_GNU_SOURCE -DCC_INTERP -DZERO -DPPC -DZERO_LIBARCH=\"ppc\" -DPRODUCT -I. -I../generated/adfiles -I../generated/jvmtifiles -I/home/mfranz/icedtea/icedtea/openjdk-boot/hotspot/src/share/vm/asm -I/home/mfranz/icedtea/icedtea/openjdk-boot/hotspot/src/share/vm/c1 -I/home/mfranz/icedtea/icedtea/openjdk-boot/hotspot/src/share/vm/ci -I/home/mfranz/icedtea/icedtea/openjdk-boot/hotspot/src/share/vm/classfile -I/home/mfranz/icedtea/icedtea/openjdk-boot/hotspot/src/share/vm/code -I/home/mfranz/icedtea/icedtea/openjdk-boot/hotspot/src/share/vm/compiler -I/home/mfranz/icedtea/icedtea/openjdk-boot/hotspot/src/share/vm/gc_implementation -I/home/mfranz/icedtea/icedtea/openjdk-boot/hotspot/src/share/vm/gc_implementation/g1 -I/home/mfranz/icedtea/icedtea/openjdk-boot/hotspot/src/share/vm/gc_implementation/parNew -I/home/mfranz/icedtea/icedtea/openjdk-boot/hotspot/src/share/vm/gc_implementation/concurrentMarkSweep -I/home/mfranz/icedtea/icedtea/openjdk-boot/hotspot/src/share/vm/gc_implementation/parallelScavenge -I/home/mfranz/icedtea/icedtea/openjdk-boot/hotspot/src/share/vm/gc_implementation/shared -I/home/mfranz/icedtea/icedtea/openjdk-boot/hotspot/src/share/vm/gc_interface -I/home/mfranz/icedtea/icedtea/openjdk-boot/hotspot/src/share/vm/interpreter -I/home/mfranz/icedtea/icedtea/openjdk-boot/hotspot/src/share/vm/memory -I/home/mfranz/icedtea/icedtea/openjdk-boot/hotspot/src/share/vm/oops -I/home/mfranz/icedtea/icedtea/openjdk-boot/hotspot/src/share/vm/prims -I/home/mfranz/icedtea/icedtea/openjdk-boot/hotspot/src/share/vm/runtime -I/home/mfranz/icedtea/icedtea/openjdk-boot/hotspot/src/share/vm/services -I/home/mfranz/icedtea/icedtea/openjdk-boot/hotspot/src/share/vm/shark -I/home/mfranz/icedtea/icedtea/openjdk-boot/hotspot/src/share/vm/utilities -I/home/mfranz/icedtea/icedtea/openjdk-boot/hotspot/src/cpu/zero/vm -I/home/mfranz/icedtea/icedtea/openjdk-boot/hotspot/src/os/linux/vm -I/home/mfranz/icedtea/icedtea/openjdk-boot/hotspot/src/os_cpu/linux_zero/vm -I../generated -DHOTSPOT_RELEASE_VERSION="\"17.0-b04\"" -DHOTSPOT_BUILD_TARGET="\"product\"" -DHOTSPOT_BUILD_USER="\"mfranz\"" -DHOTSPOT_LIB_ARCH=\"ppc\" -DJRE_RELEASE_VERSION="\"1.7.0_0-b75\"" -DHOTSPOT_VM_DISTRO="\"OpenJDK\"" -DDISTRIBUTION_ID="\"Built on Fedora release 11 (Leonidas)\"" -DSHARK -I/usr/lib/libffi-3.0.5/include -I/usr/include -DNDEBUG -D_GNU_SOURCE -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -fPIC -DSHARK_LLVM_VERSION=25 -fPIC -fno-rtti -fno-exceptions -D_REENTRANT -fcheck-new -m32 -pipe -g -O3 -fno-strict-aliasing -D_LP64=1 -Werror -Wpointer-arith -Wsign-compare -c -x c++-header -c ../generated/incls/_precompiled.incl -o incls/_precompiled.incl.gch In file included from ../generated/incls/_precompiled.incl:52: /home/mfranz/icedtea/icedtea/openjdk-boot/hotspot/src/share/vm/oops/klassVtable.hpp:234:1: error: multi-line comment /home/mfranz/icedtea/icedtea/openjdk-boot/hotspot/src/share/vm/oops/klassVtable.hpp:237:1: error: multi-line comment /home/mfranz/icedtea/icedtea/openjdk-boot/hotspot/src/share/vm/oops/klassVtable.hpp:240:1: error: multi-line comment /home/mfranz/icedtea/icedtea/openjdk-boot/hotspot/src/share/vm/oops/klassVtable.hpp:243:1: error: multi-line comment Michael On Sun, Nov 8, 2009 at 6:49 PM, Andrew John Hughes < gnu_andrew at member.fsf.org> wrote: > 2009/11/8 Michael Franz : > > Hi, > > > > I notice that most of the documentation talks about OpenJDK 6, does > > Zero/Shark currently compile with OpenJDK 7? > > > > Michael > > > > Yes. In fact, Zero has been accepted upstream for OpenJDK7: > > http://gbenson.net/?p=166 > http://blog.fuseyism.com/index.php/2009/10/15/zero-assembler-port-upstream/ > http://blog.fuseyism.com/index.php/2009/11/01/halfway-there/ > > which means it should appear in the bsd-port repository when they > update to b76/milestone 5, but will need some porting work to run on > that platform. > > Shark builds but can't currently bootstrap itself. > -- > Andrew :-) > > Free Java Software Engineer > Red Hat, Inc. (http://www.redhat.com) > > Support Free Java! > Contribute to GNU Classpath and the OpenJDK > http://www.gnu.org/software/classpath > http://openjdk.java.net > > PGP Key: 94EFD9D8 (http://subkeys.pgp.net) > Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/zero-dev/attachments/20091108/5b4ad611/attachment.html From xerxes at zafena.se Mon Nov 9 02:38:41 2009 From: xerxes at zafena.se (=?ISO-8859-1?Q?Xerxes_R=E5nby?=) Date: Mon, 09 Nov 2009 11:38:41 +0100 Subject: [patch] rfc: -XX:SharkPrintAsmOf llvm2.7 api update Message-ID: <4AF7F131.2090508@zafena.se> In llvm2.7 svn trunk Chris Lattner added a new API on Aph's request that would enable and disable debugging output more vigorously. http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20091026/089863.html - new api for us, yay! The attached patch in this mail makes Shark use this new API for the -XX:SharkPrintAsmOf debug option. Unfortunally there was a small namespaces bug in the implementation of this new LLVM API and I am waiting for response from Chris reguarding this issue: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20091109/090682.html - correspondence You have to apply the patch on llvm in this correspondence in-order to build the new patch for icedtea6. Should i remove the old pre LLVM2.7 support for -XX:SharkPrintAsmOf ? Currently you need a special patched llvm version to make the option work at all on older LLVM versions. Cheers and have a great day! Xerxes -------------- next part -------------- A non-text attachment was scrubbed... Name: 9nov-SharkPrintAsmOf-llvm2.7api.patch Type: text/x-patch Size: 1724 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/zero-dev/attachments/20091109/427a6d04/attachment.bin From gbenson at redhat.com Mon Nov 9 03:06:24 2009 From: gbenson at redhat.com (Gary Benson) Date: Mon, 9 Nov 2009 11:06:24 +0000 Subject: [patch] rfc: shark llvm2.7 r84651 SharkMemoryManager fix. In-Reply-To: <4AF5E70E.7040501@zafena.se> References: <4AF5E70E.7040501@zafena.se> Message-ID: <20091109110624.GC3281@redhat.com> Xerxes R?nby wrote: > The LLVM JITMemoryManager changed a little in r84651 and by using > the attached patch re-enables Shark to be build-able using the > latest LLVM svn trunk. > http://llvm.org/viewvc/llvm-project?view=rev&revision=84651 > > Clear to push? Rather than having two #ifs, how about having a #else? Otherwise, please push :) Cheers, Gary -- http://gbenson.net/ From gbenson at redhat.com Mon Nov 9 03:08:58 2009 From: gbenson at redhat.com (Gary Benson) Date: Mon, 9 Nov 2009 11:08:58 +0000 Subject: [patch] rfc: -XX:SharkPrintAsmOf llvm2.7 api update In-Reply-To: <4AF7F131.2090508@zafena.se> References: <4AF7F131.2090508@zafena.se> Message-ID: <20091109110858.GD3281@redhat.com> Xerxes R?nby wrote: > In llvm2.7 svn trunk Chris Lattner added a new API on Aph's request > that would enable and disable debugging output more vigorously. > http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20091026/089863.html > - new api for us, yay! > The attached patch in this mail makes Shark use this new API for the > -XX:SharkPrintAsmOf debug option. > > Unfortunally there was a small namespaces bug in the implementation > of this new LLVM API and I am waiting for response from Chris > reguarding this issue: > http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20091109/090682.html > - correspondence > You have to apply the patch on llvm in this correspondence in-order > to build the new patch for icedtea6. > > Should i remove the old pre LLVM2.7 support for -XX:SharkPrintAsmOf ? > Currently you need a special patched llvm version to make the option > work at all on older LLVM versions. Please leave the old support in, with a #else as I mentioned in my last mail. Thanks for doing this! Cheers, Gary -- http://gbenson.net/ From xerxes at zafena.se Mon Nov 9 03:13:26 2009 From: xerxes at zafena.se (=?ISO-8859-1?Q?Xerxes_R=E5nby?=) Date: Mon, 09 Nov 2009 12:13:26 +0100 Subject: [patch] rfc: -XX:SharkPrintAsmOf llvm2.7 api update In-Reply-To: <4AF7F131.2090508@zafena.se> References: <4AF7F131.2090508@zafena.se> Message-ID: <4AF7F956.6020206@zafena.se> Xerxes R?nby skrev: > In llvm2.7 svn trunk Chris Lattner added a new API on Aph's request that > would enable and disable debugging output more vigorously. > http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20091026/089863.html > - new api for us, yay! > The attached patch in this mail makes Shark use this new API for the > -XX:SharkPrintAsmOf debug option. > > Unfortunally there was a small namespaces bug in the implementation of > this new LLVM API and I am waiting for response from Chris reguarding > this issue: > http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20091109/090682.html > - correspondence > You have to apply the patch on llvm in this correspondence in-order to > build the new patch for icedtea6. > > Should i remove the old pre LLVM2.7 support for -XX:SharkPrintAsmOf ? > Currently you need a special patched llvm version to make the option > work at all on older LLVM versions. > > Cheers and have a great day! > Xerxes > 2nd try i somehow attached the wrong version of the patch with some missing curly-brackets, this should be the correct version. Xerxes -------------- next part -------------- A non-text attachment was scrubbed... Name: 9nov-take2-SharkPrintAsmOf-llvm2.7api.patch Type: text/x-patch Size: 1744 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/zero-dev/attachments/20091109/74a66ece/attachment-0001.bin From xerxes at zafena.se Mon Nov 9 03:15:01 2009 From: xerxes at zafena.se (=?ISO-8859-1?Q?Xerxes_R=E5nby?=) Date: Mon, 09 Nov 2009 12:15:01 +0100 Subject: [patch] rfc: -XX:SharkPrintAsmOf llvm2.7 api update In-Reply-To: <20091109110858.GD3281@redhat.com> References: <4AF7F131.2090508@zafena.se> <20091109110858.GD3281@redhat.com> Message-ID: <4AF7F9B5.4030803@zafena.se> Gary Benson skrev: > Xerxes R?nby wrote: > >> In llvm2.7 svn trunk Chris Lattner added a new API on Aph's request >> that would enable and disable debugging output more vigorously. >> http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20091026/089863.html >> - new api for us, yay! >> The attached patch in this mail makes Shark use this new API for the >> -XX:SharkPrintAsmOf debug option. >> >> Unfortunally there was a small namespaces bug in the implementation >> of this new LLVM API and I am waiting for response from Chris >> reguarding this issue: >> http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20091109/090682.html >> - correspondence >> You have to apply the patch on llvm in this correspondence in-order >> to build the new patch for icedtea6. >> >> Should i remove the old pre LLVM2.7 support for -XX:SharkPrintAsmOf ? >> Currently you need a special patched llvm version to make the option >> work at all on older LLVM versions. >> > > Please leave the old support in, with a #else as I mentioned in my > last mail. > > Thanks for doing this! > > Cheers, > Gary > > Ok thanks, i will add as many #else as appropriate and commit! Cheers Xerxes From xerxes at zafena.se Mon Nov 9 07:02:17 2009 From: xerxes at zafena.se (=?ISO-8859-1?Q?Xerxes_R=E5nby?=) Date: Mon, 09 Nov 2009 16:02:17 +0100 Subject: [patch] rfc: -XX:SharkPrintAsmOf llvm2.7 api update In-Reply-To: <4AF7F9B5.4030803@zafena.se> References: <4AF7F131.2090508@zafena.se> <20091109110858.GD3281@redhat.com> <4AF7F9B5.4030803@zafena.se> Message-ID: <4AF82EF9.8070907@zafena.se> Xerxes R?nby skrev: > Gary Benson skrev: > >> Xerxes R?nby wrote: >> >> >>> In llvm2.7 svn trunk Chris Lattner added a new API on Aph's request >>> that would enable and disable debugging output more vigorously. >>> http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20091026/089863.html >>> - new api for us, yay! >>> The attached patch in this mail makes Shark use this new API for the >>> -XX:SharkPrintAsmOf debug option. >>> >>> Unfortunally there was a small namespaces bug in the implementation >>> of this new LLVM API and I am waiting for response from Chris >>> reguarding this issue: >>> http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20091109/090682.html >>> - correspondence >>> You have to apply the patch on llvm in this correspondence in-order >>> to build the new patch for icedtea6. >>> For your information: Patching of llvm are no longer needed to make use of the -XX:SharkPrintAsmOf= debug option when using llvm2.7svn rev 86544 and later with icedtea6! All fixed upstream. http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20091109/090686.html Enjoy! Xerxes From mvfranz at gmail.com Tue Nov 10 15:24:43 2009 From: mvfranz at gmail.com (Michael Franz) Date: Tue, 10 Nov 2009 18:24:43 -0500 Subject: What is the status of Zero on OpenJDK 7 In-Reply-To: References: <17c6771e0911081549j36e06285j6645a8c56e2a774@mail.gmail.com> Message-ID: On Sun, Nov 8, 2009 at 6:55 PM, Michael Franz wrote: > So, I should be able to build on Fedora 11? I am currently getting errors > when NOT use bsd. > > g++ -DLINUX -D_GNU_SOURCE -DCC_INTERP -DZERO -DPPC -DZERO_LIBARCH=\"ppc\" > -DPRODUCT -I. -I../generated/adfiles -I../generated/jvmtifiles > -I/home/mfranz/icedtea/icedtea/openjdk-boot/hotspot/src/share/vm/asm > -I/home/mfranz/icedtea/icedtea/openjdk-boot/hotspot/src/share/vm/c1 > -I/home/mfranz/icedtea/icedtea/openjdk-boot/hotspot/src/share/vm/ci > -I/home/mfranz/icedtea/icedtea/openjdk-boot/hotspot/src/share/vm/classfile > -I/home/mfranz/icedtea/icedtea/openjdk-boot/hotspot/src/share/vm/code > -I/home/mfranz/icedtea/icedtea/openjdk-boot/hotspot/src/share/vm/compiler > -I/home/mfranz/icedtea/icedtea/openjdk-boot/hotspot/src/share/vm/gc_implementation > -I/home/mfranz/icedtea/icedtea/openjdk-boot/hotspot/src/share/vm/gc_implementation/g1 > -I/home/mfranz/icedtea/icedtea/openjdk-boot/hotspot/src/share/vm/gc_implementation/parNew > -I/home/mfranz/icedtea/icedtea/openjdk-boot/hotspot/src/share/vm/gc_implementation/concurrentMarkSweep > -I/home/mfranz/icedtea/icedtea/openjdk-boot/hotspot/src/share/vm/gc_implementation/parallelScavenge > -I/home/mfranz/icedtea/icedtea/openjdk-boot/hotspot/src/share/vm/gc_implementation/shared > -I/home/mfranz/icedtea/icedtea/openjdk-boot/hotspot/src/share/vm/gc_interface > -I/home/mfranz/icedtea/icedtea/openjdk-boot/hotspot/src/share/vm/interpreter > -I/home/mfranz/icedtea/icedtea/openjdk-boot/hotspot/src/share/vm/memory > -I/home/mfranz/icedtea/icedtea/openjdk-boot/hotspot/src/share/vm/oops > -I/home/mfranz/icedtea/icedtea/openjdk-boot/hotspot/src/share/vm/prims > -I/home/mfranz/icedtea/icedtea/openjdk-boot/hotspot/src/share/vm/runtime > -I/home/mfranz/icedtea/icedtea/openjdk-boot/hotspot/src/share/vm/services > -I/home/mfranz/icedtea/icedtea/openjdk-boot/hotspot/src/share/vm/shark > -I/home/mfranz/icedtea/icedtea/openjdk-boot/hotspot/src/share/vm/utilities > -I/home/mfranz/icedtea/icedtea/openjdk-boot/hotspot/src/cpu/zero/vm > -I/home/mfranz/icedtea/icedtea/openjdk-boot/hotspot/src/os/linux/vm > -I/home/mfranz/icedtea/icedtea/openjdk-boot/hotspot/src/os_cpu/linux_zero/vm > -I../generated -DHOTSPOT_RELEASE_VERSION="\"17.0-b04\"" > -DHOTSPOT_BUILD_TARGET="\"product\"" -DHOTSPOT_BUILD_USER="\"mfranz\"" > -DHOTSPOT_LIB_ARCH=\"ppc\" -DJRE_RELEASE_VERSION="\"1.7.0_0-b75\"" > -DHOTSPOT_VM_DISTRO="\"OpenJDK\"" -DDISTRIBUTION_ID="\"Built on Fedora > release 11 (Leonidas)\"" -DSHARK -I/usr/lib/libffi-3.0.5/include > -I/usr/include -DNDEBUG -D_GNU_SOURCE -D__STDC_LIMIT_MACROS > -D__STDC_CONSTANT_MACROS -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 > -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -fPIC > -DSHARK_LLVM_VERSION=25 -fPIC -fno-rtti -fno-exceptions -D_REENTRANT > -fcheck-new -m32 -pipe -g -O3 -fno-strict-aliasing -D_LP64=1 -Werror > -Wpointer-arith -Wsign-compare -c -x c++-header -c > ../generated/incls/_precompiled.incl -o incls/_precompiled.incl.gch > In file included from ../generated/incls/_precompiled.incl:52: > /home/mfranz/icedtea/icedtea/openjdk-boot/hotspot/src/share/vm/oops/klassVtable.hpp:234:1: > error: multi-line comment > /home/mfranz/icedtea/icedtea/openjdk-boot/hotspot/src/share/vm/oops/klassVtable.hpp:237:1: > error: multi-line comment > /home/mfranz/icedtea/icedtea/openjdk-boot/hotspot/src/share/vm/oops/klassVtable.hpp:240:1: > error: multi-line comment > /home/mfranz/icedtea/icedtea/openjdk-boot/hotspot/src/share/vm/oops/klassVtable.hpp:243:1: > error: multi-line comment > > I was able to get past this by upgrading to llvm 2.6 (Fedora 11 as 2.5). I see post referencing llvm 2.7. Is this going to be the required version soon? I am building on a G4 which is 32 bits, but _LP64=1 is being defined. This is causing problems as jlong is being defined incorrectly (long instead of long long). How do I unset _LP64? Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/zero-dev/attachments/20091110/44cf953e/attachment.html From gbenson at redhat.com Wed Nov 11 01:46:52 2009 From: gbenson at redhat.com (Gary Benson) Date: Wed, 11 Nov 2009 09:46:52 +0000 Subject: What is the status of Zero on OpenJDK 7 In-Reply-To: References: <17c6771e0911081549j36e06285j6645a8c56e2a774@mail.gmail.com> Message-ID: <20091111094651.GA3256@redhat.com> Michael Franz wrote: > I was able to get past this by upgrading to llvm 2.6 (Fedora 11 as > 2.5). I see post referencing llvm 2.7. Is this going to be the > required version soon? There's no plans for that. In the past we've generally supported as many versions as developers cared about. > I am building on a G4 which is 32 bits, but _LP64=1 is being > defined. This is causing problems as jlong is being defined > incorrectly (long instead of long long). How do I unset _LP64? What does 'uname -m' say on your machine? Cheers, Gary -- http://gbenson.net/ From mvfranz at gmail.com Wed Nov 11 05:46:36 2009 From: mvfranz at gmail.com (Michael Franz) Date: Wed, 11 Nov 2009 08:46:36 -0500 Subject: What is the status of Zero on OpenJDK 7 In-Reply-To: <20091111094651.GA3256@redhat.com> References: <17c6771e0911081549j36e06285j6645a8c56e2a774@mail.gmail.com> <20091111094651.GA3256@redhat.com> Message-ID: On Wed, Nov 11, 2009 at 4:46 AM, Gary Benson wrote: > Michael Franz wrote: > > I was able to get past this by upgrading to llvm 2.6 (Fedora 11 as > > 2.5). I see post referencing llvm 2.7. Is this going to be the > > required version soon? > > There's no plans for that. In the past we've generally supported as > many versions as developers cared about. > > > I am building on a G4 which is 32 bits, but _LP64=1 is being > > defined. This is causing problems as jlong is being defined > > incorrectly (long instead of long long). How do I unset _LP64? > > What does 'uname -m' say on your machine? > > uname -m ppc I was able to get the build to progress by setting ARCH_DATA_MODEL=32 before calling make. I did this since there didn't seem to be a case where the ARCH was equal to ppc and it then defaults to 64. Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/zero-dev/attachments/20091111/2ba720c1/attachment.html From gbenson at redhat.com Wed Nov 11 05:55:01 2009 From: gbenson at redhat.com (Gary Benson) Date: Wed, 11 Nov 2009 13:55:01 +0000 Subject: What is the status of Zero on OpenJDK 7 In-Reply-To: References: <17c6771e0911081549j36e06285j6645a8c56e2a774@mail.gmail.com> <20091111094651.GA3256@redhat.com> Message-ID: <20091111135501.GC3256@redhat.com> Michael Franz wrote: > On Wed, Nov 11, 2009 at 4:46 AM, Gary Benson wrote: > > Michael Franz wrote: > > > I was able to get past this by upgrading to llvm 2.6 (Fedora 11 as > > > 2.5). I see post referencing llvm 2.7. Is this going to be the > > > required version soon? > > > > There's no plans for that. In the past we've generally supported as > > many versions as developers cared about. > > > > > I am building on a G4 which is 32 bits, but _LP64=1 is being > > > defined. This is causing problems as jlong is being defined > > > incorrectly (long instead of long long). How do I unset _LP64? > > > > What does 'uname -m' say on your machine? > > > > uname -m > > ppc > > I was able to get the build to progress by setting ARCH_DATA_MODEL=32 > before calling make. I did this since there didn't seem to be a case > where the ARCH was equal to ppc and it then defaults to 64. Interesting. Is this with IcedTea7? Cheers, Gary -- http://gbenson.net/ From gbenson at redhat.com Wed Nov 11 05:56:58 2009 From: gbenson at redhat.com (Gary Benson) Date: Wed, 11 Nov 2009 13:56:58 +0000 Subject: Zero tweak Message-ID: <20091111135658.GD3256@redhat.com> Hi all, This commit inlines a couple of methods in Zero. I had thought that declaring methods in the header file caused them to be automatically inlined, but apparently that isn't the case. There are probably more methods that could benefit from this; I only noticed these because you end up with two frames for every Java call in gdb. Cheers, Gary -- http://gbenson.net/ -------------- next part -------------- diff -r ff96e96a485b -r b078cdccad9c ChangeLog --- a/ChangeLog Mon Nov 09 13:07:15 2009 +0100 +++ b/ChangeLog Wed Nov 11 10:30:19 2009 +0000 @@ -1,3 +1,10 @@ +2009-11-11 Gary Benson + + * ports/hotspot/src/cpu/zero/vm/entry_zero.hpp + (ZeroEntry::entry_point): Inlined. + (ZeroEntry::invoke): Likewise. + (ZeroEntry::invoke_osr): Likewise. + 2009-11-09 Xerxes R?nby * ports/hotspot/src/share/vm/shark/llvmHeaders.hpp, diff -r ff96e96a485b -r b078cdccad9c ports/hotspot/src/cpu/zero/vm/entry_zero.hpp --- a/ports/hotspot/src/cpu/zero/vm/entry_zero.hpp Mon Nov 09 13:07:15 2009 +0100 +++ b/ports/hotspot/src/cpu/zero/vm/entry_zero.hpp Wed Nov 11 10:30:19 2009 +0000 @@ -33,7 +33,7 @@ address _entry_point; public: - address entry_point() const { + inline address entry_point() const { return _entry_point; } void set_entry_point(address entry_point) { @@ -50,10 +50,10 @@ TRAPS); public: - void invoke(methodOop method, TRAPS) const { + inline void invoke(methodOop method, TRAPS) const { ((NormalEntryFunc) entry_point())(method, (intptr_t) this, THREAD); } - void invoke_osr(methodOop method, address osr_buf, TRAPS) const { + inline void invoke_osr(methodOop method, address osr_buf, TRAPS) const { ((OSREntryFunc) entry_point())(method, osr_buf, (intptr_t) this, THREAD); } From gbenson at redhat.com Wed Nov 11 06:00:55 2009 From: gbenson at redhat.com (Gary Benson) Date: Wed, 11 Nov 2009 14:00:55 +0000 Subject: Zero stack walker tweak Message-ID: <20091111140054.GE3256@redhat.com> Hi all, This commit combines the handling of most of the different types of frame you get with Zero and Shark. The old method mirrors how it's done for the architecture-specific HotSpot ports, but it's unnecessary with Zero. I balked at adding yet another unnecessary special case to handle Shark-compiled JNI method wrappers... Cheers, Gary -- http://gbenson.net/ -------------- next part -------------- diff -r b078cdccad9c -r 3adabf9ea7ef ChangeLog --- a/ChangeLog Wed Nov 11 10:30:19 2009 +0000 +++ b/ChangeLog Wed Nov 11 10:34:05 2009 +0000 @@ -1,3 +1,15 @@ +2009-11-11 Gary Benson + + * ports/hotspot/src/cpu/zero/vm/frame_zero.hpp + (frame::is_fake_stub_frame): Removed. + (frame::sender_for_fake_stub_frame): Likewise. + (frame::sender_for_nonentry_frame): New method. + * ports/hotspot/src/cpu/zero/vm/frame_zero.cpp + (frame::is_fake_stub_frame): Removed. + (frame::sender_for_fake_stub_frame): Likewise. + (frame::sender_for_nonentry_frame): New method. + (frame::sender): Refactored. + 2009-11-11 Gary Benson * ports/hotspot/src/cpu/zero/vm/entry_zero.hpp diff -r b078cdccad9c -r 3adabf9ea7ef ports/hotspot/src/cpu/zero/vm/frame_zero.cpp --- a/ports/hotspot/src/cpu/zero/vm/frame_zero.cpp Wed Nov 11 10:30:19 2009 +0000 +++ b/ports/hotspot/src/cpu/zero/vm/frame_zero.cpp Wed Nov 11 10:34:05 2009 +0000 @@ -36,10 +36,6 @@ return zeroframe()->is_interpreter_frame(); } -bool frame::is_fake_stub_frame() const { - return zeroframe()->is_fake_stub_frame(); -} - frame frame::sender_for_entry_frame(RegisterMap *map) const { assert(map != NULL, "map must be set"); assert(!entry_frame_is_first(), "next Java fp must be non zero"); @@ -50,15 +46,7 @@ return frame(sender_sp(), sp() + 1); } -frame frame::sender_for_interpreter_frame(RegisterMap *map) const { - return frame(sender_sp(), sp() + 1); -} - -frame frame::sender_for_compiled_frame(RegisterMap *map) const { - return frame(sender_sp(), sp() + 1); -} - -frame frame::sender_for_fake_stub_frame(RegisterMap *map) const { +frame frame::sender_for_nonentry_frame(RegisterMap *map) const { return frame(sender_sp(), sp() + 1); } @@ -69,17 +57,8 @@ if (is_entry_frame()) return sender_for_entry_frame(map); - - if (is_interpreted_frame()) - return sender_for_interpreter_frame(map); - - if (is_compiled_frame()) - return sender_for_compiled_frame(map); - - if (is_fake_stub_frame()) - return sender_for_fake_stub_frame(map); - - ShouldNotReachHere(); + else + return sender_for_nonentry_frame(map); } #ifdef CC_INTERP diff -r b078cdccad9c -r 3adabf9ea7ef ports/hotspot/src/cpu/zero/vm/frame_zero.hpp --- a/ports/hotspot/src/cpu/zero/vm/frame_zero.hpp Wed Nov 11 10:30:19 2009 +0000 +++ b/ports/hotspot/src/cpu/zero/vm/frame_zero.hpp Wed Nov 11 10:34:05 2009 +0000 @@ -65,10 +65,7 @@ } public: - bool is_fake_stub_frame() const; - - public: - frame sender_for_fake_stub_frame(RegisterMap* map) const; + frame sender_for_nonentry_frame(RegisterMap* map) const; public: void zero_print_on_error(int index, From gbenson at redhat.com Wed Nov 11 06:03:45 2009 From: gbenson at redhat.com (Gary Benson) Date: Wed, 11 Nov 2009 14:03:45 +0000 Subject: Shark tweak Message-ID: <20091111140345.GF3256@redhat.com> Hi all, SharkType had two methods for referring to objects which represent an oop in the JVM: oop_type and jobject_type. HotSpot has C types called oop and jobject, and I thought they were synonymous, but they aren't; everything in Shark is an oop and not a jobject. This commit removes all references to jobject from Shark for clarity. Cheers, Gary -- http://gbenson.net/ -------------- next part -------------- diff -r 3adabf9ea7ef -r 79079fb4d3b4 ChangeLog --- a/ChangeLog Wed Nov 11 10:34:05 2009 +0000 +++ b/ChangeLog Wed Nov 11 13:52:48 2009 +0000 @@ -1,3 +1,32 @@ +2009-11-11 Gary Benson + + * ports/hotspot/src/share/vm/shark/sharkType.hpp + (SharkType::jobject_type): Removed. + + * ports/hotspot/src/share/vm/shark/llvmValue.hpp + (LLVMValue::null): Use SharkType::oop_type() instead of + SharkType::jobject_type(). + * ports/hotspot/src/share/vm/shark/sharkBuilder.cpp + (SharkBuilder::CreateInlineOop): Likewise. + * ports/hotspot/src/share/vm/shark/sharkIntrinsics.cpp + (SharkIntrinsics::do_Object_getClass): Likewise. + (SharkIntrinsics::do_Thread_currentThread): Likewise. + * ports/hotspot/src/share/vm/shark/sharkTopLevelBlock.hpp + (SharkTopLevelBlock::pending_exception_address): Likewise. + (SharkTopLevelBlock::get_vm_result): Likewise. + * ports/hotspot/src/share/vm/shark/sharkTopLevelBlock.cpp + (SharkTopLevelBlock::call_register_finalizer): Likewise. + (SharkTopLevelBlock::get_virtual_callee): Likewise. + (SharkTopLevelBlock::get_interface_callee): Likewise. + (SharkTopLevelBlock::do_full_instance_check): Likewise. + (SharkTopLevelBlock::do_new): Likewise. + * ports/hotspot/src/share/vm/shark/sharkType.cpp + (SharkType::initialize): Likewise. + * ports/hotspot/src/share/vm/shark/sharkValue.hpp + (SharkValue::create_jobject): Likewise. + * ports/hotspot/src/share/vm/shark/sharkValue.cpp + (SharkNormalValue::is_jobject): Likewise. + 2009-11-11 Gary Benson * ports/hotspot/src/cpu/zero/vm/frame_zero.hpp diff -r 3adabf9ea7ef -r 79079fb4d3b4 ports/hotspot/src/share/vm/shark/llvmValue.hpp --- a/ports/hotspot/src/share/vm/shark/llvmValue.hpp Wed Nov 11 10:34:05 2009 +0000 +++ b/ports/hotspot/src/share/vm/shark/llvmValue.hpp Wed Nov 11 13:52:48 2009 +0000 @@ -55,7 +55,7 @@ } static llvm::ConstantPointerNull* null() { - return llvm::ConstantPointerNull::get(SharkType::jobject_type()); + return llvm::ConstantPointerNull::get(SharkType::oop_type()); } public: diff -r 3adabf9ea7ef -r 79079fb4d3b4 ports/hotspot/src/share/vm/shark/sharkBuilder.cpp --- a/ports/hotspot/src/share/vm/shark/sharkBuilder.cpp Wed Nov 11 10:34:05 2009 +0000 +++ b/ports/hotspot/src/share/vm/shark/sharkBuilder.cpp Wed Nov 11 13:52:48 2009 +0000 @@ -577,7 +577,7 @@ return CreateLoad( CreateIntToPtr( code_buffer_address(code_buffer()->inline_oop(object)), - PointerType::getUnqual(SharkType::jobject_type())), + PointerType::getUnqual(SharkType::oop_type())), name); } diff -r 3adabf9ea7ef -r 79079fb4d3b4 ports/hotspot/src/share/vm/shark/sharkIntrinsics.cpp --- a/ports/hotspot/src/share/vm/shark/sharkIntrinsics.cpp Wed Nov 11 10:34:05 2009 +0000 +++ b/ports/hotspot/src/share/vm/shark/sharkIntrinsics.cpp Wed Nov 11 13:52:48 2009 +0000 @@ -212,7 +212,7 @@ Value *klass = builder()->CreateValueOfStructEntry( state()->pop()->jobject_value(), in_ByteSize(oopDesc::klass_offset_in_bytes()), - SharkType::jobject_type(), + SharkType::oop_type(), "klass"); Value *klass_part = builder()->CreateAddressOfStructEntry( @@ -246,7 +246,7 @@ SharkValue::create_jobject( builder()->CreateValueOfStructEntry( thread(), JavaThread::threadObj_offset(), - SharkType::jobject_type(), + SharkType::oop_type(), "threadObj"), true)); } diff -r 3adabf9ea7ef -r 79079fb4d3b4 ports/hotspot/src/share/vm/shark/sharkTopLevelBlock.cpp --- a/ports/hotspot/src/share/vm/shark/sharkTopLevelBlock.cpp Wed Nov 11 10:34:05 2009 +0000 +++ b/ports/hotspot/src/share/vm/shark/sharkTopLevelBlock.cpp Wed Nov 11 13:52:48 2009 +0000 @@ -580,7 +580,7 @@ Value *klass = builder()->CreateValueOfStructEntry( receiver, in_ByteSize(oopDesc::klass_offset_in_bytes()), - SharkType::jobject_type(), + SharkType::oop_type(), "klass"); Value *klass_part = builder()->CreateAddressOfStructEntry( @@ -956,7 +956,7 @@ Value *klass = builder()->CreateValueOfStructEntry( receiver->jobject_value(), in_ByteSize(oopDesc::klass_offset_in_bytes()), - SharkType::jobject_type(), + SharkType::oop_type(), "klass"); return builder()->CreateLoad( @@ -981,7 +981,7 @@ // Locate the receiver's itable Value *object_klass = builder()->CreateValueOfStructEntry( receiver->jobject_value(), in_ByteSize(oopDesc::klass_offset_in_bytes()), - SharkType::jobject_type(), + SharkType::oop_type(), "object_klass"); Value *vtable_start = builder()->CreateAdd( @@ -1028,7 +1028,7 @@ Value *itable_iklass = builder()->CreateValueOfStructEntry( itable_entry, in_ByteSize(itableOffsetEntry::interface_offset_in_bytes()), - SharkType::jobject_type(), + SharkType::oop_type(), "itable_iklass"); builder()->CreateCondBr( @@ -1328,7 +1328,7 @@ // Get the class of the object being tested Value *object_klass = builder()->CreateValueOfStructEntry( object, in_ByteSize(oopDesc::klass_offset_in_bytes()), - SharkType::jobject_type(), + SharkType::oop_type(), "object_klass"); // Perform the check @@ -1486,7 +1486,7 @@ builder()->SetInsertPoint(got_tlab); tlab_object = builder()->CreateIntToPtr( - old_top, SharkType::jobject_type(), "tlab_object"); + old_top, SharkType::oop_type(), "tlab_object"); builder()->CreateStore(new_top, top_addr); builder()->CreateBr(initialize); @@ -1519,7 +1519,7 @@ builder()->SetInsertPoint(got_heap); heap_object = builder()->CreateIntToPtr( - old_top, SharkType::jobject_type(), "heap_object"); + old_top, SharkType::oop_type(), "heap_object"); Value *check = builder()->CreateCmpxchgPtr(new_top, top_addr, old_top); builder()->CreateCondBr( @@ -1530,7 +1530,7 @@ builder()->SetInsertPoint(initialize); if (tlab_object) { PHINode *phi = builder()->CreatePHI( - SharkType::jobject_type(), "fast_object"); + SharkType::oop_type(), "fast_object"); phi->addIncoming(tlab_object, got_tlab); phi->addIncoming(heap_object, got_heap); fast_object = phi; @@ -1553,7 +1553,7 @@ Value *klass_addr = builder()->CreateAddressOfStructEntry( fast_object, in_ByteSize(oopDesc::klass_offset_in_bytes()), - PointerType::getUnqual(SharkType::jobject_type()), + PointerType::getUnqual(SharkType::oop_type()), "klass_addr"); // Set the mark @@ -1590,7 +1590,7 @@ builder()->SetInsertPoint(push_object); } if (fast_object) { - PHINode *phi = builder()->CreatePHI(SharkType::jobject_type(), "object"); + PHINode *phi = builder()->CreatePHI(SharkType::oop_type(), "object"); phi->addIncoming(fast_object, got_fast); phi->addIncoming(slow_object, got_slow); object = phi; diff -r 3adabf9ea7ef -r 79079fb4d3b4 ports/hotspot/src/share/vm/shark/sharkTopLevelBlock.hpp --- a/ports/hotspot/src/share/vm/shark/sharkTopLevelBlock.hpp Wed Nov 11 10:34:05 2009 +0000 +++ b/ports/hotspot/src/share/vm/shark/sharkTopLevelBlock.hpp Wed Nov 11 13:52:48 2009 +0000 @@ -245,7 +245,7 @@ { return builder()->CreateAddressOfStructEntry( thread(), Thread::pending_exception_offset(), - llvm::PointerType::getUnqual(SharkType::jobject_type()), + llvm::PointerType::getUnqual(SharkType::oop_type()), "pending_exception_addr"); } llvm::LoadInst* get_pending_exception() const @@ -349,7 +349,7 @@ { llvm::Value *addr = builder()->CreateAddressOfStructEntry( thread(), JavaThread::vm_result_offset(), - llvm::PointerType::getUnqual(SharkType::jobject_type()), + llvm::PointerType::getUnqual(SharkType::oop_type()), "vm_result_addr"); llvm::LoadInst *result = builder()->CreateLoad(addr, "vm_result"); builder()->CreateStore(LLVMValue::null(), addr); diff -r 3adabf9ea7ef -r 79079fb4d3b4 ports/hotspot/src/share/vm/shark/sharkType.cpp --- a/ports/hotspot/src/share/vm/shark/sharkType.cpp Wed Nov 11 10:34:05 2009 +0000 +++ b/ports/hotspot/src/share/vm/shark/sharkType.cpp Wed Nov 11 13:52:48 2009 +0000 @@ -168,8 +168,8 @@ case T_OBJECT: case T_ARRAY: - _to_stackType_tab[i] = jobject_type(); - _to_arrayType_tab[i] = jobject_type(); + _to_stackType_tab[i] = oop_type(); + _to_arrayType_tab[i] = oop_type(); break; case T_ADDRESS: diff -r 3adabf9ea7ef -r 79079fb4d3b4 ports/hotspot/src/share/vm/shark/sharkType.hpp --- a/ports/hotspot/src/share/vm/shark/sharkType.hpp Wed Nov 11 10:34:05 2009 +0000 +++ b/ports/hotspot/src/share/vm/shark/sharkType.hpp Wed Nov 11 13:52:48 2009 +0000 @@ -1,6 +1,6 @@ /* * Copyright 1999-2007 Sun Microsystems, Inc. All Rights Reserved. - * Copyright 2008 Red Hat, Inc. + * Copyright 2008, 2009 Red Hat, Inc. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -161,10 +161,6 @@ return llvm::Type::DoubleTy; #endif } - static const llvm::PointerType* jobject_type() - { - return oop_type(); - } // Java types as they appear on the stack and in fields private: diff -r 3adabf9ea7ef -r 79079fb4d3b4 ports/hotspot/src/share/vm/shark/sharkValue.cpp --- a/ports/hotspot/src/share/vm/shark/sharkValue.cpp Wed Nov 11 10:34:05 2009 +0000 +++ b/ports/hotspot/src/share/vm/shark/sharkValue.cpp Wed Nov 11 13:52:48 2009 +0000 @@ -151,7 +151,7 @@ } bool SharkNormalValue::is_jobject() const { - return llvm_value()->getType() == SharkType::jobject_type(); + return llvm_value()->getType() == SharkType::oop_type(); } bool SharkNormalValue::is_jarray() const { diff -r 3adabf9ea7ef -r 79079fb4d3b4 ports/hotspot/src/share/vm/shark/sharkValue.hpp --- a/ports/hotspot/src/share/vm/shark/sharkValue.hpp Wed Nov 11 10:34:05 2009 +0000 +++ b/ports/hotspot/src/share/vm/shark/sharkValue.hpp Wed Nov 11 13:52:48 2009 +0000 @@ -118,7 +118,7 @@ } static SharkValue* create_jobject(llvm::Value* value, bool zero_checked) { - assert(value->getType() == SharkType::jobject_type(), "should be"); + assert(value->getType() == SharkType::oop_type(), "should be"); return create_generic(ciType::make(T_OBJECT), value, zero_checked); } From mvfranz at gmail.com Wed Nov 11 06:03:53 2009 From: mvfranz at gmail.com (Michael Franz) Date: Wed, 11 Nov 2009 09:03:53 -0500 Subject: What is the status of Zero on OpenJDK 7 In-Reply-To: <20091111135501.GC3256@redhat.com> References: <17c6771e0911081549j36e06285j6645a8c56e2a774@mail.gmail.com> <20091111094651.GA3256@redhat.com> <20091111135501.GC3256@redhat.com> Message-ID: On Wed, Nov 11, 2009 at 8:55 AM, Gary Benson wrote: > Michael Franz wrote: > > On Wed, Nov 11, 2009 at 4:46 AM, Gary Benson wrote: > > > Michael Franz wrote: > > > > I was able to get past this by upgrading to llvm 2.6 (Fedora 11 as > > > > 2.5). I see post referencing llvm 2.7. Is this going to be the > > > > required version soon? > > > > > > There's no plans for that. In the past we've generally supported as > > > many versions as developers cared about. > > > > > > > I am building on a G4 which is 32 bits, but _LP64=1 is being > > > > defined. This is causing problems as jlong is being defined > > > > incorrectly (long instead of long long). How do I unset _LP64? > > > > > > What does 'uname -m' say on your machine? > > > > > > uname -m > > > > ppc > > > > I was able to get the build to progress by setting ARCH_DATA_MODEL=32 > > before calling make. I did this since there didn't seem to be a case > > where the ARCH was equal to ppc and it then defaults to 64. > > Interesting. Is this with IcedTea7? > > Yes, It is current TIP as of a few days ago. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/zero-dev/attachments/20091111/9a531ed8/attachment.html From gbenson at redhat.com Wed Nov 11 06:09:40 2009 From: gbenson at redhat.com (Gary Benson) Date: Wed, 11 Nov 2009 14:09:40 +0000 Subject: What is the status of Zero on OpenJDK 7 In-Reply-To: References: <17c6771e0911081549j36e06285j6645a8c56e2a774@mail.gmail.com> <20091111094651.GA3256@redhat.com> <20091111135501.GC3256@redhat.com> Message-ID: <20091111140940.GG3256@redhat.com> Michael Franz wrote: > On Wed, Nov 11, 2009 at 8:55 AM, Gary Benson wrote: > > Michael Franz wrote: > > > On Wed, Nov 11, 2009 at 4:46 AM, Gary Benson wrote: > > > > Michael Franz wrote: > > > > > I am building on a G4 which is 32 bits, but _LP64=1 is being > > > > > defined. This is causing problems as jlong is being defined > > > > > incorrectly (long instead of long long). How do I unset > > > > > _LP64? > > > > > > > > What does 'uname -m' say on your machine? > > > > > > > > uname -m > > > > > > ppc > > > > > > I was able to get the build to progress by setting > > > ARCH_DATA_MODEL=32 before calling make. I did this since there > > > didn't seem to be a case where the ARCH was equal to ppc and it > > > then defaults to 64. > > > > Interesting. Is this with IcedTea7? > > > > Yes, It is current TIP as of a few days ago. Ah, it looks like it hasn't been updated with the different environment variables that the upstreamed Zero requires. I'll fix it... Cheers, Gary -- http://gbenson.net/ From gbenson at redhat.com Wed Nov 11 08:20:54 2009 From: gbenson at redhat.com (Gary Benson) Date: Wed, 11 Nov 2009 16:20:54 +0000 Subject: Workaround for PR icedtea/324 Message-ID: <20091111162054.GI3256@redhat.com> Hi all, This commit works around $SUBJECT. Cheers, Gary -- http://gbenson.net/ -------------- next part -------------- diff -r 79079fb4d3b4 -r b3d03017bdef ChangeLog --- a/ChangeLog Wed Nov 11 13:52:48 2009 +0000 +++ b/ChangeLog Wed Nov 11 10:50:38 2009 -0500 @@ -1,3 +1,9 @@ +2009-11-11 Gary Benson + + PR icedtea/324: + * ports/hotspot/src/share/vm/shark/sharkValue.cpp + (SharkNormalValue::jarray_value): Work around the above. + 2009-11-11 Gary Benson * ports/hotspot/src/share/vm/shark/sharkType.hpp diff -r 79079fb4d3b4 -r b3d03017bdef ports/hotspot/src/share/vm/shark/sharkValue.cpp --- a/ports/hotspot/src/share/vm/shark/sharkValue.cpp Wed Nov 11 13:52:48 2009 +0000 +++ b/ports/hotspot/src/share/vm/shark/sharkValue.cpp Wed Nov 11 10:50:38 2009 -0500 @@ -220,7 +220,9 @@ } Value* SharkNormalValue::jarray_value() const { - assert(is_jarray(), "should be"); + // XXX assert(is_jarray(), "should be"); + // XXX http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=324 + assert(is_jobject(), "should be"); return llvm_value(); } int SharkAddressValue::address_value() const From gnu_andrew at member.fsf.org Wed Nov 11 08:23:00 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Wed, 11 Nov 2009 16:23:00 +0000 Subject: Workaround for PR icedtea/324 In-Reply-To: <20091111162054.GI3256@redhat.com> References: <20091111162054.GI3256@redhat.com> Message-ID: <17c6771e0911110823h4ceb5b43v1c465f3dcb29a8ec@mail.gmail.com> 2009/11/11 Gary Benson : > Hi all, > > This commit works around $SUBJECT. > > Cheers, > Gary > > -- > http://gbenson.net/ > Haha, I like the brevity ;) -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From gbenson at redhat.com Wed Nov 11 08:29:17 2009 From: gbenson at redhat.com (Gary Benson) Date: Wed, 11 Nov 2009 16:29:17 +0000 Subject: Workaround for PR icedtea/324 In-Reply-To: <17c6771e0911110823h4ceb5b43v1c465f3dcb29a8ec@mail.gmail.com> References: <20091111162054.GI3256@redhat.com> <17c6771e0911110823h4ceb5b43v1c465f3dcb29a8ec@mail.gmail.com> Message-ID: <20091111162917.GK3256@redhat.com> Andrew John Hughes wrote: > 2009/11/11 Gary Benson : > > This commit works around $SUBJECT. > > Haha, I like the brevity ;) I've written a lot of emails today ;) Cheers, Gary -- http://gbenson.net/ From gbenson at redhat.com Wed Nov 11 09:37:20 2009 From: gbenson at redhat.com (Gary Benson) Date: Wed, 11 Nov 2009 17:37:20 +0000 Subject: Native method wrapper generation Message-ID: <20091111173720.GA17404@redhat.com> Hi all, This commit adds native wrapper generation to Shark. It also removes support for LLVM < 2.6, because the new code requires it. I'll write this up in more detail tomorrow with some benchmarks. Cheers, Gary -- http://gbenson.net/ -------------- next part -------------- A non-text attachment was scrubbed... Name: patch.gz Type: application/x-gzip Size: 24621 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/zero-dev/attachments/20091111/da302eca/attachment-0001.bin From mvfranz at gmail.com Wed Nov 11 14:07:04 2009 From: mvfranz at gmail.com (Michael Franz) Date: Wed, 11 Nov 2009 17:07:04 -0500 Subject: What is the status of Zero on OpenJDK 7 In-Reply-To: <20091111140940.GG3256@redhat.com> References: <17c6771e0911081549j36e06285j6645a8c56e2a774@mail.gmail.com> <20091111094651.GA3256@redhat.com> <20091111135501.GC3256@redhat.com> <20091111140940.GG3256@redhat.com> Message-ID: On Wed, Nov 11, 2009 at 9:09 AM, Gary Benson wrote: > Michael Franz wrote: > > On Wed, Nov 11, 2009 at 8:55 AM, Gary Benson wrote: > > > Michael Franz wrote: > > > > On Wed, Nov 11, 2009 at 4:46 AM, Gary Benson > wrote: > > > > > Michael Franz wrote: > > > > > > I am building on a G4 which is 32 bits, but _LP64=1 is being > > > > > > defined. This is causing problems as jlong is being defined > > > > > > incorrectly (long instead of long long). How do I unset > > > > > > _LP64? > > > > > > > > > > What does 'uname -m' say on your machine? > > > > > > > > > > uname -m > > > > > > > > ppc > > > > > > > > I was able to get the build to progress by setting > > > > ARCH_DATA_MODEL=32 before calling make. I did this since there > > > > didn't seem to be a case where the ARCH was equal to ppc and it > > > > then defaults to 64. > > > > > > Interesting. Is this with IcedTea7? > > > > > > Yes, It is current TIP as of a few days ago. > > Ah, it looks like it hasn't been updated with the different > environment variables that the upstreamed Zero requires. > I'll fix it... > My build finished successfully when I set arch before make. That seems to be the only thing missing. I am going to try with the latest TIP. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/zero-dev/attachments/20091111/cdb74076/attachment.html From mvfranz at gmail.com Wed Nov 11 20:23:07 2009 From: mvfranz at gmail.com (Michael Franz) Date: Wed, 11 Nov 2009 23:23:07 -0500 Subject: What is the status of Zero on OpenJDK 7 In-Reply-To: References: <17c6771e0911081549j36e06285j6645a8c56e2a774@mail.gmail.com> <20091111094651.GA3256@redhat.com> <20091111135501.GC3256@redhat.com> <20091111140940.GG3256@redhat.com> Message-ID: On Wed, Nov 11, 2009 at 5:07 PM, Michael Franz wrote: > > > On Wed, Nov 11, 2009 at 9:09 AM, Gary Benson wrote: > >> Michael Franz wrote: >> > On Wed, Nov 11, 2009 at 8:55 AM, Gary Benson >> wrote: >> > > Michael Franz wrote: >> > > > On Wed, Nov 11, 2009 at 4:46 AM, Gary Benson >> wrote: >> > > > > Michael Franz wrote: >> > > > > > I am building on a G4 which is 32 bits, but _LP64=1 is being >> > > > > > defined. This is causing problems as jlong is being defined >> > > > > > incorrectly (long instead of long long). How do I unset >> > > > > > _LP64? >> > > > > >> > > > > What does 'uname -m' say on your machine? >> > > > > >> > > > > uname -m >> > > > >> > > > ppc >> > > > >> > > > I was able to get the build to progress by setting >> > > > ARCH_DATA_MODEL=32 before calling make. I did this since there >> > > > didn't seem to be a case where the ARCH was equal to ppc and it >> > > > then defaults to 64. >> > > >> > > Interesting. Is this with IcedTea7? >> > > >> > > Yes, It is current TIP as of a few days ago. >> >> Ah, it looks like it hasn't been updated with the different >> environment variables that the upstreamed Zero requires. >> I'll fix it... >> > > My build finished successfully when I set arch before make. That seems to > be the only thing missing. I am going to try with the latest TIP. > The latest does not build. Here is the error: mkdir -p extra-lib /home/mfranz/icedtea/icedtea/bootstrap/jdk1.6.0/bin/javac -g -encoding utf-8 -source 5 -target 5 -d extra-lib \ -classpath /home/mfranz/icedtea/icedtea/lib/rt \ -sourcepath /home/mfranz/icedtea/icedtea/extra:/home/mfranz/icedtea/icedtea/generated:openjdk/jdk/src/share/classes:openjdk/jdk/src/solaris/classes:openjdk/langtools/src/share/classes:openjdk/jaxp/src/share/classes:openjdk/corba/src/share/classes:openjdk/jaxws/src/share/classes:/home/mfranz/icedtea/icedtea/netx \ -bootclasspath \'\' \ @extra-source-files.txt ; \ cp -r /home/mfranz/icedtea/icedtea/extra/net/sourceforge/jnlp/about/resources \ extra-lib/net/sourceforge/jnlp/about javac: PPCJITInfo.cpp:391: virtual void llvm::PPCJITInfo::relocate(void*, llvm::MachineRelocation*, unsigned int, unsigned char*): Assertion `ResultPtr >= -(1 << 23) && ResultPtr < (1 << 23) && "Relocation out of range!"' failed. Stack dump: 0. Running pass 'PowerPC Machine Code Emitter' on function '@"com.sun.tools.javac.file.ZipFileIndex$ZipDirectory::readEntry"' /bin/sh: line 6: 9353 Aborted /home/mfranz/icedtea/icedtea/bootstrap/jdk1.6.0/bin/javac -g -encoding utf-8 -source 5 -target 5 -d extra-lib -classpath /home/mfranz/icedtea/icedtea/lib/rt -sourcepath /home/mfranz/icedtea/icedtea/extra:/home/mfranz/icedtea/icedtea/generated:openjdk/jdk/src/share/classes:openjdk/jdk/src/solaris/classes:openjdk/langtools/src/share/classes:openjdk/jaxp/src/share/classes:openjdk/corba/src/share/classes:openjdk/jaxws/src/share/classes:/home/mfranz/icedtea/icedtea/netx -bootclasspath \'\' @extra-source-files.txt cp: cannot create directory `extra-lib/net/sourceforge/jnlp/about': No such file or directory make: *** [stamps/extra-class-files.stamp] Error 1 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/zero-dev/attachments/20091111/957bd920/attachment.html From gbenson at redhat.com Thu Nov 12 02:19:15 2009 From: gbenson at redhat.com (Gary Benson) Date: Thu, 12 Nov 2009 10:19:15 +0000 Subject: What is the status of Zero on OpenJDK 7 In-Reply-To: References: <17c6771e0911081549j36e06285j6645a8c56e2a774@mail.gmail.com> <20091111094651.GA3256@redhat.com> <20091111135501.GC3256@redhat.com> <20091111140940.GG3256@redhat.com> Message-ID: <20091112101915.GA3424@redhat.com> Michael Franz wrote: > The latest does not build. Here is the error: [snip] > javac: PPCJITInfo.cpp:391: virtual void llvm::PPCJITInfo::relocate(void*, > llvm::MachineRelocation*, unsigned int, unsigned char*): Assertion > `ResultPtr >= -(1 << 23) && ResultPtr < (1 << 23) && "Relocation out of > range!"' failed. You need to patch LLVM to run Shark with LLVM 2.6 on PowerPC: http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=399 Cheers, Gary -- http://gbenson.net/ From xerxes at zafena.se Thu Nov 12 06:58:19 2009 From: xerxes at zafena.se (=?ISO-8859-1?Q?Xerxes_R=E5nby?=) Date: Thu, 12 Nov 2009 15:58:19 +0100 Subject: [patch] rfc: shark llvm2.7 hotspot macros.hpp NOT_X86 patch Message-ID: <4AFC228B.9090408@zafena.se> Shark require the NOT_X86 macro to build with llvm 2.7 and later, the attached patch adds this new macro to hotspot. ok to push? Xerxes -------------- next part -------------- A non-text attachment was scrubbed... Name: icedtea-shark_hotspot_NOT_X86.patch Type: text/x-patch Size: 914 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/zero-dev/attachments/20091112/77089ff2/attachment.bin From xerxes at zafena.se Thu Nov 12 07:07:05 2009 From: xerxes at zafena.se (=?ISO-8859-1?Q?Xerxes_R=E5nby?=) Date: Thu, 12 Nov 2009 16:07:05 +0100 Subject: [patch] rfc: shark llvm2.7 r86606 sharkMemoryManager fix Message-ID: <4AFC2499.8020906@zafena.se> The dlsym stubs got removed from JITMemoryManager in llvm 2.7svn r86606 and the attached patch updates sharkMemoryManager accordingly. http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/ExecutionEngine/JIT/JITMemoryManager.cpp?r1=84859&r2=86606 Cheers Xerxes -------------- next part -------------- A non-text attachment was scrubbed... Name: llvm2.7_r86606_sharkMemoryManager-fix.patch Type: text/x-patch Size: 1453 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/zero-dev/attachments/20091112/a43ff404/attachment.bin From gbenson at redhat.com Thu Nov 12 07:24:25 2009 From: gbenson at redhat.com (Gary Benson) Date: Thu, 12 Nov 2009 15:24:25 +0000 Subject: [patch] rfc: shark llvm2.7 hotspot macros.hpp NOT_X86 patch In-Reply-To: <4AFC228B.9090408@zafena.se> References: <4AFC228B.9090408@zafena.se> Message-ID: <20091112152425.GC3424@redhat.com> Xerxes R?nby wrote: > Shark require the NOT_X86 macro to build with llvm 2.7 and later, > the attached patch adds this new macro to hotspot. ok to push? Push away :) Cheers, Gary -- http://gbenson.net/ From gbenson at redhat.com Thu Nov 12 07:25:21 2009 From: gbenson at redhat.com (Gary Benson) Date: Thu, 12 Nov 2009 15:25:21 +0000 Subject: [patch] rfc: shark llvm2.7 r86606 sharkMemoryManager fix In-Reply-To: <4AFC2499.8020906@zafena.se> References: <4AFC2499.8020906@zafena.se> Message-ID: <20091112152521.GD3424@redhat.com> Xerxes R?nby wrote: > The dlsym stubs got removed from JITMemoryManager in llvm 2.7svn > r86606 and the attached patch updates sharkMemoryManager > accordingly. > http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/ExecutionEngine/JIT/JITMemoryManager.cpp?r1=84859&r2=86606 Please push this too. Cheers, Gary -- http://gbenson.net/ From gbenson at redhat.com Thu Nov 12 09:33:54 2009 From: gbenson at redhat.com (Gary Benson) Date: Thu, 12 Nov 2009 17:33:54 +0000 Subject: What is the status of Zero on OpenJDK 7 In-Reply-To: <40C664BC8DEC2A4F8E8DD6B78C9C6D1207B1C489@ct11exm63.ds.mot.com> References: <20091112101915.GA3424@redhat.com> <40C664BC8DEC2A4F8E8DD6B78C9C6D1207B1C489@ct11exm63.ds.mot.com> Message-ID: <20091112173354.GE3424@redhat.com> Hi Eugene, It's just that one, as far as I know, and only for PowerPC. x86_64 works out of the box. ARM I'm not sure about, maybe Xerxes could fill you in on that. Cheers, Gary Gordienko Evgueni-XPNG76 wrote: > Gary, > > Can you please update on list of patches needed for Shark to > compile/run with llvm 2.6? > > Thanks > Eugene > > -----Original Message----- > From: distro-pkg-dev-bounces at openjdk.java.net > [mailto:distro-pkg-dev-bounces at openjdk.java.net] On Behalf Of Gary > Benson > Sent: Thursday, November 12, 2009 2:19 AM > To: distro-pkg-dev at openjdk.java.net; zero-dev at openjdk.java.net > Subject: Re: What is the status of Zero on OpenJDK 7 > > Michael Franz wrote: > > The latest does not build. Here is the error: > [snip] > > javac: PPCJITInfo.cpp:391: virtual void > > llvm::PPCJITInfo::relocate(void*, llvm::MachineRelocation*, unsigned > > int, unsigned char*): Assertion `ResultPtr >= -(1 << 23) && ResultPtr > > < (1 << 23) && "Relocation out of range!"' failed. > > You need to patch LLVM to run Shark with LLVM 2.6 on PowerPC: > http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=399 > > Cheers, > Gary > > -- > http://gbenson.net/ From evgueni.gordienko at motorola.com Thu Nov 12 09:18:14 2009 From: evgueni.gordienko at motorola.com (Gordienko Evgueni-XPNG76) Date: Thu, 12 Nov 2009 12:18:14 -0500 Subject: What is the status of Zero on OpenJDK 7 In-Reply-To: <20091112101915.GA3424@redhat.com> References: <17c6771e0911081549j36e06285j6645a8c56e2a774@mail.gmail.com><20091111094651.GA3256@redhat.com><20091111135501.GC3256@redhat.com><20091111140940.GG3256@redhat.com> <20091112101915.GA3424@redhat.com> Message-ID: <40C664BC8DEC2A4F8E8DD6B78C9C6D1207B1C489@ct11exm63.ds.mot.com> Gary, Can you please update on list of patches needed for Shark to compile/run with llvm 2.6? Thanks Eugene -----Original Message----- From: distro-pkg-dev-bounces at openjdk.java.net [mailto:distro-pkg-dev-bounces at openjdk.java.net] On Behalf Of Gary Benson Sent: Thursday, November 12, 2009 2:19 AM To: distro-pkg-dev at openjdk.java.net; zero-dev at openjdk.java.net Subject: Re: What is the status of Zero on OpenJDK 7 Michael Franz wrote: > The latest does not build. Here is the error: [snip] > javac: PPCJITInfo.cpp:391: virtual void > llvm::PPCJITInfo::relocate(void*, llvm::MachineRelocation*, unsigned > int, unsigned char*): Assertion `ResultPtr >= -(1 << 23) && ResultPtr > < (1 << 23) && "Relocation out of range!"' failed. You need to patch LLVM to run Shark with LLVM 2.6 on PowerPC: http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=399 Cheers, Gary -- http://gbenson.net/ From xerxes at zafena.se Fri Nov 13 01:05:46 2009 From: xerxes at zafena.se (=?ISO-8859-1?Q?Xerxes_R=E5nby?=) Date: Fri, 13 Nov 2009 10:05:46 +0100 Subject: What is the status of Zero on OpenJDK 7 In-Reply-To: <20091112173354.GE3424@redhat.com> References: <20091112101915.GA3424@redhat.com> <40C664BC8DEC2A4F8E8DD6B78C9C6D1207B1C489@ct11exm63.ds.mot.com> <20091112173354.GE3424@redhat.com> Message-ID: <4AFD216A.5040303@zafena.se> Gary Benson wrote: > Hi Eugene, > > It's just that one, as far as I know, and only for PowerPC. > x86_64 works out of the box. ARM I'm not sure about, maybe > Xerxes could fill you in on that. > > Cheers, > Gary > > Gordienko Evgueni-XPNG76 wrote: > >> Gary, >> >> Can you please update on list of patches needed for Shark to >> compile/run with llvm 2.6? >> >> Thanks >> Eugene >> >> Shark on ARM builds out of the box with LLVM 2.6 but have some runtime issues. It requires some patching of the LLVM JIT to make it be fully usable with Shark, i dont know the minimal list of patches required for LLVM 2.6 to make it stable on ARM right now. The best experience with Shark on ARM that i have had so fair are to use a llvm svn2.7 rev 83459 with a small JIT patch as explained in the build docs here: http://labb.zafena.se/shark-testing/armv5/5nov-armv5-build-info.txt The main reason why LLVM ships versions that sometimes are partially broken for PowerPC and ARM are that LLVM release criteria only require that the x86-32 and 64 backends are stable for a release to be made. http://llvm.org/docs/HowToReleaseLLVM.html#release-qualify My experience working with the LLVM team to stabilise the ARM JIT backend for Linux have been good, bugs are fixed quite rapidly in the llvm svn tree after bugreports with "small" testcases ( .ll/.bc files with problematic llvm IR or small unittests) can be produced that exposes the bug. Checkout the llvm docs, it contains quite some good material how to write bugreports for llvm: http://llvm.org/docs/HowToSubmitABug.html Cheers Xerxes From mvfranz at gmail.com Fri Nov 13 15:45:37 2009 From: mvfranz at gmail.com (Michael Franz) Date: Fri, 13 Nov 2009 18:45:37 -0500 Subject: What is the status of Zero on OpenJDK 7 In-Reply-To: <20091112101915.GA3424@redhat.com> References: <17c6771e0911081549j36e06285j6645a8c56e2a774@mail.gmail.com> <20091111094651.GA3256@redhat.com> <20091111135501.GC3256@redhat.com> <20091111140940.GG3256@redhat.com> <20091112101915.GA3424@redhat.com> Message-ID: On Thu, Nov 12, 2009 at 5:19 AM, Gary Benson wrote: > Michael Franz wrote: > > The latest does not build. Here is the error: > [snip] > > javac: PPCJITInfo.cpp:391: virtual void llvm::PPCJITInfo::relocate(void*, > > llvm::MachineRelocation*, unsigned int, unsigned char*): Assertion > > `ResultPtr >= -(1 << 23) && ResultPtr < (1 << 23) && "Relocation out of > > range!"' failed. > > You need to patch LLVM to run Shark with LLVM 2.6 on PowerPC: > http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=399 > > Cheers, > Gary > I applied this patch and the build progresses farther. I guess llvm is just not stable at this point. I get the following crash during the build. -def-check: -check-boot.java.home: -def-pcompile: # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (debugInfo.cpp:85), pid=22190, tid=1209107600 # Error: ShouldNotReachHere() # # JRE version: 7.0-b75 # Java VM: OpenJDK Shark VM (17.0-b04 mixed mode linux-ppc ) # Distribution: Built on Fedora release 11 (Leonidas) # An error report file with more information is saved as: # /home/mfranz/icedtea/icedtea/openjdk/langtools/make/hs_err_pid22190.log # # If you would like to submit a bug report, please include # instructions how to reproduce the bug and visit: # http://icedtea.classpath.org/bugzilla # -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/zero-dev/attachments/20091113/66b1a704/attachment.html From gbenson at redhat.com Mon Nov 16 01:25:50 2009 From: gbenson at redhat.com (Gary Benson) Date: Mon, 16 Nov 2009 09:25:50 +0000 Subject: What is the status of Zero on OpenJDK 7 In-Reply-To: References: <20091111094651.GA3256@redhat.com> <20091111135501.GC3256@redhat.com> <20091111140940.GG3256@redhat.com> <20091112101915.GA3424@redhat.com> Message-ID: <20091116092549.GA3423@redhat.com> Michael Franz wrote: > On Thu, Nov 12, 2009 at 5:19 AM, Gary Benson wrote: > > You need to patch LLVM to run Shark with LLVM 2.6 on PowerPC: > > http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=399 > > I applied this patch and the build progresses farther. I guess llvm > is just not stable at this point. I get the following crash during > the build. > > # > # A fatal error has been detected by the Java Runtime Environment: > # > # Internal Error (debugInfo.cpp:85), pid=22190, tid=1209107600 > # Error: ShouldNotReachHere() > # > # JRE version: 7.0-b75 > # Java VM: OpenJDK Shark VM (17.0-b04 mixed mode linux-ppc ) > # Distribution: Built on Fedora release 11 (Leonidas) > # An error report file with more information is saved as: > # /home/mfranz/icedtea/icedtea/openjdk/langtools/make/hs_err_pid22190.log > # > # If you would like to submit a bug report, please include > # instructions how to reproduce the bug and visit: > # http://icedtea.classpath.org/bugzilla > # This is http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=348. It's on my list :) Cheers, Gary -- http://gbenson.net/ From gbenson at redhat.com Mon Nov 16 09:31:13 2009 From: gbenson at redhat.com (Gary Benson) Date: Mon, 16 Nov 2009 17:31:13 +0000 Subject: IcedTea7 Zero/Shark build patch Message-ID: <20091116173113.GA31912@redhat.com> Hi all, Zero (and Shark) require different build variables to be set for the upstream Zero than the ones we've currently been using. This patch should fix the way these are set. I haven't tested this with Cacao, or with the build-multiple-vms-at-once that doko contributed. Is this ok to commit? Cheers, Gary -- http://gbenson.net/ -------------- next part -------------- diff -r 1d2d9efc77e6 Makefile.am --- a/Makefile.am Sun Nov 15 20:19:16 2009 +0000 +++ b/Makefile.am Mon Nov 16 17:27:47 2009 +0000 @@ -427,21 +427,6 @@ endif # OpenJDK build environment. -if CORE_BUILD - ICEDTEA_CORE_BUILD = true -else - ICEDTEA_CORE_BUILD = -endif -if ZERO_BUILD - ICEDTEA_ZERO_BUILD = true -else - ICEDTEA_ZERO_BUILD = -endif -if SHARK_BUILD - ICEDTEA_SHARK_BUILD = yes -else - ICEDTEA_SHARK_BUILD = -endif JDK_UPDATE_VERSION = 0 COMBINED_VERSION = $(JDK_UPDATE_VERSION)-$(OPENJDK_VERSION) @@ -462,19 +447,6 @@ ENDORSED="-Djava.endorsed.dirs=$(ICEDTEA_ENDORSED_DIR)" \ CLASSPATH="" \ LD_LIBRARY_PATH="" \ - CORE_BUILD="$(ICEDTEA_CORE_BUILD)" \ - ZERO_BUILD="$(ICEDTEA_ZERO_BUILD)" \ - ICEDTEA_SHARK_BUILD="$(ICEDTEA_SHARK_BUILD)" \ - ZERO_LIBARCH="$(ZERO_LIBARCH)" \ - ARCH_DATA_MODEL="$(ZERO_BITSPERWORD)" \ - ZERO_ENDIANNESS="$(ZERO_ENDIANNESS)" \ - ZERO_ARCHDEF="$(ZERO_ARCHDEF)" \ - ZERO_ARCHFLAG="$(ZERO_ARCHFLAG)" \ - LIBFFI_CFLAGS="$(LIBFFI_CFLAGS)" \ - LIBFFI_LIBS="$(LIBFFI_LIBS)" \ - LLVM_CFLAGS="$(LLVM_CFLAGS)" \ - LLVM_LDFLAGS="$(LLVM_LDFLAGS)" \ - LLVM_LIBS="$(LLVM_LIBS)" \ FREETYPE2_HEADERS="$(FREETYPE2_CFLAGS)" \ FT2_LIB="$(FREETYPE2_LIBS)" \ ALT_PARALLEL_COMPILE_JOBS="$(PARALLEL_JOBS)" \ @@ -494,6 +466,25 @@ DISABLE_INTREE_EC="true" \ ALT_DROPS_DIR="$(abs_top_builddir)/drops" +if ZERO_BUILD +ICEDTEA_ENV += \ + ZERO_BUILD="true"\ + ZERO_LIBARCH="$(ZERO_LIBARCH)" \ + ARCH_DATA_MODEL="$(ZERO_BITSPERWORD)" \ + ZERO_ENDIANNESS="$(ZERO_ENDIANNESS)" \ + ZERO_ARCHDEF="$(ZERO_ARCHDEF)" \ + ZERO_ARCHFLAG="$(ZERO_ARCHFLAG)" \ + LIBFFI_CFLAGS="$(LIBFFI_CFLAGS)" \ + LIBFFI_LIBS="$(LIBFFI_LIBS)" +if SHARK_BUILD +ICEDTEA_ENV += \ + ICEDTEA_SHARK_BUILD="true" \ + LLVM_CFLAGS="$(LLVM_CFLAGS)" \ + LLVM_LDFLAGS="$(LLVM_LDFLAGS)" \ + LLVM_LIBS="$(LLVM_LIBS)" +endif +endif + if WITH_CACAO ICEDTEA_ENV += \ ALT_HOTSPOT_IMPORT_PATH="$(CACAO_IMPORT_PATH)" @@ -1300,7 +1291,7 @@ touch $@ clean-extract-jaxws: - if [ -d $(BUILD_OUTPUT_DIR)/jaxws ] ; then + if [ -d $(BUILD_OUTPUT_DIR)/jaxws ] ; then \ (cd openjdk/jaxws ; \ $(ANT) -Doutput.dir=$(BUILD_OUTPUT_DIR)/jaxws clobber ; \ cd ../../); \ @@ -1315,13 +1306,12 @@ link=$$(dirname $$target | sed 's/^.*ports/openjdk/'|sed "s#hotspot/build#hotspot/make#"); \ ln -sfv $$target $$link; \ done - if ! test "x$(ICEDTEA_CORE_BUILD)$(ICEDTEA_SHARK_BUILD)$(WITH_CACAO)" \ - = "xno" ; then \ + if ! test "x$(WITH_CACAO)" = "xno" ; then \ mkdir -p openjdk/jdk/src/solaris/bin/$(BUILD_ARCH_DIR) ; \ ln -sf $(abs_top_builddir)/jvm.cfg \ openjdk/jdk/src/solaris/bin/$(BUILD_ARCH_DIR)/jvm.cfg ; \ fi - if ! test "x$(ICEDTEA_ZERO_BUILD)$(WITH_CACAO)" = "xno"; then \ + if ! test "x$(WITH_CACAO)" = "xno"; then \ ln -sf $(abs_top_builddir)/ergo.c \ openjdk/jdk/src/solaris/bin/ergo_$(BUILD_ARCH_DIR).c; \ fi @@ -1743,10 +1733,11 @@ $(BUILD_OUTPUT_DIR)/j2sdk-image/jre/lib endif if ZERO_BUILD +if SHARK_BUILD + printf -- '-shark ALIASED_TO -server\n' >> $(BUILD_JRE_ARCH_DIR)/jvm.cfg +else printf -- '-zero ALIASED_TO -server\n' >> $(BUILD_JRE_ARCH_DIR)/jvm.cfg endif -if SHARK_BUILD - printf -- '-shark ALIASED_TO -server\n' >> $(BUILD_JRE_ARCH_DIR)/jvm.cfg endif if WITH_CACAO printf -- '-cacao ALIASED_TO -server\n' >> $(BUILD_JRE_ARCH_DIR)/jvm.cfg @@ -1818,10 +1809,11 @@ $(BUILD_OUTPUT_DIR)-debug/j2sdk-image/jre/lib endif if ZERO_BUILD +if SHARK_BUILD + printf -- '-shark ALIASED_TO -server\n' >> $(BUILD_DEBUG_JRE_ARCH_DIR)/jvm.cfg +else printf -- '-zero ALIASED_TO -server\n' >> $(BUILD_DEBUG_JRE_ARCH_DIR)/jvm.cfg endif -if SHARK_BUILD - printf -- '-shark ALIASED_TO -server\n' >> $(BUILD_DEBUG_JRE_ARCH_DIR)/jvm.cfg endif if WITH_CACAO printf -- '-cacao ALIASED_TO -server\n' >> $(BUILD_DEBUG_JRE_ARCH_DIR)/jvm.cfg diff -r 1d2d9efc77e6 acinclude.m4 --- a/acinclude.m4 Sun Nov 15 20:19:16 2009 +0000 +++ b/acinclude.m4 Mon Nov 16 17:27:47 2009 +0000 @@ -718,16 +718,6 @@ AC_MSG_RESULT($use_zero) AM_CONDITIONAL(ZERO_BUILD, test "x${use_zero}" = xyes) - use_core=no - if test "x${WITH_CACAO}" != "xno"; then - use_core=yes; - elif test "x${use_zero}" = "xyes"; then - if test "x${use_shark}" = "xno"; then - use_core=yes; - fi - fi - AM_CONDITIONAL(CORE_BUILD, test "x${use_core}" = xyes) - ZERO_LIBARCH="${INSTALL_ARCH_DIR}" dnl can't use AC_CHECK_SIZEOF on multilib case "${ZERO_LIBARCH}" in From gbenson at redhat.com Tue Nov 17 03:44:51 2009 From: gbenson at redhat.com (Gary Benson) Date: Tue, 17 Nov 2009 11:44:51 +0000 Subject: IcedTea7 Zero/Shark build patch, take 2 Message-ID: <20091117114450.GA3239@redhat.com> Hi all, Given that my previous patch turned out to be not such a good idea, how about this one? It removes the core build stuff, which isn't required for upstream Zero and was causing some files (jvm.cfg and ergo_$arch.c) to be created that are now handled upstream. It also removes a patch that seems to have been left behind from somewhere. Ok to commit? Cheers, Gary -- http://gbenson.net/ -------------- next part -------------- diff -r 766972166cea Makefile.am --- a/Makefile.am Tue Nov 17 04:35:14 2009 +0000 +++ b/Makefile.am Tue Nov 17 11:35:37 2009 +0000 @@ -427,11 +427,6 @@ endif # OpenJDK build environment. -if CORE_BUILD - ICEDTEA_CORE_BUILD = true -else - ICEDTEA_CORE_BUILD = -endif if ZERO_BUILD ICEDTEA_ZERO_BUILD = true else @@ -462,7 +457,6 @@ ENDORSED="-Djava.endorsed.dirs=$(ICEDTEA_ENDORSED_DIR)" \ CLASSPATH="" \ LD_LIBRARY_PATH="" \ - CORE_BUILD="$(ICEDTEA_CORE_BUILD)" \ ZERO_BUILD="$(ICEDTEA_ZERO_BUILD)" \ ICEDTEA_SHARK_BUILD="$(ICEDTEA_SHARK_BUILD)" \ ZERO_LIBARCH="$(ZERO_LIBARCH)" \ @@ -1315,13 +1309,12 @@ link=$$(dirname $$target | sed 's/^.*ports/openjdk/'|sed "s#hotspot/build#hotspot/make#"); \ ln -sfv $$target $$link; \ done - if ! test "x$(ICEDTEA_CORE_BUILD)$(ICEDTEA_SHARK_BUILD)$(WITH_CACAO)" \ - = "xno" ; then \ + if ! test "x$(WITH_CACAO)" = "xno" ; then \ mkdir -p openjdk/jdk/src/solaris/bin/$(BUILD_ARCH_DIR) ; \ ln -sf $(abs_top_builddir)/jvm.cfg \ openjdk/jdk/src/solaris/bin/$(BUILD_ARCH_DIR)/jvm.cfg ; \ fi - if ! test "x$(ICEDTEA_ZERO_BUILD)$(WITH_CACAO)" = "xno"; then \ + if ! test "x$(WITH_CACAO)" = "xno"; then \ ln -sf $(abs_top_builddir)/ergo.c \ openjdk/jdk/src/solaris/bin/ergo_$(BUILD_ARCH_DIR).c; \ fi diff -r 766972166cea acinclude.m4 --- a/acinclude.m4 Tue Nov 17 04:35:14 2009 +0000 +++ b/acinclude.m4 Tue Nov 17 11:35:37 2009 +0000 @@ -718,16 +718,6 @@ AC_MSG_RESULT($use_zero) AM_CONDITIONAL(ZERO_BUILD, test "x${use_zero}" = xyes) - use_core=no - if test "x${WITH_CACAO}" != "xno"; then - use_core=yes; - elif test "x${use_zero}" = "xyes"; then - if test "x${use_shark}" = "xno"; then - use_core=yes; - fi - fi - AM_CONDITIONAL(CORE_BUILD, test "x${use_core}" = xyes) - ZERO_LIBARCH="${INSTALL_ARCH_DIR}" dnl can't use AC_CHECK_SIZEOF on multilib case "${ZERO_LIBARCH}" in diff -r 766972166cea patches/hotspot/default/icedtea-core-zero-build.patch --- a/patches/hotspot/default/icedtea-core-zero-build.patch Tue Nov 17 04:35:14 2009 +0000 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,104 +0,0 @@ ---- openjdk/hotspot/make/Makefile.orig 2008-11-25 09:11:57.000000000 +0000 -+++ openjdk/hotspot/make/Makefile 2008-12-05 16:54:54.000000000 +0000 -@@ -91,6 +91,15 @@ - all_debug: jvmg jvmg1 jvmgkernel docs export_debug - all_optimized: optimized optimized1 optimizedkernel docs export_optimized - -+# Core (non-compiler) targets made available with this Makefile -+CORE_VM_TARGETS=productcore fastdebugcore optimizedcore jvmgcore -+ -+allcore: all_productcore all_fastdebugcore -+all_productcore: productcore docs export_product -+all_fastdebugcore: fastdebugcore docs export_fastdebug -+all_debugcore: jvmgcore docs export_debug -+all_optimizedcore: optimizedcore docs export_optimized -+ - # Do everything - world: all create_jdk - -@@ -113,6 +122,10 @@ - $(CD) $(GAMMADIR)/make; \ - $(MAKE) VM_TARGET=$@ generic_build2 $(ALT_OUT) - -+$(CORE_VM_TARGETS): -+ $(CD) $(GAMMADIR)/make; \ -+ $(MAKE) VM_TARGET=$@ generic_buildcore $(ALT_OUT) -+ - $(KERNEL_VM_TARGETS): - $(CD) $(GAMMADIR)/make; \ - $(MAKE) VM_TARGET=$@ generic_buildkernel $(ALT_OUT) -@@ -159,6 +172,12 @@ - $(MAKE_ARGS) $(VM_TARGET) - endif - -+generic_buildcore: -+ $(MKDIR) -p $(OUTPUTDIR) -+ $(CD) $(OUTPUTDIR); \ -+ $(MAKE) -f $(ABS_OS_MAKEFILE) \ -+ $(MAKE_ARGS) $(VM_TARGET) -+ - generic_buildkernel: - $(MKDIR) -p $(OUTPUTDIR) - ifeq ($(OSNAME),windows) -@@ -205,13 +224,21 @@ - XUSAGE=$(HS_SRC_DIR)/share/vm/Xusage.txt - DOCS_DIR=$(OUTPUTDIR)/$(VM_PLATFORM)_docs - C1_BASE_DIR=$(OUTPUTDIR)/$(VM_PLATFORM)_compiler1 -+ifdef CORE_BUILD -+C2_BASE_DIR=$(OUTPUTDIR)/$(VM_PLATFORM)_core -+else - C2_BASE_DIR=$(OUTPUTDIR)/$(VM_PLATFORM)_compiler2 -+endif - KERNEL_BASE_DIR=$(OUTPUTDIR)/$(VM_PLATFORM)_kernel - C1_DIR=$(C1_BASE_DIR)/$(VM_SUBDIR) - C2_DIR=$(C2_BASE_DIR)/$(VM_SUBDIR) - KERNEL_DIR=$(KERNEL_BASE_DIR)/$(VM_SUBDIR) - - # Misc files and generated files need to come from C1 or C2 area -+ifdef CORE_BUILD -+ MISC_DIR=$(C2_DIR) -+ GEN_DIR=$(C2_BASE_DIR)/generated -+else - ifeq ($(ARCH_DATA_MODEL), 32) - MISC_DIR=$(C1_DIR) - GEN_DIR=$(C1_BASE_DIR)/generated -@@ -219,6 +246,7 @@ - MISC_DIR=$(C2_DIR) - GEN_DIR=$(C2_BASE_DIR)/generated - endif -+endif - - # Bin files (windows) - ifeq ($(OSNAME),windows) ---- openjdk/hotspot/src/share/vm/runtime/vm_version.cpp.orig 2008-12-05 16:54:13.000000000 +0000 -+++ openjdk/hotspot/src/share/vm/runtime/vm_version.cpp 2008-12-05 16:54:54.000000000 +0000 -@@ -89,8 +89,12 @@ - #ifdef TIERED - #define VMTYPE "Server" - #else -- #define VMTYPE COMPILER1_PRESENT("Client") \ -- COMPILER2_PRESENT("Server") -+#if defined(COMPILER1) || defined(COMPILER2) -+ #define VMTYPE COMPILER1_PRESENT("Client") \ -+ COMPILER2_PRESENT("Server") -+#else -+ #define VMTYPE "Core" -+#endif // COMPILER1 || COMPILER2 - #endif // TIERED - - #ifndef HOTSPOT_VM_DISTRO ---- openjdk/hotspot/build/linux/makefiles/defs.make.orig 2008-11-25 09:11:51.000000000 +0000 -+++ openjdk/hotspot/build/linux/makefiles/defs.make 2008-12-05 16:54:54.000000000 +0000 -@@ -97,6 +97,7 @@ - EXPORT_LIST += $(EXPORT_SERVER_DIR)/Xusage.txt - EXPORT_LIST += $(EXPORT_SERVER_DIR)/libjsig.so - EXPORT_LIST += $(EXPORT_SERVER_DIR)/libjvm.so -+ifndef CORE_BUILD - ifeq ($(ARCH_DATA_MODEL), 32) - EXPORT_CLIENT_DIR = $(EXPORT_JRE_LIB_ARCH_DIR)/client - EXPORT_LIST += $(EXPORT_CLIENT_DIR)/Xusage.txt -@@ -111,3 +112,4 @@ - EXPORT_LIST += $(EXPORT_LIB_DIR)/sa-jdi.jar - endif - endif -+endif From gnu_andrew at member.fsf.org Tue Nov 17 04:44:33 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Tue, 17 Nov 2009 12:44:33 +0000 Subject: IcedTea7 Zero/Shark build patch, take 2 In-Reply-To: <20091117114450.GA3239@redhat.com> References: <20091117114450.GA3239@redhat.com> Message-ID: <17c6771e0911170444u6e1ebae6pb676124ce13733a4@mail.gmail.com> 2009/11/17 Gary Benson : > Hi all, > > Given that my previous patch turned out to be not such a good idea, > how about this one? ?It removes the core build stuff, which isn't > required for upstream Zero and was causing some files (jvm.cfg and > ergo_$arch.c) to be created that are now handled upstream. ?It also > removes a patch that seems to have been left behind from somewhere. > Ok to commit? > > Cheers, > Gary > > -- > http://gbenson.net/ > Hi Gary, It wasn't that the last patch wasn't a good idea, I'm just wary about disrupting the build too much just before the release. I hoped to have 1.12 out by now but keep finding more and more issues :( This patch looks fine, just dropping dead options, so please commit. -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From gbenson at redhat.com Tue Nov 17 05:29:49 2009 From: gbenson at redhat.com (Gary Benson) Date: Tue, 17 Nov 2009 13:29:49 +0000 Subject: IcedTea7 Zero/Shark build patch, take 2 In-Reply-To: <17c6771e0911170444u6e1ebae6pb676124ce13733a4@mail.gmail.com> References: <20091117114450.GA3239@redhat.com> <17c6771e0911170444u6e1ebae6pb676124ce13733a4@mail.gmail.com> Message-ID: <20091117132949.GB3239@redhat.com> Andrew John Hughes wrote: > 2009/11/17 Gary Benson : > > Given that my previous patch turned out to be not such a good > > idea, how about this one? ?It removes the core build stuff, which > > isn't required for upstream Zero and was causing some files > > (jvm.cfg and ergo_$arch.c) to be created that are now handled > > upstream. ?It also removes a patch that seems to have been left > > behind from somewhere. Ok to commit? > > It wasn't that the last patch wasn't a good idea, I'm just wary > about disrupting the build too much just before the release. I > hoped to have 1.12 out by now but keep finding more and more issues > :( > > This patch looks fine, just dropping dead options, so please commit. Cool, committed. Cheers, Gary -- http://gbenson.net/