dacapo bloat benchmark fails on openjdk7
Apologies for cross posting to the dacapobench-researchers and [EMAIL PROTECTED] lists. Hi all, I recently tried to execute the DaCapo benchmark on OpenJDK 7 and I found that "bloat" benchmark fails with the following exception: $ OpenJDK/jdk7/build/linux-i586/j2re-image/bin/java-jar ~/dacapo-2006-10-MR2.jar bloat = DaCapo bloat starting = ** Exception while optimizing transform(LEDU/purdue/cs/bloat/editor/MethodEditor;)Z of class EDU/purdue/cs/bloat/trans/CompactArrayInitializer String index out of range: -1802716504 java.lang.StringIndexOutOfBoundsException: String index out of range: -1802716504 at java.lang.String.getChars(String.java:860) at java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:408) at java.lang.StringBuilder.append(StringBuilder.java:136) at java.lang.StringBuilder.append(StringBuilder.java:132) at java.util.AbstractCollection.toString(AbstractCollection.java:439) at EDU.purdue.cs.bloat.codegen.RegisterAllocator$IGNode.toString(RegisterAllocator.java:570) at java.lang.String.valueOf(String.java:2838) at java.lang.StringBuffer.append(StringBuffer.java:236) at EDU.purdue.cs.bloat.util.Graph$4.next(Graph.java:983) at java.util.AbstractCollection.addAll(AbstractCollection.java:322) at EDU.purdue.cs.bloat.codegen.RegisterAllocator.(RegisterAllocator.java:288) at EDU.purdue.cs.bloat.optimize.Main.bloatMethod(Main.java:1078) at EDU.purdue.cs.bloat.optimize.Main.editClass(Main.java:688) at EDU.purdue.cs.bloat.optimize.Main.main(Main.java:446) at dacapo.bloat.BloatHarness.iterate(BloatHarness.java:25) at dacapo.Benchmark.run(Benchmark.java:126) at dacapo.TestHarness.runBenchmark(TestHarness.java:302) at dacapo.TestHarness.main(TestHarness.java:242) at Harness.main(Harness.java:5) I really don't know if it's a DaCapo problem or if I missed something in the build process of OpenJDK. The version of the DaCapo is 2006-10-MR2. I built OpenJDK both using mercurial repository and source bundle, and the build runs fine but when executing the benchmark the same error come up. These are the options I used for building OpenJDK 7: LANG=C FINDBUGS_HOME= ALT_BOOTDIR=/usr/lib/jvm/java-6-sun ALT_BINARY_PLUGS_PATH= ANT_HOME=/usr/share/ant ARCH_DADA_MODEL=32 Here there are some information on my machine: $ uname -a Linux 2.6.24-21-generic #1 SMP Tue Aug 12 13:37:22 UTC 2008 i686 GNU/Linux Any clues? Can anybody confirm such error? Thanks for your attention, Luca -- * Ing. Luca Martini Dipartimento di Ing. dell'Informazione Università di Pisa Via Diotisalvi, 2, I-56126 Pisa, Italy Tel: +39 050 2217 465 Fax: +39 050 2217 600 e-mail: [EMAIL PROTECTED] *
Re: [dacapobench-researchers] dacapo bloat benchmark fails on openjdk7
Luca, This is not a known problem with DaCapo, so on the face of it, this looks like a bug in your version of the VM (perhaps a bug in how you built it). FYI, we maintain 12 hourly performance regressions of a number of VMs here: http://dacapo.anu.edu.au/regression/perf/2006-10-MR2.html (the latest DaCapo release) and here: http://dacapo.anu.edu.au/regression/perf/head.html (the current DaCapo svn head). If there is interest and I can find the time, I may add the OpenJDK head to the list of tested benchmarks. Cheers, --Steve On 27/08/2008, at 6:34 PM, Luca Martini wrote: Apologies for cross posting to the dacapobench-researchers and [EMAIL PROTECTED] lists. Hi all, I recently tried to execute the DaCapo benchmark on OpenJDK 7 and I found that "bloat" benchmark fails with the following exception: $ OpenJDK/jdk7/build/linux-i586/j2re-image/bin/java-jar ~/dacapo-2006-10-MR2.jar bloat = DaCapo bloat starting = ** Exception while optimizing transform(LEDU/purdue/cs/bloat/editor/MethodEditor;)Z of class EDU/purdue/cs/bloat/trans/CompactArrayInitializer String index out of range: -1802716504 java.lang.StringIndexOutOfBoundsException: String index out of range: -1802716504 at java.lang.String.getChars(String.java:860) at java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:408) at java.lang.StringBuilder.append(StringBuilder.java:136) at java.lang.StringBuilder.append(StringBuilder.java:132) at java.util.AbstractCollection.toString(AbstractCollection.java:439) at EDU.purdue.cs.bloat.codegen.RegisterAllocator $IGNode.toString(RegisterAllocator.java:570) at java.lang.String.valueOf(String.java:2838) at java.lang.StringBuffer.append(StringBuffer.java:236) at EDU.purdue.cs.bloat.util.Graph$4.next(Graph.java:983) at java.util.AbstractCollection.addAll(AbstractCollection.java:322) at EDU .purdue .cs.bloat.codegen.RegisterAllocator.(RegisterAllocator.java:288) at EDU.purdue.cs.bloat.optimize.Main.bloatMethod(Main.java:1078) at EDU.purdue.cs.bloat.optimize.Main.editClass(Main.java:688) at EDU.purdue.cs.bloat.optimize.Main.main(Main.java:446) at dacapo.bloat.BloatHarness.iterate(BloatHarness.java:25) at dacapo.Benchmark.run(Benchmark.java:126) at dacapo.TestHarness.runBenchmark(TestHarness.java:302) at dacapo.TestHarness.main(TestHarness.java:242) at Harness.main(Harness.java:5) I really don't know if it's a DaCapo problem or if I missed something in the build process of OpenJDK. The version of the DaCapo is 2006-10- MR2. I built OpenJDK both using mercurial repository and source bundle, and the build runs fine but when executing the benchmark the same error come up. These are the options I used for building OpenJDK 7: LANG=C FINDBUGS_HOME= ALT_BOOTDIR=/usr/lib/jvm/java-6-sun ALT_BINARY_PLUGS_PATH= ANT_HOME=/usr/share/ant ARCH_DADA_MODEL=32 Here there are some information on my machine: $ uname -a Linux 2.6.24-21-generic #1 SMP Tue Aug 12 13:37:22 UTC 2008 i686 GNU/ Linux Any clues? Can anybody confirm such error? Thanks for your attention, Luca -- * Ing. Luca Martini Dipartimento di Ing. dell'Informazione Università di Pisa Via Diotisalvi, 2, I-56126 Pisa, Italy Tel: +39 050 2217 465 Fax: +39 050 2217 600 e-mail: [EMAIL PROTECTED] * - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ dacapobench-researchers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dacapobench-researchers
Re: [dacapobench-researchers] dacapo bloat benchmark fails on openjdk7
Steve, Thanks for your reply. I hope that someone of the OpenJDK folk could tell me if it's only a problem of my build or not. Regards, Luca -- * Ing. Luca Martini Dipartimento di Ing. dell'Informazione Università di Pisa Via Diotisalvi, 2, I-56126 Pisa, Italy Tel: +39 050 2217 465 Fax: +39 050 2217 600 e-mail: [EMAIL PROTECTED] *
fastdebug_build triggers -Werror with g++ 4.3.1-9 (Debian)
g++ -DLINUX -D_GNU_SOURCE -DAMD64 -DASSERT -DFASTDEBUG -I. -I../generated/adfiles -I../generated/jvmtifiles -I/home/fw/src/java/jdk7/hotspot/src/share/vm/asm -I/home/fw/src/java/jdk7/hotspot/src/share/vm/ci -I/home/fw/src/java/jdk7/hotspot/src/share/vm/classfile -I/home/fw/src/java/jdk7/hotspot/src/share/vm/code -I/home/fw/src/java/jdk7/hotspot/src/share/vm/compiler -I/home/fw/src/java/jdk7/hotspot/src/share/vm/gc_implementation -I/home/fw/src/java/jdk7/hotspot/src/share/vm/gc_implementation/parNew -I/home/fw/src/java/jdk7/hotspot/src/share/vm/gc_implementation/concurrentMarkSweep -I/home/fw/src/java/jdk7/hotspot/src/share/vm/gc_implementation/shared -I/home/fw/src/java/jdk7/hotspot/src/share/vm/gc_implementation/parallelScavenge -I/home/fw/src/java/jdk7/hotspot/src/share/vm/gc_interface -I/home/fw/src/java/jdk7/hotspot/src/share/vm/interpreter -I/home/fw/src/java/jdk7/hotspot/src/share/vm/libadt -I/home/fw/src/java/jdk7/hotspot/src/share/vm/memory -I/home/fw/src/java/jdk7/hotspot/src/share/vm/oops -I/home/fw/src/java/jdk7/hotspot/src/share/vm/opto -I/home/fw/src/java/jdk7/hotspot/src/share/vm/prims -I/home/fw/src/java/jdk7/hotspot/src/share/vm/runtime -I/home/fw/src/java/jdk7/hotspot/src/share/vm/services -I/home/fw/src/java/jdk7/hotspot/src/share/vm/utilities -I/home/fw/src/java/jdk7/hotspot/src/cpu/x86/vm -I/home/fw/src/java/jdk7/hotspot/src/os/linux/vm -I/home/fw/src/java/jdk7/hotspot/src/os_cpu/linux_x86/vm -I../generated -DHOTSPOT_RELEASE_VERSION="\"14.0-b01\"" -DHOTSPOT_BUILD_TARGET="\"fastdebug\"" -DHOTSPOT_BUILD_USER="\"fw\"" -DHOTSPOT_LIB_ARCH=\"amd64\" -DJRE_RELEASE_VERSION="\"1.7.0-internal-fastdebug-fw_2008_08_27_11_45-b00\"" -DHOTSPOT_VM_DISTRO="\"OpenJDK\"" -DCOMPILER2 -fPIC -fno-rtti -fno-exceptions -D_REENTRANT -fcheck-new -m64 -pipe -O3 -fno-strict-aliasing -DVM_LITTLE_ENDIAN -D_LP64=1 -fno-omit-frame-pointer -Werror -Wpointer-arith -Wsign-compare-c -o ciMethodBlocks.o /home/fw/src/java/jdk7/hotspot/src/share/vm/ci/ciMethodBlocks.cpp cc1plus: warnings being treated as errors /home/fw/src/java/jdk7/hotspot/src/share/vm/ci/ciMethodBlocks.cpp:362: error: deprecated conversion from string constant to ‘char*’ It's inside #ifndef PRODUCT, that's why it hasn't been caught before. This happens with this tip: changeset: 241:5b3b8a69f10f tag: tip user:xdono date:Thu Aug 14 09:26:23 2008 -0700 summary: Added tag jdk7-b33 for changeset 585535ec8a14 To be honest, I think -Werror should be disabled except for test builds (with well-defined compilers). For downstream consumers, -Werror only adds additional hassle.
Re: splashscreen.so is missing pnggccrd.c
Hi Martin, On 08/25/2008 08:17 PM Martin Buchholz wrote: Thanks for the link, but... - The fix for 6613927 is applied in my workspace And it gets activated when building on a 64-bit system only. Could you please take a look at the make/sun/splashscreen/Makefile file and make sure it defines the "CPPFLAGS += -DPNG_NO_MMX_CODE" in every case. It is really very interesting if this will resolve the issue. Thank you in advance. This is not an ideal solution. Updating to a new libpng version would be fine, however these should be some clean sources (i.e. vanilla libpng source tarball, w/o any static <-> const swaps, etc.), and secondly it requires some Sun-internal bureaucratic process to put these sources to the OpenJDK source tree. Currently I don't see the suggested change is justified since using the standard build environment does not reproduce the problem. However, you might probably be interested in fixing the following CR: http://bugs.sun.com/view_bug.do?bug_id=6565114 This would eliminate this problem at once and forever. Diego 'Flameeyes' Pettenò didn't provide us with a working patch (please see the archives of the awt-dev mailing list), hence the CR has been suspended. -- best regards, Anthony
Re: fastdebug_build triggers -Werror with g++ 4.3.1-9 (Debian)
If you set the variable WARNINGS_ARE_ERRORS to be empty, it should be sent through to all the makefiles. It's the variable WARNINGS_ARE_ERRORS that contains the option "-Werror". So try: make WARNINGS_ARE_ERRORS= Not using -Werror will likely let more warning errors creep into the builds, and using it means a few people get annoyed. And the changeset below probably has nothing to do with it, must be an earlier changeset. -kto Florian Weimer wrote: g++ -DLINUX -D_GNU_SOURCE -DAMD64 -DASSERT -DFASTDEBUG -I. -I../generated/adfiles -I../generated/jvmtifiles -I/home/fw/src/java/jdk7/hotspot/src/share/vm/asm -I/home/fw/src/java/jdk7/hotspot/src/share/vm/ci -I/home/fw/src/java/jdk7/hotspot/src/share/vm/classfile -I/home/fw/src/java/jdk7/hotspot/src/share/vm/code -I/home/fw/src/java/jdk7/hotspot/src/share/vm/compiler -I/home/fw/src/java/jdk7/hotspot/src/share/vm/gc_implementation -I/home/fw/src/java/jdk7/hotspot/src/share/vm/gc_implementation/parNew -I/home/fw/src/java/jdk7/hotspot/src/share/vm/gc_implementation/concurrentMarkSweep -I/home/fw/src/java/jdk7/hotspot/src/share/vm/gc_implementation/shared -I/home/fw/src/java/jdk7/hotspot/src/share/vm/gc_implementation/parallelScavenge -I/home/fw/src/java/jdk7/hotspot/src/share/vm/gc_interface -I/home/fw/src/java/jdk7/hotspot/src/share/vm/interpreter -I/home/fw/src/java/jdk7/hotspot/src/share/vm/libadt -I/home/fw/src/java/jdk7/hotspot/src/share/vm/memory -I/home/fw/src/java/jdk7/ hotspot/src/share/vm/oops -I/home/fw/src/java/jdk7/hotspot/src/share/vm/opto -I/home/fw/src/java/jdk7/hotspot/src/share/vm/prims -I/home/fw/src/java/jdk7/hotspot/src/share/vm/runtime -I/home/fw/src/java/jdk7/hotspot/src/share/vm/services -I/home/fw/src/java/jdk7/hotspot/src/share/vm/utilities -I/home/fw/src/java/jdk7/hotspot/src/cpu/x86/vm -I/home/fw/src/java/jdk7/hotspot/src/os/linux/vm -I/home/fw/src/java/jdk7/hotspot/src/os_cpu/linux_x86/vm -I../generated -DHOTSPOT_RELEASE_VERSION="\"14.0-b01\"" -DHOTSPOT_BUILD_TARGET="\"fastdebug\"" -DHOTSPOT_BUILD_USER="\"fw\"" -DHOTSPOT_LIB_ARCH=\"amd64\" -DJRE_RELEASE_VERSION="\"1.7.0-internal-fastdebug-fw_2008_08_27_11_45-b00\"" -DHOTSPOT_VM_DISTRO="\"OpenJDK\"" -DCOMPILER2 -fPIC -fno-rtti -fno-exceptions -D_REENTRANT -fcheck-new -m64 -pipe -O3 -fno-strict-aliasing -DVM_LITTLE_ENDIAN -D_LP64=1 -fno-omit-frame-pointer -Werror -Wpointer-arith -Wsign-compare-c -o ciMethodBlocks.o /home/fw/src/java/jdk7/hotspot/src/share/vm/ci/ciMetho dBlocks.cpp cc1plus: warnings being treated as errors /home/fw/src/java/jdk7/hotspot/src/share/vm/ci/ciMethodBlocks.cpp:362: error: deprecated conversion from string constant to ‘char*’ It's inside #ifndef PRODUCT, that's why it hasn't been caught before. This happens with this tip: changeset: 241:5b3b8a69f10f tag: tip user:xdono date:Thu Aug 14 09:26:23 2008 -0700 summary: Added tag jdk7-b33 for changeset 585535ec8a14 To be honest, I think -Werror should be disabled except for test builds (with well-defined compilers). For downstream consumers, -Werror only adds additional hassle.
Re: fastdebug_build triggers -Werror with g++ 4.3.1-9 (Debian)
This was fixed as part of 6712835. http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/6ca61c728c2d tom On Aug 27, 2008, at 5:24 AM, Florian Weimer wrote: g++ -DLINUX -D_GNU_SOURCE -DAMD64 -DASSERT -DFASTDEBUG -I. -I../ generated/adfiles -I../generated/jvmtifiles -I/home/fw/src/java/jdk7/ hotspot/src/share/vm/asm -I/home/fw/src/java/jdk7/hotspot/src/share/ vm/ci -I/home/fw/src/java/jdk7/hotspot/src/share/vm/classfile -I/ home/fw/src/java/jdk7/hotspot/src/share/vm/code -I/home/fw/src/java/ jdk7/hotspot/src/share/vm/compiler -I/home/fw/src/java/jdk7/hotspot/ src/share/vm/gc_implementation -I/home/fw/src/java/jdk7/hotspot/src/ share/vm/gc_implementation/parNew -I/home/fw/src/java/jdk7/hotspot/ src/share/vm/gc_implementation/concurrentMarkSweep -I/home/fw/src/ java/jdk7/hotspot/src/share/vm/gc_implementation/shared -I/home/fw/ src/java/jdk7/hotspot/src/share/vm/gc_implementation/ parallelScavenge -I/home/fw/src/java/jdk7/hotspot/src/share/vm/ gc_interface -I/home/fw/src/java/jdk7/hotspot/src/share/vm/ interpreter -I/home/fw/src/java/jdk7/hotspot/src/share/vm/libadt -I/ home/fw/src/java/jdk7/hotspot/src/share/vm/memory -I/home/fw/src/ java/jdk7/hotspot/src/share/vm/oops -I/home/fw/src/java/jdk7/hotspot/ src/share/vm/opto -I/home/fw/src/java/jdk7/hotspot/src/share/vm/ prims -I/home/fw/src/java/jdk7/hotspot/src/share/vm/runtime -I/home/ fw/src/java/jdk7/hotspot/src/share/vm/services -I/home/fw/src/java/ jdk7/hotspot/src/share/vm/utilities -I/home/fw/src/java/jdk7/hotspot/ src/cpu/x86/vm -I/home/fw/src/java/jdk7/hotspot/src/os/linux/vm -I/ home/fw/src/java/jdk7/hotspot/src/os_cpu/linux_x86/vm -I../generated -DHOTSPOT_RELEASE_VERSION="\"14.0-b01\"" - DHOTSPOT_BUILD_TARGET="\"fastdebug\"" -DHOTSPOT_BUILD_USER="\"fw\"" - DHOTSPOT_LIB_ARCH=\"amd64\" -DJRE_RELEASE_VERSION="\"1.7.0-internal- fastdebug-fw_2008_08_27_11_45-b00\"" -DHOTSPOT_VM_DISTRO="\"OpenJDK \"" -DCOMPILER2 -fPIC -fno-rtti -fno-exceptions -D_REENTRANT -fcheck- new -m64 -pipe -O3 -fno-strict-aliasing -DVM_LITTLE_ENDIAN -D_LP64=1 -fno-omit-frame-pointer -Werror -Wpointer-arith -Wsign-compare-c -o ciMethodBlocks.o /home/fw/src/java/jdk7/hotspot/src/share/vm/ci/ ciMethodBlocks.cpp cc1plus: warnings being treated as errors /home/fw/src/java/jdk7/hotspot/src/share/vm/ci/ciMethodBlocks.cpp: 362: error: deprecated conversion from string constant to ‘char*’ It's inside #ifndef PRODUCT, that's why it hasn't been caught before. This happens with this tip: changeset: 241:5b3b8a69f10f tag: tip user:xdono date:Thu Aug 14 09:26:23 2008 -0700 summary: Added tag jdk7-b33 for changeset 585535ec8a14 To be honest, I think -Werror should be disabled except for test builds (with well-defined compilers). For downstream consumers, -Werror only adds additional hassle.
Re: dacapo bloat benchmark fails on openjdk7
Could you be more specific about what bits you are running, i.e. which changeset of hotspot? The official openjdk bits run fine for me with at least b30-b33. tom On Aug 27, 2008, at 1:34 AM, Luca Martini wrote: Apologies for cross posting to the dacapobench-researchers and [EMAIL PROTECTED] lists. Hi all, I recently tried to execute the DaCapo benchmark on OpenJDK 7 and I found that "bloat" benchmark fails with the following exception: $ OpenJDK/jdk7/build/linux-i586/j2re-image/bin/java-jar ~/dacapo-2006-10-MR2.jar bloat = DaCapo bloat starting = ** Exception while optimizing transform(LEDU/purdue/cs/bloat/editor/MethodEditor;)Z of class EDU/purdue/cs/bloat/trans/CompactArrayInitializer String index out of range: -1802716504 java.lang.StringIndexOutOfBoundsException: String index out of range: -1802716504 at java.lang.String.getChars(String.java:860) at java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:408) at java.lang.StringBuilder.append(StringBuilder.java:136) at java.lang.StringBuilder.append(StringBuilder.java:132) at java.util.AbstractCollection.toString(AbstractCollection.java:439) at EDU.purdue.cs.bloat.codegen.RegisterAllocator $IGNode.toString(RegisterAllocator.java:570) at java.lang.String.valueOf(String.java:2838) at java.lang.StringBuffer.append(StringBuffer.java:236) at EDU.purdue.cs.bloat.util.Graph$4.next(Graph.java:983) at java.util.AbstractCollection.addAll(AbstractCollection.java:322) at EDU .purdue .cs.bloat.codegen.RegisterAllocator.(RegisterAllocator.java:288) at EDU.purdue.cs.bloat.optimize.Main.bloatMethod(Main.java:1078) at EDU.purdue.cs.bloat.optimize.Main.editClass(Main.java:688) at EDU.purdue.cs.bloat.optimize.Main.main(Main.java:446) at dacapo.bloat.BloatHarness.iterate(BloatHarness.java:25) at dacapo.Benchmark.run(Benchmark.java:126) at dacapo.TestHarness.runBenchmark(TestHarness.java:302) at dacapo.TestHarness.main(TestHarness.java:242) at Harness.main(Harness.java:5) I really don't know if it's a DaCapo problem or if I missed something in the build process of OpenJDK. The version of the DaCapo is 2006-10- MR2. I built OpenJDK both using mercurial repository and source bundle, and the build runs fine but when executing the benchmark the same error come up. These are the options I used for building OpenJDK 7: LANG=C FINDBUGS_HOME= ALT_BOOTDIR=/usr/lib/jvm/java-6-sun ALT_BINARY_PLUGS_PATH= ANT_HOME=/usr/share/ant ARCH_DADA_MODEL=32 Here there are some information on my machine: $ uname -a Linux 2.6.24-21-generic #1 SMP Tue Aug 12 13:37:22 UTC 2008 i686 GNU/ Linux Any clues? Can anybody confirm such error? Thanks for your attention, Luca -- * Ing. Luca Martini Dipartimento di Ing. dell'Informazione Università di Pisa Via Diotisalvi, 2, I-56126 Pisa, Italy Tel: +39 050 2217 465 Fax: +39 050 2217 600 e-mail: [EMAIL PROTECTED] *
Re: dacapo bloat benchmark fails on openjdk7
I concur with Tom. I went back to b25 and didn't have any problems running dacapo bloat with JDK7. -- Chuck On 08/27/08 11:35, Tom Rodriguez wrote: Could you be more specific about what bits you are running, i.e. which changeset of hotspot? The official openjdk bits run fine for me with at least b30-b33. tom On Aug 27, 2008, at 1:34 AM, Luca Martini wrote: Apologies for cross posting to the dacapobench-researchers and [EMAIL PROTECTED] lists. Hi all, I recently tried to execute the DaCapo benchmark on OpenJDK 7 and I found that "bloat" benchmark fails with the following exception: $ OpenJDK/jdk7/build/linux-i586/j2re-image/bin/java-jar ~/dacapo-2006-10-MR2.jar bloat = DaCapo bloat starting = ** Exception while optimizing transform(LEDU/purdue/cs/bloat/editor/MethodEditor;)Z of class EDU/purdue/cs/bloat/trans/CompactArrayInitializer String index out of range: -1802716504 java.lang.StringIndexOutOfBoundsException: String index out of range: -1802716504 at java.lang.String.getChars(String.java:860) at java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:408) at java.lang.StringBuilder.append(StringBuilder.java:136) at java.lang.StringBuilder.append(StringBuilder.java:132) at java.util.AbstractCollection.toString(AbstractCollection.java:439) at EDU.purdue.cs.bloat.codegen.RegisterAllocator$IGNode.toString(RegisterAllocator.java:570) at java.lang.String.valueOf(String.java:2838) at java.lang.StringBuffer.append(StringBuffer.java:236) at EDU.purdue.cs.bloat.util.Graph$4.next(Graph.java:983) at java.util.AbstractCollection.addAll(AbstractCollection.java:322) at EDU.purdue.cs.bloat.codegen.RegisterAllocator.(RegisterAllocator.java:288) at EDU.purdue.cs.bloat.optimize.Main.bloatMethod(Main.java:1078) at EDU.purdue.cs.bloat.optimize.Main.editClass(Main.java:688) at EDU.purdue.cs.bloat.optimize.Main.main(Main.java:446) at dacapo.bloat.BloatHarness.iterate(BloatHarness.java:25) at dacapo.Benchmark.run(Benchmark.java:126) at dacapo.TestHarness.runBenchmark(TestHarness.java:302) at dacapo.TestHarness.main(TestHarness.java:242) at Harness.main(Harness.java:5) I really don't know if it's a DaCapo problem or if I missed something in the build process of OpenJDK. The version of the DaCapo is 2006-10-MR2. I built OpenJDK both using mercurial repository and source bundle, and the build runs fine but when executing the benchmark the same error come up. These are the options I used for building OpenJDK 7: LANG=C FINDBUGS_HOME= ALT_BOOTDIR=/usr/lib/jvm/java-6-sun ALT_BINARY_PLUGS_PATH= ANT_HOME=/usr/share/ant ARCH_DADA_MODEL=32 Here there are some information on my machine: $ uname -a Linux 2.6.24-21-generic #1 SMP Tue Aug 12 13:37:22 UTC 2008 i686 GNU/Linux Any clues? Can anybody confirm such error? Thanks for your attention, Luca -- * Ing. Luca Martini Dipartimento di Ing. dell'Informazione Università di Pisa Via Diotisalvi, 2, I-56126 Pisa, Italy Tel: +39 050 2217 465 Fax: +39 050 2217 600 e-mail: [EMAIL PROTECTED] *
make sanity RFE
For the first time, I've been trying a full complete build of OpenJDK (full open+closed forest.) I'm building on Ubuntu, and the build has now failed a second time because of a missing command -- or more specifically, a command which is not installed by default. The first command was msgfmt, the latest was bb. I do not know if there are more to come. It would be nice if make sanity had a mechanism for a quick existence check for commands that are likely to be required during the build, so that missing commands can be detected and reported early, and not one at a time at the end of a long build. -- Jon
Re: make sanity RFE
If you're running on Ubuntu, the makefiles could check for the installed-ness of various build-time dependencies. The Ubuntu packagers (i.e. doko) must already have such a list. Martin On Wed, Aug 27, 2008 at 2:25 PM, Jonathan Gibbons <[EMAIL PROTECTED]> wrote: > For the first time, I've been trying a full complete build of OpenJDK > (full open+closed forest.) > > I'm building on Ubuntu, and the build has now failed a second time > because of a missing command -- or more specifically, a command which > is not installed by default. The first command was msgfmt, the latest > was bb. I do not know if there are more to come. > > It would be nice if make sanity had a mechanism for a quick existence > check for commands that are likely to be required during the build, so > that missing commands can be detected and reported early, and not > one at a time at the end of a long build. > > -- Jon >
Re: make sanity RFE
Jonathan Gibbons wrote: For the first time, I've been trying a full complete build of OpenJDK (full open+closed forest.) I'm building on Ubuntu, and the build has now failed a second time because of a missing command -- or more specifically, a command which is not installed by default. The first command was msgfmt, the latest was bb. I do not know if there are more to come. It would be nice if make sanity had a mechanism for a quick existence check for commands that are likely to be required during the build, so that missing commands can be detected and reported early, and not one at a time at the end of a long build. -- Jon sudo apt-get build-dep openjdk-6 should get you the necessary build dependencies installed. cheers, dalibor topic -- *** Dalibor Topic Tel: (+49 40) 23 646 738 Java F/OSS Ambassador AIM: robiladonaim Sun Microsystems GmbH Mobile: (+49 177) 2664 192 Nagelsweg 55http://openjdk.java.net D-20097 Hamburg mailto:[EMAIL PROTECTED] Sitz der Gesellschaft: Sonnenallee 1, D-85551 Kirchheim-Heimstetten Amtsgericht München: HRB 161028 Geschäftsführer: Thomas Schröder, Wolfgang Engels, Dr. Roland Bömer Vorsitzender des Aufsichtsrates: Martin Häring
Re: splashscreen.so is missing pnggccrd.c
Anthony, Thanks for your patience; you were entirely right, it was indeed necessary to define PNG_NO_MMX_CODE. Since pnggccrd.c is never compiled, and it contains the MMX code, the only correct thing appears to be to define this macro unconditionally. The obvious patch follows (tested on 32-bit Ubuntu Linux with very recent gcc toolchain) (Has anyone actually tested png splashscreen images on 32 or 64-bit Linux?) # HG changeset patch # User martin # Date 1219875308 25200 # Node ID 86b160e4bc1aae927aa71dfd712bb2365ebc0e1c # Parent 1267605489211c6c162bb246f653759e933bd06e 6613927: Compilation of splashscreen png library failed on Ubuntu 7.04 (64bit) Summary: Define -DPNG_NO_MMX_CODE unconditionally, not just on 64-bit Linux Reviewed-by: anthony diff --git a/make/sun/splashscreen/Makefile b/make/sun/splashscreen/Makefile --- a/make/sun/splashscreen/Makefile +++ b/make/sun/splashscreen/Makefile @@ -85,13 +85,6 @@ CPPFLAGS += -I$(PLATFORM_SRC)/native/$(PKGDIR)/splashscreen -I$(SHARE_SRC)/native/$(PKGDIR)/splashscreen CPPFLAGS += -I$(SHARE_SRC)/native/$(PKGDIR)/image/jpeg -I$(SHARE_SRC)/native/java/util/zip/zlib-1.1.3 -ifeq ($(PLATFORM), linux) - ifeq ($(ARCH_DATA_MODEL), 64) -# 64-bit gcc has problems compiling MMX instructions. -# Google it for more details. Possibly the newer versions of -# the PNG-library and/or the new compiler will not need this -# option in the future. -CPPFLAGS += -DPNG_NO_MMX_CODE - endif -endif - +# Shun the less than portable MMX assembly code in pnggccrd.c. +# Newer versions of the PNG-library may not need this option. +CPPFLAGS += -DPNG_NO_MMX_CODE Martin On Wed, Aug 27, 2008 at 5:48 AM, Anthony Petrov <[EMAIL PROTECTED]> wrote: > Hi Martin, > > On 08/25/2008 08:17 PM Martin Buchholz wrote: >> >> Thanks for the link, but... >> - The fix for 6613927 is applied in my workspace > > And it gets activated when building on a 64-bit system only. Could you > please take a look at the make/sun/splashscreen/Makefile file and make sure > it defines the "CPPFLAGS += -DPNG_NO_MMX_CODE" in every case. It is really > very interesting if this will resolve the issue. Thank you in advance.
Re: make sanity RFE
Neat! -- Jon Dalibor Topic wrote: Jonathan Gibbons wrote: For the first time, I've been trying a full complete build of OpenJDK (full open+closed forest.) I'm building on Ubuntu, and the build has now failed a second time because of a missing command -- or more specifically, a command which is not installed by default. The first command was msgfmt, the latest was bb. I do not know if there are more to come. It would be nice if make sanity had a mechanism for a quick existence check for commands that are likely to be required during the build, so that missing commands can be detected and reported early, and not one at a time at the end of a long build. -- Jon sudo apt-get build-dep openjdk-6 should get you the necessary build dependencies installed. cheers, dalibor topic
Re: splashscreen.so is missing pnggccrd.c
On Wed, Aug 27, 2008 at 5:48 AM, Anthony Petrov <[EMAIL PROTECTED]> wrote: > This is not an ideal solution. Updating to a new libpng version would be > fine, however these should be some clean sources (i.e. vanilla libpng source > tarball, w/o any static <-> const swaps, etc.), and secondly it requires > some Sun-internal bureaucratic process to put these sources to the OpenJDK > source tree. I'm well acquainted with the Sun-internal bureaucratic process. I encourage the libpng upgrade to happen, but it's not high enough priority for me to do the work. > Currently I don't see the suggested change is justified since using the > standard build environment does not reproduce the problem. OpenJDK is a community effort, and no longer just a Sun effort. For us this is a P1 bug, since it is a compilation error in our environment. If we cannot get a fix for this accepted upstream, we would be forced to fork. However, you > might probably be interested in fixing the following CR: > http://bugs.sun.com/view_bug.do?bug_id=6565114 > This would eliminate this problem at once and forever. Diego 'Flameeyes' > Pettenò didn't provide us with a working patch (please see the archives of > the awt-dev mailing list), hence the CR has been suspended. Adding options to use the system versions of these graphics libraries is integrated into IcedTea already. IcedTea and Sun AWT engineers should work together to put such changes into OpenJDK7. Martin
Re: make sanity RFE
On Wed, Aug 27, 2008 at 3:19 PM, Dalibor Topic <[EMAIL PROTECTED]> wrote: > > sudo apt-get build-dep openjdk-6 Wow! __That__'s the command I've been looking for! Martin
Re: make sanity RFE
> Date: Thu, 28 Aug 2008 00:19:24 +0200 > From: [EMAIL PROTECTED] > sudo apt-get build-dep openjdk-6 > > should get you the necessary build dependencies installed. Wow. That is just too slick for words. - Mark
