From xerxes at zafena.se Wed Apr 1 15:31:53 2009 From: xerxes at zafena.se (=?ISO-8859-1?Q?Xerxes_R=E5nby?=) Date: Thu, 02 Apr 2009 00:31:53 +0200 Subject: [patch] Shark reroute LLVM atomic intrinsics to Zero In-Reply-To: <49D143B2.80007@gmx.net> References: <49CE9FD0.6030202@zafena.se> <49CEACD7.8040203@gmx.net> <49CFA59F.4030509@redhat.com> <49D143B2.80007@gmx.net> Message-ID: <49D3EB59.9030808@zafena.se> Robert Schuster skrev: > Hi Andrew, > > Andrew Haley schrieb: > >> Definitely; we really don't want a function call just do do an atomic >> cmpxchg. >> > That is why I opted for enabling it only for the arches that really need > it by using #ifdef. > > Before I start prepare a patch adding lots of #ifdefs all over sharkBuilder for all kinds of architectures, i would like to ask if it would be better to do this instead: I consider implementing a new configure option say --enable-shark-atomic-reroute that can enable or disable this rerouting thus then we only needs to add one #ifdef SHARK_LLVM_ATOMIC_REROUTE around the parts that i patch in. My thinking is that it should be easy to add new zero/shark architectures without having to update sharkBuilder at all. configure should be made to set this to be enabled for all zero architectures that we know needing it. >> This is really just a workaround for an llvm bug, and hopefully >> it'll soon go away. >> > Do you know more than me? > > The 'bug' is actually a missing feature and I don't see someone working > on this. I tried fixing it myself but it will take me a while until > understand how to use llvm's tablegen syntax to describe the generation > of a series of instructions for the compiler Found this great google-find: http://markmail.org/message/73owc5nrvsbmrhes It is the mail correspondence when Gary implemented the atomic intrinsics in llvm for PPC. Great work Gary! Cheers, and have a great day. Xerxes From neale at sinenomine.net Fri Apr 3 08:04:41 2009 From: neale at sinenomine.net (Neale Ferguson) Date: Fri, 03 Apr 2009 11:04:41 -0400 Subject: Make or Makefile problem? Message-ID: I?m building icedtea6-1.4.1 and am encountering the following error: /bin/mkdir -p /home/neale/icedtea6-1.4.1/openjdk-ecj/control/build/linux-s390x/tmp rm -f /home/neale/icedtea6-1.4.1/openjdk-ecj/control/build/linux-s390x/tmp/rt-orig .jar ifneq (,1) /bin/sh: -c: line 0: syntax error near unexpected token `,1' /bin/sh: -c: line 0: `ifneq (,1)' make[2]: *** [/home/neale/icedtea6-1.4.1/openjdk-ecj/control/build/linux-s390x/tmp/rt-ori g.jar] Error 2 make[2]: Leaving directory `/home/neale/icedtea6-1.4.1/openjdk-ecj/jdk/make' It appears due to this part of the recipe: $(RT_JAR): $(if $(JAR_KNOWS_ATFILE),$(RT_JAR_FILELIST),$(RT_JAR_ARGLIST)) \ $(JAR_MANIFEST_FILE) $(prep-target) ifneq (,$(JAR_KNOWS_ATFILE)) (cd $(CLASSBINDIR) && \ $(BOOT_JAR_CMD) c0mf $(JAR_MANIFEST_FILE) $@ \ $(JAR_JFLAGS) @$(RT_JAR_FILELIST)) else : I'm using GNU make 3.81. Neale From neale at sinenomine.net Fri Apr 3 19:30:07 2009 From: neale at sinenomine.net (Neale Ferguson) Date: Fri, 03 Apr 2009 22:30:07 -0400 Subject: Build progressing... Message-ID: After upgrading make from 3.80 to 3.81, my build of icedtea6-1.4.1 is progressing. It runs for a number of hours, completes building in openjdk-ecj and appears to start building within openjdk where it comes to a halt with: make[2]: Entering directory `/home/neale/icedtea6-1.4.1/openjdk/langtools/make' JAVA_HOME=/home/neale/icedtea6-1.4.1/bootstrap/jdk1.6.0 ANT_OPTS=-Djava.io.tmpdir='/home/neale/icedtea6-1.4.1/openjdk/control/build/ linux-s390x/langtools/build/ant-tmp' ant -diagnostics > /home/neale/icedtea6-1.4.1/openjdk/control/build/linux-s390x/langtools/build /ant-diagnostics.log Exception in thread "main" java.lang.NoClassDefFoundError: org/apache/tools/ant/launch/Launcher Caused by: java.lang.ClassNotFoundException: org.apache.tools.ant.launch.Launcher at java.net.URLClassLoader$2.run(URLClassLoader.java:217) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:206) at java.lang.ClassLoader.loadClass(ClassLoader.java:323) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:294) at java.lang.ClassLoader.loadClass(ClassLoader.java:268) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:336) Could not find the main class: org.apache.tools.ant.launch.Launcher. Program will exit. The difference is now JAVA_HOME is being specified. Obviously it can?t find the ant jar which is lurking in /usr/share/java. So what configuration piece have I missed so that it knows where to look? Neale From Kelly.Ohair at Sun.COM Sat Apr 4 12:05:25 2009 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Sat, 04 Apr 2009 12:05:25 -0700 Subject: Build progressing... In-Reply-To: References: Message-ID: <49D7AF75.1040105@sun.com> Make sure you can run 'ant -version', and also try: export JAVA_HOME=/home/neale/icedtea6-1.4.1/bootstrap/jdk1.6.0 ant -version If that doesn't work, then you need to track that down. I usually download my own ant 1.7.0 in my home directory and use that. I've had problems with the ant's placed in /usr/bin or /usr/local/bin, I think the ant startup script gets confused sometimes when it doesn't live in it's own 'home' location. -kto Neale Ferguson wrote: > After upgrading make from 3.80 to 3.81, my build of icedtea6-1.4.1 is > progressing. It runs for a number of hours, completes building in > openjdk-ecj and appears to start building within openjdk where it comes to a > halt with: > > make[2]: Entering directory > `/home/neale/icedtea6-1.4.1/openjdk/langtools/make' > JAVA_HOME=/home/neale/icedtea6-1.4.1/bootstrap/jdk1.6.0 > ANT_OPTS=-Djava.io.tmpdir='/home/neale/icedtea6-1.4.1/openjdk/control/build/ > linux-s390x/langtools/build/ant-tmp' ant -diagnostics > > /home/neale/icedtea6-1.4.1/openjdk/control/build/linux-s390x/langtools/build > /ant-diagnostics.log > Exception in thread "main" java.lang.NoClassDefFoundError: > org/apache/tools/ant/launch/Launcher > Caused by: java.lang.ClassNotFoundException: > org.apache.tools.ant.launch.Launcher > at java.net.URLClassLoader$2.run(URLClassLoader.java:217) > at java.security.AccessController.doPrivileged(Native Method) > at java.net.URLClassLoader.findClass(URLClassLoader.java:206) > at java.lang.ClassLoader.loadClass(ClassLoader.java:323) > at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:294) > at java.lang.ClassLoader.loadClass(ClassLoader.java:268) > at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:336) > Could not find the main class: org.apache.tools.ant.launch.Launcher. Program > will exit. > > The difference is now JAVA_HOME is being specified. Obviously it can?t find > the ant jar which is lurking in /usr/share/java. So what configuration piece > have I missed so that it knows where to look? > > Neale > > From gbenson at redhat.com Mon Apr 6 02:22:34 2009 From: gbenson at redhat.com (Gary Benson) Date: Mon, 6 Apr 2009 10:22:34 +0100 Subject: In-Reply-To: References: Message-ID: <20090406092234.GC3260@redhat.com> This error (The type java.lang.Object cannot be resolved) happens when ecj's bootclasspath is wrong. Cheers, Gary Neale Ferguson wrote: > This is my first attempt building zero and am making it to this > point before bombing out: > > ANT_OPTS=-Djava.io.tmpdir='/home/neale/icedtea-1.9/openjdk-ecj/build/linux-s > 390x/langtools/build/ant-tmp' ant -Djdk.version=1.7.0_0 > -Dfull.version='1.7.0_0-b50' -Drelease=1.7.0_0 -Dbuild.number=b50 > -Djavac.debug=true -Djavac.target=5 > -Dboot.java.home=/home/neale/icedtea-1.9/bootstrap/jdk1.6.0 > -Djavac.executable=/home/neale/icedtea-1.9/bootstrap/jdk1.6.0/bin/javac > -Dbuild.dir=/home/neale/icedtea-1.9/openjdk-ecj/build/linux-s390x/langtools/ > build > -Ddist.dir=/home/neale/icedtea-1.9/openjdk-ecj/build/linux-s390x/langtools/d > ist build > Buildfile: build.xml > > -def-check: > > -check-boot.java.home: > > -def-pcompile: > [mkdir] Created dir: > /home/neale/icedtea-1.9/openjdk-ecj/build/linux-s390x/langtools/build/toolcl > asses > [javac] Compiling 2 source files to > /home/neale/icedtea-1.9/openjdk-ecj/build/linux-s390x/langtools/build/toolcl > asses > [javac] ---------- > [javac] 1. ERROR in > /home/neale/icedtea-1.9/openjdk-ecj/langtools/make/tools/CompileProperties/C > ompileProperties.java (at line 1) > [javac] /* > [javac] ^ > [javac] The type java.lang.Object cannot be resolved. It is indirectly > referenced from required .class files > [javac] ---------- > [javac] 2. ERROR in > /home/neale/icedtea-1.9/openjdk-ecj/langtools/make/tools/CompileProperties/C > ompileProperties.java (at line 1) > : > : > ... A total of 100 errors in all. > > I?m sure this is a newbie problem but can someone lend me a clue? I'm using > the IBM 1.6 JDK. > > Neale > > > -- http://gbenson.net/ From gbenson at redhat.com Mon Apr 6 05:58:37 2009 From: gbenson at redhat.com (Gary Benson) Date: Mon, 6 Apr 2009 13:58:37 +0100 Subject: [patch] Shark reroute LLVM atomic intrinsics to Zero In-Reply-To: <49D09E0F.40802@zafena.se> References: <49CE9FD0.6030202@zafena.se> <49CEACD7.8040203@gmx.net> <49CFA59F.4030509@redhat.com> <49D01DB8.9050007@zafena.se> <49D08F90.8020904@redhat.com> <49D09E0F.40802@zafena.se> Message-ID: <20090406125837.GF3260@redhat.com> Xerxes R?nby wrote: > Andrew Haley skrev: > > Xerxes R?nby wrote: > > > Andrew Haley skrev: > > > > Robert Schuster wrote: > > > > > Xerxes R?nby schrieb: > > > > > > This patch will make shark reroute LLVM atomic intrinsics > > > > > > to the existing atomic operations implemented in Zero. > > > > > > > > > > > > This patch are both platform and arch independent. I have > > > > > > tested this patch on Shark compiled for X86, PPC and ARM. > > > > > > > > > > I would make this rerouting optional depending on the > > > > > architecture. LLVM has atomic intrinsic fucntion support > > > > > for x86(-64), powerpc (32,64) and alpha. On those > > > > > architectures you really want to use what LLVM provides. > > > > > > > > > > E.g. on x86 the function is converted into a series of > > > > > machine instructions and no function call. > > > > > > > > Definitely; we really don't want a function call just do do an > > > > atomic cmpxchg. This is really just a workaround for an llvm > > > > bug, and hopefully it'll soon go away. > > > > > > I have done a small investigation to see how large the cost is > > > to use the reroute patch on PPC. The test machine is a > > > PowerBook G4 1.333Ghz with F10 installed. > > > > > > I used Caffeine Mark 3.0 for this benchmark, why? It is a quick > > > benchmark and it includes some graphics tests so it is quite fun > > > to benchmark with. > > > > And, perhaps unsurprisingly, it doesn't use java.lang.concurrent.* > > at all. :-) > > > > Really, the use of lock-free in Java is only just beginning; in the > > future I expect it'll be the obvious way to do things. > > I agree that it is a rather stupid benchmark to use yet I dont have > any benchmark that i know specifically tests for concurrency. My > thinking was to use a benchmark with some gui parts since AWT > internally are multi-threaded AFAIC just to see if i could measure > any effect at all from the use of the reroute. [snip] > If someone know of a better benchmark that tests concurrency > throughfully i would be happy to hear about it. Here's a microbenchmark. On PowerPC, the new instruction is more than three times slower with the function call once the thread's (small) local allocation buffer is exhausted. This definitely needs to be conditional code. Having said that, is there any reason to use atomic intrinsics on a single processor system? And, do multiprocessor ARM systems exist? If the answers to those questions are both no then we could make Shark emit non-atomic code to emulate cmpxchg when it is running on a single processor system, which would sidestep the issue for ARM entirely. Cheers, Gary -- http://gbenson.net/ -------------- next part -------------- class Test { static long test(int size) { Object[] array = new Object[size]; long start = System.currentTimeMillis(); for (int i = 0; i < size; i++) array[i] = new Object(); return System.currentTimeMillis() - start; } public static void main(String[] args) { int size = Integer.parseInt(args[0]); while (true) System.out.println("time taken: " + test(size) + "ms"); } } -------------- next part -------------- tooma:[mixtec]$ openjdk-ecj/control/build/linux-ppc/j2sdk-image/bin/java -XX:+PrintCompilation -XX:-UseTLAB -Xm{s,x}1G -XX:+PrintGC Test 1000000 1 java.lang.String::hashCode (60 bytes) 2 java.lang.String::charAt (33 bytes) 3 java.lang.String::indexOf (152 bytes) 4 sun.nio.cs.UTF_8$Encoder::encodeArrayLoop (490 bytes) 5 java.lang.Object:: (1 bytes) time taken: 5590ms 6 Test::test (41 bytes) time taken: 5591ms time taken: 72ms time taken: 72ms time taken: 72ms [GC 64512K->5836K(1040512K), 1.0372710 secs] time taken: 1113ms time taken: 73ms time taken: 72ms time taken: 73ms time taken: 72ms [GC 70348K->11753K(1040512K), 3.4359440 secs] time taken: 3510ms time taken: 72ms time taken: 73ms time taken: 72ms time taken: 72ms time taken: 72ms [GC 76265K->9534K(1040512K), 1.0564340 secs] time taken: 1129ms time taken: 72ms time taken: 73ms time taken: 81ms time taken: 72ms time taken: 73ms [GC 74003K->3689K(1040512K), 0.1494880 secs] time taken: 70ms time taken: 71ms time taken: 72ms time taken: 72ms time taken: 72ms ^C -------------- next part -------------- tooma:[mixtec]$ openjdk-ecj/control/build/linux-ppc/j2sdk-image/bin/java -XX:+PrintCompilation -XX:-UseTLAB -Xm{s,x}1G -XX:+PrintGC Test 1000000 1 java.lang.String::hashCode (60 bytes) 2 java.lang.String::charAt (33 bytes) 3 java.lang.String::indexOf (152 bytes) 4 sun.nio.cs.UTF_8$Encoder::encodeArrayLoop (490 bytes) 5 java.lang.Object:: (1 bytes) time taken: 5612ms 6 Test::test (41 bytes) time taken: 5565ms time taken: 233ms time taken: 231ms time taken: 232ms [GC 64512K->5836K(1040512K), 1.0353880 secs] time taken: 1268ms time taken: 231ms time taken: 231ms time taken: 234ms time taken: 231ms [GC 70348K->11752K(1040512K), 3.4058850 secs] time taken: 3638ms time taken: 231ms time taken: 231ms time taken: 231ms time taken: 230ms time taken: 232ms [GC 76264K->9532K(1040512K), 1.0380370 secs] time taken: 1269ms time taken: 230ms time taken: 231ms time taken: 230ms time taken: 231ms time taken: 231ms [GC 74003K->3688K(1040512K), 0.1496730 secs] time taken: 231ms time taken: 231ms time taken: 232ms time taken: 231ms time taken: 232ms [GC 68200K->9605K(1040512K), 1.0443780 secs] time taken: 1276ms time taken: 230ms time taken: 230ms time taken: 231ms time taken: 231ms ^C From neale at sinenomine.net Mon Apr 6 06:03:18 2009 From: neale at sinenomine.net (Neale Ferguson) Date: Mon, 06 Apr 2009 09:03:18 -0400 Subject: In-Reply-To: <20090406092234.GC3260@redhat.com> Message-ID: It's all good now. To get the build going - 1. Upgrade packages: - make 3.81 - glitz - cairo - freetype2 2. Update Defs-linux.gmk so OPENWIN_LIB points to /usr/lib64 for s390x (like amd64) 3. s390x is a big endian system so contrib/templater/generate.py needs to reflect this [I built before finding this but it didn't appear to hurt things] 4. Build and install gcc-4.3.3 and libgij-4.3 5. Set up /usr/lib/gcj-jdk directory to mimic gcc-4.4 layout 6. Lots of patience (build takes > 18 hours on z990) [neale - ~]> java -version java version "1.6.0_0" OpenJDK Runtime Environment (IcedTea6 1.4.1) (build 1.6.0_0-b14) OpenJDK 64-Bit Core VM (build 14.0-b08, interpreted mode) Now for LLVM and Shark... Neale On 4/6/09 5:22 AM, "Gary Benson" wrote: > This error (The type java.lang.Object cannot be resolved) happens when > ecj's bootclasspath is wrong. > > Cheers, > Gary > > Neale Ferguson wrote: >> This is my first attempt building zero and am making it to this >> point before bombing out: >> >> ANT_OPTS=-Djava.io.tmpdir='/home/neale/icedtea-1.9/openjdk-ecj/build/linux-s >> 390x/langtools/build/ant-tmp' ant -Djdk.version=1.7.0_0 >> -Dfull.version='1.7.0_0-b50' -Drelease=1.7.0_0 -Dbuild.number=b50 >> -Djavac.debug=true -Djavac.target=5 >> -Dboot.java.home=/home/neale/icedtea-1.9/bootstrap/jdk1.6.0 >> -Djavac.executable=/home/neale/icedtea-1.9/bootstrap/jdk1.6.0/bin/javac >> -Dbuild.dir=/home/neale/icedtea-1.9/openjdk-ecj/build/linux-s390x/langtools/ >> build >> -Ddist.dir=/home/neale/icedtea-1.9/openjdk-ecj/build/linux-s390x/langtools/d >> ist build >> Buildfile: build.xml >> >> -def-check: >> >> -check-boot.java.home: >> >> -def-pcompile: >> [mkdir] Created dir: >> /home/neale/icedtea-1.9/openjdk-ecj/build/linux-s390x/langtools/build/toolcl >> asses >> [javac] Compiling 2 source files to >> /home/neale/icedtea-1.9/openjdk-ecj/build/linux-s390x/langtools/build/toolcl >> asses >> [javac] ---------- >> [javac] 1. ERROR in >> /home/neale/icedtea-1.9/openjdk-ecj/langtools/make/tools/CompileProperties/C >> ompileProperties.java (at line 1) >> [javac] /* >> [javac] ^ >> [javac] The type java.lang.Object cannot be resolved. It is indirectly >> referenced from required .class files >> [javac] ---------- >> [javac] 2. ERROR in >> /home/neale/icedtea-1.9/openjdk-ecj/langtools/make/tools/CompileProperties/C >> ompileProperties.java (at line 1) >> : >> : >> ... A total of 100 errors in all. >> >> I?m sure this is a newbie problem but can someone lend me a clue? I'm using >> the IBM 1.6 JDK. >> >> Neale >> >> >> From gbenson at redhat.com Mon Apr 6 06:14:44 2009 From: gbenson at redhat.com (Gary Benson) Date: Mon, 6 Apr 2009 14:14:44 +0100 Subject: In-Reply-To: References: <20090406092234.GC3260@redhat.com> Message-ID: <20090406131444.GI3260@redhat.com> Neale Ferguson wrote: > 2. Update Defs-linux.gmk so OPENWIN_LIB points to /usr/lib64 for > s390x (like amd64) Could you provide a patch for this? > 3. s390x is a big endian system so contrib/templater/generate.py > needs to reflect this [I built before finding this but it didn't > appear to hurt things] The templater is old code, and not used for Zero builds. > Now for LLVM and Shark... LLVM doesn't have JIT support on zSeries, so you won't be able to run Shark. Cheers, Gary -- http://gbenson.net/ From neale at sinenomine.net Mon Apr 6 06:33:40 2009 From: neale at sinenomine.net (Neale Ferguson) Date: Mon, 06 Apr 2009 09:33:40 -0400 Subject: In-Reply-To: <20090406131444.GI3260@redhat.com> Message-ID: On 4/6/09 9:14 AM, "Gary Benson" wrote: > Neale Ferguson wrote: >> 2. Update Defs-linux.gmk so OPENWIN_LIB points to /usr/lib64 for >> s390x (like amd64) > > Could you provide a patch for this? --- openjdk/corba/make/common/Defs-linux.gmk.orig 2009-04-06 09:30:55.000000000 -0400 +++ openjdk/corba/make/common/Defs-linux.gmk 2009-04-03 16:54:34.000000000 -0400 @@ -306,13 +306,17 @@ override LIBTHREAD = override MOOT_PRIORITIES = true override NO_INTERRUPTIBLE_IO = true override OPENWIN_HOME = /usr/X11R6 ifeq ($(ARCH), amd64) -override OPENWIN_LIB = $(OPENWIN_HOME)/lib64 + override OPENWIN_LIB = $(OPENWIN_HOME)/lib64 else -override OPENWIN_LIB = $(OPENWIN_HOME)/lib + ifeq ($(ARCH), s390x) + override OPENWIN_LIB = $(OPENWIN_HOME)/lib64 + else + override OPENWIN_LIB = $(OPENWIN_HOME)/lib + endif endif override OTHER_M4FLAGS = -D__GLIBC__ -DGNU_ASSEMBLER override SUN_CMM_SUBDIR = override THREADS_FLAG = native override USE_GNU_M4 = true --- ./openjdk/jdk/make/common/Defs-linux.gmk.orig 2009-04-06 09:32:16.000000000 -0400 +++ ./openjdk/jdk/make/common/Defs-linux.gmk 2009-04-03 16:54:55.000000000 -0400 @@ -316,13 +316,17 @@ override LIBTHREAD = override MOOT_PRIORITIES = true override NO_INTERRUPTIBLE_IO = true override OPENWIN_HOME = /usr/X11R6 ifeq ($(ARCH), amd64) -override OPENWIN_LIB = $(OPENWIN_HOME)/lib64 + override OPENWIN_LIB = $(OPENWIN_HOME)/lib64 else -override OPENWIN_LIB = $(OPENWIN_HOME)/lib + ifeq ($(ARCH), s390x) + override OPENWIN_LIB = $(OPENWIN_HOME)/lib64 + else + override OPENWIN_LIB = $(OPENWIN_HOME)/lib + endif endif override OTHER_M4FLAGS = -D__GLIBC__ -DGNU_ASSEMBLER override SUN_CMM_SUBDIR = override THREADS_FLAG = native override USE_GNU_M4 = true >> 3. s390x is a big endian system so contrib/templater/generate.py >> needs to reflect this [I built before finding this but it didn't >> appear to hurt things] > > The templater is old code, and not used for Zero builds. Ok >> Now for LLVM and Shark... > > LLVM doesn't have JIT support on zSeries, so you won't be able to > run Shark. I mean providing LLVM with the necessary support so we can build Shark. This'll be the 4th or 5th time I've had to do something like this. I did it for 32-bit and 64-bit System z for the mono project, the 1.2.2 and 1.3 Blackdown JDKs, and did the 1st implementation of libffi for System z many years ago now. From neale at sinenomine.net Mon Apr 6 06:36:16 2009 From: neale at sinenomine.net (Neale Ferguson) Date: Mon, 06 Apr 2009 09:36:16 -0400 Subject: Running demo apps In-Reply-To: <20090406131444.GI3260@redhat.com> Message-ID: Now that I have a clean build I was just trying to run a couple of the demo apps. For SampleTree I am seeing the following: [neale at aussie-3 - SampleTree] PATH=openjdk/control/build/linux-s390x/bin:$PATH java -jar SampleTree.jar Exception in thread "main" java.lang.ExceptionInInitializerError at java.lang.Class.initializeClass(natClass.cc:792) at java.lang.Class.initializeClass(Class.h:742) at java.lang.reflect.Method.invoke(Class.h:742) at javax.swing.UIDefaults.getUI(UIDefaults.java:748) at javax.swing.UIManager.getUI(UIManager.java:840) at javax.swing.JTree.updateUI(JTree.java:1685) at javax.swing.JTree.(JTree.java:1572) at SampleTree.(SampleTree.java:105) at SampleTree.main(SampleTree.java:602) Caused by: java.awt.IllegalComponentStateException: component java.awt.Label not showing at java.awt.Component.getLocationOnScreen(Component.java:1361) at java.awt.event.MouseEvent.(MouseEvent.java:251) at java.awt.event.MouseEvent.(MouseEvent.java:275) at javax.swing.plaf.basic.BasicTreeUI.(BasicTreeUI.java:286) at java.lang.Class.initializeClass(natClass.cc:780) ...8 more Now I'm running the app directly out of the build directory - i.e. I haven't done whatever the equivalent of "make install" is for the build (speaking of which what is the mechanism of installing the code?). Neale From gbenson at redhat.com Mon Apr 6 06:45:42 2009 From: gbenson at redhat.com (Gary Benson) Date: Mon, 6 Apr 2009 14:45:42 +0100 Subject: In-Reply-To: References: <20090406131444.GI3260@redhat.com> Message-ID: <20090406134542.GJ3260@redhat.com> Neale Ferguson wrote: > On 4/6/09 9:14 AM, "Gary Benson" wrote: > > Neale Ferguson wrote: > > > 2. Update Defs-linux.gmk so OPENWIN_LIB points to /usr/lib64 for > > > s390x (like amd64) > > > > Could you provide a patch for this? [snip] Thanks. I wonder why ppc64 didn't need this... > > > Now for LLVM and Shark... > > > > LLVM doesn't have JIT support on zSeries, so you won't be able to > > run Shark. > > I mean providing LLVM with the necessary support so we can build > Shark. This'll be the 4th or 5th time I've had to do something like > this. I did it for 32-bit and 64-bit System z for the mono project, > the 1.2.2 and 1.3 Blackdown JDKs, and did the 1st implementation of > libffi for System z many years ago now. Oh, wow, that's great news! Cheers, Gary -- http://gbenson.net/ From gbenson at redhat.com Mon Apr 6 06:48:37 2009 From: gbenson at redhat.com (Gary Benson) Date: Mon, 6 Apr 2009 14:48:37 +0100 Subject: Running demo apps In-Reply-To: References: <20090406131444.GI3260@redhat.com> Message-ID: <20090406134837.GK3260@redhat.com> Neale Ferguson wrote: > Now that I have a clean build I was just trying to run a couple of > the demo apps. For SampleTree I am seeing the following: > > [neale at aussie-3 - SampleTree] > PATH=openjdk/control/build/linux-s390x/bin:$PATH java -jar SampleTree.jar > Exception in thread "main" java.lang.ExceptionInInitializerError > at java.lang.Class.initializeClass(natClass.cc:792) > at java.lang.Class.initializeClass(Class.h:742) > at java.lang.reflect.Method.invoke(Class.h:742) > at javax.swing.UIDefaults.getUI(UIDefaults.java:748) > at javax.swing.UIManager.getUI(UIManager.java:840) > at javax.swing.JTree.updateUI(JTree.java:1685) > at javax.swing.JTree.(JTree.java:1572) > at SampleTree.(SampleTree.java:105) > at SampleTree.main(SampleTree.java:602) > Caused by: java.awt.IllegalComponentStateException: component java.awt.Label > not showing > at java.awt.Component.getLocationOnScreen(Component.java:1361) > at java.awt.event.MouseEvent.(MouseEvent.java:251) > at java.awt.event.MouseEvent.(MouseEvent.java:275) > at javax.swing.plaf.basic.BasicTreeUI.(BasicTreeUI.java:286) > at java.lang.Class.initializeClass(natClass.cc:780) > ...8 more I haven't seen this one before. > Now I'm running the app directly out of the build directory - i.e. I > haven't done whatever the equivalent of "make install" is for the > build (speaking of which what is the mechanism of installing the > code?). There isn't a "make install" for IcedTea or OpenJDK, you just run it from the build directory. When I'm debugging I usually use the ecj build, to save waiting forever for a full build to complete. So, the first time around I do "make icedtea-against-ecj" to build everything, then after that, when I change things I do "make hotspot" which rebuilds only HotSpot. Cheers, Gary -- http://gbenson.net/ From neale at sinenomine.net Mon Apr 6 07:09:40 2009 From: neale at sinenomine.net (Neale Ferguson) Date: Mon, 06 Apr 2009 10:09:40 -0400 Subject: Running demo apps In-Reply-To: <20090406134837.GK3260@redhat.com> Message-ID: On 4/6/09 9:48 AM, "Gary Benson" wrote: > Neale Ferguson wrote: >> Now that I have a clean build I was just trying to run a couple of >> the demo apps. For SampleTree I am seeing the following: >> >> [neale at aussie-3 - SampleTree] >> PATH=openjdk/control/build/linux-s390x/bin:$PATH java -jar SampleTree.jar >> Exception in thread "main" java.lang.ExceptionInInitializerError >> at java.lang.Class.initializeClass(natClass.cc:792) >> at java.lang.Class.initializeClass(Class.h:742) >> at java.lang.reflect.Method.invoke(Class.h:742) >> at javax.swing.UIDefaults.getUI(UIDefaults.java:748) >> at javax.swing.UIManager.getUI(UIManager.java:840) >> at javax.swing.JTree.updateUI(JTree.java:1685) >> at javax.swing.JTree.(JTree.java:1572) >> at SampleTree.(SampleTree.java:105) >> at SampleTree.main(SampleTree.java:602) >> Caused by: java.awt.IllegalComponentStateException: component java.awt.Label >> not showing >> at java.awt.Component.getLocationOnScreen(Component.java:1361) >> at java.awt.event.MouseEvent.(MouseEvent.java:251) >> at java.awt.event.MouseEvent.(MouseEvent.java:275) >> at javax.swing.plaf.basic.BasicTreeUI.(BasicTreeUI.java:286) >> at java.lang.Class.initializeClass(natClass.cc:780) >> ...8 more > > I haven't seen this one before. My fault, my PATH was incorrect and it was actually using gnu gij! From aph at redhat.com Tue Apr 7 02:08:34 2009 From: aph at redhat.com (Andrew Haley) Date: Tue, 07 Apr 2009 10:08:34 +0100 Subject: [patch] Shark reroute LLVM atomic intrinsics to Zero In-Reply-To: <20090406125837.GF3260@redhat.com> References: <49CE9FD0.6030202@zafena.se> <49CEACD7.8040203@gmx.net> <49CFA59F.4030509@redhat.com> <49D01DB8.9050007@zafena.se> <49D08F90.8020904@redhat.com> <49D09E0F.40802@zafena.se> <20090406125837.GF3260@redhat.com> Message-ID: <49DB1812.8000500@redhat.com> Gary Benson wrote: > Having said that, is there any reason to use atomic intrinsics on a > single processor system? Yes. The problem is essentially the same on multi-core and single-core systems. A thread switch can happen at any time. > And, do multiprocessor ARM systems exist? > If the answers to those questions are both no then we could make Shark > emit non-atomic code to emulate cmpxchg when it is running on a single > processor system, which would sidestep the issue for ARM entirely. I don't think that's possible without making a system call. Andrew. From neale at sinenomine.net Thu Apr 9 08:49:11 2009 From: neale at sinenomine.net (Neale Ferguson) Date: Thu, 09 Apr 2009 11:49:11 -0400 Subject: Icedtea-1.9 Makefile.in Message-ID: One thing I had to do for my Linux on System z port was the following: --- Makefile.in 2009-03-20 06:53:53.000000000 -0400 +++ Makefile.in.new 2009-03-27 13:39:02.000000000 -0400 @@ -2345,12 +2345,11 @@ @WITH_ALT_HSBUILD_TRUE@ $(abs_top_srcdir)/hotspot.map) openjdk/hotspot ; \ @WITH_ALT_HSBUILD_TRUE@ fi ; \ @WITH_ALT_HSBUILD_TRUE@ fi chmod -R ug+w openjdk sh $(srcdir)/fsg.sh ; - find openjdk -name '*.java' \ - -exec sed -i 's/^[[:space:]]*@Override//' {} + ; \ + sh $(srcdir)/fsed.sh ; mkdir -p stamps touch stamps/extract.stamp stamps/extract-cacao.stamp: stamps/extract.stamp @USE_SYSTEM_CACAO_FALSE@@WITH_CACAO_TRUE@ if ! test -d cacao ; \ The command line created for sed was too long for my system to handle. So I created an fsed script: #!/bin/bash echo "Excising @Override from .java files" JDKSED=`mktemp -p /tmp jdksed.XXXXXXXX` find openjdk -name '*.java' | \ xargs grep -l "@Override" | \ awk '{print "sed -i 's/^[[:space:]]*@Override//' "$1}' >$JDKSED if [ -s $JDKSED ] then sh $JDKSED fi rm $JDKSED From xerxes at zafena.se Tue Apr 14 05:03:25 2009 From: xerxes at zafena.se (=?ISO-8859-1?Q?Xerxes_R=E5nby?=) Date: Tue, 14 Apr 2009 14:03:25 +0200 Subject: shark + assertions + llvm2.6 Message-ID: <49E47B8D.2030900@zafena.se> Hi Gary! I tested building a debuggable shark with assertions enabled using the current llvm 2.6 svn trunk on X86. I have one assertion that fails when running trivial stuff like java -version I wanted to know your opinion if this IA32_ONLY assertion in /openjdk-ecj/hotspot/src/share/vm/interpreter/bytecodeInterpreter.cpp:424 are valid for shark or should i simply ignore it? Cheers Xerxes ================================================= assertion block around bytecodeInterpreter.cpp:424 #ifdef ASSERT if (istate->_msg != initialize) { assert(abs(istate->_stack_base - istate->_stack_limit) == (istate->_method->max_stack() + 1), "bad stack limit"); IA32_ONLY(assert(istate->_stack_limit == istate->_thread->last_Java_sp() + 1, "wrong")); } // Verify linkages. interpreterState l = istate; do { assert(l == l->_self_link, "bad link"); l = l->_prev_link; } while (l != NULL); // Screwups with stack management usually cause us to overwrite istate // save a copy so we can verify it. interpreterState orig = istate; #endif ================================================================== error java -version # To suppress the following error report, specify this argument # after -XX: or in .hotspotrc: SuppressErrorAt=/bytecodeInterpreter.cpp:424 # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (/home/xerxes/icedtea6/openjdk-ecj/hotspot/src/share/vm/interpreter/bytecodeInterpreter.cpp:424), pid=15040, tid=1093299088 # Error: assert(istate->_stack_limit == istate->_thread->last_Java_sp() + 1,"wrong") # # JRE version: 6.0-b14 # Java VM: OpenJDK Shark VM (14.0-b10-product mixed mode linux-i386 ) # An error report file with more information is saved as: # /home/xerxes/icedtea6/hs_err_pid15040.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 # Current thread is 1093299088 Dumping core ... /bin/sh: line 6: 15040 Avbruten (SIGABRT) bootstrap/jdk1.6.0/bin/java -version From gbenson at redhat.com Tue Apr 14 06:11:47 2009 From: gbenson at redhat.com (Gary Benson) Date: Tue, 14 Apr 2009 14:11:47 +0100 Subject: shark + assertions + llvm2.6 In-Reply-To: <49E47B8D.2030900@zafena.se> References: <49E47B8D.2030900@zafena.se> Message-ID: <20090414131146.GD3268@redhat.com> Hi Xerces, Xerxes R?nby wrote: > I tested building a debuggable shark with assertions enabled using > the current llvm 2.6 svn trunk on X86. > > I have one assertion that fails when running trivial stuff like java > -version > I wanted to know your opinion if this IA32_ONLY assertion in > /openjdk-ecj/hotspot/src/share/vm/interpreter/bytecodeInterpreter.cpp:424 > are valid for shark or should i simply ignore it? That one's definitely important. If it fails then your stack is corrupted. Cheers, Gary From xerxes at zafena.se Tue Apr 14 06:55:16 2009 From: xerxes at zafena.se (=?ISO-8859-1?Q?Xerxes_R=E5nby?=) Date: Tue, 14 Apr 2009 15:55:16 +0200 Subject: [patch] shark + assertions + llvm2.6 on X86 and ARM Message-ID: <49E495C4.90604@zafena.se> Cheers I have been playing with Shark combined with the recent llvm (pre2.6) svn trunk on ARM during the easter weekend: If someone want to try to improve shark and llvm i have attached some patches to use on icedtea6 * mixtec-hacks.patch : tweaked version of Garys mixtec hacks patch to apply on current icedtea tip. it enables assertions and makes a nice debuggable build. original mixtec-hacks fetched from http://gbenson.net/wp-content/uploads/2008/08/mixtec-hacks.patch * sharkCompiler_fnmatch.patch : prevents a compile error when compiling using assertions on X86 /home/xerxes/icedtea6/openjdk-ecj/hotspot/src/share/vm/shark/sharkCompiler.cpp:152: error: 'fnmatch' was not declared in this scope * llvm-2.6-compat-patch : patches shark to compile against current llvm svn trunk (pre2.6) rev 69038 * On ARM I have also applied the Shark reroute LLVM atomic intrinsics to Zero patch found in: http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2009-March/005255.html Now for some demonstrations of all the current fun you can have using shark on ARM: root at overo:/home/xerxes/shark_java_test/success/Hello# java -version java version "1.6.0_0" OpenJDK Runtime Environment (build 1.6.0_0-b14) OpenJDK Shark VM (build 14.0-b08-product, mixed mode) root at overo:/home/xerxes/shark_java_test/success/Hello# java -XX:+PrintCompilation -XX:+SharkTraceInstalls -XX:+VerifyBeforeGC Hello [Verifying threads permgen tenured generation def new generation remset ref_proc syms strs zone dict hand C-heap ] 1 java.lang.String::hashCode (60 bytes) [0x6799a010-0x6799a2c8): java.lang.String::hashCode (696 bytes code) Hello World! Hello World works and shark does insert the jited code. Nice :) Running something less trivial like java -X root at overo:/home/xerxes/shark_java_test/success/Hello# java -XX:+PrintCompilation -XX:+SharkTraceInstalls -XX:+VerifyBeforeGC -X [Verifying threads permgen tenured generation def new generation remset ref_proc syms strs zone dict hand C-heap ] 1 java.lang.String::hashCode (60 bytes) [0x6799a010-0x6799a2c8): java.lang.String::hashCode (696 bytes code) 2 java.lang.String::charAt (33 bytes) [0x6799a2d0-0x6799a4f4): java.lang.String::charAt (548 bytes code) 3 ! sun.nio.cs.US_ASCII$Encoder::encodeArrayLoop (279 bytes) [0x6799a500-0x6799bbf4): sun.nio.cs.US_ASCII$Encoder::encodeArrayLoop (5876 bytes code) 4 ! java.io.BufferedReader::readLine (304 bytes) [0x6799bc00-0x6799cb84): java.io.BufferedReader::readLine (3972 bytes code) 5 ! sun.nio.cs.US_ASCII$Decoder::decodeArrayLoop (241 bytes) [0x6799cb90-0x6799d9d0): sun.nio.cs.US_ASCII$Decoder::decodeArrayLoop (3648 bytes code) 6 java.lang.String::equals (88 bytes) [0x6799d9e0-0x6799e268): java.lang.String::equals (2184 bytes code) 7 java.lang.String::indexOf (151 bytes) [0x6799e270-0x6799e6a0): java.lang.String::indexOf (1072 bytes code) 8 java.lang.String::lastIndexOf (156 bytes) [0x6799e6b0-0x6799ea68): java.lang.String::lastIndexOf (952 bytes code) 9 java.util.Properties$LineReader::readLine (452 bytes) [0x6799ea70-0x6799fa30): java.util.Properties$LineReader::readLine (4032 bytes code) 10 java.util.Properties::loadConvert (505 bytes) [0x6799fa40-0x679a06c8): java.util.Properties::loadConvert (3208 bytes code) # To suppress the following error report, specify this argument # after -XX: or in .hotspotrc: SuppressErrorAt=/bytecodeInterpreter.cpp:854 # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (/usr/src/openembedded/overo/tmp/work/armv7a-angstrom-linux-gnueabi/openjdk-6-shark-jre-6b14-r3/icedtea6-1.4.1+hg20090912/openjdk/hotspot/src/share/vm/interpreter/bytecodeInterpreter.cpp:854), pid=14277, tid=1090688144 # Error: assert(topOfStack < istate->stack_base(),"Stack underrun") # # Java VM: OpenJDK Shark VM (14.0-b08-product mixed mode linux-arm ) # Distribution: Built on Ubuntu 8.04.2 # An error report file with more information is saved as: # /home/xerxes/shark_java_test/success/Hello/hs_err_pid14277.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 # Current thread is 1090688144 Dumping core ... Aborted root at overo:/home/xerxes/shark_java_test/success/Hello# try again... root at overo:/home/xerxes/shark_java_test/success/Hello# java -XX:SuppressErrorAt=/bytecodeInterpreter.cpp:854 -X # To suppress the following error report, specify this argument # after -XX: or in .hotspotrc: SuppressErrorAt=/linkResolver.cpp:71 # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (/usr/src/openembedded/overo/tmp/work/armv7a-angstrom-linux-gnueabi/openjdk-6-shark-jre-6b14-r3/icedtea6-1.4.1+hg20090912/openjdk/hotspot/src/share/vm/interpreter/linkResolver.cpp:71), pid=14307, tid=1090688144 # Error: assert(resolved_method->signature() == selected_method->signature(),"signatures must correspond") # # Java VM: OpenJDK Shark VM (14.0-b08-product mixed mode linux-arm ) # Distribution: Built on Ubuntu 8.04.2 # An error report file with more information is saved as: # /home/xerxes/shark_java_test/success/Hello/hs_err_pid14307.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 # Current thread is 1090688144 Dumping core ... Aborted try again... root at overo:/home/xerxes/shark_java_test/success/Hello# java -XX:SuppressErrorAt=/bytecodeInterpreter.cpp:854 -XX:SuppressErrorAt=/linkResolver.cpp:71 -X -Xmixed mixed mode execution (default) -Xint interpreted mode execution only -Xbootclasspath: set search path for bootstrap classes and resources -Xbootclasspath/a: append to end of bootstrap class path -Xbootclasspath/p: prepend in front of bootstrap class path -Xnoclassgc disable class garbage collection -Xincgc enable incremental garbage collection -Xloggc: log GC status to a file with time stamps -Xbatch disable background compilation -Xms set initial Java heap size -Xmx set maximum Java heap size -Xss set java thread stack size -Xprof output cpu profiling data -Xfuture enable strictest checks, anticipating future default -Xrs reduce use of OS signals by Java/VM (see documentation) -Xcheck:jni perform additional checks for JNI functions -Xshare:off do not attempt to use shared class data -Xshare:auto use shared class data if possible (default) -Xshare:on require using shared class data, otherwise fail. The -X options are non-standard and subject to change without notice. root at overo:/home/xerxes/shark_java_test/success/Hello# echo $? 0 root at overo:/home/xerxes/shark_java_test/success/Hello# ... ok we try again this time using all the nice options like -XX:+PrintCompilation -XX:+SharkTraceInstalls -XX:+VerifyBeforeGC and have fun of observing all strange errors in llvm: root at overo:/home/xerxes/shark_java_test/success/Hello# java -XX:SuppressErrorAt=/bytecodeInterpreter.cpp:854 -XX:SuppressErrorAt=/linkResolver.cpp:71 -XX:+PrintCompilation -XX:+SharkTraceInstalls -XX:+VerifyBeforeGC -X [Verifying threads permgen tenured generation def new generation remset ref_proc syms strs zone dict hand C-heap ] 1 java.lang.String::hashCode (60 bytes) [0x6799a010-0x6799a2c8): java.lang.String::hashCode (696 bytes code) 2 java.lang.String::charAt (33 bytes) [0x6799a2d0-0x6799a4f4): java.lang.String::charAt (548 bytes code) 3 ! sun.nio.cs.US_ASCII$Encoder::encodeArrayLoop (279 bytes) [0x6799a500-0x6799bbf4): sun.nio.cs.US_ASCII$Encoder::encodeArrayLoop (5876 bytes code) 4 ! java.io.BufferedReader::readLine (304 bytes) java: /usr/src/openembedded/overo/tmp/work/armv7a-angstrom-linux-gnueabi/llvm2.6-2.5+svnr69038-r2/trunk/lib/ExecutionEngine/JIT/JIT.cpp:518: void llvm::JIT::runJITOnFunctionUnlocked(llvm::Function*, const llvm::MutexGuard&): Assertion `!isAlreadyCodeGenerating && "Error: Recursive compilation detected!"' failed. Stack dump: 0. Running pass 'Linear Scan Register Allocator' on function '@"java.io.BufferedReader::readLine"' Aborted root at overo:/home/xerxes/shark_java_test/success/Hello# If someone want root at overo:/home/xerxes/shark_java_test/success/Hello# java -XX:SuppressErrorAt=/bytecodeInterpreter.cpp:854 -XX:SuppressErrorAt=/linkResolver.cpp:71 -XX:+Pr intCompilation -XX:+SharkTraceInstalls -XX:+VerifyBeforeGC -X [Verifying threads permgen tenured generation def new generation remset ref_proc syms strs zone dict hand C-heap ] 1 java.lang.String::hashCode (60 bytes) [0x6799a010-0x6799a2c8): java.lang.String::hashCode (696 bytes code) 2 java.lang.String::charAt (33 bytes) [0x6799a2d0-0x6799a4f4): java.lang.String::charAt (548 bytes code) 3 ! sun.nio.cs.US_ASCII$Encoder::encodeArrayLoop (279 bytes) [0x6799a500-0x6799bbf4): sun.nio.cs.US_ASCII$Encoder::encodeArrayLoop (5876 bytes code) 4 ! java.io.BufferedReader::readLine (304 bytes) java: /usr/src/openembedded/overo/tmp/work/armv7a-angstrom-linux-gnueabi/llvm2.6-2.5+svnr69038-r2/trunk/lib/ExecutionEngine/JIT/JIT.cpp:518: void llvm::JIT::runJITOnFunctionUnlocked(llvm::Function*, const llvm::MutexGuard&): Assertion `!isAlreadyCodeGenerating && "Error: Recursive compilation detected!"' failed. Stack dump: 0. Running pass 'Linear Scan Register Allocator' on function '@"java.io.BufferedReader::readLine"' Aborted root at overo:/home/xerxes/shark_java_test/success/Hello# On X86 the assertions reports that Shark have some stack issues: http://mail.openjdk.java.net/pipermail/zero-dev/2009-April/000074.html Cheers and have a great day! Xerxes -------------- next part -------------- A non-text attachment was scrubbed... Name: mixtec-hacks.patch Type: text/x-patch Size: 5155 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/zero-dev/attachments/20090414/d01c87fc/attachment.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: llvm-2.6-compat.patch Type: text/x-patch Size: 2240 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/zero-dev/attachments/20090414/d01c87fc/attachment-0001.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: sharkCompiler_fnmatch.patch Type: text/x-patch Size: 397 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/zero-dev/attachments/20090414/d01c87fc/attachment-0002.bin From xerxes at zafena.se Tue Apr 14 09:54:15 2009 From: xerxes at zafena.se (=?ISO-8859-1?Q?Xerxes_R=E5nby?=) Date: Tue, 14 Apr 2009 18:54:15 +0200 Subject: shark + assertions + llvm2.6 In-Reply-To: <20090414131146.GD3268@redhat.com> References: <49E47B8D.2030900@zafena.se> <20090414131146.GD3268@redhat.com> Message-ID: <49E4BFB7.2010104@zafena.se> Den 2009-04-14 15:11, Gary Benson skrev: > Hi Xerces, > > Xerxes R?nby wrote: > >> I tested building a debuggable shark with assertions enabled using >> the current llvm 2.6 svn trunk on X86. >> >> I have one assertion that fails when running trivial stuff like java >> -version >> I wanted to know your opinion if this IA32_ONLY assertion in >> /openjdk-ecj/hotspot/src/share/vm/interpreter/bytecodeInterpreter.cpp:424 >> are valid for shark or should i simply ignore it? >> > > That one's definitely important. If it fails then your stack is > corrupted. > > Cheers, > Gary > Thanks, i will look for what corrupts my stack then. Do you know the reason why this assertion is only enabled for IA32 ? Would not all hotspots using shark or not benefit for checking this assertions as well? Cheers Xerxes -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/zero-dev/attachments/20090414/f4f6039b/attachment.html From gbenson at redhat.com Wed Apr 15 03:15:48 2009 From: gbenson at redhat.com (Gary Benson) Date: Wed, 15 Apr 2009 11:15:48 +0100 Subject: shark + assertions + llvm2.6 In-Reply-To: <49E4BFB7.2010104@zafena.se> References: <49E47B8D.2030900@zafena.se> <20090414131146.GD3268@redhat.com> <49E4BFB7.2010104@zafena.se> Message-ID: <20090415101548.GB3192@redhat.com> Xerxes R?nby wrote: > Den 2009-04-14 15:11, Gary Benson skrev: > > Xerxes R?nby wrote: > > > I tested building a debuggable shark with assertions enabled using > > > the current llvm 2.6 svn trunk on X86. > > > > > > I have one assertion that fails when running trivial stuff like java > > > -version > > > I wanted to know your opinion if this IA32_ONLY assertion in > > > /openjdk-ecj/hotspot/src/share/vm/interpreter/bytecodeInterpreter.cpp:424 > > > are valid for shark or should i simply ignore it? > > > > > > > That one's definitely important. If it fails then your stack is > > corrupted. > > Thanks, i will look for what corrupts my stack then. > > Do you know the reason why this assertion is only enabled for IA32 ? > > Would not all hotspots using shark or not benefit for checking this > assertions as well? Hmmm, I'm confused, I thought it was the assertion before the IA32 one that was firing, but it's not is it. Are you building on IA32? If not, there's something wrong with your build! But in any case, I don't think that IA32_ONLY assertion is valid on Shark, so it should be surrounded by an #ifdef SHARK ... #endif // SHARK. Cheers, Gary -- http://gbenson.net/ From xerxes at zafena.se Wed Apr 15 03:43:28 2009 From: xerxes at zafena.se (=?ISO-8859-1?Q?Xerxes_R=E5nby?=) Date: Wed, 15 Apr 2009 12:43:28 +0200 Subject: shark + assertions + llvm2.6 [PATCH] shark IA32 In-Reply-To: <20090415101548.GB3192@redhat.com> References: <49E47B8D.2030900@zafena.se> <20090414131146.GD3268@redhat.com> <49E4BFB7.2010104@zafena.se> <20090415101548.GB3192@redhat.com> Message-ID: <49E5BA50.5000206@zafena.se> Gary Benson skrev: > Xerxes R?nby wrote: > >> Den 2009-04-14 15:11, Gary Benson skrev: >> >>> Xerxes R?nby wrote: >>> >>>> I tested building a debuggable shark with assertions enabled using >>>> the current llvm 2.6 svn trunk on X86. >>>> >>>> I have one assertion that fails when running trivial stuff like java >>>> -version >>>> I wanted to know your opinion if this IA32_ONLY assertion in >>>> /openjdk-ecj/hotspot/src/share/vm/interpreter/bytecodeInterpreter.cpp:424 >>>> are valid for shark or should i simply ignore it? >>>> >>>> >>> That one's definitely important. If it fails then your stack is >>> corrupted. >>> >> Thanks, i will look for what corrupts my stack then. >> >> Do you know the reason why this assertion is only enabled for IA32 ? >> >> Would not all hotspots using shark or not benefit for checking this >> assertions as well? >> > > Hmmm, I'm confused, I thought it was the assertion before the IA32 > one that was firing, but it's not is it. Are you building on IA32? > If not, there's something wrong with your build! But in any case, > I don't think that IA32_ONLY assertion is valid on Shark, so it > should be surrounded by an #ifdef SHARK ... #endif // SHARK. > > Cheers, > Gary > > I was building on a IA32 machine, more precisely i was building shark on a Intel(R) Core(TM)2 Quad CPU Q9550 @ 2.83GHz This is a IA32 CPU in my world so i think the build got that one right. I have attached a patch against Icedtea6 as a remedy for this problem using Shark on IA32 Cheers Xerxes -------------- next part -------------- A non-text attachment was scrubbed... Name: hg_diff_icedtea-ia32-hotspot-shark.patch Type: text/x-patch Size: 1183 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/zero-dev/attachments/20090415/01d9e3ea/attachment.bin From gbenson at redhat.com Wed Apr 15 04:49:34 2009 From: gbenson at redhat.com (Gary Benson) Date: Wed, 15 Apr 2009 12:49:34 +0100 Subject: shark + assertions + llvm2.6 [PATCH] shark IA32 In-Reply-To: <49E5BA50.5000206@zafena.se> References: <49E47B8D.2030900@zafena.se> <20090414131146.GD3268@redhat.com> <49E4BFB7.2010104@zafena.se> <20090415101548.GB3192@redhat.com> <49E5BA50.5000206@zafena.se> Message-ID: <20090415114934.GC3192@redhat.com> Xerxes R?nby wrote: > Gary Benson skrev: > > Hmmm, I'm confused, I thought it was the assertion before the IA32 > > one that was firing, but it's not is it. Are you building on > > IA32? If not, there's something wrong with your build! But in > > any case, I don't think that IA32_ONLY assertion is valid on > > Shark, so it should be surrounded by an #ifdef SHARK ... #endif // > > SHARK. > > I was building on a IA32 machine, more precisely i was building > shark on a > Intel(R) Core(TM)2 Quad CPU Q9550 @ 2.83GHz > This is a IA32 CPU in my world so i think the build got that one > right. > > I have attached a patch against Icedtea6 as a remedy for this > problem using Shark on IA32 I added this chunk to icedtea-zero.patch. It's a Zero thing really, not Shark, my brain's not working today ;) Cheers, Gary -- http://gbenson.net/ From xerxes at zafena.se Thu Apr 23 02:42:01 2009 From: xerxes at zafena.se (=?ISO-8859-1?Q?Xerxes_R=E5nby?=) Date: Thu, 23 Apr 2009 11:42:01 +0200 Subject: [patch] Shark reroute LLVM atomic intrinsics to Zero (new ARM specific patch) In-Reply-To: <20090407095101.GB3204@redhat.com> References: <49CE9FD0.6030202@zafena.se> <49CEACD7.8040203@gmx.net> <49CFA59F.4030509@redhat.com> <49D01DB8.9050007@zafena.se> <49D08F90.8020904@redhat.com> <49D09E0F.40802@zafena.se> <20090406125837.GF3260@redhat.com> <49DA10EB.9080704@gatech.edu> <20090407095101.GB3204@redhat.com> Message-ID: <49F037E9.2040806@zafena.se> Gary Benson skrev: > Ok, so there's no way around this. > > I'm thinking is that ARM is a special case here: you could implement > SharkBuilder::CreateCmpxchg* on ARM by inlining arm_compare_and_swap > from atomic_linux_zero.inline.hpp. That wouldn't require any LLVM > modifications, and it wouldn't be any slower than a "real" > implementation of llvm.atomic.cmp.swap.i32 because either way the > atomic part is handled by the call to __kernel_cmpxchg so the > generated code would be the same. > > Obviously it would be preferable for this code to be in LLVM rather > than in Shark, but I know that implementing it in LLVM won't be quick > or easy so I can live with a bit of clutter in Shark for this. > > What I'm not happy with is the idea of a generic solution that would > perform a function call on platforms that don't require one, because > that _would_ be slower than an implementation of llvm.atomic.cmp.swap. > For platforms that have instructions to do this I'm going to insist > people bite the bullet and implement the intrinsic. > > Cheers, > Gary > > Hi Gary i have attached a reworked patch which only apply for ARM with appropriate comments so that new developers will know whats going on and also know what can be removed once the LLVM implementation are in place. Cheers, Xerxes -------------- next part -------------- A non-text attachment was scrubbed... Name: icedtea6_sharkBuilder_arm_atomic.patch Type: text/x-patch Size: 2526 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/zero-dev/attachments/20090423/3d041a4d/attachment.bin From xerxes at zafena.se Thu Apr 23 02:47:24 2009 From: xerxes at zafena.se (=?ISO-8859-1?Q?Xerxes_R=E5nby?=) Date: Thu, 23 Apr 2009 11:47:24 +0200 Subject: [patch] Zero and Shark improved ARM memory barrier implementation Message-ID: <49F0392C.2020900@zafena.se> I have attached a improved version of the memory barrier functionality for the ARM arch used in Zero and Shark that makes use of the ARM kernel memory barrier helper. Cheers, and have a great day! Xerxes -------------- next part -------------- A non-text attachment was scrubbed... Name: icedtea6_sharkBuilder_arm_memory_barrier.patch Type: text/x-patch Size: 1224 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/zero-dev/attachments/20090423/8c34765e/attachment.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: icedtea6_zero_arm_memory_barrier.patch Type: text/x-patch Size: 1448 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/zero-dev/attachments/20090423/8c34765e/attachment-0001.bin From gbenson at redhat.com Thu Apr 23 03:39:50 2009 From: gbenson at redhat.com (Gary Benson) Date: Thu, 23 Apr 2009 11:39:50 +0100 Subject: [patch] Shark reroute LLVM atomic intrinsics to Zero (new ARM specific patch) In-Reply-To: <49F037E9.2040806@zafena.se> References: <49CE9FD0.6030202@zafena.se> <49CEACD7.8040203@gmx.net> <49CFA59F.4030509@redhat.com> <49D01DB8.9050007@zafena.se> <49D08F90.8020904@redhat.com> <49D09E0F.40802@zafena.se> <20090406125837.GF3260@redhat.com> <49DA10EB.9080704@gatech.edu> <20090407095101.GB3204@redhat.com> <49F037E9.2040806@zafena.se> Message-ID: <20090423103949.GB3221@redhat.com> Xerxes R?nby wrote: > Hi Gary i have attached a reworked patch which only apply for ARM > with appropriate comments so that new developers will know whats > going on and also know what can be removed once the LLVM > implementation are in place. Looks good. Do you have commit access? Cheers, Gary -- http://gbenson.net/ From xerxes at zafena.se Thu Apr 23 03:43:23 2009 From: xerxes at zafena.se (=?ISO-8859-1?Q?Xerxes_R=E5nby?=) Date: Thu, 23 Apr 2009 12:43:23 +0200 Subject: [patch] Shark reroute LLVM atomic intrinsics to Zero (new ARM specific patch) In-Reply-To: <20090423103949.GB3221@redhat.com> References: <49CE9FD0.6030202@zafena.se> <49CEACD7.8040203@gmx.net> <49CFA59F.4030509@redhat.com> <49D01DB8.9050007@zafena.se> <49D08F90.8020904@redhat.com> <49D09E0F.40802@zafena.se> <20090406125837.GF3260@redhat.com> <49DA10EB.9080704@gatech.edu> <20090407095101.GB3204@redhat.com> <49F037E9.2040806@zafena.se> <20090423103949.GB3221@redhat.com> Message-ID: <49F0464B.8050104@zafena.se> Gary Benson skrev: > Xerxes R?nby wrote: > >> Hi Gary i have attached a reworked patch which only apply for ARM >> with appropriate comments so that new developers will know whats >> going on and also know what can be removed once the LLVM >> implementation are in place. >> > > Looks good. Do you have commit access? > > Cheers, > Gary > > No, I do not have commit access to the icedtea repositorys. Could this be arranged? Xerxes From gbenson at redhat.com Thu Apr 23 03:43:57 2009 From: gbenson at redhat.com (Gary Benson) Date: Thu, 23 Apr 2009 11:43:57 +0100 Subject: [patch] Zero and Shark improved ARM memory barrier implementation In-Reply-To: <49F0392C.2020900@zafena.se> References: <49F0392C.2020900@zafena.se> Message-ID: <20090423104357.GC3221@redhat.com> Xerxes R?nby wrote: > +#ifdef ARM > + make_function( > + 0xffff0fa0, > + type, > + "__kernel_dmb")); > +#else Can you add a little "// __kernel_dmb" after the 0xffff0fa0? > inline void OrderAccess::acquire() > { > +#ifdef ARM > + __kernel_dmb(); > +#else > READ_MEM_BARRIER; > +#endif // ARM > } > > inline void OrderAccess::release() > { > +#ifdef ARM > + __kernel_dmb(); > +#else > WRITE_MEM_BARRIER; > +#endif // ARM > } For these two I'd prefer if you did something like: #ifdef ARM #define READ_MEM_BARRIER __kernel_dmb() #define WRITE_MEM_BARRIER __kernel_dmb() #else ... PPC, etc > inline void OrderAccess::fence() > { > +#ifdef ARM > + __kernel_dmb(); > +#else > __sync_synchronize(); > +#endif // ARM > } For this one, can we do it like acquire() and release()? Define FULL_MEM_BARRIER as either __kernel_dmb() or __sync_synchronize() in the same block that defines the other barrier macros? Cheers, Gary -- http://gbenson.net/ From gbenson at redhat.com Thu Apr 23 04:00:05 2009 From: gbenson at redhat.com (Gary Benson) Date: Thu, 23 Apr 2009 12:00:05 +0100 Subject: [patch] Shark reroute LLVM atomic intrinsics to Zero (new ARM specific patch) In-Reply-To: <49F0464B.8050104@zafena.se> References: <49CFA59F.4030509@redhat.com> <49D01DB8.9050007@zafena.se> <49D08F90.8020904@redhat.com> <49D09E0F.40802@zafena.se> <20090406125837.GF3260@redhat.com> <49DA10EB.9080704@gatech.edu> <20090407095101.GB3204@redhat.com> <49F037E9.2040806@zafena.se> <20090423103949.GB3221@redhat.com> <49F0464B.8050104@zafena.se> Message-ID: <20090423110005.GE3221@redhat.com> Xerxes R?nby wrote: > Gary Benson skrev: > > Xerxes R?nby wrote: > > > Hi Gary i have attached a reworked patch which only apply for > > > ARM with appropriate comments so that new developers will know > > > whats going on and also know what can be removed once the LLVM > > > implementation are in place. > > > > Looks good. Do you have commit access? > > No, I do not have commit access to the icedtea repositorys. > Could this be arranged? I certainly wouldn't have a problem with it :) Mark Wielaard is the man to sort you out if nobody else objects. By the way, what's your SCA status these days? Cheers, Gary -- http://gbenson.net/ From xerxes at zafena.se Thu Apr 23 04:16:19 2009 From: xerxes at zafena.se (=?ISO-8859-1?Q?Xerxes_R=E5nby?=) Date: Thu, 23 Apr 2009 13:16:19 +0200 Subject: [patch] Zero and Shark improved ARM memory barrier implementation In-Reply-To: <20090423104357.GC3221@redhat.com> References: <49F0392C.2020900@zafena.se> <20090423104357.GC3221@redhat.com> Message-ID: <49F04E03.8000401@zafena.se> Gary Benson skrev: > Xerxes R?nby wrote: > >> +#ifdef ARM >> + make_function( >> + 0xffff0fa0, >> + type, >> + "__kernel_dmb")); >> +#else >> > > Can you add a little "// __kernel_dmb" after the 0xffff0fa0? > > >> inline void OrderAccess::acquire() >> { >> +#ifdef ARM >> + __kernel_dmb(); >> +#else >> READ_MEM_BARRIER; >> +#endif // ARM >> } >> >> inline void OrderAccess::release() >> { >> +#ifdef ARM >> + __kernel_dmb(); >> +#else >> WRITE_MEM_BARRIER; >> +#endif // ARM >> } >> > > For these two I'd prefer if you did something like: > > #ifdef ARM > #define READ_MEM_BARRIER __kernel_dmb() > #define WRITE_MEM_BARRIER __kernel_dmb() > #else > ... PPC, etc > > >> inline void OrderAccess::fence() >> { >> +#ifdef ARM >> + __kernel_dmb(); >> +#else >> __sync_synchronize(); >> +#endif // ARM >> } >> > > For this one, can we do it like acquire() and release()? Define > FULL_MEM_BARRIER as either __kernel_dmb() or __sync_synchronize() > in the same block that defines the other barrier macros? > > Cheers, > Gary > > Thank you gary for the review. I have updated the two patches accordingly. Cheers, Xerxes -------------- next part -------------- A non-text attachment was scrubbed... Name: icedtea6_sharkBuilder_arm_memory_barrier.patch Type: text/x-patch Size: 1240 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/zero-dev/attachments/20090423/fdf4ad12/attachment.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: icedtea6_zero_arm_memory_barrier.patch Type: text/x-patch Size: 1461 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/zero-dev/attachments/20090423/fdf4ad12/attachment-0001.bin From gbenson at redhat.com Thu Apr 23 04:47:18 2009 From: gbenson at redhat.com (Gary Benson) Date: Thu, 23 Apr 2009 12:47:18 +0100 Subject: [patch] Zero and Shark improved ARM memory barrier implementation In-Reply-To: <49F04E03.8000401@zafena.se> References: <49F0392C.2020900@zafena.se> <20090423104357.GC3221@redhat.com> <49F04E03.8000401@zafena.se> Message-ID: <20090423114718.GG3221@redhat.com> Xerxes R?nby wrote: > Thank you gary for the review. > I have updated the two patches accordingly. I'll look forward to seeing you commit them :) Cheers, Gary -- http://gbenson.net/ From xerxes at zafena.se Thu Apr 23 08:06:50 2009 From: xerxes at zafena.se (=?ISO-8859-1?Q?Xerxes_R=E5nby?=) Date: Thu, 23 Apr 2009 17:06:50 +0200 Subject: [patch] Shark reroute LLVM atomic intrinsics to Zero (new ARM specific patch) In-Reply-To: <49F0464B.8050104@zafena.se> References: <49CE9FD0.6030202@zafena.se> <49CEACD7.8040203@gmx.net> <49CFA59F.4030509@redhat.com> <49D01DB8.9050007@zafena.se> <49D08F90.8020904@redhat.com> <49D09E0F.40802@zafena.se> <20090406125837.GF3260@redhat.com> <49DA10EB.9080704@gatech.edu> <20090407095101.GB3204@redhat.com> <49F037E9.2040806@zafena.se> <20090423103949.GB3221@redhat.com> <49F0464B.8050104@zafena.se> Message-ID: <49F0840A.70308@zafena.se> Xerxes R?nby skrev: > Gary Benson skrev: >> Xerxes R?nby wrote: >> >>> Hi Gary i have attached a reworked patch which only apply for ARM >>> with appropriate comments so that new developers will know whats >>> going on and also know what can be removed once the LLVM >>> implementation are in place. >>> >> >> Looks good. Do you have commit access? >> >> Cheers, >> Gary >> >> > No, I do not have commit access to the icedtea repositorys. > Could this be arranged? > > Xerxes Commited! http://icedtea.classpath.org/hg/icedtea6/rev/c1db7ce41839 Cheers Xerxes From xerxes at zafena.se Thu Apr 23 08:07:45 2009 From: xerxes at zafena.se (=?ISO-8859-1?Q?Xerxes_R=E5nby?=) Date: Thu, 23 Apr 2009 17:07:45 +0200 Subject: [patch] Zero and Shark improved ARM memory barrier implementation In-Reply-To: <20090423114718.GG3221@redhat.com> References: <49F0392C.2020900@zafena.se> <20090423104357.GC3221@redhat.com> <49F04E03.8000401@zafena.se> <20090423114718.GG3221@redhat.com> Message-ID: <49F08441.1010600@zafena.se> Gary Benson skrev: > Xerxes R?nby wrote: > >> Thank you gary for the review. >> I have updated the two patches accordingly. >> > > I'll look forward to seeing you commit them :) > > Cheers, > Gary > > http://icedtea.classpath.org/hg/icedtea6/rev/7c7835fceadc Enjoy! Xerxes From gbenson at redhat.com Thu Apr 23 08:17:24 2009 From: gbenson at redhat.com (Gary Benson) Date: Thu, 23 Apr 2009 16:17:24 +0100 Subject: [patch] Shark reroute LLVM atomic intrinsics to Zero (new ARM specific patch) In-Reply-To: <49F0840A.70308@zafena.se> References: <49D01DB8.9050007@zafena.se> <49D08F90.8020904@redhat.com> <49D09E0F.40802@zafena.se> <20090406125837.GF3260@redhat.com> <49DA10EB.9080704@gatech.edu> <20090407095101.GB3204@redhat.com> <49F037E9.2040806@zafena.se> <20090423103949.GB3221@redhat.com> <49F0464B.8050104@zafena.se> <49F0840A.70308@zafena.se> Message-ID: <20090423151724.GH3221@redhat.com> Xerxes R?nby wrote: > Xerxes R?nby skrev: > > Gary Benson skrev: > > > Xerxes R?nby wrote: > > > > Hi Gary i have attached a reworked patch which only apply for > > > > ARM with appropriate comments so that new developers will know > > > > whats going on and also know what can be removed once the LLVM > > > > implementation are in place. > > > > > > Looks good. Do you have commit access? > > > No, I do not have commit access to the icedtea repositorys. > > Could this be arranged? > > Commited! > http://icedtea.classpath.org/hg/icedtea6/rev/c1db7ce41839 Sweet :D Cheers, Gary -- http://gbenson.net/ From gbenson at redhat.com Mon Apr 27 02:48:43 2009 From: gbenson at redhat.com (Gary Benson) Date: Mon, 27 Apr 2009 10:48:43 +0100 Subject: Shark bugfix Message-ID: <20090427094843.GA3196@redhat.com> Hi all, This patch fixes a bug in Shark where the blocks associated with states were not the same as the blocks the states were associated with. I can't figure out how it worked like this, but t wasn't causing any problems, just confusing me, so I fixed it. Cheers, Gary -- http://gbenson.net/ -------------- next part -------------- diff -r ac377bd5008f -r db61663b8232 ChangeLog --- a/ChangeLog Fri Apr 24 14:09:22 2009 -0400 +++ b/ChangeLog Mon Apr 27 05:35:03 2009 -0400 @@ -1,3 +1,14 @@ +2009-04-27 Gary Benson + + * ports/hotspot/src/share/vm/shark/sharkState.hpp + (SharkState::SharkState): Add explicit block argument. + (SharkState::copy): Pass block to constructor. + * ports/hotspot/src/share/vm/shark/sharkState.cpp + (SharkState::SharkState): Add explicit block argument. + * ports/hotspot/src/share/vm/shark/sharkBlock.cpp + (SharkBlock::initial_current_state): Pass block to + SharkState constructor. + 2009-04-24 Lillian Angel Fixes #497191 diff -r ac377bd5008f -r db61663b8232 ports/hotspot/src/share/vm/shark/sharkBlock.cpp --- a/ports/hotspot/src/share/vm/shark/sharkBlock.cpp Fri Apr 24 14:09:22 2009 -0400 +++ b/ports/hotspot/src/share/vm/shark/sharkBlock.cpp Mon Apr 27 05:35:03 2009 -0400 @@ -853,7 +853,7 @@ SharkState* SharkBlock::initial_current_state() { - return new SharkState(entry_state()); + return new SharkState(this, entry_state()); } int SharkBlock::switch_default_dest() diff -r ac377bd5008f -r db61663b8232 ports/hotspot/src/share/vm/shark/sharkState.cpp --- a/ports/hotspot/src/share/vm/shark/sharkState.cpp Fri Apr 24 14:09:22 2009 -0400 +++ b/ports/hotspot/src/share/vm/shark/sharkState.cpp Mon Apr 27 05:35:03 2009 -0400 @@ -38,8 +38,8 @@ initialize(NULL); } -SharkState::SharkState(const SharkState* state) - : _block(state->block()), +SharkState::SharkState(SharkBlock* block, const SharkState* state) + : _block(block), _function(state->function()), _method(state->method()) { diff -r ac377bd5008f -r db61663b8232 ports/hotspot/src/share/vm/shark/sharkState.hpp --- a/ports/hotspot/src/share/vm/shark/sharkState.hpp Fri Apr 24 14:09:22 2009 -0400 +++ b/ports/hotspot/src/share/vm/shark/sharkState.hpp Mon Apr 27 05:35:03 2009 -0400 @@ -32,7 +32,7 @@ SharkState(SharkBlock* block, SharkFunction* function = NULL, llvm::Value* method = NULL); - SharkState(const SharkState* state); + SharkState(SharkBlock* block, const SharkState* state); private: void initialize(const SharkState* state); @@ -137,7 +137,7 @@ public: SharkState* copy() const { - return new SharkState(this); + return new SharkState(block(), this); } void merge(SharkState* other, llvm::BasicBlock* other_block, From gbenson at redhat.com Mon Apr 27 04:22:39 2009 From: gbenson at redhat.com (Gary Benson) Date: Mon, 27 Apr 2009 12:22:39 +0100 Subject: Deoptimization fix for Shark Message-ID: <20090427112239.GB3196@redhat.com> Hi all, Deoptimization in HotSpot is where you assume you can optimize code in a certain way, inserting a runtime check called a trap which will force the method to be recompiled if the assumption failed. Shark's traps were firing early, meaning that sometimes they were firing when they didn't need to and causing methods to be recompiled endlessly. This commit fixes. Cheers, Gary -- http://gbenson.net/ -------------- next part -------------- diff -r db61663b8232 -r 010cb02d0958 ChangeLog --- a/ChangeLog Mon Apr 27 05:35:03 2009 -0400 +++ b/ChangeLog Mon Apr 27 07:13:07 2009 -0400 @@ -1,3 +1,34 @@ +2009-04-27 Gary Benson + + * ports/hotspot/src/share/vm/shark/sharkBlock.hpp + (SharkBlock::has_trap): New method. + (SharkBlock::trap_request): Likewise. + (SharkBlock::trap_bci): Likewise. + (SharkBlock::do_trap): Likewise. + * ports/hotspot/src/share/vm/shark/sharkBlock.cpp + (SharkBlock::has_trap): New method. + (SharkBlock::trap_request): Likewise. + (SharkBlock::trap_bci): Likewise. + (SharkBlock::do_trap): Likewise. + (SharkBlock::parse_bytecode): Handle traps. + * ports/hotspot/src/share/vm/shark/sharkTopLevelBlock.hpp + (SharkTopLevelBlock::_has_trap): New field. + (SharkTopLevelBlock::_trap_bci): Likewise. + (SharkTopLevelBlock::has-trap): Updated. + (SharkTopLevelBlock::trap_request): Likewise. + (SharkTopLevelBlock::set_trap): New method. + (SharkTopLevelBlock::trap_bci): Likewise. + (SharkTopLevelBlock::do_trap): Likewise. + (SharkTopLevelBlock::scan_for_traps): New prototype. + * ports/hotspot/src/share/vm/shark/sharkTopLevelBlock.cpp + (SharkTopLevelBlock::scan_for_traps): Store trap_bci along + with trap_request, and don't assume that traps found by + typeflow are the first traps in the block. + (SharkTopLevelBlock::enter): Scan for traps, and always + enter exception sucessors. + (SharkTopLevelBlock::emit_IR): Remove old trap handling. + (SharkTopLevelBlock::do_trap): New method. + 2009-04-27 Gary Benson * ports/hotspot/src/share/vm/shark/sharkState.hpp diff -r db61663b8232 -r 010cb02d0958 ports/hotspot/src/share/vm/shark/sharkBlock.cpp --- a/ports/hotspot/src/share/vm/shark/sharkBlock.cpp Mon Apr 27 05:35:03 2009 -0400 +++ b/ports/hotspot/src/share/vm/shark/sharkBlock.cpp Mon Apr 27 07:13:07 2009 -0400 @@ -46,6 +46,11 @@ if (SharkTraceBytecodes) tty->print_cr("%4d: %s", bci(), Bytecodes::name(bc())); + if (has_trap() && trap_bci() == bci()) { + do_trap(trap_request()); + return; + } + if (UseLoopSafepoints) { // XXX if a lcmp is followed by an if_?? then C2 maybe-inserts // the safepoint before the lcmp rather than before the if. @@ -1138,6 +1143,26 @@ ShouldNotCallThis(); } +bool SharkBlock::has_trap() +{ + return false; +} + +int SharkBlock::trap_request() +{ + ShouldNotCallThis(); +} + +int SharkBlock::trap_bci() +{ + ShouldNotCallThis(); +} + +void SharkBlock::do_trap(int trap_request) +{ + ShouldNotCallThis(); +} + Value* SharkBlock::lookup_for_ldc() { ShouldNotCallThis(); diff -r db61663b8232 -r 010cb02d0958 ports/hotspot/src/share/vm/shark/sharkBlock.hpp --- a/ports/hotspot/src/share/vm/shark/sharkBlock.hpp Mon Apr 27 05:35:03 2009 -0400 +++ b/ports/hotspot/src/share/vm/shark/sharkBlock.hpp Mon Apr 27 07:13:07 2009 -0400 @@ -233,6 +233,13 @@ protected: virtual void add_safepoint(); + // Traps + protected: + virtual bool has_trap(); + virtual int trap_request(); + virtual int trap_bci(); + virtual void do_trap(int trap_request); + // ldc* private: void do_ldc() diff -r db61663b8232 -r 010cb02d0958 ports/hotspot/src/share/vm/shark/sharkTopLevelBlock.cpp --- a/ports/hotspot/src/share/vm/shark/sharkTopLevelBlock.cpp Mon Apr 27 05:35:03 2009 -0400 +++ b/ports/hotspot/src/share/vm/shark/sharkTopLevelBlock.cpp Mon Apr 27 07:13:07 2009 -0400 @@ -28,19 +28,14 @@ using namespace llvm; -int SharkTopLevelBlock::scan_for_traps() +void SharkTopLevelBlock::scan_for_traps() { - // If typeflow got one then we're already done - if (ciblock()->has_trap()) { - return Deoptimization::make_trap_request( - Deoptimization::Reason_unloaded, - Deoptimization::Action_reinterpret, - ciblock()->trap_index()); - } + // If typeflow found a trap then don't scan past it + int limit_bci = ciblock()->has_trap() ? ciblock()->trap_bci() : limit(); - // Scan the bytecode + // Scan the bytecode for traps that are always hit iter()->reset_to_bci(start()); - while (iter()->next_bci() < limit()) { + while (iter()->next_bci() < limit_bci) { iter()->next(); ciField *field; @@ -62,9 +57,11 @@ // If the bytecode does not match the field then bail out to // the interpreter to throw an IncompatibleClassChangeError if (is_field == field->is_static()) { - return Deoptimization::make_trap_request( - Deoptimization::Reason_unhandled, - Deoptimization::Action_none); + set_trap( + Deoptimization::make_trap_request( + Deoptimization::Reason_unhandled, + Deoptimization::Action_none), bci()); + return; } // If this is a getfield or putfield then there won't be a @@ -96,9 +93,11 @@ // set up otherwise. if (bc() == Bytecodes::_invokevirtual && !method->is_final_method()) { if (!method->holder()->is_linked()) { - return Deoptimization::make_trap_request( - Deoptimization::Reason_uninitialized, - Deoptimization::Action_reinterpret); + set_trap( + Deoptimization::make_trap_request( + Deoptimization::Reason_uninitialized, + Deoptimization::Action_reinterpret), bci()); + return; } break; } @@ -112,13 +111,24 @@ if (index != -1) { if (!target()->holder()->is_cache_entry_resolved( Bytes::swap_u2(index), bc())) { - return Deoptimization::make_trap_request( - Deoptimization::Reason_uninitialized, - Deoptimization::Action_reinterpret); + set_trap( + Deoptimization::make_trap_request( + Deoptimization::Reason_uninitialized, + Deoptimization::Action_reinterpret), bci()); + return; } } } - return TRAP_NO_TRAPS; + + // Trap if typeflow trapped (and we didn't before) + if (ciblock()->has_trap()) { + set_trap( + Deoptimization::make_trap_request( + Deoptimization::Reason_unloaded, + Deoptimization::Action_reinterpret, + ciblock()->trap_index()), ciblock()->trap_bci()); + return; + } } SharkState* SharkTopLevelBlock::entry_state() @@ -163,13 +173,14 @@ if (!entered()) { _entered = true; + scan_for_traps(); if (!has_trap()) { for (int i = 0; i < num_successors(); i++) { successor(i)->enter(this, false); } - for (int i = 0; i < num_exceptions(); i++) { - exception(i)->enter(this, true); - } + } + for (int i = 0; i < num_exceptions(); i++) { + exception(i)->enter(this, true); } } } @@ -215,25 +226,12 @@ { builder()->SetInsertPoint(entry_block()); - // Handle traps - if (has_trap()) { - iter()->force_bci(start()); - - current_state()->decache_for_trap(); - builder()->CreateCall2( - SharkRuntime::uncommon_trap(), - thread(), - LLVMValue::jint_constant(trap_request())); - builder()->CreateRetVoid(); - return; - } - // Parse the bytecode parse_bytecode(start(), limit()); // If this block falls through to the next then it won't have been // terminated by a bytecode and we have to add the branch ourselves - if (falls_through()) + if (falls_through() && !has_trap()) do_branch(ciTypeFlow::FALL_THROUGH); } @@ -476,6 +474,16 @@ builder()->SetInsertPoint(safepointed); current_state()->merge(orig_state, orig_block, safepointed_block); +} + +void SharkTopLevelBlock::do_trap(int trap_request) +{ + current_state()->decache_for_trap(); + builder()->CreateCall2( + SharkRuntime::uncommon_trap(), + thread(), + LLVMValue::jint_constant(trap_request)); + builder()->CreateRetVoid(); } void SharkTopLevelBlock::call_register_finalizer(Value *receiver) diff -r db61663b8232 -r 010cb02d0958 ports/hotspot/src/share/vm/shark/sharkTopLevelBlock.hpp --- a/ports/hotspot/src/share/vm/shark/sharkTopLevelBlock.hpp Mon Apr 27 05:35:03 2009 -0400 +++ b/ports/hotspot/src/share/vm/shark/sharkTopLevelBlock.hpp Mon Apr 27 07:13:07 2009 -0400 @@ -32,8 +32,8 @@ function->thread()), _function(function), _ciblock(ciblock), - _trap_request(TRAP_UNCHECKED), _entered(false), + _has_trap(false), _needs_phis(false), _entry_state(NULL), _entry_block(NULL) {} @@ -106,26 +106,36 @@ // Traps private: - enum { - TRAP_UNCHECKED = 232323, // > any constant pool index - TRAP_NO_TRAPS - }; - int _trap_request; + bool _has_trap; + int _trap_request; + int _trap_bci; - public: - int trap_request() + void set_trap(int trap_request, int trap_bci) { - if (_trap_request == TRAP_UNCHECKED) - _trap_request = scan_for_traps(); - return _trap_request; - } - bool has_trap() - { - return trap_request() != TRAP_NO_TRAPS; + assert(!has_trap(), "shouldn't have"); + _has_trap = true; + _trap_request = trap_request; + _trap_bci = trap_bci; } private: - int scan_for_traps(); + bool has_trap() + { + return _has_trap; + } + int trap_request() + { + assert(has_trap(), "should have"); + return _trap_request; + } + int trap_bci() + { + assert(has_trap(), "should have"); + return _trap_bci; + } + + private: + void scan_for_traps(); // Entry state private: @@ -293,6 +303,10 @@ private: void add_safepoint(); + // Traps + private: + void do_trap(int trap_request); + // Returns private: void call_register_finalizer(llvm::Value* receiver); From gbenson at redhat.com Tue Apr 28 02:58:34 2009 From: gbenson at redhat.com (Gary Benson) Date: Tue, 28 Apr 2009 10:58:34 +0100 Subject: Improved checkcast and instanceof for Shark Message-ID: <20090428095833.GA5266@redhat.com> Hi all, In Shark, checkcast and instanceof would check if the class they were checking against was loaded, and drop into the runtime if required. This commit moves that check to compile time, deoptimizing if the class isn't loaded. Cheers, Gary -- http://gbenson.net/ -------------- next part -------------- diff -r 9b0b945113de ChangeLog --- a/ChangeLog Mon Apr 27 11:15:01 2009 -0400 +++ b/ChangeLog Tue Apr 28 05:49:34 2009 -0400 @@ -1,3 +1,23 @@ +2009-04-28 Gary Benson + + * patches/hotspot/default/icedtea-shark.patch + (ciInstanceKlass::constant_pool_tag_at): New method. + * ports/hotspot/src/share/vm/shark/sharkTopLevelBlock.hpp + (SharkTopLevelBlock::do_full_instance_check): New method. + (SharkTopLevelBlock::do_trapping_instance_check): Likewise. + * ports/hotspot/src/share/vm/shark/sharkTopLevelBlock.cpp + (SharkTopLevelBlock::do_instance_check): Split. + (SharkTopLevelBlock::do_full_instance_check): New method. + (SharkTopLevelBlock::do_trapping_instance_check): Likewise. + * ports/hotspot/src/share/vm/shark/sharkRuntime.hpp + (SharkRuntime::_resolve_klass): Removed. + (SharkRuntime::resolve_klass): Likewise. + (SharkRuntime::resolve_klass_C): Likewise. + * ports/hotspot/src/share/vm/shark/sharkRuntime.cpp + (SharkRuntime::_resolve_klass): Likewise. + (SharkRuntime::resolve_klass_C): Likewise. + (SharkRuntime::initialize): Removed _resolve_klass init. + 2009-04-27 Deepak Bhole * plugin/icedtea/sun/applet/PluginAppletViewer.java: Unescape " diff -r 9b0b945113de patches/hotspot/default/icedtea-shark.patch --- a/patches/hotspot/default/icedtea-shark.patch Mon Apr 27 11:15:01 2009 -0400 +++ b/patches/hotspot/default/icedtea-shark.patch Tue Apr 28 05:49:35 2009 -0400 @@ -363,28 +363,24 @@ } // ------------------------------------------------------------------ -diff -r 5297ff20101d openjdk-ecj/hotspot/src/share/vm/ci/ciInstanceKlass.hpp ---- openjdk/hotspot/src/share/vm/ci/ciInstanceKlass.hpp Mon Dec 15 15:32:37 2008 +0000 -+++ openjdk/hotspot/src/share/vm/ci/ciInstanceKlass.hpp Thu Mar 05 11:48:56 2009 +0000 -@@ -198,4 +198,9 @@ - // What kind of ciObject is this? - bool is_instance_klass() { return true; } - bool is_java_klass() { return true; } -+ -+#ifdef SHARK -+ // Is this entry in the constant pool cache resolved? -+ bool is_cache_entry_resolved(int index, Bytecodes::Code opcode); -+#endif // SHARK - }; diff -r 5297ff20101d openjdk-ecj/hotspot/src/share/vm/ci/ciInstanceKlass.cpp --- openjdk/hotspot/src/share/vm/ci/ciInstanceKlass.cpp Mon Dec 15 15:32:37 2008 +0000 -+++ openjdk/hotspot/src/share/vm/ci/ciInstanceKlass.cpp Thu Mar 05 11:48:56 2009 +0000 -@@ -548,3 +548,14 @@ ++++ openjdk/hotspot/src/share/vm/ci/ciInstanceKlass.cpp Tue Apr 21 09:47:27 2009 +0100 +@@ -548,3 +548,23 @@ } return impl; } + +#ifdef SHARK ++// ------------------------------------------------------------------ ++// ciInstanceKlass::constant_pool_tag_at ++// ++// What is in this constant pool slot? ++constantTag ciInstanceKlass::constant_pool_tag_at(int index) { ++ VM_ENTRY_MARK; ++ return get_instanceKlass()->constants()->tag_at(index); ++} ++ +// ------------------------------------------------------------------ +// ciInstanceKlass::is_cache_entry_resolved +// @@ -394,3 +390,19 @@ + return get_instanceKlass()->constants()->cache()->entry_at(index)->is_resolved(opcode); +} +#endif // SHARK +diff -r 5297ff20101d openjdk-ecj/hotspot/src/share/vm/ci/ciInstanceKlass.hpp +--- openjdk/hotspot/src/share/vm/ci/ciInstanceKlass.hpp Mon Dec 15 15:32:37 2008 +0000 ++++ openjdk/hotspot/src/share/vm/ci/ciInstanceKlass.hpp Tue Apr 21 09:47:27 2009 +0100 +@@ -198,4 +198,12 @@ + // What kind of ciObject is this? + bool is_instance_klass() { return true; } + bool is_java_klass() { return true; } ++ ++#ifdef SHARK ++ // What is in this constant pool slot? ++ constantTag constant_pool_tag_at(int index); ++ ++ // Is this entry in the constant pool cache resolved? ++ bool is_cache_entry_resolved(int index, Bytecodes::Code opcode); ++#endif // SHARK + }; diff -r 9b0b945113de ports/hotspot/src/share/vm/shark/sharkRuntime.cpp --- a/ports/hotspot/src/share/vm/shark/sharkRuntime.cpp Mon Apr 27 11:15:01 2009 -0400 +++ b/ports/hotspot/src/share/vm/shark/sharkRuntime.cpp Tue Apr 28 05:49:35 2009 -0400 @@ -37,7 +37,6 @@ Constant* SharkRuntime::_anewarray; Constant* SharkRuntime::_multianewarray; Constant* SharkRuntime::_register_finalizer; -Constant* SharkRuntime::_resolve_klass; Constant* SharkRuntime::_safepoint; Constant* SharkRuntime::_throw_ArrayIndexOutOfBoundsException; Constant* SharkRuntime::_throw_NullPointerException; @@ -93,10 +92,6 @@ (intptr_t) new_instance_C, FunctionType::get(Type::VoidTy, params, false), "SharkRuntime__new_instance"); - _resolve_klass = builder->make_function( - (intptr_t) resolve_klass_C, - FunctionType::get(Type::VoidTy, params, false), - "SharkRuntime__resolve_klass"); params.clear(); params.push_back(SharkType::thread_type()); @@ -372,13 +367,6 @@ } JRT_END -JRT_ENTRY(void, SharkRuntime::resolve_klass_C(JavaThread* thread, int index)) -{ - klassOop klass = method(thread)->constants()->klass_at(index, CHECK); - thread->set_vm_result(klass); -} -JRT_END - JRT_ENTRY(void, SharkRuntime::throw_ArrayIndexOutOfBoundsException_C( JavaThread* thread, const char* file, diff -r 9b0b945113de ports/hotspot/src/share/vm/shark/sharkRuntime.hpp --- a/ports/hotspot/src/share/vm/shark/sharkRuntime.hpp Mon Apr 27 11:15:01 2009 -0400 +++ b/ports/hotspot/src/share/vm/shark/sharkRuntime.hpp Tue Apr 28 05:49:35 2009 -0400 @@ -37,7 +37,6 @@ static llvm::Constant* _anewarray; static llvm::Constant* _multianewarray; static llvm::Constant* _register_finalizer; - static llvm::Constant* _resolve_klass; static llvm::Constant* _safepoint; static llvm::Constant* _throw_ArrayIndexOutOfBoundsException; static llvm::Constant* _throw_NullPointerException; @@ -75,10 +74,6 @@ { return _register_finalizer; } - static llvm::Constant* resolve_klass() - { - return _resolve_klass; - } static llvm::Constant* safepoint() { return _safepoint; @@ -110,7 +105,6 @@ static void register_finalizer_C(JavaThread* thread, oop object); - static void resolve_klass_C(JavaThread* thread, int index); static void throw_ArrayIndexOutOfBoundsException_C(JavaThread* thread, const char* file, int line, diff -r 9b0b945113de ports/hotspot/src/share/vm/shark/sharkTopLevelBlock.cpp --- a/ports/hotspot/src/share/vm/shark/sharkTopLevelBlock.cpp Mon Apr 27 11:15:01 2009 -0400 +++ b/ports/hotspot/src/share/vm/shark/sharkTopLevelBlock.cpp Tue Apr 28 05:49:35 2009 -0400 @@ -1205,24 +1205,24 @@ void SharkTopLevelBlock::do_instance_check() { - // Leave the object on the stack until after all the VM calls - assert(xstack(0)->is_jobject(), "should be"); - - ciKlass *klass = NULL; - if (bc() == Bytecodes::_checkcast) { - bool will_link; - klass = iter()->get_klass(will_link); - if (!will_link) { - // XXX why is this not typeflow's responsibility? - NOT_PRODUCT(warning("unresolved checkcast in %s", function()->name())); - klass = (ciKlass *) xstack(0)->type(); - } + constantTag tag = + target()->holder()->constant_pool_tag_at(iter()->get_klass_index()); + if (!tag.is_klass()) { + assert(tag.is_unresolved_klass(), "should be"); + do_trapping_instance_check(); } + else { + do_full_instance_check(); + } +} + +void SharkTopLevelBlock::do_full_instance_check() +{ + bool will_link; + ciKlass *klass = iter()->get_klass(will_link); + assert(will_link, "should do"); BasicBlock *not_null = function()->CreateBlock("not_null"); - BasicBlock *fast_path = function()->CreateBlock("fast_path"); - BasicBlock *slow_path = function()->CreateBlock("slow_path"); - BasicBlock *got_klass = function()->CreateBlock("got_klass"); BasicBlock *subtype_check = function()->CreateBlock("subtype_check"); BasicBlock *is_instance = function()->CreateBlock("is_instance"); BasicBlock *not_instance = function()->CreateBlock("not_instance"); @@ -1235,9 +1235,12 @@ IC_NOT_INSTANCE, }; + // Pop the object off the stack + Value *object = pop()->jobject_value(); + // Null objects aren't instances of anything builder()->CreateCondBr( - builder()->CreateICmpEQ(xstack(0)->jobject_value(), LLVMValue::null()), + builder()->CreateICmpEQ(object, LLVMValue::null()), merge2, not_null); BasicBlock *null_block = builder()->GetInsertBlock(); SharkState *null_state = current_state()->copy(); @@ -1245,42 +1248,11 @@ // Get the class we're checking against builder()->SetInsertPoint(not_null); SharkConstantPool constants(this); - Value *tag = constants.tag_at(iter()->get_klass_index()); - builder()->CreateCondBr( - builder()->CreateOr( - builder()->CreateICmpEQ( - tag, LLVMValue::jbyte_constant(JVM_CONSTANT_UnresolvedClass)), - builder()->CreateICmpEQ( - tag, LLVMValue::jbyte_constant(JVM_CONSTANT_UnresolvedClassInError))), - slow_path, fast_path); - - // The fast path - builder()->SetInsertPoint(fast_path); - BasicBlock *fast_block = builder()->GetInsertBlock(); - SharkState *fast_state = current_state()->copy(); - Value *fast_klass = constants.object_at(iter()->get_klass_index()); - builder()->CreateBr(got_klass); - - // The slow path - builder()->SetInsertPoint(slow_path); - call_vm( - SharkRuntime::resolve_klass(), - LLVMValue::jint_constant(iter()->get_klass_index())); - Value *slow_klass = function()->CreateGetVMResult(); - BasicBlock *slow_block = builder()->GetInsertBlock(); - builder()->CreateBr(got_klass); - - // We have the class to test against - builder()->SetInsertPoint(got_klass); - current_state()->merge(fast_state, fast_block, slow_block); - PHINode *check_klass = builder()->CreatePHI( - SharkType::jobject_type(), "check_klass"); - check_klass->addIncoming(fast_klass, fast_block); - check_klass->addIncoming(slow_klass, slow_block); + Value *check_klass = constants.object_at(iter()->get_klass_index()); // Get the class of the object being tested Value *object_klass = builder()->CreateValueOfStructEntry( - xstack(0)->jobject_value(), in_ByteSize(oopDesc::klass_offset_in_bytes()), + object, in_ByteSize(oopDesc::klass_offset_in_bytes()), SharkType::jobject_type(), "object_klass"); @@ -1322,9 +1294,6 @@ result->addIncoming(LLVMValue::jint_constant(IC_IS_NULL), null_block); result->addIncoming(nonnull_result, nonnull_block); - // We can finally pop the object! - Value *object = pop()->jobject_value(); - // Handle the result if (bc() == Bytecodes::_checkcast) { BasicBlock *failure = function()->CreateBlock("failure"); @@ -1349,6 +1318,34 @@ builder()->CreateICmpEQ( result, LLVMValue::jint_constant(IC_IS_INSTANCE)), SharkType::jint_type(), false), false)); + } +} + +void SharkTopLevelBlock::do_trapping_instance_check() +{ + BasicBlock *not_null = function()->CreateBlock("not_null"); + BasicBlock *is_null = function()->CreateBlock("null"); + + // Leave the object on the stack so it's there if we trap + builder()->CreateCondBr( + builder()->CreateICmpEQ(xstack(0)->jobject_value(), LLVMValue::null()), + is_null, not_null); + SharkState *saved_state = current_state()->copy(); + + // If it's not null then we need to trap + builder()->SetInsertPoint(not_null); + set_current_state(saved_state->copy()); + do_trap( + Deoptimization::make_trap_request( + Deoptimization::Reason_uninitialized, + Deoptimization::Action_reinterpret)); + + // If it's null then we're ok + builder()->SetInsertPoint(is_null); + set_current_state(saved_state); + if (bc() == Bytecodes::_instanceof) { + pop(); + push(SharkValue::jint_constant(0)); } } diff -r 9b0b945113de ports/hotspot/src/share/vm/shark/sharkTopLevelBlock.hpp --- a/ports/hotspot/src/share/vm/shark/sharkTopLevelBlock.hpp Mon Apr 27 11:15:01 2009 -0400 +++ b/ports/hotspot/src/share/vm/shark/sharkTopLevelBlock.hpp Tue Apr 28 05:49:35 2009 -0400 @@ -366,6 +366,9 @@ // checkcast and instanceof private: + void do_full_instance_check(); + void do_trapping_instance_check(); + void do_instance_check(); // new and *newarray From gbenson at redhat.com Wed Apr 29 02:00:23 2009 From: gbenson at redhat.com (Gary Benson) Date: Wed, 29 Apr 2009 10:00:23 +0100 Subject: Improved ldc for Shark Message-ID: <20090429090022.GA3978@redhat.com> Hi all, This patch causes Shark to trap on unresolved ldc and ldc_w instructions, and makes the implementation of the instructions much neater. Cheers, Gary -- http://gbenson.net/ -------------- next part -------------- diff -r df5a8e49d157 -r a37e9b594cb2 ChangeLog --- a/ChangeLog Tue Apr 28 16:53:58 2009 +0200 +++ b/ChangeLog Wed Apr 29 04:53:32 2009 -0400 @@ -1,3 +1,12 @@ +2009-04-29 Gary Benson + + * ports/hotspot/src/share/vm/shark/sharkTopLevelBlock.cpp + (SharkTopLevelBlock::scan_for_traps): Trap on ldc and ldc_w + when the constant is unresolved. + (SharkTopLevelBlock::lookup_for_ldc): Rewritten. + * ports/hotspot/src/share/vm/shark/sharkConstantPool.cpp + (SharkConstantPool::java_mirror): Add a comment. + 2009-04-28 Mark Wielaard * tapset/hotspot.stp.in: New systemtap tapset for hotspot. diff -r df5a8e49d157 -r a37e9b594cb2 ports/hotspot/src/share/vm/shark/sharkConstantPool.cpp --- a/ports/hotspot/src/share/vm/shark/sharkConstantPool.cpp Tue Apr 28 16:53:58 2009 +0200 +++ b/ports/hotspot/src/share/vm/shark/sharkConstantPool.cpp Wed Apr 29 04:53:32 2009 -0400 @@ -116,6 +116,7 @@ SharkType::klass_type(), "klass_part"); + // XXX should there be a memory barrier before this load? return builder()->CreateValueOfStructEntry( klass_part, in_ByteSize(Klass::java_mirror_offset_in_bytes()), diff -r df5a8e49d157 -r a37e9b594cb2 ports/hotspot/src/share/vm/shark/sharkTopLevelBlock.cpp --- a/ports/hotspot/src/share/vm/shark/sharkTopLevelBlock.cpp Tue Apr 28 16:53:58 2009 +0200 +++ b/ports/hotspot/src/share/vm/shark/sharkTopLevelBlock.cpp Wed Apr 29 04:53:32 2009 -0400 @@ -46,6 +46,17 @@ int index = -1; switch (bc()) { + case Bytecodes::_ldc: + case Bytecodes::_ldc_w: + if (iter()->is_unresolved_string() || iter()->is_unresolved_klass()) { + set_trap( + Deoptimization::make_trap_request( + Deoptimization::Reason_uninitialized, + Deoptimization::Action_reinterpret), bci()); + return; + } + break; + case Bytecodes::_getfield: case Bytecodes::_getstatic: case Bytecodes::_putfield: @@ -579,69 +590,33 @@ Value *SharkTopLevelBlock::lookup_for_ldc() { + int index = iter()->get_constant_index(); + constantTag tag = target()->holder()->constant_pool_tag_at(index); + SharkConstantPool constants(this); + Value *entry = constants.object_at(index); - BasicBlock *resolved = function()->CreateBlock("resolved"); - BasicBlock *resolved_class = function()->CreateBlock("resolved_class"); - BasicBlock *unresolved = function()->CreateBlock("unresolved"); - BasicBlock *unknown = function()->CreateBlock("unknown"); - BasicBlock *done = function()->CreateBlock("done"); + Value *klass_part; + switch (tag.value()) { + case JVM_CONSTANT_String: + return entry; - SwitchInst *switchinst = builder()->CreateSwitch( - constants.tag_at(iter()->get_constant_index()), - unknown, 5); + case JVM_CONSTANT_Class: + klass_part = builder()->CreateAddressOfStructEntry( + entry, + in_ByteSize(klassOopDesc::klass_part_offset_in_bytes()), + SharkType::klass_type(), + "klass_part"); + // XXX FIXME: We need a memory barrier before this load + return builder()->CreateValueOfStructEntry( + klass_part, + in_ByteSize(Klass::java_mirror_offset_in_bytes()), + SharkType::oop_type(), + "java_mirror"); - switchinst->addCase( - LLVMValue::jbyte_constant(JVM_CONSTANT_String), resolved); - switchinst->addCase( - LLVMValue::jbyte_constant(JVM_CONSTANT_Class), resolved_class); - switchinst->addCase( - LLVMValue::jbyte_constant(JVM_CONSTANT_UnresolvedString), unresolved); - switchinst->addCase( - LLVMValue::jbyte_constant(JVM_CONSTANT_UnresolvedClass), unresolved); - switchinst->addCase( - LLVMValue::jbyte_constant(JVM_CONSTANT_UnresolvedClassInError), - unresolved); - - builder()->SetInsertPoint(resolved); - Value *resolved_value = constants.object_at(iter()->get_constant_index()); - builder()->CreateBr(done); - - builder()->SetInsertPoint(resolved_class); - Value *resolved_class_value - = constants.object_at(iter()->get_constant_index()); - resolved_class_value - = builder()->CreatePtrToInt(resolved_class_value, - SharkType::intptr_type()); - resolved_class_value - = (builder()->CreateAdd - (resolved_class_value, - (LLVMValue::intptr_constant - (klassOopDesc::klass_part_offset_in_bytes() - + Klass::java_mirror_offset_in_bytes())))); - // XXX FIXME: We need a memory barrier before this load. - resolved_class_value - = (builder()->CreateLoad - (builder()->CreateIntToPtr - (resolved_class_value, - PointerType::getUnqual(SharkType::jobject_type())))); - builder()->CreateBr(done); - - builder()->SetInsertPoint(unresolved); - builder()->CreateUnimplemented(__FILE__, __LINE__); - Value *unresolved_value = LLVMValue::null(); - builder()->CreateBr(done); - - builder()->SetInsertPoint(unknown); - builder()->CreateShouldNotReachHere(__FILE__, __LINE__); - builder()->CreateUnreachable(); - - builder()->SetInsertPoint(done); - PHINode *phi = builder()->CreatePHI(SharkType::jobject_type(), "constant"); - phi->addIncoming(resolved_value, resolved); - phi->addIncoming(resolved_class_value, resolved_class); - phi->addIncoming(unresolved_value, unresolved); - return phi; + default: + ShouldNotReachHere(); + } } Value* SharkTopLevelBlock::lookup_for_field_access()