From rkennke at redhat.com Wed Nov 21 03:47:47 2012 From: rkennke at redhat.com (Roman Kennke) Date: Wed, 21 Nov 2012 12:47:47 +0100 Subject: The return of the Shark Message-ID: <1353498467.1744.17.camel@mercury> Hi there, the last couple of days I worked on getting Shark back into shape for OpenJDK8. I have it working now with LLVM 3.1 and latest OpenJDK8 hsx/hotspot-comp now, it successfully runs Eclipse and a bunch of other apps I tried. I have one question to which I'd like to hear other people's input. In the Shark code we have several #ifdefs that check for specific LLVM versions like this: +#if SHARK_LLVM_VERSION >= 30 For LLVM 3.1 I'd need to add more to this. However, I fear this will be an increasingly difficult thing to do, and would actually prefer to get rid of those check altogether and only support whatever is the latest LLVM release (or at least, some specific known LLVM release). Even now it's difficult for me to say which code is generic or specific to an LLVM version, and I don't think we can possibly expect to test against all those LLVM versions. And it also clutters the code unnecessarily. So I guess my question is, would it be ok for everybody to simply drop this version check, and support latest LLVM only (3.1 as of now).? Or is there a need for specific LLVM version support, and if yes, then which versions are they (maybe we can then at least limit the number of versions we have). What do you think? Roman From doko at ubuntu.com Wed Nov 21 06:00:50 2012 From: doko at ubuntu.com (Matthias Klose) Date: Wed, 21 Nov 2012 15:00:50 +0100 Subject: The return of the Shark In-Reply-To: <1353498467.1744.17.camel@mercury> References: <1353498467.1744.17.camel@mercury> Message-ID: <50ACDE92.2020709@ubuntu.com> Am 21.11.2012 12:47, schrieb Roman Kennke: > Hi there, > > the last couple of days I worked on getting Shark back into shape for > OpenJDK8. I have it working now with LLVM 3.1 and latest OpenJDK8 > hsx/hotspot-comp now, it successfully runs Eclipse and a bunch of other > apps I tried. \o/ which architectures was this tested with? > I have one question to which I'd like to hear other people's input. In > the Shark code we have several #ifdefs that check for specific LLVM > versions like this: > > +#if SHARK_LLVM_VERSION >= 30 > > For LLVM 3.1 I'd need to add more to this. However, I fear this will be > an increasingly difficult thing to do, and would actually prefer to get > rid of those check altogether and only support whatever is the latest > LLVM release (or at least, some specific known LLVM release). Even now > it's difficult for me to say which code is generic or specific to an > LLVM version, and I don't think we can possibly expect to test against > all those LLVM versions. And it also clutters the code unnecessarily. > > So I guess my question is, would it be ok for everybody to simply drop > this version check, and support latest LLVM only (3.1 as of now).? Or is > there a need for specific LLVM version support, and if yes, then which > versions are they (maybe we can then at least limit the number of > versions we have). > > What do you think? I don't like the idea of just supporting one llvm version, which makes it harder to build if you first have to build llvm. So maybe remove the version checks for older llvm versions (I'm ok having 3.1 as the minimal version), keep these for 3.1, and make sure that it works for 3.2 too (first rc was just released). Matthias From rkennke at redhat.com Wed Nov 21 09:31:34 2012 From: rkennke at redhat.com (Roman Kennke) Date: Wed, 21 Nov 2012 18:31:34 +0100 Subject: RFR: Fix shark for latest Hotspot and LLVM Message-ID: <1353519094.1744.42.camel@mercury> Hi there, during the last days I worked on fixing the Shark compiler for Hotspot to get it to build and run again, with the latest Hotspot code and LLVM. Here are some details: - A lot of changes are just to make it build and the compiler happy. For example, I had to remove a lot of 'const' qualifiers because of API changes in LLVM. - Most other changes have to do with the split of the oop and metadata class hierarchies in Hotspot. - Then there have been a few changes caused by LLVM changes and improvements, most notably the LLVM intrinsics for atomic operations (memory barrier and cmpxchg) have been removed and now have a representation directly in LLVM's IR. This makes our code a little nicer. I tested this by running a number of applications, most notably Eclipse (which is notoriously difficult on VMs), Java2Demo, SwingSet2 and a bunch of other stuff. I would like to get this integrated into OpenJDK now if possible. You can find the full webrev here: http://cr.openjdk.java.net/~rkennke/shark/webrev.00/ There are also a very minor change required in JDK: http://cr.openjdk.java.net/~rkennke/shark/webrev-jdk-00/ In order to build it, apply the patches on hsx/hotspot-comp 's hotspot and jdk repositories respectivly. Find my build script here: http://cr.openjdk.java.net/~rkennke/shark/Build8-zero-shark (Review and adjust variables to your settings, most notably you will need to change LLVM_CONFIG to point to your LLVM 3.1 installation.) Please let me know if there are any issues or how we can get this integrated into Hotspot. Best regards, Roman From rkennke at redhat.com Wed Nov 21 12:54:11 2012 From: rkennke at redhat.com (Roman Kennke) Date: Wed, 21 Nov 2012 21:54:11 +0100 Subject: RFR (L): 8003868: fix shark for latest HotSpot and LLVM [Was: Re: RFR: Fix shark for latest Hotspot and LLVM] In-Reply-To: <34C51B6D-6582-42AB-9BDE-2CF7D721532E@oracle.com> References: <1353519094.1744.42.camel@mercury> <34C51B6D-6582-42AB-9BDE-2CF7D721532E@oracle.com> Message-ID: <1353531251.1744.53.camel@mercury> Am Mittwoch, den 21.11.2012, 12:47 -0800 schrieb Christian Thalinger: > On Nov 21, 2012, at 11:43 AM, Christian Thalinger wrote: > > > On Nov 21, 2012, at 9:31 AM, Roman Kennke wrote: > > > >> Hi there, > >> > >> during the last days I worked on fixing the Shark compiler for Hotspot > >> to get it to build and run again, with the latest Hotspot code and LLVM. > >> Here are some details: > >> > >> - A lot of changes are just to make it build and the compiler happy. For > >> example, I had to remove a lot of 'const' qualifiers because of API > >> changes in LLVM. > >> - Most other changes have to do with the split of the oop and metadata > >> class hierarchies in Hotspot. > >> - Then there have been a few changes caused by LLVM changes and > >> improvements, most notably the LLVM intrinsics for atomic operations > >> (memory barrier and cmpxchg) have been removed and now have a > >> representation directly in LLVM's IR. This makes our code a little > >> nicer. > >> > >> I tested this by running a number of applications, most notably Eclipse > >> (which is notoriously difficult on VMs), Java2Demo, SwingSet2 and a > >> bunch of other stuff. > >> > >> I would like to get this integrated into OpenJDK now if possible. You > >> can find the full webrev here: > >> > >> http://cr.openjdk.java.net/~rkennke/shark/webrev.00/ > > > > The changes seem to touch almost only shark files so these should be fine. One question though: > > > > + develop(bool, SharkShowCompiledMethods, false, \ > > > > Isn't PrintCompilation doing that already? > > > > The shared code changes look good. I filed: > > > > 8003868: fix shark for latest HotSpot and LLVM > > > > -- Chris > > > >> > >> There are also a very minor change required in JDK: > >> > >> http://cr.openjdk.java.net/~rkennke/shark/webrev-jdk-00/ > >> > >> In order to build it, apply the patches on hsx/hotspot-comp 's hotspot > >> and jdk repositories respectivly. Find my build script here: > >> > >> http://cr.openjdk.java.net/~rkennke/shark/Build8-zero-shark > >> > >> (Review and adjust variables to your settings, most notably you will > >> need to change LLVM_CONFIG to point to your LLVM 3.1 installation.) > >> > >> Please let me know if there are any issues or how we can get this > >> integrated into Hotspot. > > Finally I installed LLVM on one of our machines to be able to do a Shark build once in a while. When I try to do a jvmgshark build I get: > > In file included from /usr/local/include/llvm/Support/PointerLikeTypeTraits.h:18, > from /usr/local/include/llvm/ADT/PointerIntPair.h:17, > from /usr/local/include/llvm/Use.h:28, > from /usr/local/include/llvm/Value.h:17, > from /usr/local/include/llvm/Argument.h:17, > from /home/cthaling/8003868/src/share/vm/shark/llvmHeaders.hpp:39, > from /home/cthaling/8003868/src/share/vm/shark/sharkEntry.hpp:29, > from /home/cthaling/8003868/src/share/vm/compiler/disassembler.cpp:51: > /usr/local/include/llvm/Support/DataTypes.h:53:3: error: #error "Must #define __STDC_CONSTANT_MACROS before " "#including Support/DataTypes.h" > > and: > > In file included from /usr/local/include/llvm/Attributes.h:18, > from /usr/local/include/llvm/Argument.h:18, > from /home/cthaling/8003868/src/share/vm/shark/llvmHeaders.hpp:39, > from /home/cthaling/8003868/src/share/vm/shark/sharkEntry.hpp:29, > from /home/cthaling/8003868/src/share/vm/compiler/disassembler.cpp:51: > /usr/local/include/llvm/Support/MathExtras.h: In function ?bool llvm::isInt(int64_t)?: > /usr/local/include/llvm/Support/MathExtras.h:38: error: there are no arguments to ?INT64_C? that depend on a template parameter, so a declaration of ?INT64_C? must be available > /usr/local/include/llvm/Support/MathExtras.h:38: note: (if you use ?-fpermissive?, G++ will accept your code, but allowing the use of an undeclared name is deprecated) > /usr/local/include/llvm/Support/MathExtras.h:38: error: there are no arguments to ?INT64_C? that depend on a template parameter, so a declaration of ?INT64_C? must be available > /usr/local/include/llvm/Support/MathExtras.h: In function ?bool llvm::isUInt(uint64_t)?: > /usr/local/include/llvm/Support/MathExtras.h:64: error: there are no arguments to ?UINT64_C? that depend on a template parameter, so a declaration of ?UINT64_C? must be available > /usr/local/include/llvm/Support/MathExtras.h: In function ?bool llvm::isIntN(unsigned int, int64_t)?: > /usr/local/include/llvm/Support/MathExtras.h:96: error: ?INT64_C? was not declared in this scope > > Not sure if the latter is because of the former one. Have you seen this before? Yes, it's caused by the former. And yes, I have seen it before. IIRC, this happens when certain cflags are not set correctly. The script jdk/make/jdk_generic_profile.sh will call llvm-config to figure out the correct flags. In order for this to work, you need to have the full path to the llvm-config script set in the LLVM_CONFIG env variable. Were you using the build script that I provided? Roman From rkennke at redhat.com Wed Nov 21 13:01:28 2012 From: rkennke at redhat.com (Roman Kennke) Date: Wed, 21 Nov 2012 22:01:28 +0100 Subject: RFR (L): 8003868: fix shark for latest HotSpot and LLVM [Was: Re: RFR: Fix shark for latest Hotspot and LLVM] In-Reply-To: References: <1353519094.1744.42.camel@mercury> Message-ID: <1353531688.1744.55.camel@mercury> Am Mittwoch, den 21.11.2012, 11:43 -0800 schrieb Christian Thalinger: > On Nov 21, 2012, at 9:31 AM, Roman Kennke wrote: > > > Hi there, > > > > during the last days I worked on fixing the Shark compiler for Hotspot > > to get it to build and run again, with the latest Hotspot code and LLVM. > > Here are some details: > > > > - A lot of changes are just to make it build and the compiler happy. For > > example, I had to remove a lot of 'const' qualifiers because of API > > changes in LLVM. > > - Most other changes have to do with the split of the oop and metadata > > class hierarchies in Hotspot. > > - Then there have been a few changes caused by LLVM changes and > > improvements, most notably the LLVM intrinsics for atomic operations > > (memory barrier and cmpxchg) have been removed and now have a > > representation directly in LLVM's IR. This makes our code a little > > nicer. > > > > I tested this by running a number of applications, most notably Eclipse > > (which is notoriously difficult on VMs), Java2Demo, SwingSet2 and a > > bunch of other stuff. > > > > I would like to get this integrated into OpenJDK now if possible. You > > can find the full webrev here: > > > > http://cr.openjdk.java.net/~rkennke/shark/webrev.00/ > > The changes seem to touch almost only shark files so these should be fine. One question though: > > + develop(bool, SharkShowCompiledMethods, false, \ > > Isn't PrintCompilation doing that already? Oh yes, didn't know that one! And it's even much better. > The shared code changes look good. I filed: > > 8003868: fix shark for latest HotSpot and LLVM Thanks. I removed the above flag, and posted another webrev: http://cr.openjdk.java.net/~rkennke/shark/webrev.01/ Cheers, Roman From rkennke at redhat.com Thu Nov 22 06:19:55 2012 From: rkennke at redhat.com (Roman Kennke) Date: Thu, 22 Nov 2012 15:19:55 +0100 Subject: The return of the Shark In-Reply-To: <50ACDE92.2020709@ubuntu.com> References: <1353498467.1744.17.camel@mercury> <50ACDE92.2020709@ubuntu.com> Message-ID: <1353593995.11230.7.camel@mercury> Am Mittwoch, den 21.11.2012, 15:00 +0100 schrieb Matthias Klose: > Am 21.11.2012 12:47, schrieb Roman Kennke: > > Hi there, > > > > the last couple of days I worked on getting Shark back into shape for > > OpenJDK8. I have it working now with LLVM 3.1 and latest OpenJDK8 > > hsx/hotspot-comp now, it successfully runs Eclipse and a bunch of other > > apps I tried. > > \o/ > > which architectures was this tested with? So far, only on x86. I (and my team) is currently working on testing ARM and maybe PPC. > > I have one question to which I'd like to hear other people's input. In > > the Shark code we have several #ifdefs that check for specific LLVM > > versions like this: > > > > +#if SHARK_LLVM_VERSION >= 30 > > > > For LLVM 3.1 I'd need to add more to this. However, I fear this will be > > an increasingly difficult thing to do, and would actually prefer to get > > rid of those check altogether and only support whatever is the latest > > LLVM release (or at least, some specific known LLVM release). Even now > > it's difficult for me to say which code is generic or specific to an > > LLVM version, and I don't think we can possibly expect to test against > > all those LLVM versions. And it also clutters the code unnecessarily. > > > > So I guess my question is, would it be ok for everybody to simply drop > > this version check, and support latest LLVM only (3.1 as of now).? Or is > > there a need for specific LLVM version support, and if yes, then which > > versions are they (maybe we can then at least limit the number of > > versions we have). > > > > What do you think? > > I don't like the idea of just supporting one llvm version, which makes it harder > to build if you first have to build llvm. So maybe remove the version checks for > older llvm versions (I'm ok having 3.1 as the minimal version), keep these for > 3.1, and make sure that it works for 3.2 too (first rc was just released). Ok, I removed the version checks for now, which means that 3.1 is the baseline (it might even work on 3.0). Hopefully there are not too many breaking changes coming down the line from LLVM (I will give the 3.2rc a spin as soon as I have some time). 3.0->3.1 has been relatively smooth as far as I can tell. *IF* there are any breaking changes, I propose to not maintain support for more than one additional older version (e.g. latest released LLVM and one older release, maybe a version that is available in a majority of distros or so). Would that be ok? Roman From rkennke at redhat.com Thu Nov 22 08:48:10 2012 From: rkennke at redhat.com (Roman Kennke) Date: Thu, 22 Nov 2012 17:48:10 +0100 Subject: RFR (L): 8003868: fix shark for latest HotSpot and LLVM [Was: Re: RFR: Fix shark for latest Hotspot and LLVM] In-Reply-To: <6B77725B-3BCF-40E0-AF0B-77E58B36B095@oracle.com> References: <1353519094.1744.42.camel@mercury> <34C51B6D-6582-42AB-9BDE-2CF7D721532E@oracle.com> <1353531251.1744.53.camel@mercury> <32151B51-A2A1-4DE4-B5DD-B665E2548704@oracle.com> <6B77725B-3BCF-40E0-AF0B-77E58B36B095@oracle.com> Message-ID: <1353602890.11230.13.camel@mercury> Am Mittwoch, den 21.11.2012, 14:52 -0800 schrieb Christian Thalinger: > On Nov 21, 2012, at 2:22 PM, Christian Thalinger wrote: > > > > > On Nov 21, 2012, at 2:17 PM, Christian Thalinger wrote: > > > >> > >> On Nov 21, 2012, at 12:54 PM, Roman Kennke wrote: > >> > >>> Am Mittwoch, den 21.11.2012, 12:47 -0800 schrieb Christian Thalinger: > >>>> On Nov 21, 2012, at 11:43 AM, Christian Thalinger wrote: > >>>> > >>>>> On Nov 21, 2012, at 9:31 AM, Roman Kennke wrote: > >>>>> > >>>>>> Hi there, > >>>>>> > >>>>>> during the last days I worked on fixing the Shark compiler for Hotspot > >>>>>> to get it to build and run again, with the latest Hotspot code and LLVM. > >>>>>> Here are some details: > >>>>>> > >>>>>> - A lot of changes are just to make it build and the compiler happy. For > >>>>>> example, I had to remove a lot of 'const' qualifiers because of API > >>>>>> changes in LLVM. > >>>>>> - Most other changes have to do with the split of the oop and metadata > >>>>>> class hierarchies in Hotspot. > >>>>>> - Then there have been a few changes caused by LLVM changes and > >>>>>> improvements, most notably the LLVM intrinsics for atomic operations > >>>>>> (memory barrier and cmpxchg) have been removed and now have a > >>>>>> representation directly in LLVM's IR. This makes our code a little > >>>>>> nicer. > >>>>>> > >>>>>> I tested this by running a number of applications, most notably Eclipse > >>>>>> (which is notoriously difficult on VMs), Java2Demo, SwingSet2 and a > >>>>>> bunch of other stuff. > >>>>>> > >>>>>> I would like to get this integrated into OpenJDK now if possible. You > >>>>>> can find the full webrev here: > >>>>>> > >>>>>> http://cr.openjdk.java.net/~rkennke/shark/webrev.00/ > >>>>> > >>>>> The changes seem to touch almost only shark files so these should be fine. One question though: > >>>>> > >>>>> + develop(bool, SharkShowCompiledMethods, false, \ > >>>>> > >>>>> Isn't PrintCompilation doing that already? > >>>>> > >>>>> The shared code changes look good. I filed: > >>>>> > >>>>> 8003868: fix shark for latest HotSpot and LLVM > >>>>> > >>>>> -- Chris > >>>>> > >>>>>> > >>>>>> There are also a very minor change required in JDK: > >>>>>> > >>>>>> http://cr.openjdk.java.net/~rkennke/shark/webrev-jdk-00/ > >>>>>> > >>>>>> In order to build it, apply the patches on hsx/hotspot-comp 's hotspot > >>>>>> and jdk repositories respectivly. Find my build script here: > >>>>>> > >>>>>> http://cr.openjdk.java.net/~rkennke/shark/Build8-zero-shark > >>>>>> > >>>>>> (Review and adjust variables to your settings, most notably you will > >>>>>> need to change LLVM_CONFIG to point to your LLVM 3.1 installation.) > >>>>>> > >>>>>> Please let me know if there are any issues or how we can get this > >>>>>> integrated into Hotspot. > >>>> > >>>> Finally I installed LLVM on one of our machines to be able to do a Shark build once in a while. When I try to do a jvmgshark build I get: > >>>> > >>>> In file included from /usr/local/include/llvm/Support/PointerLikeTypeTraits.h:18, > >>>> from /usr/local/include/llvm/ADT/PointerIntPair.h:17, > >>>> from /usr/local/include/llvm/Use.h:28, > >>>> from /usr/local/include/llvm/Value.h:17, > >>>> from /usr/local/include/llvm/Argument.h:17, > >>>> from /home/cthaling/8003868/src/share/vm/shark/llvmHeaders.hpp:39, > >>>> from /home/cthaling/8003868/src/share/vm/shark/sharkEntry.hpp:29, > >>>> from /home/cthaling/8003868/src/share/vm/compiler/disassembler.cpp:51: > >>>> /usr/local/include/llvm/Support/DataTypes.h:53:3: error: #error "Must #define __STDC_CONSTANT_MACROS before " "#including Support/DataTypes.h" > >>>> > >>>> and: > >>>> > >>>> In file included from /usr/local/include/llvm/Attributes.h:18, > >>>> from /usr/local/include/llvm/Argument.h:18, > >>>> from /home/cthaling/8003868/src/share/vm/shark/llvmHeaders.hpp:39, > >>>> from /home/cthaling/8003868/src/share/vm/shark/sharkEntry.hpp:29, > >>>> from /home/cthaling/8003868/src/share/vm/compiler/disassembler.cpp:51: > >>>> /usr/local/include/llvm/Support/MathExtras.h: In function ?bool llvm::isInt(int64_t)?: > >>>> /usr/local/include/llvm/Support/MathExtras.h:38: error: there are no arguments to ?INT64_C? that depend on a template parameter, so a declaration of ?INT64_C? must be available > >>>> /usr/local/include/llvm/Support/MathExtras.h:38: note: (if you use ?-fpermissive?, G++ will accept your code, but allowing the use of an undeclared name is deprecated) > >>>> /usr/local/include/llvm/Support/MathExtras.h:38: error: there are no arguments to ?INT64_C? that depend on a template parameter, so a declaration of ?INT64_C? must be available > >>>> /usr/local/include/llvm/Support/MathExtras.h: In function ?bool llvm::isUInt(uint64_t)?: > >>>> /usr/local/include/llvm/Support/MathExtras.h:64: error: there are no arguments to ?UINT64_C? that depend on a template parameter, so a declaration of ?UINT64_C? must be available > >>>> /usr/local/include/llvm/Support/MathExtras.h: In function ?bool llvm::isIntN(unsigned int, int64_t)?: > >>>> /usr/local/include/llvm/Support/MathExtras.h:96: error: ?INT64_C? was not declared in this scope > >>>> > >>>> Not sure if the latter is because of the former one. Have you seen this before? > >>> > >>> Yes, it's caused by the former. And yes, I have seen it before. IIRC, > >>> this happens when certain cflags are not set correctly. The script > >>> jdk/make/jdk_generic_profile.sh will call llvm-config to figure out the > >>> correct flags. In order for this to work, you need to have the full path > >>> to the llvm-config script set in the LLVM_CONFIG env variable. Were you > >>> using the build script that I provided? > >> > >> No. I took your script and got the important environment variables. But I missed the LLVM_* ones. Usually we only build hotspot so we don't have this jdk script. > >> > >> Now that I have the LLVM_* variables it's even worse: > >> > >> /home/cthaling/8003868/src/share/vm/oops/oop.hpp:72: error: cast from type ?markOopDesc* const volatile*? to type ?markOopDesc**? casts away constness > >> > >> It's probably this guy: -Wcast-qual > > > > Got it: > > > > $ java -version > > java version "1.8.0-ea" > > Java(TM) SE Runtime Environment (build 1.8.0-ea-b65) > > OpenJDK 64-Bit Shark VM (build 25.0-b11-internal-jvmg, mixed mode) > > I ran the compiler regression tests and Shark crashes in 5091921: > > cthaling at intelsdv03.us.oracle.com:~/8003868/test$ jtreg -workDir:$EXPORTHOME/jtreg -reportDir:$EXPORTHOME/jtreg -testjdk:$JAVA_HOME -verbose:summary compiler/5091921/ > Directory "/export/twisti/jtreg/scratch" not found: creating > Passed: compiler/5091921/Test5091921.java > Passed: compiler/5091921/Test6186134.java > Passed: compiler/5091921/Test6196102.java > Passed: compiler/5091921/Test6357214.java > Passed: compiler/5091921/Test6559156.java > Passed: compiler/5091921/Test6753639.java > Passed: compiler/5091921/Test6850611.java > Passed: compiler/5091921/Test6890943.java > Passed: compiler/5091921/Test6897150.java > Passed: compiler/5091921/Test6905845.java > Passed: compiler/5091921/Test6931567.java > /net/sqenfs-1.us.oracle.com/export1/comp/vm/tool/jtreg/execution/linux/bin/jtreg: line 139: 27784 Segmentation fault (core dumped) "${JT_JAVA}" $javaOpts -Dprogram=`basename "$0"` -jar "${JT_HOME}/lib/jtreg.jar" $jtregOpts > > You can also run all them with a simple make in test/ by setting: > > PRODUCT_HOME=$JAVA_HOME > TESTDIRS=compiler > This is interesting. I am not getting segfaults, but trip over assertions inside LLVM (probably the same thingy). I tried looking (and running through verifier) at the LLVM IR code, but nothing suspicious. Then I turned off optimizations in LLVM and suddenly everything passed (except for some tests that time out... probably performance tests that time out because shark is too slow?). It could be a bug in LLVM, I suspect this: http://llvm.org/bugs/show_bug.cgi?id=12470 I am not sure though. I added a -XX:SharkOptimizationLevel switch to select an optimization level at runtime. I will also check out the LLVM-3.2 RC code and see if that's any better. I will keep you posted. Roman From rkennke at redhat.com Thu Nov 22 09:47:45 2012 From: rkennke at redhat.com (Roman Kennke) Date: Thu, 22 Nov 2012 18:47:45 +0100 Subject: RFR (L): 8003868: fix shark for latest HotSpot and LLVM [Was: Re: RFR: Fix shark for latest Hotspot and LLVM] In-Reply-To: <1353602890.11230.13.camel@mercury> References: <1353519094.1744.42.camel@mercury> <34C51B6D-6582-42AB-9BDE-2CF7D721532E@oracle.com> <1353531251.1744.53.camel@mercury> <32151B51-A2A1-4DE4-B5DD-B665E2548704@oracle.com> <6B77725B-3BCF-40E0-AF0B-77E58B36B095@oracle.com> <1353602890.11230.13.camel@mercury> Message-ID: <1353606465.11230.15.camel@mercury> Am Donnerstag, den 22.11.2012, 17:48 +0100 schrieb Roman Kennke: > Am Mittwoch, den 21.11.2012, 14:52 -0800 schrieb Christian Thalinger: > > On Nov 21, 2012, at 2:22 PM, Christian Thalinger wrote: > > > > > > > > On Nov 21, 2012, at 2:17 PM, Christian Thalinger wrote: > > > > > >> > > >> On Nov 21, 2012, at 12:54 PM, Roman Kennke wrote: > > >> > > >>> Am Mittwoch, den 21.11.2012, 12:47 -0800 schrieb Christian Thalinger: > > >>>> On Nov 21, 2012, at 11:43 AM, Christian Thalinger wrote: > > >>>> > > >>>>> On Nov 21, 2012, at 9:31 AM, Roman Kennke wrote: > > >>>>> > > >>>>>> Hi there, > > >>>>>> > > >>>>>> during the last days I worked on fixing the Shark compiler for Hotspot > > >>>>>> to get it to build and run again, with the latest Hotspot code and LLVM. > > >>>>>> Here are some details: > > >>>>>> > > >>>>>> - A lot of changes are just to make it build and the compiler happy. For > > >>>>>> example, I had to remove a lot of 'const' qualifiers because of API > > >>>>>> changes in LLVM. > > >>>>>> - Most other changes have to do with the split of the oop and metadata > > >>>>>> class hierarchies in Hotspot. > > >>>>>> - Then there have been a few changes caused by LLVM changes and > > >>>>>> improvements, most notably the LLVM intrinsics for atomic operations > > >>>>>> (memory barrier and cmpxchg) have been removed and now have a > > >>>>>> representation directly in LLVM's IR. This makes our code a little > > >>>>>> nicer. > > >>>>>> > > >>>>>> I tested this by running a number of applications, most notably Eclipse > > >>>>>> (which is notoriously difficult on VMs), Java2Demo, SwingSet2 and a > > >>>>>> bunch of other stuff. > > >>>>>> > > >>>>>> I would like to get this integrated into OpenJDK now if possible. You > > >>>>>> can find the full webrev here: > > >>>>>> > > >>>>>> http://cr.openjdk.java.net/~rkennke/shark/webrev.00/ > > >>>>> > > >>>>> The changes seem to touch almost only shark files so these should be fine. One question though: > > >>>>> > > >>>>> + develop(bool, SharkShowCompiledMethods, false, \ > > >>>>> > > >>>>> Isn't PrintCompilation doing that already? > > >>>>> > > >>>>> The shared code changes look good. I filed: > > >>>>> > > >>>>> 8003868: fix shark for latest HotSpot and LLVM > > >>>>> > > >>>>> -- Chris > > >>>>> > > >>>>>> > > >>>>>> There are also a very minor change required in JDK: > > >>>>>> > > >>>>>> http://cr.openjdk.java.net/~rkennke/shark/webrev-jdk-00/ > > >>>>>> > > >>>>>> In order to build it, apply the patches on hsx/hotspot-comp 's hotspot > > >>>>>> and jdk repositories respectivly. Find my build script here: > > >>>>>> > > >>>>>> http://cr.openjdk.java.net/~rkennke/shark/Build8-zero-shark > > >>>>>> > > >>>>>> (Review and adjust variables to your settings, most notably you will > > >>>>>> need to change LLVM_CONFIG to point to your LLVM 3.1 installation.) > > >>>>>> > > >>>>>> Please let me know if there are any issues or how we can get this > > >>>>>> integrated into Hotspot. > > >>>> > > >>>> Finally I installed LLVM on one of our machines to be able to do a Shark build once in a while. When I try to do a jvmgshark build I get: > > >>>> > > >>>> In file included from /usr/local/include/llvm/Support/PointerLikeTypeTraits.h:18, > > >>>> from /usr/local/include/llvm/ADT/PointerIntPair.h:17, > > >>>> from /usr/local/include/llvm/Use.h:28, > > >>>> from /usr/local/include/llvm/Value.h:17, > > >>>> from /usr/local/include/llvm/Argument.h:17, > > >>>> from /home/cthaling/8003868/src/share/vm/shark/llvmHeaders.hpp:39, > > >>>> from /home/cthaling/8003868/src/share/vm/shark/sharkEntry.hpp:29, > > >>>> from /home/cthaling/8003868/src/share/vm/compiler/disassembler.cpp:51: > > >>>> /usr/local/include/llvm/Support/DataTypes.h:53:3: error: #error "Must #define __STDC_CONSTANT_MACROS before " "#including Support/DataTypes.h" > > >>>> > > >>>> and: > > >>>> > > >>>> In file included from /usr/local/include/llvm/Attributes.h:18, > > >>>> from /usr/local/include/llvm/Argument.h:18, > > >>>> from /home/cthaling/8003868/src/share/vm/shark/llvmHeaders.hpp:39, > > >>>> from /home/cthaling/8003868/src/share/vm/shark/sharkEntry.hpp:29, > > >>>> from /home/cthaling/8003868/src/share/vm/compiler/disassembler.cpp:51: > > >>>> /usr/local/include/llvm/Support/MathExtras.h: In function ?bool llvm::isInt(int64_t)?: > > >>>> /usr/local/include/llvm/Support/MathExtras.h:38: error: there are no arguments to ?INT64_C? that depend on a template parameter, so a declaration of ?INT64_C? must be available > > >>>> /usr/local/include/llvm/Support/MathExtras.h:38: note: (if you use ?-fpermissive?, G++ will accept your code, but allowing the use of an undeclared name is deprecated) > > >>>> /usr/local/include/llvm/Support/MathExtras.h:38: error: there are no arguments to ?INT64_C? that depend on a template parameter, so a declaration of ?INT64_C? must be available > > >>>> /usr/local/include/llvm/Support/MathExtras.h: In function ?bool llvm::isUInt(uint64_t)?: > > >>>> /usr/local/include/llvm/Support/MathExtras.h:64: error: there are no arguments to ?UINT64_C? that depend on a template parameter, so a declaration of ?UINT64_C? must be available > > >>>> /usr/local/include/llvm/Support/MathExtras.h: In function ?bool llvm::isIntN(unsigned int, int64_t)?: > > >>>> /usr/local/include/llvm/Support/MathExtras.h:96: error: ?INT64_C? was not declared in this scope > > >>>> > > >>>> Not sure if the latter is because of the former one. Have you seen this before? > > >>> > > >>> Yes, it's caused by the former. And yes, I have seen it before. IIRC, > > >>> this happens when certain cflags are not set correctly. The script > > >>> jdk/make/jdk_generic_profile.sh will call llvm-config to figure out the > > >>> correct flags. In order for this to work, you need to have the full path > > >>> to the llvm-config script set in the LLVM_CONFIG env variable. Were you > > >>> using the build script that I provided? > > >> > > >> No. I took your script and got the important environment variables. But I missed the LLVM_* ones. Usually we only build hotspot so we don't have this jdk script. > > >> > > >> Now that I have the LLVM_* variables it's even worse: > > >> > > >> /home/cthaling/8003868/src/share/vm/oops/oop.hpp:72: error: cast from type ?markOopDesc* const volatile*? to type ?markOopDesc**? casts away constness > > >> > > >> It's probably this guy: -Wcast-qual > > > > > > Got it: > > > > > > $ java -version > > > java version "1.8.0-ea" > > > Java(TM) SE Runtime Environment (build 1.8.0-ea-b65) > > > OpenJDK 64-Bit Shark VM (build 25.0-b11-internal-jvmg, mixed mode) > > > > I ran the compiler regression tests and Shark crashes in 5091921: > > > > cthaling at intelsdv03.us.oracle.com:~/8003868/test$ jtreg -workDir:$EXPORTHOME/jtreg -reportDir:$EXPORTHOME/jtreg -testjdk:$JAVA_HOME -verbose:summary compiler/5091921/ > > Directory "/export/twisti/jtreg/scratch" not found: creating > > Passed: compiler/5091921/Test5091921.java > > Passed: compiler/5091921/Test6186134.java > > Passed: compiler/5091921/Test6196102.java > > Passed: compiler/5091921/Test6357214.java > > Passed: compiler/5091921/Test6559156.java > > Passed: compiler/5091921/Test6753639.java > > Passed: compiler/5091921/Test6850611.java > > Passed: compiler/5091921/Test6890943.java > > Passed: compiler/5091921/Test6897150.java > > Passed: compiler/5091921/Test6905845.java > > Passed: compiler/5091921/Test6931567.java > > /net/sqenfs-1.us.oracle.com/export1/comp/vm/tool/jtreg/execution/linux/bin/jtreg: line 139: 27784 Segmentation fault (core dumped) "${JT_JAVA}" $javaOpts -Dprogram=`basename "$0"` -jar "${JT_HOME}/lib/jtreg.jar" $jtregOpts > > > > You can also run all them with a simple make in test/ by setting: > > > > PRODUCT_HOME=$JAVA_HOME > > TESTDIRS=compiler > > > > This is interesting. I am not getting segfaults, but trip over > assertions inside LLVM (probably the same thingy). I tried looking (and > running through verifier) at the LLVM IR code, but nothing suspicious. > Then I turned off optimizations in LLVM and suddenly everything passed > (except for some tests that time out... probably performance tests that > time out because shark is too slow?). It could be a bug in LLVM, I > suspect this: > > http://llvm.org/bugs/show_bug.cgi?id=12470 > > I am not sure though. I added a -XX:SharkOptimizationLevel switch to > select an optimization level at runtime. I will also check out the > LLVM-3.2 RC code and see if that's any better. I will keep you posted. So I tried with 3.2. Good news is that only minimal changes in Shark are required to do this, and another good news is that it does indeed make the crash go away :-) Will send out the patch later tonight (needs cleanup, and I need food ;-) ). Roman From rkennke at redhat.com Thu Nov 22 14:00:53 2012 From: rkennke at redhat.com (Roman Kennke) Date: Thu, 22 Nov 2012 23:00:53 +0100 Subject: RFR (L): 8003868: fix shark for latest HotSpot and LLVM [Was: Re: RFR: Fix shark for latest Hotspot and LLVM] In-Reply-To: <1353606465.11230.15.camel@mercury> References: <1353519094.1744.42.camel@mercury> <34C51B6D-6582-42AB-9BDE-2CF7D721532E@oracle.com> <1353531251.1744.53.camel@mercury> <32151B51-A2A1-4DE4-B5DD-B665E2548704@oracle.com> <6B77725B-3BCF-40E0-AF0B-77E58B36B095@oracle.com> <1353602890.11230.13.camel@mercury> <1353606465.11230.15.camel@mercury> Message-ID: <1353621653.11230.24.camel@mercury> Am Donnerstag, den 22.11.2012, 18:47 +0100 schrieb Roman Kennke: > Am Donnerstag, den 22.11.2012, 17:48 +0100 schrieb Roman Kennke: > > Am Mittwoch, den 21.11.2012, 14:52 -0800 schrieb Christian Thalinger: > > > On Nov 21, 2012, at 2:22 PM, Christian Thalinger wrote: > > > > > > > > > > > On Nov 21, 2012, at 2:17 PM, Christian Thalinger wrote: > > > > > > > >> > > > >> On Nov 21, 2012, at 12:54 PM, Roman Kennke wrote: > > > >> > > > >>> Am Mittwoch, den 21.11.2012, 12:47 -0800 schrieb Christian Thalinger: > > > >>>> On Nov 21, 2012, at 11:43 AM, Christian Thalinger wrote: > > > >>>> > > > >>>>> On Nov 21, 2012, at 9:31 AM, Roman Kennke wrote: > > > >>>>> > > > >>>>>> Hi there, > > > >>>>>> > > > >>>>>> during the last days I worked on fixing the Shark compiler for Hotspot > > > >>>>>> to get it to build and run again, with the latest Hotspot code and LLVM. > > > >>>>>> Here are some details: > > > >>>>>> > > > >>>>>> - A lot of changes are just to make it build and the compiler happy. For > > > >>>>>> example, I had to remove a lot of 'const' qualifiers because of API > > > >>>>>> changes in LLVM. > > > >>>>>> - Most other changes have to do with the split of the oop and metadata > > > >>>>>> class hierarchies in Hotspot. > > > >>>>>> - Then there have been a few changes caused by LLVM changes and > > > >>>>>> improvements, most notably the LLVM intrinsics for atomic operations > > > >>>>>> (memory barrier and cmpxchg) have been removed and now have a > > > >>>>>> representation directly in LLVM's IR. This makes our code a little > > > >>>>>> nicer. > > > >>>>>> > > > >>>>>> I tested this by running a number of applications, most notably Eclipse > > > >>>>>> (which is notoriously difficult on VMs), Java2Demo, SwingSet2 and a > > > >>>>>> bunch of other stuff. > > > >>>>>> > > > >>>>>> I would like to get this integrated into OpenJDK now if possible. You > > > >>>>>> can find the full webrev here: > > > >>>>>> > > > >>>>>> http://cr.openjdk.java.net/~rkennke/shark/webrev.00/ > > > >>>>> > > > >>>>> The changes seem to touch almost only shark files so these should be fine. One question though: > > > >>>>> > > > >>>>> + develop(bool, SharkShowCompiledMethods, false, \ > > > >>>>> > > > >>>>> Isn't PrintCompilation doing that already? > > > >>>>> > > > >>>>> The shared code changes look good. I filed: > > > >>>>> > > > >>>>> 8003868: fix shark for latest HotSpot and LLVM > > > >>>>> > > > >>>>> -- Chris > > > >>>>> > > > >>>>>> > > > >>>>>> There are also a very minor change required in JDK: > > > >>>>>> > > > >>>>>> http://cr.openjdk.java.net/~rkennke/shark/webrev-jdk-00/ > > > >>>>>> > > > >>>>>> In order to build it, apply the patches on hsx/hotspot-comp 's hotspot > > > >>>>>> and jdk repositories respectivly. Find my build script here: > > > >>>>>> > > > >>>>>> http://cr.openjdk.java.net/~rkennke/shark/Build8-zero-shark > > > >>>>>> > > > >>>>>> (Review and adjust variables to your settings, most notably you will > > > >>>>>> need to change LLVM_CONFIG to point to your LLVM 3.1 installation.) > > > >>>>>> > > > >>>>>> Please let me know if there are any issues or how we can get this > > > >>>>>> integrated into Hotspot. > > > >>>> > > > >>>> Finally I installed LLVM on one of our machines to be able to do a Shark build once in a while. When I try to do a jvmgshark build I get: > > > >>>> > > > >>>> In file included from /usr/local/include/llvm/Support/PointerLikeTypeTraits.h:18, > > > >>>> from /usr/local/include/llvm/ADT/PointerIntPair.h:17, > > > >>>> from /usr/local/include/llvm/Use.h:28, > > > >>>> from /usr/local/include/llvm/Value.h:17, > > > >>>> from /usr/local/include/llvm/Argument.h:17, > > > >>>> from /home/cthaling/8003868/src/share/vm/shark/llvmHeaders.hpp:39, > > > >>>> from /home/cthaling/8003868/src/share/vm/shark/sharkEntry.hpp:29, > > > >>>> from /home/cthaling/8003868/src/share/vm/compiler/disassembler.cpp:51: > > > >>>> /usr/local/include/llvm/Support/DataTypes.h:53:3: error: #error "Must #define __STDC_CONSTANT_MACROS before " "#including Support/DataTypes.h" > > > >>>> > > > >>>> and: > > > >>>> > > > >>>> In file included from /usr/local/include/llvm/Attributes.h:18, > > > >>>> from /usr/local/include/llvm/Argument.h:18, > > > >>>> from /home/cthaling/8003868/src/share/vm/shark/llvmHeaders.hpp:39, > > > >>>> from /home/cthaling/8003868/src/share/vm/shark/sharkEntry.hpp:29, > > > >>>> from /home/cthaling/8003868/src/share/vm/compiler/disassembler.cpp:51: > > > >>>> /usr/local/include/llvm/Support/MathExtras.h: In function ?bool llvm::isInt(int64_t)?: > > > >>>> /usr/local/include/llvm/Support/MathExtras.h:38: error: there are no arguments to ?INT64_C? that depend on a template parameter, so a declaration of ?INT64_C? must be available > > > >>>> /usr/local/include/llvm/Support/MathExtras.h:38: note: (if you use ?-fpermissive?, G++ will accept your code, but allowing the use of an undeclared name is deprecated) > > > >>>> /usr/local/include/llvm/Support/MathExtras.h:38: error: there are no arguments to ?INT64_C? that depend on a template parameter, so a declaration of ?INT64_C? must be available > > > >>>> /usr/local/include/llvm/Support/MathExtras.h: In function ?bool llvm::isUInt(uint64_t)?: > > > >>>> /usr/local/include/llvm/Support/MathExtras.h:64: error: there are no arguments to ?UINT64_C? that depend on a template parameter, so a declaration of ?UINT64_C? must be available > > > >>>> /usr/local/include/llvm/Support/MathExtras.h: In function ?bool llvm::isIntN(unsigned int, int64_t)?: > > > >>>> /usr/local/include/llvm/Support/MathExtras.h:96: error: ?INT64_C? was not declared in this scope > > > >>>> > > > >>>> Not sure if the latter is because of the former one. Have you seen this before? > > > >>> > > > >>> Yes, it's caused by the former. And yes, I have seen it before. IIRC, > > > >>> this happens when certain cflags are not set correctly. The script > > > >>> jdk/make/jdk_generic_profile.sh will call llvm-config to figure out the > > > >>> correct flags. In order for this to work, you need to have the full path > > > >>> to the llvm-config script set in the LLVM_CONFIG env variable. Were you > > > >>> using the build script that I provided? > > > >> > > > >> No. I took your script and got the important environment variables. But I missed the LLVM_* ones. Usually we only build hotspot so we don't have this jdk script. > > > >> > > > >> Now that I have the LLVM_* variables it's even worse: > > > >> > > > >> /home/cthaling/8003868/src/share/vm/oops/oop.hpp:72: error: cast from type ?markOopDesc* const volatile*? to type ?markOopDesc**? casts away constness > > > >> > > > >> It's probably this guy: -Wcast-qual > > > > > > > > Got it: > > > > > > > > $ java -version > > > > java version "1.8.0-ea" > > > > Java(TM) SE Runtime Environment (build 1.8.0-ea-b65) > > > > OpenJDK 64-Bit Shark VM (build 25.0-b11-internal-jvmg, mixed mode) > > > > > > I ran the compiler regression tests and Shark crashes in 5091921: > > > > > > cthaling at intelsdv03.us.oracle.com:~/8003868/test$ jtreg -workDir:$EXPORTHOME/jtreg -reportDir:$EXPORTHOME/jtreg -testjdk:$JAVA_HOME -verbose:summary compiler/5091921/ > > > Directory "/export/twisti/jtreg/scratch" not found: creating > > > Passed: compiler/5091921/Test5091921.java > > > Passed: compiler/5091921/Test6186134.java > > > Passed: compiler/5091921/Test6196102.java > > > Passed: compiler/5091921/Test6357214.java > > > Passed: compiler/5091921/Test6559156.java > > > Passed: compiler/5091921/Test6753639.java > > > Passed: compiler/5091921/Test6850611.java > > > Passed: compiler/5091921/Test6890943.java > > > Passed: compiler/5091921/Test6897150.java > > > Passed: compiler/5091921/Test6905845.java > > > Passed: compiler/5091921/Test6931567.java > > > /net/sqenfs-1.us.oracle.com/export1/comp/vm/tool/jtreg/execution/linux/bin/jtreg: line 139: 27784 Segmentation fault (core dumped) "${JT_JAVA}" $javaOpts -Dprogram=`basename "$0"` -jar "${JT_HOME}/lib/jtreg.jar" $jtregOpts > > > > > > You can also run all them with a simple make in test/ by setting: > > > > > > PRODUCT_HOME=$JAVA_HOME > > > TESTDIRS=compiler > > > > > > > This is interesting. I am not getting segfaults, but trip over > > assertions inside LLVM (probably the same thingy). I tried looking (and > > running through verifier) at the LLVM IR code, but nothing suspicious. > > Then I turned off optimizations in LLVM and suddenly everything passed > > (except for some tests that time out... probably performance tests that > > time out because shark is too slow?). It could be a bug in LLVM, I > > suspect this: > > > > http://llvm.org/bugs/show_bug.cgi?id=12470 > > > > I am not sure though. I added a -XX:SharkOptimizationLevel switch to > > select an optimization level at runtime. I will also check out the > > LLVM-3.2 RC code and see if that's any better. I will keep you posted. > > So I tried with 3.2. Good news is that only minimal changes in Shark are > required to do this, and another good news is that it does indeed make > the crash go away :-) Will send out the patch later tonight (needs > cleanup, and I need food ;-) ). Ok, so here it comes: http://cr.openjdk.java.net/~rkennke/shark/webrev.02/ The changes are (basically to enable support for LLVM3.2): - Changed include for llvm/Support/IRBuilder.h > llvm/IRBuilder.h and kept the old one in an #if SHARK_LLVM_VERSION <= 31 block. - Added -XX:SharkOptimizationLevel=None|Less|Default|Aggressive option, which is passed through to LLVM. - Changed -XX:+VerifyFunctions to -XX:VerifyFunction=$PATTERN to selectively verify functions. - Changed SetCurrentDebugType -> setCurrentDebugType (and kept old one in a version-check-block like above). - Changed call to LLVM intrinsic llvm.memset.i32 to llvm.memset.p0i8.i32 (that has already been changed pre-3.2, but apparently the old one is still working, but the verifier complains about it). I ran all the tests in test/compiler and they all pass, except one that timed out (dunno) and a few that failed with exceptions due to missing JSR292 and one segfault (haven't looked yet). Cheers, Roman From rkennke at redhat.com Fri Nov 23 09:14:48 2012 From: rkennke at redhat.com (Roman Kennke) Date: Fri, 23 Nov 2012 18:14:48 +0100 Subject: RFR (L): 8003868: fix shark for latest HotSpot and LLVM [Was: Re: RFR: Fix shark for latest Hotspot and LLVM] In-Reply-To: <6B77725B-3BCF-40E0-AF0B-77E58B36B095@oracle.com> References: <1353519094.1744.42.camel@mercury> <34C51B6D-6582-42AB-9BDE-2CF7D721532E@oracle.com> <1353531251.1744.53.camel@mercury> <32151B51-A2A1-4DE4-B5DD-B665E2548704@oracle.com> <6B77725B-3BCF-40E0-AF0B-77E58B36B095@oracle.com> Message-ID: <1353690888.31435.3.camel@mercury> Am Mittwoch, den 21.11.2012, 14:52 -0800 schrieb Christian Thalinger: > On Nov 21, 2012, at 2:22 PM, Christian Thalinger wrote: > > > > > On Nov 21, 2012, at 2:17 PM, Christian Thalinger wrote: > > > >> > >> On Nov 21, 2012, at 12:54 PM, Roman Kennke wrote: > >> > >>> Am Mittwoch, den 21.11.2012, 12:47 -0800 schrieb Christian Thalinger: > >>>> On Nov 21, 2012, at 11:43 AM, Christian Thalinger wrote: > >>>> > >>>>> On Nov 21, 2012, at 9:31 AM, Roman Kennke wrote: > >>>>> > >>>>>> Hi there, > >>>>>> > >>>>>> during the last days I worked on fixing the Shark compiler for Hotspot > >>>>>> to get it to build and run again, with the latest Hotspot code and LLVM. > >>>>>> Here are some details: > >>>>>> > >>>>>> - A lot of changes are just to make it build and the compiler happy. For > >>>>>> example, I had to remove a lot of 'const' qualifiers because of API > >>>>>> changes in LLVM. > >>>>>> - Most other changes have to do with the split of the oop and metadata > >>>>>> class hierarchies in Hotspot. > >>>>>> - Then there have been a few changes caused by LLVM changes and > >>>>>> improvements, most notably the LLVM intrinsics for atomic operations > >>>>>> (memory barrier and cmpxchg) have been removed and now have a > >>>>>> representation directly in LLVM's IR. This makes our code a little > >>>>>> nicer. > >>>>>> > >>>>>> I tested this by running a number of applications, most notably Eclipse > >>>>>> (which is notoriously difficult on VMs), Java2Demo, SwingSet2 and a > >>>>>> bunch of other stuff. > >>>>>> > >>>>>> I would like to get this integrated into OpenJDK now if possible. You > >>>>>> can find the full webrev here: > >>>>>> > >>>>>> http://cr.openjdk.java.net/~rkennke/shark/webrev.00/ > >>>>> > >>>>> The changes seem to touch almost only shark files so these should be fine. One question though: > >>>>> > >>>>> + develop(bool, SharkShowCompiledMethods, false, \ > >>>>> > >>>>> Isn't PrintCompilation doing that already? > >>>>> > >>>>> The shared code changes look good. I filed: > >>>>> > >>>>> 8003868: fix shark for latest HotSpot and LLVM > >>>>> > >>>>> -- Chris > >>>>> > >>>>>> > >>>>>> There are also a very minor change required in JDK: > >>>>>> > >>>>>> http://cr.openjdk.java.net/~rkennke/shark/webrev-jdk-00/ > >>>>>> > >>>>>> In order to build it, apply the patches on hsx/hotspot-comp 's hotspot > >>>>>> and jdk repositories respectivly. Find my build script here: > >>>>>> > >>>>>> http://cr.openjdk.java.net/~rkennke/shark/Build8-zero-shark > >>>>>> > >>>>>> (Review and adjust variables to your settings, most notably you will > >>>>>> need to change LLVM_CONFIG to point to your LLVM 3.1 installation.) > >>>>>> > >>>>>> Please let me know if there are any issues or how we can get this > >>>>>> integrated into Hotspot. > >>>> > >>>> Finally I installed LLVM on one of our machines to be able to do a Shark build once in a while. When I try to do a jvmgshark build I get: > >>>> > >>>> In file included from /usr/local/include/llvm/Support/PointerLikeTypeTraits.h:18, > >>>> from /usr/local/include/llvm/ADT/PointerIntPair.h:17, > >>>> from /usr/local/include/llvm/Use.h:28, > >>>> from /usr/local/include/llvm/Value.h:17, > >>>> from /usr/local/include/llvm/Argument.h:17, > >>>> from /home/cthaling/8003868/src/share/vm/shark/llvmHeaders.hpp:39, > >>>> from /home/cthaling/8003868/src/share/vm/shark/sharkEntry.hpp:29, > >>>> from /home/cthaling/8003868/src/share/vm/compiler/disassembler.cpp:51: > >>>> /usr/local/include/llvm/Support/DataTypes.h:53:3: error: #error "Must #define __STDC_CONSTANT_MACROS before " "#including Support/DataTypes.h" > >>>> > >>>> and: > >>>> > >>>> In file included from /usr/local/include/llvm/Attributes.h:18, > >>>> from /usr/local/include/llvm/Argument.h:18, > >>>> from /home/cthaling/8003868/src/share/vm/shark/llvmHeaders.hpp:39, > >>>> from /home/cthaling/8003868/src/share/vm/shark/sharkEntry.hpp:29, > >>>> from /home/cthaling/8003868/src/share/vm/compiler/disassembler.cpp:51: > >>>> /usr/local/include/llvm/Support/MathExtras.h: In function ?bool llvm::isInt(int64_t)?: > >>>> /usr/local/include/llvm/Support/MathExtras.h:38: error: there are no arguments to ?INT64_C? that depend on a template parameter, so a declaration of ?INT64_C? must be available > >>>> /usr/local/include/llvm/Support/MathExtras.h:38: note: (if you use ?-fpermissive?, G++ will accept your code, but allowing the use of an undeclared name is deprecated) > >>>> /usr/local/include/llvm/Support/MathExtras.h:38: error: there are no arguments to ?INT64_C? that depend on a template parameter, so a declaration of ?INT64_C? must be available > >>>> /usr/local/include/llvm/Support/MathExtras.h: In function ?bool llvm::isUInt(uint64_t)?: > >>>> /usr/local/include/llvm/Support/MathExtras.h:64: error: there are no arguments to ?UINT64_C? that depend on a template parameter, so a declaration of ?UINT64_C? must be available > >>>> /usr/local/include/llvm/Support/MathExtras.h: In function ?bool llvm::isIntN(unsigned int, int64_t)?: > >>>> /usr/local/include/llvm/Support/MathExtras.h:96: error: ?INT64_C? was not declared in this scope > >>>> > >>>> Not sure if the latter is because of the former one. Have you seen this before? > >>> > >>> Yes, it's caused by the former. And yes, I have seen it before. IIRC, > >>> this happens when certain cflags are not set correctly. The script > >>> jdk/make/jdk_generic_profile.sh will call llvm-config to figure out the > >>> correct flags. In order for this to work, you need to have the full path > >>> to the llvm-config script set in the LLVM_CONFIG env variable. Were you > >>> using the build script that I provided? > >> > >> No. I took your script and got the important environment variables. But I missed the LLVM_* ones. Usually we only build hotspot so we don't have this jdk script. > >> > >> Now that I have the LLVM_* variables it's even worse: > >> > >> /home/cthaling/8003868/src/share/vm/oops/oop.hpp:72: error: cast from type ?markOopDesc* const volatile*? to type ?markOopDesc**? casts away constness > >> > >> It's probably this guy: -Wcast-qual > > > > Got it: > > > > $ java -version > > java version "1.8.0-ea" > > Java(TM) SE Runtime Environment (build 1.8.0-ea-b65) > > OpenJDK 64-Bit Shark VM (build 25.0-b11-internal-jvmg, mixed mode) > > I ran the compiler regression tests and Shark crashes in 5091921: > > cthaling at intelsdv03.us.oracle.com:~/8003868/test$ jtreg -workDir:$EXPORTHOME/jtreg -reportDir:$EXPORTHOME/jtreg -testjdk:$JAVA_HOME -verbose:summary compiler/5091921/ > Directory "/export/twisti/jtreg/scratch" not found: creating > Passed: compiler/5091921/Test5091921.java > Passed: compiler/5091921/Test6186134.java > Passed: compiler/5091921/Test6196102.java > Passed: compiler/5091921/Test6357214.java > Passed: compiler/5091921/Test6559156.java > Passed: compiler/5091921/Test6753639.java > Passed: compiler/5091921/Test6850611.java > Passed: compiler/5091921/Test6890943.java > Passed: compiler/5091921/Test6897150.java > Passed: compiler/5091921/Test6905845.java > Passed: compiler/5091921/Test6931567.java > /net/sqenfs-1.us.oracle.com/export1/comp/vm/tool/jtreg/execution/linux/bin/jtreg: line 139: 27784 Segmentation fault (core dumped) "${JT_JAVA}" $javaOpts -Dprogram=`basename "$0"` -jar "${JT_HOME}/lib/jtreg.jar" $jtregOpts > > You can also run all them with a simple make in test/ by setting: > > PRODUCT_HOME=$JAVA_HOME > TESTDIRS=compiler Alright, I found another fairly grave bug that I would like to include a fix for: apparently, a 'fence' is not enough of a memory barrier for volatile putfield/getfield (duh). Which basically broke all of j.u.c. LLVM offers atomic loads and stores, which seem to be exactly what is needed for volatile field access. However, it does not provide helper functions for those in llvm::IRBuilder so I wrote my own. This should be the final patch for now (unless you find something else). http://cr.openjdk.java.net/~rkennke/shark/webrev.03/ Cheers, Roman From aph at redhat.com Mon Nov 26 01:50:10 2012 From: aph at redhat.com (Andrew Haley) Date: Mon, 26 Nov 2012 09:50:10 +0000 Subject: RFR (L): 8003868: fix shark for latest HotSpot and LLVM [Was: Re: RFR: Fix shark for latest Hotspot and LLVM] In-Reply-To: <1353690888.31435.3.camel@mercury> References: <1353519094.1744.42.camel@mercury> <34C51B6D-6582-42AB-9BDE-2CF7D721532E@oracle.com> <1353531251.1744.53.camel@mercury> <32151B51-A2A1-4DE4-B5DD-B665E2548704@oracle.com> <6B77725B-3BCF-40E0-AF0B-77E58B36B095@oracle.com> <1353690888.31435.3.camel@mercury> Message-ID: <50B33B52.1060404@redhat.com> On 11/23/2012 05:14 PM, Roman Kennke wrote: > > Alright, I found another fairly grave bug that I would like to include a > fix for: apparently, a 'fence' is not enough of a memory barrier for > volatile putfield/getfield (duh). Which basically broke all of j.u.c. > LLVM offers atomic loads and stores, which seem to be exactly what is > needed for volatile field access. However, it does not provide helper > functions for those in llvm::IRBuilder so I wrote my own. This should be > the final patch for now (unless you find something else). > > http://cr.openjdk.java.net/~rkennke/shark/webrev.03/ I note that you've used llvm::SequentiallyConsistent for all the atomic accesses. This looks right to me, but if there's any doubt you could ask Doug Lea. Andrew. From rkennke at redhat.com Mon Nov 26 04:58:29 2012 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 26 Nov 2012 13:58:29 +0100 Subject: RFR (L): 8003868: fix shark for latest HotSpot and LLVM [Was: Re: RFR: Fix shark for latest Hotspot and LLVM] In-Reply-To: <50B33B52.1060404@redhat.com> References: <1353519094.1744.42.camel@mercury> <34C51B6D-6582-42AB-9BDE-2CF7D721532E@oracle.com> <1353531251.1744.53.camel@mercury> <32151B51-A2A1-4DE4-B5DD-B665E2548704@oracle.com> <6B77725B-3BCF-40E0-AF0B-77E58B36B095@oracle.com> <1353690888.31435.3.camel@mercury> <50B33B52.1060404@redhat.com> Message-ID: <1353934709.7814.2.camel@mercury> Am Montag, den 26.11.2012, 09:50 +0000 schrieb Andrew Haley: > On 11/23/2012 05:14 PM, Roman Kennke wrote: > > > > > Alright, I found another fairly grave bug that I would like to include a > > fix for: apparently, a 'fence' is not enough of a memory barrier for > > volatile putfield/getfield (duh). Which basically broke all of j.u.c. > > LLVM offers atomic loads and stores, which seem to be exactly what is > > needed for volatile field access. However, it does not provide helper > > functions for those in llvm::IRBuilder so I wrote my own. This should be > > the final patch for now (unless you find something else). > > > > http://cr.openjdk.java.net/~rkennke/shark/webrev.03/ > > I note that you've used llvm::SequentiallyConsistent for all the atomic > accesses. This looks right to me, but if there's any doubt you could > ask Doug Lea. Yeah. Except for monitorenter and monitorexit, where I used Acquire and Release (which I believe is right too, at least it seems *very* sensible :-) ). The other access flags (unordered and monotonic) don't seem to have a mapping in Java, except maybe in some of the many Unsafe intrinsics, but they are not implemented in Shark (yet). Roman From rkennke at redhat.com Mon Nov 26 06:20:22 2012 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 26 Nov 2012 15:20:22 +0100 Subject: RFR (L): 8003868: fix shark for latest HotSpot and LLVM [Was: Re: RFR: Fix shark for latest Hotspot and LLVM] In-Reply-To: <50B369C1.4000607@oracle.com> References: <1353519094.1744.42.camel@mercury> <34C51B6D-6582-42AB-9BDE-2CF7D721532E@oracle.com> <1353531251.1744.53.camel@mercury> <32151B51-A2A1-4DE4-B5DD-B665E2548704@oracle.com> <6B77725B-3BCF-40E0-AF0B-77E58B36B095@oracle.com> <1353690888.31435.3.camel@mercury> <50B33B52.1060404@redhat.com> <1353934709.7814.2.camel@mercury> <50B369C1.4000607@oracle.com> Message-ID: <1353939622.7814.5.camel@mercury> Am Montag, den 26.11.2012, 17:08 +0400 schrieb Aleksey Shipilev: > On 11/26/2012 04:58 PM, Roman Kennke wrote: > > Am Montag, den 26.11.2012, 09:50 +0000 schrieb Andrew Haley: > >> On 11/23/2012 05:14 PM, Roman Kennke wrote: > >> > >>> > >>> Alright, I found another fairly grave bug that I would like to include a > >>> fix for: apparently, a 'fence' is not enough of a memory barrier for > >>> volatile putfield/getfield (duh). Which basically broke all of j.u.c. > >>> LLVM offers atomic loads and stores, which seem to be exactly what is > >>> needed for volatile field access. However, it does not provide helper > >>> functions for those in llvm::IRBuilder so I wrote my own. This should be > >>> the final patch for now (unless you find something else). > >>> > >>> http://cr.openjdk.java.net/~rkennke/shark/webrev.03/ > >> > >> I note that you've used llvm::SequentiallyConsistent for all the atomic > >> accesses. This looks right to me, but if there's any doubt you could > >> ask Doug Lea. > > > > Yeah. Except for monitorenter and monitorexit, where I used Acquire and > > Release (which I believe is right too, at least it seems *very* > > sensible :-) ). The other access flags (unordered and monotonic) don't > > seem to have a mapping in Java, except maybe in some of the many Unsafe > > intrinsics, but they are not implemented in Shark (yet). > > My 2c: making atomics SC is ok. I wonder if Shark can pass the > concurrency torture tests [1]? (if you run these, make sure you do that > against the latest hotspot-comp) Wow, that is a great test. As far as I can tell (in a short default-options run), Shark does everything correctly (i.e. all FORBIDDEN have 0 occurances, all REQUIRED do happen, etc). Speaking of hotspot-comp, I tried to run JVMSpec with Shark and it seemed to get stuck in one of the tests (don't remember which one). Then I tried it with latest hotspot-comp and it got stuck in the same place. (No idea what it was though, need to look closer when I find some time). Regards, Roman From rkennke at redhat.com Mon Nov 26 15:18:50 2012 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 27 Nov 2012 00:18:50 +0100 Subject: RFR (L): 8003868: fix shark for latest HotSpot and LLVM [Was: Re: RFR: Fix shark for latest Hotspot and LLVM] In-Reply-To: <13D4C44A-91EA-4175-A6E9-23FE2A3D7F79@oracle.com> References: <1353519094.1744.42.camel@mercury> <34C51B6D-6582-42AB-9BDE-2CF7D721532E@oracle.com> <1353531251.1744.53.camel@mercury> <32151B51-A2A1-4DE4-B5DD-B665E2548704@oracle.com> <6B77725B-3BCF-40E0-AF0B-77E58B36B095@oracle.com> <1353690888.31435.3.camel@mercury> <13D4C44A-91EA-4175-A6E9-23FE2A3D7F79@oracle.com> Message-ID: <1353971930.20183.3.camel@mercury> Am Montag, den 26.11.2012, 11:55 -0800 schrieb Christian Thalinger: > On Nov 23, 2012, at 9:14 AM, Roman Kennke wrote: > > > Am Mittwoch, den 21.11.2012, 14:52 -0800 schrieb Christian Thalinger: > >> On Nov 21, 2012, at 2:22 PM, Christian Thalinger wrote: > >> > >>> > >>> On Nov 21, 2012, at 2:17 PM, Christian Thalinger wrote: > >>> > >>>> > >>>> On Nov 21, 2012, at 12:54 PM, Roman Kennke wrote: > >>>> > >>>>> Am Mittwoch, den 21.11.2012, 12:47 -0800 schrieb Christian Thalinger: > >>>>>> On Nov 21, 2012, at 11:43 AM, Christian Thalinger wrote: > >>>>>> > >>>>>>> On Nov 21, 2012, at 9:31 AM, Roman Kennke wrote: > >>>>>>> > >>>>>>>> Hi there, > >>>>>>>> > >>>>>>>> during the last days I worked on fixing the Shark compiler for Hotspot > >>>>>>>> to get it to build and run again, with the latest Hotspot code and LLVM. > >>>>>>>> Here are some details: > >>>>>>>> > >>>>>>>> - A lot of changes are just to make it build and the compiler happy. For > >>>>>>>> example, I had to remove a lot of 'const' qualifiers because of API > >>>>>>>> changes in LLVM. > >>>>>>>> - Most other changes have to do with the split of the oop and metadata > >>>>>>>> class hierarchies in Hotspot. > >>>>>>>> - Then there have been a few changes caused by LLVM changes and > >>>>>>>> improvements, most notably the LLVM intrinsics for atomic operations > >>>>>>>> (memory barrier and cmpxchg) have been removed and now have a > >>>>>>>> representation directly in LLVM's IR. This makes our code a little > >>>>>>>> nicer. > >>>>>>>> > >>>>>>>> I tested this by running a number of applications, most notably Eclipse > >>>>>>>> (which is notoriously difficult on VMs), Java2Demo, SwingSet2 and a > >>>>>>>> bunch of other stuff. > >>>>>>>> > >>>>>>>> I would like to get this integrated into OpenJDK now if possible. You > >>>>>>>> can find the full webrev here: > >>>>>>>> > >>>>>>>> http://cr.openjdk.java.net/~rkennke/shark/webrev.00/ > >>>>>>> > >>>>>>> The changes seem to touch almost only shark files so these should be fine. One question though: > >>>>>>> > >>>>>>> + develop(bool, SharkShowCompiledMethods, false, \ > >>>>>>> > >>>>>>> Isn't PrintCompilation doing that already? > >>>>>>> > >>>>>>> The shared code changes look good. I filed: > >>>>>>> > >>>>>>> 8003868: fix shark for latest HotSpot and LLVM > >>>>>>> > >>>>>>> -- Chris > >>>>>>> > >>>>>>>> > >>>>>>>> There are also a very minor change required in JDK: > >>>>>>>> > >>>>>>>> http://cr.openjdk.java.net/~rkennke/shark/webrev-jdk-00/ > >>>>>>>> > >>>>>>>> In order to build it, apply the patches on hsx/hotspot-comp 's hotspot > >>>>>>>> and jdk repositories respectivly. Find my build script here: > >>>>>>>> > >>>>>>>> http://cr.openjdk.java.net/~rkennke/shark/Build8-zero-shark > >>>>>>>> > >>>>>>>> (Review and adjust variables to your settings, most notably you will > >>>>>>>> need to change LLVM_CONFIG to point to your LLVM 3.1 installation.) > >>>>>>>> > >>>>>>>> Please let me know if there are any issues or how we can get this > >>>>>>>> integrated into Hotspot. > >>>>>> > >>>>>> Finally I installed LLVM on one of our machines to be able to do a Shark build once in a while. When I try to do a jvmgshark build I get: > >>>>>> > >>>>>> In file included from /usr/local/include/llvm/Support/PointerLikeTypeTraits.h:18, > >>>>>> from /usr/local/include/llvm/ADT/PointerIntPair.h:17, > >>>>>> from /usr/local/include/llvm/Use.h:28, > >>>>>> from /usr/local/include/llvm/Value.h:17, > >>>>>> from /usr/local/include/llvm/Argument.h:17, > >>>>>> from /home/cthaling/8003868/src/share/vm/shark/llvmHeaders.hpp:39, > >>>>>> from /home/cthaling/8003868/src/share/vm/shark/sharkEntry.hpp:29, > >>>>>> from /home/cthaling/8003868/src/share/vm/compiler/disassembler.cpp:51: > >>>>>> /usr/local/include/llvm/Support/DataTypes.h:53:3: error: #error "Must #define __STDC_CONSTANT_MACROS before " "#including Support/DataTypes.h" > >>>>>> > >>>>>> and: > >>>>>> > >>>>>> In file included from /usr/local/include/llvm/Attributes.h:18, > >>>>>> from /usr/local/include/llvm/Argument.h:18, > >>>>>> from /home/cthaling/8003868/src/share/vm/shark/llvmHeaders.hpp:39, > >>>>>> from /home/cthaling/8003868/src/share/vm/shark/sharkEntry.hpp:29, > >>>>>> from /home/cthaling/8003868/src/share/vm/compiler/disassembler.cpp:51: > >>>>>> /usr/local/include/llvm/Support/MathExtras.h: In function ?bool llvm::isInt(int64_t)?: > >>>>>> /usr/local/include/llvm/Support/MathExtras.h:38: error: there are no arguments to ?INT64_C? that depend on a template parameter, so a declaration of ?INT64_C? must be available > >>>>>> /usr/local/include/llvm/Support/MathExtras.h:38: note: (if you use ?-fpermissive?, G++ will accept your code, but allowing the use of an undeclared name is deprecated) > >>>>>> /usr/local/include/llvm/Support/MathExtras.h:38: error: there are no arguments to ?INT64_C? that depend on a template parameter, so a declaration of ?INT64_C? must be available > >>>>>> /usr/local/include/llvm/Support/MathExtras.h: In function ?bool llvm::isUInt(uint64_t)?: > >>>>>> /usr/local/include/llvm/Support/MathExtras.h:64: error: there are no arguments to ?UINT64_C? that depend on a template parameter, so a declaration of ?UINT64_C? must be available > >>>>>> /usr/local/include/llvm/Support/MathExtras.h: In function ?bool llvm::isIntN(unsigned int, int64_t)?: > >>>>>> /usr/local/include/llvm/Support/MathExtras.h:96: error: ?INT64_C? was not declared in this scope > >>>>>> > >>>>>> Not sure if the latter is because of the former one. Have you seen this before? > >>>>> > >>>>> Yes, it's caused by the former. And yes, I have seen it before. IIRC, > >>>>> this happens when certain cflags are not set correctly. The script > >>>>> jdk/make/jdk_generic_profile.sh will call llvm-config to figure out the > >>>>> correct flags. In order for this to work, you need to have the full path > >>>>> to the llvm-config script set in the LLVM_CONFIG env variable. Were you > >>>>> using the build script that I provided? > >>>> > >>>> No. I took your script and got the important environment variables. But I missed the LLVM_* ones. Usually we only build hotspot so we don't have this jdk script. > >>>> > >>>> Now that I have the LLVM_* variables it's even worse: > >>>> > >>>> /home/cthaling/8003868/src/share/vm/oops/oop.hpp:72: error: cast from type ?markOopDesc* const volatile*? to type ?markOopDesc**? casts away constness > >>>> > >>>> It's probably this guy: -Wcast-qual > >>> > >>> Got it: > >>> > >>> $ java -version > >>> java version "1.8.0-ea" > >>> Java(TM) SE Runtime Environment (build 1.8.0-ea-b65) > >>> OpenJDK 64-Bit Shark VM (build 25.0-b11-internal-jvmg, mixed mode) > >> > >> I ran the compiler regression tests and Shark crashes in 5091921: > >> > >> cthaling at intelsdv03.us.oracle.com:~/8003868/test$ jtreg -workDir:$EXPORTHOME/jtreg -reportDir:$EXPORTHOME/jtreg -testjdk:$JAVA_HOME -verbose:summary compiler/5091921/ > >> Directory "/export/twisti/jtreg/scratch" not found: creating > >> Passed: compiler/5091921/Test5091921.java > >> Passed: compiler/5091921/Test6186134.java > >> Passed: compiler/5091921/Test6196102.java > >> Passed: compiler/5091921/Test6357214.java > >> Passed: compiler/5091921/Test6559156.java > >> Passed: compiler/5091921/Test6753639.java > >> Passed: compiler/5091921/Test6850611.java > >> Passed: compiler/5091921/Test6890943.java > >> Passed: compiler/5091921/Test6897150.java > >> Passed: compiler/5091921/Test6905845.java > >> Passed: compiler/5091921/Test6931567.java > >> /net/sqenfs-1.us.oracle.com/export1/comp/vm/tool/jtreg/execution/linux/bin/jtreg: line 139: 27784 Segmentation fault (core dumped) "${JT_JAVA}" $javaOpts -Dprogram=`basename "$0"` -jar "${JT_HOME}/lib/jtreg.jar" $jtregOpts > >> > >> You can also run all them with a simple make in test/ by setting: > >> > >> PRODUCT_HOME=$JAVA_HOME > >> TESTDIRS=compiler > > > > Alright, I found another fairly grave bug that I would like to include a > > fix for: apparently, a 'fence' is not enough of a memory barrier for > > volatile putfield/getfield (duh). Which basically broke all of j.u.c. > > LLVM offers atomic loads and stores, which seem to be exactly what is > > needed for volatile field access. However, it does not provide helper > > functions for those in llvm::IRBuilder so I wrote my own. This should be > > the final patch for now (unless you find something else). > > > > http://cr.openjdk.java.net/~rkennke/shark/webrev.03/ > > Hmm. Maybe I did something wrong but I've already rebuilt twice: > > $ java -Xcomp -version > Value type size is target-dependent. Ask TLI. > UNREACHABLE executed at /usr/local/src/llvm-3.1.src/include/llvm/CodeGen/ValueTypes.h:257! > Stack dump: > 0. Running pass 'X86 DAG->DAG Instruction Selection' on function '@"java.lang.System::getProperty"' > Aborted (core dumped) Arg! The last couple of changes I did only with LLVM3.2, where the problem disappears. Apparently, LLVM3.1 (and pre) don't deal well with atomic load/store :-( I re-introduced the CreateMemoryBarrier call and use that for SHARK_LLVM_VERSION <= 31. http://cr.openjdk.java.net/~rkennke/shark/webrev.04/ Hope that works better :-) Roman From rkennke at redhat.com Mon Nov 26 16:44:17 2012 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 27 Nov 2012 01:44:17 +0100 Subject: RFR (L): 8003868: fix shark for latest HotSpot and LLVM [Was: Re: RFR: Fix shark for latest Hotspot and LLVM] In-Reply-To: References: <1353519094.1744.42.camel@mercury> <34C51B6D-6582-42AB-9BDE-2CF7D721532E@oracle.com> <1353531251.1744.53.camel@mercury> <32151B51-A2A1-4DE4-B5DD-B665E2548704@oracle.com> <6B77725B-3BCF-40E0-AF0B-77E58B36B095@oracle.com> <1353690888.31435.3.camel@mercury> <13D4C44A-91EA-4175-A6E9-23FE2A3D7F79@oracle.com> <1353971930.20183.3.camel@mercury> Message-ID: <1353977057.20183.8.camel@mercury> Am Montag, den 26.11.2012, 15:43 -0800 schrieb Christian Thalinger: > On Nov 26, 2012, at 3:18 PM, Roman Kennke wrote: > > > Am Montag, den 26.11.2012, 11:55 -0800 schrieb Christian Thalinger: > >> On Nov 23, 2012, at 9:14 AM, Roman Kennke wrote: > >> > >>> Am Mittwoch, den 21.11.2012, 14:52 -0800 schrieb Christian Thalinger: > >>>> On Nov 21, 2012, at 2:22 PM, Christian Thalinger wrote: > >>>> > >>>>> > >>>>> On Nov 21, 2012, at 2:17 PM, Christian Thalinger wrote: > >>>>> > >>>>>> > >>>>>> On Nov 21, 2012, at 12:54 PM, Roman Kennke wrote: > >>>>>> > >>>>>>> Am Mittwoch, den 21.11.2012, 12:47 -0800 schrieb Christian Thalinger: > >>>>>>>> On Nov 21, 2012, at 11:43 AM, Christian Thalinger wrote: > >>>>>>>> > >>>>>>>>> On Nov 21, 2012, at 9:31 AM, Roman Kennke wrote: > >>>>>>>>> > >>>>>>>>>> Hi there, > >>>>>>>>>> > >>>>>>>>>> during the last days I worked on fixing the Shark compiler for Hotspot > >>>>>>>>>> to get it to build and run again, with the latest Hotspot code and LLVM. > >>>>>>>>>> Here are some details: > >>>>>>>>>> > >>>>>>>>>> - A lot of changes are just to make it build and the compiler happy. For > >>>>>>>>>> example, I had to remove a lot of 'const' qualifiers because of API > >>>>>>>>>> changes in LLVM. > >>>>>>>>>> - Most other changes have to do with the split of the oop and metadata > >>>>>>>>>> class hierarchies in Hotspot. > >>>>>>>>>> - Then there have been a few changes caused by LLVM changes and > >>>>>>>>>> improvements, most notably the LLVM intrinsics for atomic operations > >>>>>>>>>> (memory barrier and cmpxchg) have been removed and now have a > >>>>>>>>>> representation directly in LLVM's IR. This makes our code a little > >>>>>>>>>> nicer. > >>>>>>>>>> > >>>>>>>>>> I tested this by running a number of applications, most notably Eclipse > >>>>>>>>>> (which is notoriously difficult on VMs), Java2Demo, SwingSet2 and a > >>>>>>>>>> bunch of other stuff. > >>>>>>>>>> > >>>>>>>>>> I would like to get this integrated into OpenJDK now if possible. You > >>>>>>>>>> can find the full webrev here: > >>>>>>>>>> > >>>>>>>>>> http://cr.openjdk.java.net/~rkennke/shark/webrev.00/ > >>>>>>>>> > >>>>>>>>> The changes seem to touch almost only shark files so these should be fine. One question though: > >>>>>>>>> > >>>>>>>>> + develop(bool, SharkShowCompiledMethods, false, \ > >>>>>>>>> > >>>>>>>>> Isn't PrintCompilation doing that already? > >>>>>>>>> > >>>>>>>>> The shared code changes look good. I filed: > >>>>>>>>> > >>>>>>>>> 8003868: fix shark for latest HotSpot and LLVM > >>>>>>>>> > >>>>>>>>> -- Chris > >>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> There are also a very minor change required in JDK: > >>>>>>>>>> > >>>>>>>>>> http://cr.openjdk.java.net/~rkennke/shark/webrev-jdk-00/ > >>>>>>>>>> > >>>>>>>>>> In order to build it, apply the patches on hsx/hotspot-comp 's hotspot > >>>>>>>>>> and jdk repositories respectivly. Find my build script here: > >>>>>>>>>> > >>>>>>>>>> http://cr.openjdk.java.net/~rkennke/shark/Build8-zero-shark > >>>>>>>>>> > >>>>>>>>>> (Review and adjust variables to your settings, most notably you will > >>>>>>>>>> need to change LLVM_CONFIG to point to your LLVM 3.1 installation.) > >>>>>>>>>> > >>>>>>>>>> Please let me know if there are any issues or how we can get this > >>>>>>>>>> integrated into Hotspot. > >>>>>>>> > >>>>>>>> Finally I installed LLVM on one of our machines to be able to do a Shark build once in a while. When I try to do a jvmgshark build I get: > >>>>>>>> > >>>>>>>> In file included from /usr/local/include/llvm/Support/PointerLikeTypeTraits.h:18, > >>>>>>>> from /usr/local/include/llvm/ADT/PointerIntPair.h:17, > >>>>>>>> from /usr/local/include/llvm/Use.h:28, > >>>>>>>> from /usr/local/include/llvm/Value.h:17, > >>>>>>>> from /usr/local/include/llvm/Argument.h:17, > >>>>>>>> from /home/cthaling/8003868/src/share/vm/shark/llvmHeaders.hpp:39, > >>>>>>>> from /home/cthaling/8003868/src/share/vm/shark/sharkEntry.hpp:29, > >>>>>>>> from /home/cthaling/8003868/src/share/vm/compiler/disassembler.cpp:51: > >>>>>>>> /usr/local/include/llvm/Support/DataTypes.h:53:3: error: #error "Must #define __STDC_CONSTANT_MACROS before " "#including Support/DataTypes.h" > >>>>>>>> > >>>>>>>> and: > >>>>>>>> > >>>>>>>> In file included from /usr/local/include/llvm/Attributes.h:18, > >>>>>>>> from /usr/local/include/llvm/Argument.h:18, > >>>>>>>> from /home/cthaling/8003868/src/share/vm/shark/llvmHeaders.hpp:39, > >>>>>>>> from /home/cthaling/8003868/src/share/vm/shark/sharkEntry.hpp:29, > >>>>>>>> from /home/cthaling/8003868/src/share/vm/compiler/disassembler.cpp:51: > >>>>>>>> /usr/local/include/llvm/Support/MathExtras.h: In function ?bool llvm::isInt(int64_t)?: > >>>>>>>> /usr/local/include/llvm/Support/MathExtras.h:38: error: there are no arguments to ?INT64_C? that depend on a template parameter, so a declaration of ?INT64_C? must be available > >>>>>>>> /usr/local/include/llvm/Support/MathExtras.h:38: note: (if you use ?-fpermissive?, G++ will accept your code, but allowing the use of an undeclared name is deprecated) > >>>>>>>> /usr/local/include/llvm/Support/MathExtras.h:38: error: there are no arguments to ?INT64_C? that depend on a template parameter, so a declaration of ?INT64_C? must be available > >>>>>>>> /usr/local/include/llvm/Support/MathExtras.h: In function ?bool llvm::isUInt(uint64_t)?: > >>>>>>>> /usr/local/include/llvm/Support/MathExtras.h:64: error: there are no arguments to ?UINT64_C? that depend on a template parameter, so a declaration of ?UINT64_C? must be available > >>>>>>>> /usr/local/include/llvm/Support/MathExtras.h: In function ?bool llvm::isIntN(unsigned int, int64_t)?: > >>>>>>>> /usr/local/include/llvm/Support/MathExtras.h:96: error: ?INT64_C? was not declared in this scope > >>>>>>>> > >>>>>>>> Not sure if the latter is because of the former one. Have you seen this before? > >>>>>>> > >>>>>>> Yes, it's caused by the former. And yes, I have seen it before. IIRC, > >>>>>>> this happens when certain cflags are not set correctly. The script > >>>>>>> jdk/make/jdk_generic_profile.sh will call llvm-config to figure out the > >>>>>>> correct flags. In order for this to work, you need to have the full path > >>>>>>> to the llvm-config script set in the LLVM_CONFIG env variable. Were you > >>>>>>> using the build script that I provided? > >>>>>> > >>>>>> No. I took your script and got the important environment variables. But I missed the LLVM_* ones. Usually we only build hotspot so we don't have this jdk script. > >>>>>> > >>>>>> Now that I have the LLVM_* variables it's even worse: > >>>>>> > >>>>>> /home/cthaling/8003868/src/share/vm/oops/oop.hpp:72: error: cast from type ?markOopDesc* const volatile*? to type ?markOopDesc**? casts away constness > >>>>>> > >>>>>> It's probably this guy: -Wcast-qual > >>>>> > >>>>> Got it: > >>>>> > >>>>> $ java -version > >>>>> java version "1.8.0-ea" > >>>>> Java(TM) SE Runtime Environment (build 1.8.0-ea-b65) > >>>>> OpenJDK 64-Bit Shark VM (build 25.0-b11-internal-jvmg, mixed mode) > >>>> > >>>> I ran the compiler regression tests and Shark crashes in 5091921: > >>>> > >>>> cthaling at intelsdv03.us.oracle.com:~/8003868/test$ jtreg -workDir:$EXPORTHOME/jtreg -reportDir:$EXPORTHOME/jtreg -testjdk:$JAVA_HOME -verbose:summary compiler/5091921/ > >>>> Directory "/export/twisti/jtreg/scratch" not found: creating > >>>> Passed: compiler/5091921/Test5091921.java > >>>> Passed: compiler/5091921/Test6186134.java > >>>> Passed: compiler/5091921/Test6196102.java > >>>> Passed: compiler/5091921/Test6357214.java > >>>> Passed: compiler/5091921/Test6559156.java > >>>> Passed: compiler/5091921/Test6753639.java > >>>> Passed: compiler/5091921/Test6850611.java > >>>> Passed: compiler/5091921/Test6890943.java > >>>> Passed: compiler/5091921/Test6897150.java > >>>> Passed: compiler/5091921/Test6905845.java > >>>> Passed: compiler/5091921/Test6931567.java > >>>> /net/sqenfs-1.us.oracle.com/export1/comp/vm/tool/jtreg/execution/linux/bin/jtreg: line 139: 27784 Segmentation fault (core dumped) "${JT_JAVA}" $javaOpts -Dprogram=`basename "$0"` -jar "${JT_HOME}/lib/jtreg.jar" $jtregOpts > >>>> > >>>> You can also run all them with a simple make in test/ by setting: > >>>> > >>>> PRODUCT_HOME=$JAVA_HOME > >>>> TESTDIRS=compiler > >>> > >>> Alright, I found another fairly grave bug that I would like to include a > >>> fix for: apparently, a 'fence' is not enough of a memory barrier for > >>> volatile putfield/getfield (duh). Which basically broke all of j.u.c. > >>> LLVM offers atomic loads and stores, which seem to be exactly what is > >>> needed for volatile field access. However, it does not provide helper > >>> functions for those in llvm::IRBuilder so I wrote my own. This should be > >>> the final patch for now (unless you find something else). > >>> > >>> http://cr.openjdk.java.net/~rkennke/shark/webrev.03/ > >> > >> Hmm. Maybe I did something wrong but I've already rebuilt twice: > >> > >> $ java -Xcomp -version > >> Value type size is target-dependent. Ask TLI. > >> UNREACHABLE executed at /usr/local/src/llvm-3.1.src/include/llvm/CodeGen/ValueTypes.h:257! > >> Stack dump: > >> 0. Running pass 'X86 DAG->DAG Instruction Selection' on function '@"java.lang.System::getProperty"' > >> Aborted (core dumped) > > > > Arg! The last couple of changes I did only with LLVM3.2, where the > > problem disappears. Apparently, LLVM3.1 (and pre) don't deal well with > > atomic load/store :-( I re-introduced the CreateMemoryBarrier call and > > use that for SHARK_LLVM_VERSION <= 31. > > > > http://cr.openjdk.java.net/~rkennke/shark/webrev.04/ > > > > Hope that works better :-) > > I'm so sorry but... > > /export/twisti/build/8003868/build/linux_amd64_shark/product/libjvm.so: undefined reference to `SharkBuilder::memory_barrier()' Gaaa, what the... I thought I did clean rebuilds with both llvm3.2 and llvm3.1, but apparently not (maybe I shouldn't work after 1am). This (hopefully final final) patch re-instates the missing memory_barrier() method: http://cr.openjdk.java.net/~rkennke/shark/webrev.05/ Sorry for the messy back-and-forth. Roman From rkennke at redhat.com Tue Nov 27 09:24:26 2012 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 27 Nov 2012 18:24:26 +0100 Subject: RFR (L): 8003868: fix shark for latest HotSpot and LLVM [Was: Re: RFR: Fix shark for latest Hotspot and LLVM] In-Reply-To: References: <1353519094.1744.42.camel@mercury> <34C51B6D-6582-42AB-9BDE-2CF7D721532E@oracle.com> <1353531251.1744.53.camel@mercury> <32151B51-A2A1-4DE4-B5DD-B665E2548704@oracle.com> <6B77725B-3BCF-40E0-AF0B-77E58B36B095@oracle.com> <1353690888.31435.3.camel@mercury> <13D4C44A-91EA-4175-A6E9-23FE2A3D7F79@oracle.com> <1353971930.20183.3.camel@mercury> <1353977057.20183.8.camel@mercury> Message-ID: <1354037066.29268.10.camel@mercury> Am Montag, den 26.11.2012, 17:14 -0800 schrieb Christian Thalinger: > On Nov 26, 2012, at 4:44 PM, Roman Kennke wrote: > > > Am Montag, den 26.11.2012, 15:43 -0800 schrieb Christian Thalinger: > >> On Nov 26, 2012, at 3:18 PM, Roman Kennke wrote: > >> > >>> Am Montag, den 26.11.2012, 11:55 -0800 schrieb Christian Thalinger: > >>>> On Nov 23, 2012, at 9:14 AM, Roman Kennke wrote: > >>>> > >>>>> Am Mittwoch, den 21.11.2012, 14:52 -0800 schrieb Christian Thalinger: > >>>>>> On Nov 21, 2012, at 2:22 PM, Christian Thalinger wrote: > >>>>>> > >>>>>>> > >>>>>>> On Nov 21, 2012, at 2:17 PM, Christian Thalinger wrote: > >>>>>>> > >>>>>>>> > >>>>>>>> On Nov 21, 2012, at 12:54 PM, Roman Kennke wrote: > >>>>>>>> > >>>>>>>>> Am Mittwoch, den 21.11.2012, 12:47 -0800 schrieb Christian Thalinger: > >>>>>>>>>> On Nov 21, 2012, at 11:43 AM, Christian Thalinger wrote: > >>>>>>>>>> > >>>>>>>>>>> On Nov 21, 2012, at 9:31 AM, Roman Kennke wrote: > >>>>>>>>>>> > >>>>>>>>>>>> Hi there, > >>>>>>>>>>>> > >>>>>>>>>>>> during the last days I worked on fixing the Shark compiler for Hotspot > >>>>>>>>>>>> to get it to build and run again, with the latest Hotspot code and LLVM. > >>>>>>>>>>>> Here are some details: > >>>>>>>>>>>> > >>>>>>>>>>>> - A lot of changes are just to make it build and the compiler happy. For > >>>>>>>>>>>> example, I had to remove a lot of 'const' qualifiers because of API > >>>>>>>>>>>> changes in LLVM. > >>>>>>>>>>>> - Most other changes have to do with the split of the oop and metadata > >>>>>>>>>>>> class hierarchies in Hotspot. > >>>>>>>>>>>> - Then there have been a few changes caused by LLVM changes and > >>>>>>>>>>>> improvements, most notably the LLVM intrinsics for atomic operations > >>>>>>>>>>>> (memory barrier and cmpxchg) have been removed and now have a > >>>>>>>>>>>> representation directly in LLVM's IR. This makes our code a little > >>>>>>>>>>>> nicer. > >>>>>>>>>>>> > >>>>>>>>>>>> I tested this by running a number of applications, most notably Eclipse > >>>>>>>>>>>> (which is notoriously difficult on VMs), Java2Demo, SwingSet2 and a > >>>>>>>>>>>> bunch of other stuff. > >>>>>>>>>>>> > >>>>>>>>>>>> I would like to get this integrated into OpenJDK now if possible. You > >>>>>>>>>>>> can find the full webrev here: > >>>>>>>>>>>> > >>>>>>>>>>>> http://cr.openjdk.java.net/~rkennke/shark/webrev.00/ > >>>>>>>>>>> > >>>>>>>>>>> The changes seem to touch almost only shark files so these should be fine. One question though: > >>>>>>>>>>> > >>>>>>>>>>> + develop(bool, SharkShowCompiledMethods, false, \ > >>>>>>>>>>> > >>>>>>>>>>> Isn't PrintCompilation doing that already? > >>>>>>>>>>> > >>>>>>>>>>> The shared code changes look good. I filed: > >>>>>>>>>>> > >>>>>>>>>>> 8003868: fix shark for latest HotSpot and LLVM > >>>>>>>>>>> > >>>>>>>>>>> -- Chris > >>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> There are also a very minor change required in JDK: > >>>>>>>>>>>> > >>>>>>>>>>>> http://cr.openjdk.java.net/~rkennke/shark/webrev-jdk-00/ > >>>>>>>>>>>> > >>>>>>>>>>>> In order to build it, apply the patches on hsx/hotspot-comp 's hotspot > >>>>>>>>>>>> and jdk repositories respectivly. Find my build script here: > >>>>>>>>>>>> > >>>>>>>>>>>> http://cr.openjdk.java.net/~rkennke/shark/Build8-zero-shark > >>>>>>>>>>>> > >>>>>>>>>>>> (Review and adjust variables to your settings, most notably you will > >>>>>>>>>>>> need to change LLVM_CONFIG to point to your LLVM 3.1 installation.) > >>>>>>>>>>>> > >>>>>>>>>>>> Please let me know if there are any issues or how we can get this > >>>>>>>>>>>> integrated into Hotspot. > >>>>>>>>>> > >>>>>>>>>> Finally I installed LLVM on one of our machines to be able to do a Shark build once in a while. When I try to do a jvmgshark build I get: > >>>>>>>>>> > >>>>>>>>>> In file included from /usr/local/include/llvm/Support/PointerLikeTypeTraits.h:18, > >>>>>>>>>> from /usr/local/include/llvm/ADT/PointerIntPair.h:17, > >>>>>>>>>> from /usr/local/include/llvm/Use.h:28, > >>>>>>>>>> from /usr/local/include/llvm/Value.h:17, > >>>>>>>>>> from /usr/local/include/llvm/Argument.h:17, > >>>>>>>>>> from /home/cthaling/8003868/src/share/vm/shark/llvmHeaders.hpp:39, > >>>>>>>>>> from /home/cthaling/8003868/src/share/vm/shark/sharkEntry.hpp:29, > >>>>>>>>>> from /home/cthaling/8003868/src/share/vm/compiler/disassembler.cpp:51: > >>>>>>>>>> /usr/local/include/llvm/Support/DataTypes.h:53:3: error: #error "Must #define __STDC_CONSTANT_MACROS before " "#including Support/DataTypes.h" > >>>>>>>>>> > >>>>>>>>>> and: > >>>>>>>>>> > >>>>>>>>>> In file included from /usr/local/include/llvm/Attributes.h:18, > >>>>>>>>>> from /usr/local/include/llvm/Argument.h:18, > >>>>>>>>>> from /home/cthaling/8003868/src/share/vm/shark/llvmHeaders.hpp:39, > >>>>>>>>>> from /home/cthaling/8003868/src/share/vm/shark/sharkEntry.hpp:29, > >>>>>>>>>> from /home/cthaling/8003868/src/share/vm/compiler/disassembler.cpp:51: > >>>>>>>>>> /usr/local/include/llvm/Support/MathExtras.h: In function ?bool llvm::isInt(int64_t)?: > >>>>>>>>>> /usr/local/include/llvm/Support/MathExtras.h:38: error: there are no arguments to ?INT64_C? that depend on a template parameter, so a declaration of ?INT64_C? must be available > >>>>>>>>>> /usr/local/include/llvm/Support/MathExtras.h:38: note: (if you use ?-fpermissive?, G++ will accept your code, but allowing the use of an undeclared name is deprecated) > >>>>>>>>>> /usr/local/include/llvm/Support/MathExtras.h:38: error: there are no arguments to ?INT64_C? that depend on a template parameter, so a declaration of ?INT64_C? must be available > >>>>>>>>>> /usr/local/include/llvm/Support/MathExtras.h: In function ?bool llvm::isUInt(uint64_t)?: > >>>>>>>>>> /usr/local/include/llvm/Support/MathExtras.h:64: error: there are no arguments to ?UINT64_C? that depend on a template parameter, so a declaration of ?UINT64_C? must be available > >>>>>>>>>> /usr/local/include/llvm/Support/MathExtras.h: In function ?bool llvm::isIntN(unsigned int, int64_t)?: > >>>>>>>>>> /usr/local/include/llvm/Support/MathExtras.h:96: error: ?INT64_C? was not declared in this scope > >>>>>>>>>> > >>>>>>>>>> Not sure if the latter is because of the former one. Have you seen this before? > >>>>>>>>> > >>>>>>>>> Yes, it's caused by the former. And yes, I have seen it before. IIRC, > >>>>>>>>> this happens when certain cflags are not set correctly. The script > >>>>>>>>> jdk/make/jdk_generic_profile.sh will call llvm-config to figure out the > >>>>>>>>> correct flags. In order for this to work, you need to have the full path > >>>>>>>>> to the llvm-config script set in the LLVM_CONFIG env variable. Were you > >>>>>>>>> using the build script that I provided? > >>>>>>>> > >>>>>>>> No. I took your script and got the important environment variables. But I missed the LLVM_* ones. Usually we only build hotspot so we don't have this jdk script. > >>>>>>>> > >>>>>>>> Now that I have the LLVM_* variables it's even worse: > >>>>>>>> > >>>>>>>> /home/cthaling/8003868/src/share/vm/oops/oop.hpp:72: error: cast from type ?markOopDesc* const volatile*? to type ?markOopDesc**? casts away constness > >>>>>>>> > >>>>>>>> It's probably this guy: -Wcast-qual > >>>>>>> > >>>>>>> Got it: > >>>>>>> > >>>>>>> $ java -version > >>>>>>> java version "1.8.0-ea" > >>>>>>> Java(TM) SE Runtime Environment (build 1.8.0-ea-b65) > >>>>>>> OpenJDK 64-Bit Shark VM (build 25.0-b11-internal-jvmg, mixed mode) > >>>>>> > >>>>>> I ran the compiler regression tests and Shark crashes in 5091921: > >>>>>> > >>>>>> cthaling at intelsdv03.us.oracle.com:~/8003868/test$ jtreg -workDir:$EXPORTHOME/jtreg -reportDir:$EXPORTHOME/jtreg -testjdk:$JAVA_HOME -verbose:summary compiler/5091921/ > >>>>>> Directory "/export/twisti/jtreg/scratch" not found: creating > >>>>>> Passed: compiler/5091921/Test5091921.java > >>>>>> Passed: compiler/5091921/Test6186134.java > >>>>>> Passed: compiler/5091921/Test6196102.java > >>>>>> Passed: compiler/5091921/Test6357214.java > >>>>>> Passed: compiler/5091921/Test6559156.java > >>>>>> Passed: compiler/5091921/Test6753639.java > >>>>>> Passed: compiler/5091921/Test6850611.java > >>>>>> Passed: compiler/5091921/Test6890943.java > >>>>>> Passed: compiler/5091921/Test6897150.java > >>>>>> Passed: compiler/5091921/Test6905845.java > >>>>>> Passed: compiler/5091921/Test6931567.java > >>>>>> /net/sqenfs-1.us.oracle.com/export1/comp/vm/tool/jtreg/execution/linux/bin/jtreg: line 139: 27784 Segmentation fault (core dumped) "${JT_JAVA}" $javaOpts -Dprogram=`basename "$0"` -jar "${JT_HOME}/lib/jtreg.jar" $jtregOpts > >>>>>> > >>>>>> You can also run all them with a simple make in test/ by setting: > >>>>>> > >>>>>> PRODUCT_HOME=$JAVA_HOME > >>>>>> TESTDIRS=compiler > >>>>> > >>>>> Alright, I found another fairly grave bug that I would like to include a > >>>>> fix for: apparently, a 'fence' is not enough of a memory barrier for > >>>>> volatile putfield/getfield (duh). Which basically broke all of j.u.c. > >>>>> LLVM offers atomic loads and stores, which seem to be exactly what is > >>>>> needed for volatile field access. However, it does not provide helper > >>>>> functions for those in llvm::IRBuilder so I wrote my own. This should be > >>>>> the final patch for now (unless you find something else). > >>>>> > >>>>> http://cr.openjdk.java.net/~rkennke/shark/webrev.03/ > >>>> > >>>> Hmm. Maybe I did something wrong but I've already rebuilt twice: > >>>> > >>>> $ java -Xcomp -version > >>>> Value type size is target-dependent. Ask TLI. > >>>> UNREACHABLE executed at /usr/local/src/llvm-3.1.src/include/llvm/CodeGen/ValueTypes.h:257! > >>>> Stack dump: > >>>> 0. Running pass 'X86 DAG->DAG Instruction Selection' on function '@"java.lang.System::getProperty"' > >>>> Aborted (core dumped) > >>> > >>> Arg! The last couple of changes I did only with LLVM3.2, where the > >>> problem disappears. Apparently, LLVM3.1 (and pre) don't deal well with > >>> atomic load/store :-( I re-introduced the CreateMemoryBarrier call and > >>> use that for SHARK_LLVM_VERSION <= 31. > >>> > >>> http://cr.openjdk.java.net/~rkennke/shark/webrev.04/ > >>> > >>> Hope that works better :-) > >> > >> I'm so sorry but... > >> > >> /export/twisti/build/8003868/build/linux_amd64_shark/product/libjvm.so: undefined reference to `SharkBuilder::memory_barrier()' > > > > Gaaa, what the... I thought I did clean rebuilds with both llvm3.2 and > > llvm3.1, but apparently not (maybe I shouldn't work after 1am). This > > (hopefully final final) patch re-instates the missing memory_barrier() > > method: > > > > > > http://cr.openjdk.java.net/~rkennke/shark/webrev.05/ > > > > Sorry for the messy back-and-forth. > > Again, so sorry: > > $ java -Xcomp -version > LLVM ERROR: Program used external function 'llvm.memory.barrier' which could not be resolved! > > Send a new patch tomorrow after some sleep ;-) Yeah, apparently 'replaced by' means that the old thing (the intrinsics) are indeed gone ;-) The problem is that the correct way to implement it (atomic load/store) doesn't work, the 'old way' (the memory_barrier() intrinsic call) doesn't work either, I also tried CreateAtomicRMW() which is probably not 100% correct, but would have done the job, but that doesn't work either (it throws the same error as the atomic load/store ...). The problem seems to only appear on 64bit volatile access. I don't know a really good solution that doesn't require jumping through big hoops, and I don't feel like working around LLVM bugs like this, especially since LLVM 3.2 (which should be released real soon now) works just fine. If you have a suggestion, please let me know, otherwise I suggest the following patch, which gets rid of all the LLVM31 blocks again and creates atomic load/store instructions (and requires LLVM 3.2 which can be found here http://llvm.org/svn/llvm-project/llvm/branches/release_32/ ). http://cr.openjdk.java.net/~rkennke/shark/webrev.06/ Roman From rkennke at redhat.com Thu Nov 29 06:26:19 2012 From: rkennke at redhat.com (Roman Kennke) Date: Thu, 29 Nov 2012 15:26:19 +0100 Subject: RFR (L): 8003868: fix shark for latest HotSpot and LLVM [Was: Re: RFR: Fix shark for latest Hotspot and LLVM] In-Reply-To: <4C4FE174-22EA-4982-890A-F784A7977D28@oracle.com> References: <1353519094.1744.42.camel@mercury> <34C51B6D-6582-42AB-9BDE-2CF7D721532E@oracle.com> <1353531251.1744.53.camel@mercury> <32151B51-A2A1-4DE4-B5DD-B665E2548704@oracle.com> <6B77725B-3BCF-40E0-AF0B-77E58B36B095@oracle.com> <1353690888.31435.3.camel@mercury> <13D4C44A-91EA-4175-A6E9-23FE2A3D7F79@oracle.com> <1353971930.20183.3.camel@mercury> <1353977057.20183.8.camel@mercury> <1354037066.29268.10.camel@mercury> <4C4FE174-22EA-4982-890A-F784A7977D28@oracle.com> Message-ID: <1354199179.2203.34.camel@mercury> Am Dienstag, den 27.11.2012, 10:59 -0800 schrieb Christian Thalinger: > On Nov 27, 2012, at 9:24 AM, Roman Kennke wrote: > > > Am Montag, den 26.11.2012, 17:14 -0800 schrieb Christian Thalinger: > >> On Nov 26, 2012, at 4:44 PM, Roman Kennke wrote: > >> > >>> Am Montag, den 26.11.2012, 15:43 -0800 schrieb Christian Thalinger: > >>>> On Nov 26, 2012, at 3:18 PM, Roman Kennke wrote: > >>>> > >>>>> Am Montag, den 26.11.2012, 11:55 -0800 schrieb Christian Thalinger: > >>>>>> On Nov 23, 2012, at 9:14 AM, Roman Kennke wrote: > >>>>>> > >>>>>>> Am Mittwoch, den 21.11.2012, 14:52 -0800 schrieb Christian Thalinger: > >>>>>>>> On Nov 21, 2012, at 2:22 PM, Christian Thalinger wrote: > >>>>>>>> > >>>>>>>>> > >>>>>>>>> On Nov 21, 2012, at 2:17 PM, Christian Thalinger wrote: > >>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> On Nov 21, 2012, at 12:54 PM, Roman Kennke wrote: > >>>>>>>>>> > >>>>>>>>>>> Am Mittwoch, den 21.11.2012, 12:47 -0800 schrieb Christian Thalinger: > >>>>>>>>>>>> On Nov 21, 2012, at 11:43 AM, Christian Thalinger wrote: > >>>>>>>>>>>> > >>>>>>>>>>>>> On Nov 21, 2012, at 9:31 AM, Roman Kennke wrote: > >>>>>>>>>>>>> > >>>>>>>>>>>>>> Hi there, > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> during the last days I worked on fixing the Shark compiler for Hotspot > >>>>>>>>>>>>>> to get it to build and run again, with the latest Hotspot code and LLVM. > >>>>>>>>>>>>>> Here are some details: > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> - A lot of changes are just to make it build and the compiler happy. For > >>>>>>>>>>>>>> example, I had to remove a lot of 'const' qualifiers because of API > >>>>>>>>>>>>>> changes in LLVM. > >>>>>>>>>>>>>> - Most other changes have to do with the split of the oop and metadata > >>>>>>>>>>>>>> class hierarchies in Hotspot. > >>>>>>>>>>>>>> - Then there have been a few changes caused by LLVM changes and > >>>>>>>>>>>>>> improvements, most notably the LLVM intrinsics for atomic operations > >>>>>>>>>>>>>> (memory barrier and cmpxchg) have been removed and now have a > >>>>>>>>>>>>>> representation directly in LLVM's IR. This makes our code a little > >>>>>>>>>>>>>> nicer. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> I tested this by running a number of applications, most notably Eclipse > >>>>>>>>>>>>>> (which is notoriously difficult on VMs), Java2Demo, SwingSet2 and a > >>>>>>>>>>>>>> bunch of other stuff. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> I would like to get this integrated into OpenJDK now if possible. You > >>>>>>>>>>>>>> can find the full webrev here: > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> http://cr.openjdk.java.net/~rkennke/shark/webrev.00/ > >>>>>>>>>>>>> > >>>>>>>>>>>>> The changes seem to touch almost only shark files so these should be fine. One question though: > >>>>>>>>>>>>> > >>>>>>>>>>>>> + develop(bool, SharkShowCompiledMethods, false, \ > >>>>>>>>>>>>> > >>>>>>>>>>>>> Isn't PrintCompilation doing that already? > >>>>>>>>>>>>> > >>>>>>>>>>>>> The shared code changes look good. I filed: > >>>>>>>>>>>>> > >>>>>>>>>>>>> 8003868: fix shark for latest HotSpot and LLVM > >>>>>>>>>>>>> > >>>>>>>>>>>>> -- Chris > >>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> There are also a very minor change required in JDK: > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> http://cr.openjdk.java.net/~rkennke/shark/webrev-jdk-00/ > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> In order to build it, apply the patches on hsx/hotspot-comp 's hotspot > >>>>>>>>>>>>>> and jdk repositories respectivly. Find my build script here: > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> http://cr.openjdk.java.net/~rkennke/shark/Build8-zero-shark > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> (Review and adjust variables to your settings, most notably you will > >>>>>>>>>>>>>> need to change LLVM_CONFIG to point to your LLVM 3.1 installation.) > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Please let me know if there are any issues or how we can get this > >>>>>>>>>>>>>> integrated into Hotspot. > >>>>>>>>>>>> > >>>>>>>>>>>> Finally I installed LLVM on one of our machines to be able to do a Shark build once in a while. When I try to do a jvmgshark build I get: > >>>>>>>>>>>> > >>>>>>>>>>>> In file included from /usr/local/include/llvm/Support/PointerLikeTypeTraits.h:18, > >>>>>>>>>>>> from /usr/local/include/llvm/ADT/PointerIntPair.h:17, > >>>>>>>>>>>> from /usr/local/include/llvm/Use.h:28, > >>>>>>>>>>>> from /usr/local/include/llvm/Value.h:17, > >>>>>>>>>>>> from /usr/local/include/llvm/Argument.h:17, > >>>>>>>>>>>> from /home/cthaling/8003868/src/share/vm/shark/llvmHeaders.hpp:39, > >>>>>>>>>>>> from /home/cthaling/8003868/src/share/vm/shark/sharkEntry.hpp:29, > >>>>>>>>>>>> from /home/cthaling/8003868/src/share/vm/compiler/disassembler.cpp:51: > >>>>>>>>>>>> /usr/local/include/llvm/Support/DataTypes.h:53:3: error: #error "Must #define __STDC_CONSTANT_MACROS before " "#including Support/DataTypes.h" > >>>>>>>>>>>> > >>>>>>>>>>>> and: > >>>>>>>>>>>> > >>>>>>>>>>>> In file included from /usr/local/include/llvm/Attributes.h:18, > >>>>>>>>>>>> from /usr/local/include/llvm/Argument.h:18, > >>>>>>>>>>>> from /home/cthaling/8003868/src/share/vm/shark/llvmHeaders.hpp:39, > >>>>>>>>>>>> from /home/cthaling/8003868/src/share/vm/shark/sharkEntry.hpp:29, > >>>>>>>>>>>> from /home/cthaling/8003868/src/share/vm/compiler/disassembler.cpp:51: > >>>>>>>>>>>> /usr/local/include/llvm/Support/MathExtras.h: In function ?bool llvm::isInt(int64_t)?: > >>>>>>>>>>>> /usr/local/include/llvm/Support/MathExtras.h:38: error: there are no arguments to ?INT64_C? that depend on a template parameter, so a declaration of ?INT64_C? must be available > >>>>>>>>>>>> /usr/local/include/llvm/Support/MathExtras.h:38: note: (if you use ?-fpermissive?, G++ will accept your code, but allowing the use of an undeclared name is deprecated) > >>>>>>>>>>>> /usr/local/include/llvm/Support/MathExtras.h:38: error: there are no arguments to ?INT64_C? that depend on a template parameter, so a declaration of ?INT64_C? must be available > >>>>>>>>>>>> /usr/local/include/llvm/Support/MathExtras.h: In function ?bool llvm::isUInt(uint64_t)?: > >>>>>>>>>>>> /usr/local/include/llvm/Support/MathExtras.h:64: error: there are no arguments to ?UINT64_C? that depend on a template parameter, so a declaration of ?UINT64_C? must be available > >>>>>>>>>>>> /usr/local/include/llvm/Support/MathExtras.h: In function ?bool llvm::isIntN(unsigned int, int64_t)?: > >>>>>>>>>>>> /usr/local/include/llvm/Support/MathExtras.h:96: error: ?INT64_C? was not declared in this scope > >>>>>>>>>>>> > >>>>>>>>>>>> Not sure if the latter is because of the former one. Have you seen this before? > >>>>>>>>>>> > >>>>>>>>>>> Yes, it's caused by the former. And yes, I have seen it before. IIRC, > >>>>>>>>>>> this happens when certain cflags are not set correctly. The script > >>>>>>>>>>> jdk/make/jdk_generic_profile.sh will call llvm-config to figure out the > >>>>>>>>>>> correct flags. In order for this to work, you need to have the full path > >>>>>>>>>>> to the llvm-config script set in the LLVM_CONFIG env variable. Were you > >>>>>>>>>>> using the build script that I provided? > >>>>>>>>>> > >>>>>>>>>> No. I took your script and got the important environment variables. But I missed the LLVM_* ones. Usually we only build hotspot so we don't have this jdk script. > >>>>>>>>>> > >>>>>>>>>> Now that I have the LLVM_* variables it's even worse: > >>>>>>>>>> > >>>>>>>>>> /home/cthaling/8003868/src/share/vm/oops/oop.hpp:72: error: cast from type ?markOopDesc* const volatile*? to type ?markOopDesc**? casts away constness > >>>>>>>>>> > >>>>>>>>>> It's probably this guy: -Wcast-qual > >>>>>>>>> > >>>>>>>>> Got it: > >>>>>>>>> > >>>>>>>>> $ java -version > >>>>>>>>> java version "1.8.0-ea" > >>>>>>>>> Java(TM) SE Runtime Environment (build 1.8.0-ea-b65) > >>>>>>>>> OpenJDK 64-Bit Shark VM (build 25.0-b11-internal-jvmg, mixed mode) > >>>>>>>> > >>>>>>>> I ran the compiler regression tests and Shark crashes in 5091921: > >>>>>>>> > >>>>>>>> cthaling at intelsdv03.us.oracle.com:~/8003868/test$ jtreg -workDir:$EXPORTHOME/jtreg -reportDir:$EXPORTHOME/jtreg -testjdk:$JAVA_HOME -verbose:summary compiler/5091921/ > >>>>>>>> Directory "/export/twisti/jtreg/scratch" not found: creating > >>>>>>>> Passed: compiler/5091921/Test5091921.java > >>>>>>>> Passed: compiler/5091921/Test6186134.java > >>>>>>>> Passed: compiler/5091921/Test6196102.java > >>>>>>>> Passed: compiler/5091921/Test6357214.java > >>>>>>>> Passed: compiler/5091921/Test6559156.java > >>>>>>>> Passed: compiler/5091921/Test6753639.java > >>>>>>>> Passed: compiler/5091921/Test6850611.java > >>>>>>>> Passed: compiler/5091921/Test6890943.java > >>>>>>>> Passed: compiler/5091921/Test6897150.java > >>>>>>>> Passed: compiler/5091921/Test6905845.java > >>>>>>>> Passed: compiler/5091921/Test6931567.java > >>>>>>>> /net/sqenfs-1.us.oracle.com/export1/comp/vm/tool/jtreg/execution/linux/bin/jtreg: line 139: 27784 Segmentation fault (core dumped) "${JT_JAVA}" $javaOpts -Dprogram=`basename "$0"` -jar "${JT_HOME}/lib/jtreg.jar" $jtregOpts > >>>>>>>> > >>>>>>>> You can also run all them with a simple make in test/ by setting: > >>>>>>>> > >>>>>>>> PRODUCT_HOME=$JAVA_HOME > >>>>>>>> TESTDIRS=compiler > >>>>>>> > >>>>>>> Alright, I found another fairly grave bug that I would like to include a > >>>>>>> fix for: apparently, a 'fence' is not enough of a memory barrier for > >>>>>>> volatile putfield/getfield (duh). Which basically broke all of j.u.c. > >>>>>>> LLVM offers atomic loads and stores, which seem to be exactly what is > >>>>>>> needed for volatile field access. However, it does not provide helper > >>>>>>> functions for those in llvm::IRBuilder so I wrote my own. This should be > >>>>>>> the final patch for now (unless you find something else). > >>>>>>> > >>>>>>> http://cr.openjdk.java.net/~rkennke/shark/webrev.03/ > >>>>>> > >>>>>> Hmm. Maybe I did something wrong but I've already rebuilt twice: > >>>>>> > >>>>>> $ java -Xcomp -version > >>>>>> Value type size is target-dependent. Ask TLI. > >>>>>> UNREACHABLE executed at /usr/local/src/llvm-3.1.src/include/llvm/CodeGen/ValueTypes.h:257! > >>>>>> Stack dump: > >>>>>> 0. Running pass 'X86 DAG->DAG Instruction Selection' on function '@"java.lang.System::getProperty"' > >>>>>> Aborted (core dumped) > >>>>> > >>>>> Arg! The last couple of changes I did only with LLVM3.2, where the > >>>>> problem disappears. Apparently, LLVM3.1 (and pre) don't deal well with > >>>>> atomic load/store :-( I re-introduced the CreateMemoryBarrier call and > >>>>> use that for SHARK_LLVM_VERSION <= 31. > >>>>> > >>>>> http://cr.openjdk.java.net/~rkennke/shark/webrev.04/ > >>>>> > >>>>> Hope that works better :-) > >>>> > >>>> I'm so sorry but... > >>>> > >>>> /export/twisti/build/8003868/build/linux_amd64_shark/product/libjvm.so: undefined reference to `SharkBuilder::memory_barrier()' > >>> > >>> Gaaa, what the... I thought I did clean rebuilds with both llvm3.2 and > >>> llvm3.1, but apparently not (maybe I shouldn't work after 1am). This > >>> (hopefully final final) patch re-instates the missing memory_barrier() > >>> method: > >>> > >>> > >>> http://cr.openjdk.java.net/~rkennke/shark/webrev.05/ > >>> > >>> Sorry for the messy back-and-forth. > >> > >> Again, so sorry: > >> > >> $ java -Xcomp -version > >> LLVM ERROR: Program used external function 'llvm.memory.barrier' which could not be resolved! > >> > >> Send a new patch tomorrow after some sleep ;-) > > > > Yeah, apparently 'replaced by' means that the old thing (the intrinsics) > > are indeed gone ;-) > > > > The problem is that the correct way to implement it (atomic load/store) > > doesn't work, the 'old way' (the memory_barrier() intrinsic call) > > doesn't work either, I also tried CreateAtomicRMW() which is probably > > not 100% correct, but would have done the job, but that doesn't work > > either (it throws the same error as the atomic load/store ...). The > > problem seems to only appear on 64bit volatile access. > > > > I don't know a really good solution that doesn't require jumping through > > big hoops, and I don't feel like working around LLVM bugs like this, > > especially since LLVM 3.2 (which should be released real soon now) works > > just fine. If you have a suggestion, please let me know, otherwise I > > suggest the following patch, which gets rid of all the LLVM31 blocks > > again and creates atomic load/store instructions (and requires LLVM 3.2 > > which can be found here > > http://llvm.org/svn/llvm-project/llvm/branches/release_32/ ). > > > > http://cr.openjdk.java.net/~rkennke/shark/webrev.06/ > > That's a reasonable thing to do given the tentative release date of December 16th. While running the compiler regression tests I got a couple of failures. You might want to address them with separate bugs. Hi Twisti, I see that you committed the patch, thanks a lot for this! However, there is still the small jdk patch missing: http://cr.openjdk.java.net/~rkennke/shark/webrev-jdk-00/ Can I push this myself or do you want to do it? Cheers, Roman From rkennke at redhat.com Thu Nov 29 13:41:40 2012 From: rkennke at redhat.com (Roman Kennke) Date: Thu, 29 Nov 2012 22:41:40 +0100 Subject: RFR (L): 8003868: fix shark for latest HotSpot and LLVM [Was: Re: RFR: Fix shark for latest Hotspot and LLVM] In-Reply-To: <86C99234-14E7-429A-A98E-63E9E43AE8E7@oracle.com> References: <1353519094.1744.42.camel@mercury> <34C51B6D-6582-42AB-9BDE-2CF7D721532E@oracle.com> <1353531251.1744.53.camel@mercury> <32151B51-A2A1-4DE4-B5DD-B665E2548704@oracle.com> <6B77725B-3BCF-40E0-AF0B-77E58B36B095@oracle.com> <1353690888.31435.3.camel@mercury> <13D4C44A-91EA-4175-A6E9-23FE2A3D7F79@oracle.com> <1353971930.20183.3.camel@mercury> <1353977057.20183.8.camel@mercury> <1354037066.29268.10.camel@mercury> <4C4FE174-22EA-4982-890A-F784A7977D28@oracle.com> <1354199179.2203.34.camel@mercury> <86C99234-14E7-429A-A98E-63E9E43AE8E7@oracle.com> Message-ID: <1354225300.2203.44.camel@mercury> Am Donnerstag, den 29.11.2012, 10:29 -0800 schrieb Christian Thalinger: > On Nov 29, 2012, at 6:26 AM, Roman Kennke wrote: > > > Am Dienstag, den 27.11.2012, 10:59 -0800 schrieb Christian Thalinger: > >> On Nov 27, 2012, at 9:24 AM, Roman Kennke wrote: > >> > >>> Am Montag, den 26.11.2012, 17:14 -0800 schrieb Christian Thalinger: > >>>> On Nov 26, 2012, at 4:44 PM, Roman Kennke wrote: > >>>> > >>>>> Am Montag, den 26.11.2012, 15:43 -0800 schrieb Christian Thalinger: > >>>>>> On Nov 26, 2012, at 3:18 PM, Roman Kennke wrote: > >>>>>> > >>>>>>> Am Montag, den 26.11.2012, 11:55 -0800 schrieb Christian Thalinger: > >>>>>>>> On Nov 23, 2012, at 9:14 AM, Roman Kennke wrote: > >>>>>>>> > >>>>>>>>> Am Mittwoch, den 21.11.2012, 14:52 -0800 schrieb Christian Thalinger: > >>>>>>>>>> On Nov 21, 2012, at 2:22 PM, Christian Thalinger wrote: > >>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> On Nov 21, 2012, at 2:17 PM, Christian Thalinger wrote: > >>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> On Nov 21, 2012, at 12:54 PM, Roman Kennke wrote: > >>>>>>>>>>>> > >>>>>>>>>>>>> Am Mittwoch, den 21.11.2012, 12:47 -0800 schrieb Christian Thalinger: > >>>>>>>>>>>>>> On Nov 21, 2012, at 11:43 AM, Christian Thalinger wrote: > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>> On Nov 21, 2012, at 9:31 AM, Roman Kennke wrote: > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> Hi there, > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> during the last days I worked on fixing the Shark compiler for Hotspot > >>>>>>>>>>>>>>>> to get it to build and run again, with the latest Hotspot code and LLVM. > >>>>>>>>>>>>>>>> Here are some details: > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> - A lot of changes are just to make it build and the compiler happy. For > >>>>>>>>>>>>>>>> example, I had to remove a lot of 'const' qualifiers because of API > >>>>>>>>>>>>>>>> changes in LLVM. > >>>>>>>>>>>>>>>> - Most other changes have to do with the split of the oop and metadata > >>>>>>>>>>>>>>>> class hierarchies in Hotspot. > >>>>>>>>>>>>>>>> - Then there have been a few changes caused by LLVM changes and > >>>>>>>>>>>>>>>> improvements, most notably the LLVM intrinsics for atomic operations > >>>>>>>>>>>>>>>> (memory barrier and cmpxchg) have been removed and now have a > >>>>>>>>>>>>>>>> representation directly in LLVM's IR. This makes our code a little > >>>>>>>>>>>>>>>> nicer. > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> I tested this by running a number of applications, most notably Eclipse > >>>>>>>>>>>>>>>> (which is notoriously difficult on VMs), Java2Demo, SwingSet2 and a > >>>>>>>>>>>>>>>> bunch of other stuff. > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> I would like to get this integrated into OpenJDK now if possible. You > >>>>>>>>>>>>>>>> can find the full webrev here: > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~rkennke/shark/webrev.00/ > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> The changes seem to touch almost only shark files so these should be fine. One question though: > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> + develop(bool, SharkShowCompiledMethods, false, \ > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Isn't PrintCompilation doing that already? > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> The shared code changes look good. I filed: > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> 8003868: fix shark for latest HotSpot and LLVM > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> -- Chris > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> There are also a very minor change required in JDK: > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~rkennke/shark/webrev-jdk-00/ > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> In order to build it, apply the patches on hsx/hotspot-comp 's hotspot > >>>>>>>>>>>>>>>> and jdk repositories respectivly. Find my build script here: > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~rkennke/shark/Build8-zero-shark > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> (Review and adjust variables to your settings, most notably you will > >>>>>>>>>>>>>>>> need to change LLVM_CONFIG to point to your LLVM 3.1 installation.) > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> Please let me know if there are any issues or how we can get this > >>>>>>>>>>>>>>>> integrated into Hotspot. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Finally I installed LLVM on one of our machines to be able to do a Shark build once in a while. When I try to do a jvmgshark build I get: > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> In file included from /usr/local/include/llvm/Support/PointerLikeTypeTraits.h:18, > >>>>>>>>>>>>>> from /usr/local/include/llvm/ADT/PointerIntPair.h:17, > >>>>>>>>>>>>>> from /usr/local/include/llvm/Use.h:28, > >>>>>>>>>>>>>> from /usr/local/include/llvm/Value.h:17, > >>>>>>>>>>>>>> from /usr/local/include/llvm/Argument.h:17, > >>>>>>>>>>>>>> from /home/cthaling/8003868/src/share/vm/shark/llvmHeaders.hpp:39, > >>>>>>>>>>>>>> from /home/cthaling/8003868/src/share/vm/shark/sharkEntry.hpp:29, > >>>>>>>>>>>>>> from /home/cthaling/8003868/src/share/vm/compiler/disassembler.cpp:51: > >>>>>>>>>>>>>> /usr/local/include/llvm/Support/DataTypes.h:53:3: error: #error "Must #define __STDC_CONSTANT_MACROS before " "#including Support/DataTypes.h" > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> and: > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> In file included from /usr/local/include/llvm/Attributes.h:18, > >>>>>>>>>>>>>> from /usr/local/include/llvm/Argument.h:18, > >>>>>>>>>>>>>> from /home/cthaling/8003868/src/share/vm/shark/llvmHeaders.hpp:39, > >>>>>>>>>>>>>> from /home/cthaling/8003868/src/share/vm/shark/sharkEntry.hpp:29, > >>>>>>>>>>>>>> from /home/cthaling/8003868/src/share/vm/compiler/disassembler.cpp:51: > >>>>>>>>>>>>>> /usr/local/include/llvm/Support/MathExtras.h: In function ?bool llvm::isInt(int64_t)?: > >>>>>>>>>>>>>> /usr/local/include/llvm/Support/MathExtras.h:38: error: there are no arguments to ?INT64_C? that depend on a template parameter, so a declaration of ?INT64_C? must be available > >>>>>>>>>>>>>> /usr/local/include/llvm/Support/MathExtras.h:38: note: (if you use ?-fpermissive?, G++ will accept your code, but allowing the use of an undeclared name is deprecated) > >>>>>>>>>>>>>> /usr/local/include/llvm/Support/MathExtras.h:38: error: there are no arguments to ?INT64_C? that depend on a template parameter, so a declaration of ?INT64_C? must be available > >>>>>>>>>>>>>> /usr/local/include/llvm/Support/MathExtras.h: In function ?bool llvm::isUInt(uint64_t)?: > >>>>>>>>>>>>>> /usr/local/include/llvm/Support/MathExtras.h:64: error: there are no arguments to ?UINT64_C? that depend on a template parameter, so a declaration of ?UINT64_C? must be available > >>>>>>>>>>>>>> /usr/local/include/llvm/Support/MathExtras.h: In function ?bool llvm::isIntN(unsigned int, int64_t)?: > >>>>>>>>>>>>>> /usr/local/include/llvm/Support/MathExtras.h:96: error: ?INT64_C? was not declared in this scope > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Not sure if the latter is because of the former one. Have you seen this before? > >>>>>>>>>>>>> > >>>>>>>>>>>>> Yes, it's caused by the former. And yes, I have seen it before. IIRC, > >>>>>>>>>>>>> this happens when certain cflags are not set correctly. The script > >>>>>>>>>>>>> jdk/make/jdk_generic_profile.sh will call llvm-config to figure out the > >>>>>>>>>>>>> correct flags. In order for this to work, you need to have the full path > >>>>>>>>>>>>> to the llvm-config script set in the LLVM_CONFIG env variable. Were you > >>>>>>>>>>>>> using the build script that I provided? > >>>>>>>>>>>> > >>>>>>>>>>>> No. I took your script and got the important environment variables. But I missed the LLVM_* ones. Usually we only build hotspot so we don't have this jdk script. > >>>>>>>>>>>> > >>>>>>>>>>>> Now that I have the LLVM_* variables it's even worse: > >>>>>>>>>>>> > >>>>>>>>>>>> /home/cthaling/8003868/src/share/vm/oops/oop.hpp:72: error: cast from type ?markOopDesc* const volatile*? to type ?markOopDesc**? casts away constness > >>>>>>>>>>>> > >>>>>>>>>>>> It's probably this guy: -Wcast-qual > >>>>>>>>>>> > >>>>>>>>>>> Got it: > >>>>>>>>>>> > >>>>>>>>>>> $ java -version > >>>>>>>>>>> java version "1.8.0-ea" > >>>>>>>>>>> Java(TM) SE Runtime Environment (build 1.8.0-ea-b65) > >>>>>>>>>>> OpenJDK 64-Bit Shark VM (build 25.0-b11-internal-jvmg, mixed mode) > >>>>>>>>>> > >>>>>>>>>> I ran the compiler regression tests and Shark crashes in 5091921: > >>>>>>>>>> > >>>>>>>>>> cthaling at intelsdv03.us.oracle.com:~/8003868/test$ jtreg -workDir:$EXPORTHOME/jtreg -reportDir:$EXPORTHOME/jtreg -testjdk:$JAVA_HOME -verbose:summary compiler/5091921/ > >>>>>>>>>> Directory "/export/twisti/jtreg/scratch" not found: creating > >>>>>>>>>> Passed: compiler/5091921/Test5091921.java > >>>>>>>>>> Passed: compiler/5091921/Test6186134.java > >>>>>>>>>> Passed: compiler/5091921/Test6196102.java > >>>>>>>>>> Passed: compiler/5091921/Test6357214.java > >>>>>>>>>> Passed: compiler/5091921/Test6559156.java > >>>>>>>>>> Passed: compiler/5091921/Test6753639.java > >>>>>>>>>> Passed: compiler/5091921/Test6850611.java > >>>>>>>>>> Passed: compiler/5091921/Test6890943.java > >>>>>>>>>> Passed: compiler/5091921/Test6897150.java > >>>>>>>>>> Passed: compiler/5091921/Test6905845.java > >>>>>>>>>> Passed: compiler/5091921/Test6931567.java > >>>>>>>>>> /net/sqenfs-1.us.oracle.com/export1/comp/vm/tool/jtreg/execution/linux/bin/jtreg: line 139: 27784 Segmentation fault (core dumped) "${JT_JAVA}" $javaOpts -Dprogram=`basename "$0"` -jar "${JT_HOME}/lib/jtreg.jar" $jtregOpts > >>>>>>>>>> > >>>>>>>>>> You can also run all them with a simple make in test/ by setting: > >>>>>>>>>> > >>>>>>>>>> PRODUCT_HOME=$JAVA_HOME > >>>>>>>>>> TESTDIRS=compiler > >>>>>>>>> > >>>>>>>>> Alright, I found another fairly grave bug that I would like to include a > >>>>>>>>> fix for: apparently, a 'fence' is not enough of a memory barrier for > >>>>>>>>> volatile putfield/getfield (duh). Which basically broke all of j.u.c. > >>>>>>>>> LLVM offers atomic loads and stores, which seem to be exactly what is > >>>>>>>>> needed for volatile field access. However, it does not provide helper > >>>>>>>>> functions for those in llvm::IRBuilder so I wrote my own. This should be > >>>>>>>>> the final patch for now (unless you find something else). > >>>>>>>>> > >>>>>>>>> http://cr.openjdk.java.net/~rkennke/shark/webrev.03/ > >>>>>>>> > >>>>>>>> Hmm. Maybe I did something wrong but I've already rebuilt twice: > >>>>>>>> > >>>>>>>> $ java -Xcomp -version > >>>>>>>> Value type size is target-dependent. Ask TLI. > >>>>>>>> UNREACHABLE executed at /usr/local/src/llvm-3.1.src/include/llvm/CodeGen/ValueTypes.h:257! > >>>>>>>> Stack dump: > >>>>>>>> 0. Running pass 'X86 DAG->DAG Instruction Selection' on function '@"java.lang.System::getProperty"' > >>>>>>>> Aborted (core dumped) > >>>>>>> > >>>>>>> Arg! The last couple of changes I did only with LLVM3.2, where the > >>>>>>> problem disappears. Apparently, LLVM3.1 (and pre) don't deal well with > >>>>>>> atomic load/store :-( I re-introduced the CreateMemoryBarrier call and > >>>>>>> use that for SHARK_LLVM_VERSION <= 31. > >>>>>>> > >>>>>>> http://cr.openjdk.java.net/~rkennke/shark/webrev.04/ > >>>>>>> > >>>>>>> Hope that works better :-) > >>>>>> > >>>>>> I'm so sorry but... > >>>>>> > >>>>>> /export/twisti/build/8003868/build/linux_amd64_shark/product/libjvm.so: undefined reference to `SharkBuilder::memory_barrier()' > >>>>> > >>>>> Gaaa, what the... I thought I did clean rebuilds with both llvm3.2 and > >>>>> llvm3.1, but apparently not (maybe I shouldn't work after 1am). This > >>>>> (hopefully final final) patch re-instates the missing memory_barrier() > >>>>> method: > >>>>> > >>>>> > >>>>> http://cr.openjdk.java.net/~rkennke/shark/webrev.05/ > >>>>> > >>>>> Sorry for the messy back-and-forth. > >>>> > >>>> Again, so sorry: > >>>> > >>>> $ java -Xcomp -version > >>>> LLVM ERROR: Program used external function 'llvm.memory.barrier' which could not be resolved! > >>>> > >>>> Send a new patch tomorrow after some sleep ;-) > >>> > >>> Yeah, apparently 'replaced by' means that the old thing (the intrinsics) > >>> are indeed gone ;-) > >>> > >>> The problem is that the correct way to implement it (atomic load/store) > >>> doesn't work, the 'old way' (the memory_barrier() intrinsic call) > >>> doesn't work either, I also tried CreateAtomicRMW() which is probably > >>> not 100% correct, but would have done the job, but that doesn't work > >>> either (it throws the same error as the atomic load/store ...). The > >>> problem seems to only appear on 64bit volatile access. > >>> > >>> I don't know a really good solution that doesn't require jumping through > >>> big hoops, and I don't feel like working around LLVM bugs like this, > >>> especially since LLVM 3.2 (which should be released real soon now) works > >>> just fine. If you have a suggestion, please let me know, otherwise I > >>> suggest the following patch, which gets rid of all the LLVM31 blocks > >>> again and creates atomic load/store instructions (and requires LLVM 3.2 > >>> which can be found here > >>> http://llvm.org/svn/llvm-project/llvm/branches/release_32/ ). > >>> > >>> http://cr.openjdk.java.net/~rkennke/shark/webrev.06/ > >> > >> That's a reasonable thing to do given the tentative release date of December 16th. While running the compiler regression tests I got a couple of failures. You might want to address them with separate bugs. > > > > Hi Twisti, > > > > I see that you committed the patch, thanks a lot for this! However, > > there is still the small jdk patch missing: > > > > http://cr.openjdk.java.net/~rkennke/shark/webrev-jdk-00/ > > > > Can I push this myself or do you want to do it? > > Right. You can do it yourself. I would appreciate that. I tried to push to ssh://hg.openjdk.java.net/hsx/hotspot-comp-gate/jdk/ but I got: abort: could not lock repository hsx/hotspot-comp-gate/jdk: Read-only file system Was that the correct repository, or did I do something wrong? Roman