From christian.thalinger at oracle.com Thu May 3 08:53:01 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 3 May 2012 08:53:01 -0700 Subject: request for review (L): 7121756 Improve C1 inlining policy by using profiling at call sites In-Reply-To: <68105D4B-D98D-48F2-A84F-A398D295ABA3@oracle.com> References: <68105D4B-D98D-48F2-A84F-A398D295ABA3@oracle.com> Message-ID: Dec 15 is a long time ago :-) Sorry, I thought this has been reviewed. src/share/vm/c1/c1_GraphBuilder.cpp: + if (C1TypeProfileInlining && + code != Bytecodes::_invokestatic && + code != Bytecodes::_invokespecial && + code != Bytecodes::_invokedynamic && + (code != Bytecodes::_invokevirtual || !target->is_loaded() || !target->is_final_method())) { Can this be reversed and simplified? src/share/vm/c1/c1_LIR.cpp: + assert (code == lir_checkcast ||code == lir_instanceof, "expects checkcast or instanceof only"); Spacing is odd. src/share/vm/ci/ciMethod.cpp: +bool ciMethod::profile_is_hot_helper(ciProfileData* data, int bci, bool &warm, bool full) { What is "full"? Maybe you can find a better name. src/share/vm/code/compiledIC.cpp: +bool CompiledProfile::is_profiled(NativeCall* call) { +#ifdef COMPILER2 + return false; +#endif +#ifdef COMPILER1 + if (!C1ProfileInlining) return false; I think this will produce a compiler warning (or error) when compiling C2 since it defines -DCOMPILER2 -DCOMPILER1. +#ifdef ARM + // The first word of a static call stub has no reloc info. So if + // we don't find a reloc info we know, it's a static call stub. + return obj != NULL; +#endif Why does ARM not require a reloc info? More to come... I remember you mentioning to rework the patch. Is there a new version available? -- Chris On Dec 15, 2011, at 6:52 AM, Roland Westrelin wrote: > http://cr.openjdk.java.net/~roland/7121756/webrev.00/ > > Implements profile based inlining in C1. > > Execution of a method starts interpreted as usual. A method transitions from interpreted to compiled in the usual way as well. When the method is compiled, the compiler identifies a number of call sites that are candidates for profiling and further inlining. At those call sites, the method is compiled so that a per call site counter is incremented and tested for overflow when the call site is used. On first call site resolution, a timestamp is also recorded. The count and timestamp are used to compute a frequency. A frequency higher than a high water mark detects a hot call site. A hot call site triggers a recompilation of the caller method in which the callee is inlined. A frequency higher than a low water mark detects a warm call site. Otherwise the call site is cold. Recompiling with the extra inlining won't bring a performance advantage for a warm or cold call site. But keeping the profiling on at a warm call site is detrimental so it is dropped. At a cold call site profiling can be kept enabled to trigger later recompilation if the call site becomes hot. > > To perform profiling, the compiler identifies the candidate call sites and generates a stub similar to the static call stub in the nmethod's stub area. The profile call stub performs the following step: > 1- load mdo pointer in register > 2- increment counter for call site > 3- branch to runtime if counter crosses threshold > 4- jump to callee > > On call site resolution, for a call to a compiled method, the jump (4- above) is patched with the resolved call site info (to continue to callee's code or transition stub) then the call site is patched to point to the profile call stub. Profiling can be later fully disabled for the call site (if the call site is polymorphic or if the compilation policy finds it's better to not profile the call site anymore) by reresolving the call. > > The compiler also uses profile data to inline a frequent virtual method if profile data suggests a single receiver class. State changes of inline caches associated with call sites (performed in the runtime) are used to collect receiver class data. Correctness during execution is enforced with a compiled guard and a deoptimization can be triggered. From roland.westrelin at oracle.com Thu May 3 09:01:05 2012 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Thu, 03 May 2012 18:01:05 +0200 Subject: request for review (L): 7121756 Improve C1 inlining policy by using profiling at call sites In-Reply-To: References: <68105D4B-D98D-48F2-A84F-A398D295ABA3@oracle.com> Message-ID: > Dec 15 is a long time ago :-) Sorry, I thought this has been reviewed. Thanks for reviewing it! I'll answer your questions in a separate email (I have to refresh my memory first). > I remember you mentioning to rework the patch. Is there a new version available? The one that needs to be reworked is the bound check elimination one based on Tom's comments. Roland. From christian.thalinger at oracle.com Thu May 3 09:27:35 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 3 May 2012 09:27:35 -0700 Subject: request for review (L): 7121756 Improve C1 inlining policy by using profiling at call sites In-Reply-To: References: <68105D4B-D98D-48F2-A84F-A398D295ABA3@oracle.com> Message-ID: <68616A7A-2E97-4034-BEEF-09A3CE52ABC1@oracle.com> On May 3, 2012, at 9:01 AM, Roland Westrelin wrote: >> Dec 15 is a long time ago :-) Sorry, I thought this has been reviewed. > > Thanks for reviewing it! > I'll answer your questions in a separate email (I have to refresh my memory first). I hope I can finish reviewing the second part soon (whatever soon means). > >> I remember you mentioning to rework the patch. Is there a new version available? > > The one that needs to be reworked is the bound check elimination one based on Tom's comments. Right. I mixed those two up. -- Chris > > Roland. From xerox.time.tech at gmail.com Thu May 3 11:54:31 2012 From: xerox.time.tech at gmail.com (Xin Tong) Date: Thu, 3 May 2012 14:54:31 -0400 Subject: compiled method info Message-ID: I am new to hotspot JVM. I am wondering how can I get a log of all the method compiled and how can i get the intermediate representation and optimizations performed on one particular method ? Thanks Xin From john.r.rose at oracle.com Thu May 3 12:57:23 2012 From: john.r.rose at oracle.com (John Rose) Date: Thu, 3 May 2012 12:57:23 -0700 Subject: compiled method info In-Reply-To: References: Message-ID: On May 3, 2012, at 11:54 AM, Xin Tong wrote: > I am new to hotspot JVM. I am wondering how can I get a log of all the > method compiled and how can i get the intermediate representation and > optimizations performed on one particular method ? Google is your friend. Try this query and browse the results: http://www.google.com/search?q=hotspot+openjdk+intermediate+representation+optimizations ? John From christian.thalinger at oracle.com Thu May 3 13:13:55 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 3 May 2012 13:13:55 -0700 Subject: compiled method info In-Reply-To: References: Message-ID: On May 3, 2012, at 11:54 AM, Xin Tong wrote: > I am new to hotspot JVM. I am wondering how can I get a log of all the > method compiled You can print the compiled methods with -XX:+PrintCompilation. > and how can i get the intermediate representation This is more complicated. Do you mean the graph that's produced during the compile? > and > optimizations performed on one particular method ? Depends on the compiler used. You might get an idea what's going on using -XX:+TimeCompiler (this is only available in a non-product build). -- Chris > > Thanks > > Xin From xerox.time.tech at gmail.com Thu May 3 13:20:45 2012 From: xerox.time.tech at gmail.com (Xin Tong) Date: Thu, 3 May 2012 16:20:45 -0400 Subject: compiled method info In-Reply-To: References: Message-ID: On Thu, May 3, 2012 at 4:13 PM, Christian Thalinger wrote: > > On May 3, 2012, at 11:54 AM, Xin Tong wrote: > >> I am new to hotspot JVM. I am wondering how can I get a log of all the >> method compiled > > You can print the compiled methods with -XX:+PrintCompilation. This will print the compiled method to the stdout, is there a way to force it to some output file ? > >> and how can i get the intermediate representation > > This is more complicated. ?Do you mean the graph that's produced during the compile? > >> and >> optimizations performed on one particular method ? Yes. I used to work on some other compiler framework in which one is able to print the graph after every optimization. > > Depends on the compiler used. ?You might get an idea what's going on using -XX:+TimeCompiler (this is only available in a non-product build). > I used make all to build openJDK. however, all the developer options are not available. How do i make a non-product build. I do not want a debug build, as debug build tend to run slower than prod build. -- Xin > -- Chris > >> >> Thanks >> >> Xin > From christian.thalinger at oracle.com Thu May 3 14:56:09 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 3 May 2012 14:56:09 -0700 Subject: compiled method info In-Reply-To: References: Message-ID: <24475C16-BDD1-4ABE-9E66-D59BB7ACB238@oracle.com> On May 3, 2012, at 1:20 PM, Xin Tong wrote: > On Thu, May 3, 2012 at 4:13 PM, Christian Thalinger > wrote: >> >> On May 3, 2012, at 11:54 AM, Xin Tong wrote: >> >>> I am new to hotspot JVM. I am wondering how can I get a log of all the >>> method compiled >> >> You can print the compiled methods with -XX:+PrintCompilation. > > This will print the compiled method to the stdout, is there a way to > force it to some output file ? Check globals.hpp for LogCompilation (and all other sorts of switches). >> >>> and how can i get the intermediate representation >> >> This is more complicated. Do you mean the graph that's produced during the compile? >> >>> and >>> optimizations performed on one particular method ? > > Yes. I used to work on some other compiler framework in which one is > able to print the graph after every optimization. IGV is what you are looking for: http://ssw.jku.at/General/Staff/TW/igv.html > >> >> Depends on the compiler used. You might get an idea what's going on using -XX:+TimeCompiler (this is only available in a non-product build). >> > > I used make all to build openJDK. however, all the developer options > are not available. How do i make a non-product build. I do not want a > debug build, as debug build tend to run slower than prod build. A fastdebug build is probably what you want. -- Chris > > > -- Xin > >> -- Chris >> >>> >>> Thanks >>> >>> Xin >> From rednaxelafx at gmail.com Thu May 3 15:07:50 2012 From: rednaxelafx at gmail.com (Krystal Mok) Date: Fri, 4 May 2012 06:07:50 +0800 Subject: compiled method info In-Reply-To: References: Message-ID: <9B865A93-E01A-4554-ACB6-9E86F78038C9@gmail.com> Hi Xin, +1 with John, Google is your friend when you start investigating things, especially when the top hits are pretty good. Comments inline, On 2012-5-4, at 4:20, Xin Tong wrote: > On Thu, May 3, 2012 at 4:13 PM, Christian Thalinger > wrote: >> >> On May 3, 2012, at 11:54 AM, Xin Tong wrote: >> >>> I am new to hotspot JVM. I am wondering how can I get a log of all the >>> method compiled >> >> You can print the compiled methods with -XX:+PrintCompilation. > > This will print the compiled method to the stdout, is there a way to > force it to some output file ? You can learn more about all available VM options in the *globals.hpp files. Supposing you can read Chinese, there's a thread that I posted some time ago that had a list of all *globals.hpp files in it: http://hllvm.group.iteye.com/group/topic/27945 In runtime/globals.hpp, you can find the flags LogVMOutput and LogFile that should meet your needs. Use them like this (if you're using a product build): -XX:+UnlockDiagnosticVMOptions -XX:+LogVMOutput -XX:LogFile= The default path for the log is ./hotspot.log. >> >>> and how can i get the intermediate representation >> >> This is more complicated. Do you mean the graph that's produced during the compile? >> >>> and >>> optimizations performed on one particular method ? > > Yes. I used to work on some other compiler framework in which one is > able to print the graph after every optimization. Search for C1Visualizer and IdealGraphVisualizer and read their manual. Should be enough to get you started. > >> >> Depends on the compiler used. You might get an idea what's going on using -XX:+TimeCompiler (this is only available in a non-product build). >> > > I used make all to build openJDK. however, all the developer options > are not available. How do i make a non-product build. I do not want a > debug build, as debug build tend to run slower than prod build. > That's what a fastdebug build is for. It's faster than a (slow) "debug" build, even though slower than a product build. You could refer to a script that Charles Nutter wrote for building HotSpot: https://gist.github.com/1148321 . Use "build.sh fastdebug" to get a fastdebug build. - Kris > > -- Xin > >> -- Chris >> >>> >>> Thanks >>> >>> Xin >> From Ulf.Zibis at gmx.de Thu May 3 15:14:03 2012 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Fri, 04 May 2012 00:14:03 +0200 Subject: compiled method info In-Reply-To: References: Message-ID: <4FA3032B.7090300@gmx.de> Am 03.05.2012 22:20, schrieb Xin Tong: > On Thu, May 3, 2012 at 4:13 PM, Christian Thalinger > wrote: >> You can print the compiled methods with -XX:+PrintCompilation. > This will print the compiled method to the stdout, is there a way to > force it to some output file ? See also: https://wikis.oracle.com/display/HotSpotInternals/HotSpot+Tools https://wikis.oracle.com/display/HotSpotInternals/LogCompilation+tool https://wikis.oracle.com/display/HotSpotInternals/PrintAssembly https://wikis.oracle.com/display/HotSpotInternals/LogCompilation+overview Hope, that helps.... -Ulf From xerox.time.tech at gmail.com Thu May 3 16:18:11 2012 From: xerox.time.tech at gmail.com (Xin Tong) Date: Thu, 3 May 2012 19:18:11 -0400 Subject: compiled method info In-Reply-To: <4FA3032B.7090300@gmx.de> References: <4FA3032B.7090300@gmx.de> Message-ID: On Thu, May 3, 2012 at 6:14 PM, Ulf Zibis wrote: > Am 03.05.2012 22:20, schrieb Xin Tong: >> >> On Thu, May 3, 2012 at 4:13 PM, Christian Thalinger >> ?wrote: >>> >>> You can print the compiled methods with -XX:+PrintCompilation. >> >> This will print the compiled method to the stdout, is there a way to >> force it to some output file ? > > See also: > https://wikis.oracle.com/display/HotSpotInternals/HotSpot+Tools > https://wikis.oracle.com/display/HotSpotInternals/LogCompilation+tool > https://wikis.oracle.com/display/HotSpotInternals/PrintAssembly > https://wikis.oracle.com/display/HotSpotInternals/LogCompilation+overview > > Hope, that helps.... > > -Ulf > This is very helpful. Thank you all From xerox.time.tech at gmail.com Thu May 3 16:54:04 2012 From: xerox.time.tech at gmail.com (Xin Tong) Date: Thu, 3 May 2012 19:54:04 -0400 Subject: compiled method info In-Reply-To: <9B865A93-E01A-4554-ACB6-9E86F78038C9@gmail.com> References: <9B865A93-E01A-4554-ACB6-9E86F78038C9@gmail.com> Message-ID: On Thu, May 3, 2012 at 6:07 PM, Krystal Mok wrote: > Hi Xin, > > +1 with John, Google is your friend when you start investigating things, especially when the top hits are pretty good. > > Comments inline, > > On 2012-5-4, at 4:20, Xin Tong wrote: > >> On Thu, May 3, 2012 at 4:13 PM, Christian Thalinger >> wrote: >>> >>> On May 3, 2012, at 11:54 AM, Xin Tong wrote: >>> >>>> I am new to hotspot JVM. I am wondering how can I get a log of all the >>>> method compiled >>> >>> You can print the compiled methods with -XX:+PrintCompilation. >> >> This will print the compiled method to the stdout, is there a way to >> force it to some output file ? > > You can learn more about all available VM options in the *globals.hpp files. > Supposing you can read Chinese, there's a thread that I posted some time ago that had a list of all *globals.hpp files in it: http://hllvm.group.iteye.com/group/topic/27945 > > In runtime/globals.hpp, you can find the flags LogVMOutput and LogFile that should meet your needs. Use them like this (if you're using a product build): > -XX:+UnlockDiagnosticVMOptions -XX:+LogVMOutput -XX:LogFile= > > The default path for the log is ./hotspot.log. > The debugging output gets printed to the file i specified. However the same thing is printed to the stdout. How can i get it just print to the file, not stdout. also, i have been looking at this document and can not find the LogFile option in there. http://www.oracle.com/technetwork/java/javase/tech/vmoptions-jsp-140102.html Maybe this doc is out of date ? or the JVM version is old ? >>> >>>> and how can i get the intermediate representation >>> >>> This is more complicated. ?Do you mean the graph that's produced during the compile? >>> >>>> and >>>> optimizations performed on one particular method ? >> >> Yes. I used to work on some other compiler framework in which one is >> able to print the graph after every optimization. > > Search for C1Visualizer and IdealGraphVisualizer and read their manual. Should be enough to get you started. > >> >>> >>> Depends on the compiler used. ?You might get an idea what's going on using -XX:+TimeCompiler (this is only available in a non-product build). >>> >> >> I used make all ?to build openJDK. however, all the developer options >> are not available. How do i make a non-product build. I do not want a >> debug build, as debug build tend to run slower than prod build. >> > > That's what a fastdebug build is for. It's faster than a (slow) "debug" build, even though slower than a product build. You could refer to a script that Charles Nutter wrote for building HotSpot: > https://gist.github.com/1148321 . Use "build.sh fastdebug" to get a fastdebug build. > > - Kris > >> >> -- Xin >> >>> -- Chris >>> >>>> >>>> Thanks >>>> >>>> Xin >>> > From rednaxelafx at gmail.com Thu May 3 17:09:59 2012 From: rednaxelafx at gmail.com (Krystal Mok) Date: Fri, 4 May 2012 08:09:59 +0800 Subject: compiled method info In-Reply-To: References: <9B865A93-E01A-4554-ACB6-9E86F78038C9@gmail.com> Message-ID: On 2012-5-4, at 7:54, Xin Tong wrote: > On Thu, May 3, 2012 at 6:07 PM, Krystal Mok wrote: >> In runtime/globals.hpp, you can find the flags LogVMOutput and LogFile that should meet your needs. Use them like this (if you're using a product build): >> -XX:+UnlockDiagnosticVMOptions -XX:+LogVMOutput -XX:LogFile= >> >> The default path for the log is ./hotspot.log. >> > > The debugging output gets printed to the file i specified. However the > same thing is printed to the stdout. How can i get it just print to > the file, not stdout. Use -XX:-DisplayVMOutput anywhere after -XX:+UnlockDiagnosticVMOptions. > also, i have been looking at this document and > can not find the LogFile option in there. > > http://www.oracle.com/technetwork/java/javase/tech/vmoptions-jsp-140102.html > > Maybe this doc is out of date ? or the JVM version is old ? >>>>> >>>>> >>>> That page is not an exhaustive list of all VM options. Besides, there are lots of flags in the VM not meant to be used by application users/developers, so I'm okay with that page. -Kris -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20120504/911002ef/attachment-0001.html From xerox.time.tech at gmail.com Thu May 3 17:16:57 2012 From: xerox.time.tech at gmail.com (Xin Tong) Date: Thu, 3 May 2012 20:16:57 -0400 Subject: debug in hotspot Message-ID: i would like to know how to debug in hotspot, what are some of the standard procedures ? Lets say, the hotspot fails to run a Java program. a few steps to triage the problem. 1. disable JIT compilers. hotspot has 2 compilers c1 and c2. they are both used if TieredCompilation is enabled. How do I disable both of them. 2. if the Java program passes after the JIT is disabled. There is a good chance that the problem is cause by the JIT. I want to narrow down to a specific method, I can use PrintCompilation to find out all the method compiled, but how can I disable one specific method from being compiled. 3. if i am able to limit down to a specific method, i want to start disabling optimizations, is there an option to disable all optimizations in the c1 and c2 compilers, or i need to do it manually ? Thanks From rednaxelafx at gmail.com Thu May 3 17:29:47 2012 From: rednaxelafx at gmail.com (Krystal Mok) Date: Fri, 4 May 2012 08:29:47 +0800 Subject: debug in hotspot In-Reply-To: References: Message-ID: On 2012-5-4, at 8:16, Xin Tong wrote: > i would like to know how to debug in hotspot, what are some of the > standard procedures ? Lets say, the hotspot fails to run a Java > program. a few steps to triage the problem. > > 1. disable JIT compilers. hotspot has 2 compilers c1 and c2. they are > both used if TieredCompilation is enabled. How do I disable both of > them. It's there in the globals.hpp file: -XX:-UseCompiler > 2. if the Java program passes after the JIT is disabled. There is a > good chance that the problem is cause by the JIT. I want to narrow > down to a specific method, I can use PrintCompilation to find out all > the method compiled, but how can I disable one specific method from > being compiled. -XX:CompileCommand='exclude,your/class,yourMethod' Or an equivalent .hotspot_compiler configuration file. Read this thread for example (in Chinese): http://hllvm.group.iteye.com/group/topic/28201 > 3. if i am able to limit down to a specific method, i want to start > disabling optimizations, is there an option to disable all > optimizations in the c1 and c2 compilers, or i need to do it manually > ? > I don't think there's an all-in-one flag to turn all optimizations off. At least not for now. See c1_globals.hpp and c2_globals.hpp to get an idea of what optimizations you can turn off. - Kris > Thanks From xerox.time.tech at gmail.com Thu May 3 17:45:00 2012 From: xerox.time.tech at gmail.com (Xin Tong) Date: Thu, 3 May 2012 20:45:00 -0400 Subject: debug in hotspot In-Reply-To: References: Message-ID: On Thu, May 3, 2012 at 8:29 PM, Krystal Mok wrote: > On 2012-5-4, at 8:16, Xin Tong wrote: > >> i would like to know how to debug in hotspot, what are some of the >> standard procedures ? Lets say, the hotspot fails to run a Java >> program. a few steps to triage the problem. >> >> 1. disable JIT compilers. hotspot has 2 compilers c1 and c2. they are >> both used if TieredCompilation is enabled. How do I disable both of >> them. > > It's there in the globals.hpp file: -XX:-UseCompiler > >> 2. if the Java program passes after the JIT is disabled. There is a >> good chance that the problem is cause by the JIT. I want to narrow >> down to a specific method, I can use PrintCompilation to find out all >> the method compiled, but how can I disable one specific method from >> being compiled. > > -XX:CompileCommand='exclude,your/class,yourMethod' > Or an equivalent .hotspot_compiler configuration file. > Read this thread for example (in Chinese): http://hllvm.group.iteye.com/group/topic/28201 > >> 3. if i am able to limit down to a specific method, i want to start >> disabling optimizations, is there an option to disable all >> optimizations in the c1 and c2 compilers, or i need to do it manually >> ? >> > > I don't think there's an all-in-one flag to turn all optimizations off. At least not for now. > See c1_globals.hpp and c2_globals.hpp to get an idea of what optimizations you can turn off. > > - Kris > >> Thanks Thank you very much Kris. This is very helpful. From xerox.time.tech at gmail.com Thu May 3 17:48:54 2012 From: xerox.time.tech at gmail.com (Xin Tong) Date: Thu, 3 May 2012 20:48:54 -0400 Subject: debug in hotspot In-Reply-To: References: Message-ID: On Thu, May 3, 2012 at 8:45 PM, Xin Tong wrote: > On Thu, May 3, 2012 at 8:29 PM, Krystal Mok wrote: >> On 2012-5-4, at 8:16, Xin Tong wrote: >> >>> i would like to know how to debug in hotspot, what are some of the >>> standard procedures ? Lets say, the hotspot fails to run a Java >>> program. a few steps to triage the problem. >>> >>> 1. disable JIT compilers. hotspot has 2 compilers c1 and c2. they are >>> both used if TieredCompilation is enabled. How do I disable both of >>> them. >> >> It's there in the globals.hpp file: -XX:-UseCompiler >> >>> 2. if the Java program passes after the JIT is disabled. There is a >>> good chance that the problem is cause by the JIT. I want to narrow >>> down to a specific method, I can use PrintCompilation to find out all >>> the method compiled, but how can I disable one specific method from >>> being compiled. >> >> -XX:CompileCommand='exclude,your/class,yourMethod' >> Or an equivalent .hotspot_compiler configuration file. >> Read this thread for example (in Chinese): http://hllvm.group.iteye.com/group/topic/28201 By the way, one thing we can do here is to force c1 to compile a method. i.e. c2 is more likely to fail than c1 as it does more optimizations. how do i force c1 to compile a method ? and how do i know which compiler is used to compile a method in the PrintCompilation log or through any other options ? >> >>> 3. if i am able to limit down to a specific method, i want to start >>> disabling optimizations, is there an option to disable all >>> optimizations in the c1 and c2 compilers, or i need to do it manually >>> ? >>> >> >> I don't think there's an all-in-one flag to turn all optimizations off. At least not for now. >> See c1_globals.hpp and c2_globals.hpp to get an idea of what optimizations you can turn off. >> >> - Kris >> >>> Thanks > > Thank you very much Kris. This is very helpful. From rednaxelafx at gmail.com Thu May 3 18:35:15 2012 From: rednaxelafx at gmail.com (Krystal Mok) Date: Fri, 4 May 2012 09:35:15 +0800 Subject: debug in hotspot In-Reply-To: References: Message-ID: On Fri, May 4, 2012 at 8:48 AM, Xin Tong wrote: > On Thu, May 3, 2012 at 8:45 PM, Xin Tong > wrote: > > On Thu, May 3, 2012 at 8:29 PM, Krystal Mok > wrote: > >> On 2012-5-4, at 8:16, Xin Tong wrote: > >> > >>> i would like to know how to debug in hotspot, what are some of the > >>> standard procedures ? Lets say, the hotspot fails to run a Java > >>> program. a few steps to triage the problem. > >>> > >>> 1. disable JIT compilers. hotspot has 2 compilers c1 and c2. they are > >>> both used if TieredCompilation is enabled. How do I disable both of > >>> them. > >> > >> It's there in the globals.hpp file: -XX:-UseCompiler > I forgot to mention there's a shorter (and better supported) equivalent to this: -Xint > >> > >>> 2. if the Java program passes after the JIT is disabled. There is a > >>> good chance that the problem is cause by the JIT. I want to narrow > >>> down to a specific method, I can use PrintCompilation to find out all > >>> the method compiled, but how can I disable one specific method from > >>> being compiled. > >> > >> -XX:CompileCommand='exclude,your/class,yourMethod' > >> Or an equivalent .hotspot_compiler configuration file. > >> Read this thread for example (in Chinese): > http://hllvm.group.iteye.com/group/topic/28201 > > By the way, one thing we can do here is to force c1 to compile a > method. i.e. c2 is more likely to fail than c1 as it does more > optimizations. how do i force c1 to compile a method ? What platform and version of JDK are you using? If there's a Client VM for your platform, use that; If you're using JDK7 or JDK8, try -XX:+TieredCompilation -XX:TieredStopAtLevel=1, which effectively disables C2 in tiered mode. Otherwise, if you have to use the Server VM (for instance, on amd64 where Oracle doesn't provide a Client VM build), and you're using an old version of JDK6, I'm not sure if there's a way to force compilation with C1. And, there's no way (yet) to force compilation with C1/C2 on a per-method granularity. > and how do i > know which compiler is used to compile a method in the > PrintCompilation log or through any other options ? > Please refer to this note: https://gist.github.com/1165804#file_notes.md I was supposed to put this up in the HotSpotInternals wiki, but somehow I haven't done it yet...oops. - Kris > > >> > >>> 3. if i am able to limit down to a specific method, i want to start > >>> disabling optimizations, is there an option to disable all > >>> optimizations in the c1 and c2 compilers, or i need to do it manually > >>> ? > >>> > >> > >> I don't think there's an all-in-one flag to turn all optimizations off. > At least not for now. > >> See c1_globals.hpp and c2_globals.hpp to get an idea of what > optimizations you can turn off. > >> > >> - Kris > >> > >>> Thanks > > > > Thank you very much Kris. This is very helpful. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20120504/9cb7a873/attachment.html From roland.westrelin at oracle.com Fri May 4 06:04:53 2012 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Fri, 4 May 2012 15:04:53 +0200 Subject: request for review (L): 7121756 Improve C1 inlining policy by using profiling at call sites In-Reply-To: References: <68105D4B-D98D-48F2-A84F-A398D295ABA3@oracle.com> Message-ID: <7E050089-40A7-4970-BB04-491C3A3FA038@oracle.com> > src/share/vm/c1/c1_GraphBuilder.cpp: > > + if (C1TypeProfileInlining && > + code != Bytecodes::_invokestatic && > + code != Bytecodes::_invokespecial && > + code != Bytecodes::_invokedynamic && > + (code != Bytecodes::_invokevirtual || !target->is_loaded() || !target->is_final_method())) { > > Can this be reversed and simplified? I'll see what I can do when I rework this. > src/share/vm/c1/c1_LIR.cpp: > > + assert (code == lir_checkcast ||code == lir_instanceof, "expects checkcast or instanceof only"); > > Spacing is odd. Ok. > src/share/vm/ci/ciMethod.cpp: > > +bool ciMethod::profile_is_hot_helper(ciProfileData* data, int bci, bool &warm, bool full) { > > What is "full"? Maybe you can find a better name. When a method is compiled, if some profiling data at a call site is available, the compiler checks if the call site is hot or not. The call site may have been seen C1ProfileHotFrequency (i.e. we've collected full profile information) or it may be have been seen a number of times < C1ProfileHotFrequency. We consider both call sites with full and partial profile data for inlining (assuming we have sufficient profile data: number of times seen >= C1ProfileHotFrequency/2). The full argument request that only call sites with full profiling data be considered. That's used for virtual calls where we want to be sure when we inline because the profiling data says only a single klass was seen that we have sufficient data. > src/share/vm/code/compiledIC.cpp: > > +bool CompiledProfile::is_profiled(NativeCall* call) { > +#ifdef COMPILER2 > + return false; > +#endif > +#ifdef COMPILER1 > + if (!C1ProfileInlining) return false; > > I think this will produce a compiler warning (or error) when compiling C2 since it defines -DCOMPILER2 -DCOMPILER1. Ok. > > +#ifdef ARM > + // The first word of a static call stub has no reloc info. So if > + // we don't find a reloc info we know, it's a static call stub. > + return obj != NULL; > +#endif > > Why does ARM not require a reloc info? On other platforms, the first instruction of the static call stub loads an oop with a mov or similar sequence of instructions. On ARM, to accommodate all ARM instruction sets, the oop is loaded with a PC relative ldr. The oop itself is embedded in the instruction stream at the end of the stub (so that it is never "executed"). So the reloc is where the oop is embedded not on the first instruction. Roland. From xerox.time.tech at gmail.com Fri May 4 08:59:14 2012 From: xerox.time.tech at gmail.com (Xin Tong) Date: Fri, 4 May 2012 11:59:14 -0400 Subject: memoization in hotspot Message-ID: is memoization implemented as an optimization in hotspot ? I have searched through the compiler options for the c1 and opto compilers. i do not see it there. maybe it does not provide enough benefits to justify its implementation cost ? Thanks Xin From rednaxelafx at gmail.com Sun May 6 19:08:29 2012 From: rednaxelafx at gmail.com (Krystal Mok) Date: Mon, 7 May 2012 10:08:29 +0800 Subject: Request for review (S): C2 should recognize "obj.getClass() == A.class" code pattern In-Reply-To: References: <6FD39DAC-B2F5-4811-984C-645EED80900D@oracle.com> <06859214-B092-4484-8CB1-879F6D5009EF@oracle.com> Message-ID: Hi all, Updated the patch again, posted at: https://gist.github.com/2622617#file_class_eq_ver_5.patch Could I get some reviews for this new version, please? And, would anyone sponsor this patch, pleae? Per John's suggestion, in Parse::adjust_map_after_if(), I've factored the logic from "int val_in_map" downward into a new subroutine sharpen_type_after_if(), which handles comparison with constant klass as well as the old cases. I tried a few times but I just can't find a clean factoring. Tested SPECjvm2008 with default arguments on a jvmg build, and it ran okay. Regards, Kris -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20120507/5c99aba9/attachment.html From christian.thalinger at oracle.com Mon May 7 09:28:58 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 7 May 2012 09:28:58 -0700 Subject: request for review (L): 7121756 Improve C1 inlining policy by using profiling at call sites In-Reply-To: <7E050089-40A7-4970-BB04-491C3A3FA038@oracle.com> References: <68105D4B-D98D-48F2-A84F-A398D295ABA3@oracle.com> <7E050089-40A7-4970-BB04-491C3A3FA038@oracle.com> Message-ID: <5589B015-3687-4A43-B50F-0144814006A1@oracle.com> On May 4, 2012, at 6:04 AM, Roland Westrelin wrote: >> src/share/vm/c1/c1_GraphBuilder.cpp: >> >> + if (C1TypeProfileInlining && >> + code != Bytecodes::_invokestatic && >> + code != Bytecodes::_invokespecial && >> + code != Bytecodes::_invokedynamic && >> + (code != Bytecodes::_invokevirtual || !target->is_loaded() || !target->is_final_method())) { >> >> Can this be reversed and simplified? > > I'll see what I can do when I rework this. > >> src/share/vm/c1/c1_LIR.cpp: >> >> + assert (code == lir_checkcast ||code == lir_instanceof, "expects checkcast or instanceof only"); >> >> Spacing is odd. > > Ok. > >> src/share/vm/ci/ciMethod.cpp: >> >> +bool ciMethod::profile_is_hot_helper(ciProfileData* data, int bci, bool &warm, bool full) { >> >> What is "full"? Maybe you can find a better name. > > When a method is compiled, if some profiling data at a call site is available, the compiler checks if the call site is hot or not. The call site may have been seen C1ProfileHotFrequency (i.e. we've collected full profile information) or it may be have been seen a number of times < C1ProfileHotFrequency. We consider both call sites with full and partial profile data for inlining (assuming we have sufficient profile data: number of times seen >= C1ProfileHotFrequency/2). The full argument request that only call sites with full profiling data be considered. That's used for virtual calls where we want to be sure when we inline because the profiling data says only a single klass was seen that we have sufficient data. So something like do_only_full_profiles. > >> src/share/vm/code/compiledIC.cpp: >> >> +bool CompiledProfile::is_profiled(NativeCall* call) { >> +#ifdef COMPILER2 >> + return false; >> +#endif >> +#ifdef COMPILER1 >> + if (!C1ProfileInlining) return false; >> >> I think this will produce a compiler warning (or error) when compiling C2 since it defines -DCOMPILER2 -DCOMPILER1. > > Ok. > >> >> +#ifdef ARM >> + // The first word of a static call stub has no reloc info. So if >> + // we don't find a reloc info we know, it's a static call stub. >> + return obj != NULL; >> +#endif >> >> Why does ARM not require a reloc info? > > On other platforms, the first instruction of the static call stub loads an oop with a mov or similar sequence of instructions. On ARM, to accommodate all ARM instruction sets, the oop is loaded with a PC relative ldr. The oop itself is embedded in the instruction stream at the end of the stub (so that it is never "executed"). So the reloc is where the oop is embedded not on the first instruction. That makes sense. Thank you. -- Chris > > Roland. From roland.westrelin at oracle.com Mon May 7 09:29:59 2012 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Mon, 7 May 2012 18:29:59 +0200 Subject: request for review (L): 7121756 Improve C1 inlining policy by using profiling at call sites In-Reply-To: <5589B015-3687-4A43-B50F-0144814006A1@oracle.com> References: <68105D4B-D98D-48F2-A84F-A398D295ABA3@oracle.com> <7E050089-40A7-4970-BB04-491C3A3FA038@oracle.com> <5589B015-3687-4A43-B50F-0144814006A1@oracle.com> Message-ID: >>> What is "full"? Maybe you can find a better name. >> >> When a method is compiled, if some profiling data at a call site is available, the compiler checks if the call site is hot or not. The call site may have been seen C1ProfileHotFrequency (i.e. we've collected full profile information) or it may be have been seen a number of times < C1ProfileHotFrequency. We consider both call sites with full and partial profile data for inlining (assuming we have sufficient profile data: number of times seen >= C1ProfileHotFrequency/2). The full argument request that only call sites with full profiling data be considered. That's used for virtual calls where we want to be sure when we inline because the profiling data says only a single klass was seen that we have sufficient data. > > So something like do_only_full_profiles. Yes. Roland. From vladimir.kozlov at oracle.com Mon May 7 10:34:33 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 07 May 2012 10:34:33 -0700 Subject: Request for reviews (S): 7160610: Unknown Native Code compilation issue In-Reply-To: <523E196A-968A-49DA-924D-842B3470E14F@oracle.com> References: <4F863553.9070503@oracle.com> <4F8656EF.4040600@oracle.com> <3A34CB19-A388-466A-9A29-C2C707C6B1C8@oracle.com> <4F866A5B.5010303@oracle.com> <4F875730.4070907@oracle.com> <523E196A-968A-49DA-924D-842B3470E14F@oracle.com> Message-ID: <4FA807A9.2030904@oracle.com> Thank you, Christian Vladimir Christian Thalinger wrote: > I think this looks good. -- Chris > > On Apr 12, 2012, at 3:29 PM, Vladimir Kozlov wrote: > >> http://cr.openjdk.java.net/~kvn/7160610/webrev >> >> I updated webrev with added regression test and using BasicType for input's type verification. And I ran nsk, full CTW and compiler regression tests with -XX:-OptimizeFile and -XX:-TieredCompilation. They passed. >> >> Thanks, >> Vladimir >> >> Vladimir Kozlov wrote: >>> On 4/11/12 9:34 PM, Tom Rodriguez wrote: >>>> On Apr 11, 2012, at 9:15 PM, Vladimir Kozlov wrote: >>>>>>> http://cr.openjdk.java.net/~kvn/7160610/webrev >>>>>>> >>>>>>> 7160610: Unknown Native Code compilation issue >>>>>>> >>>>>>> When constructing input vector use type of vector's operation which use it since element's sizes should match. In the bug case byte value is used for initialization of int[] array. The store vector is Store2I and input's type (byte) was used to construct init vector but there is no Replicate2B. Even if Replicate2B existed it will be wrong since it initialize only lowest 2 bytes. >>>>>> Why does in_bb(opd) ever affect which type to use? >>>>> If you ask why we had this condition, I don't know. I also think it is bogus. >>>> Yes, that's what I'm asking. Maybe it's some kind of shortcut check for whether it's part of the pack or not? >>> I think it was simple shortcut to get type. Nodes in loop has special types velt_type() pre-calculated for them, like next (in container_type()): >>> if (t->basic_type() == T_INT) { >>> if (t->higher_equal(TypeInt::BOOL)) return TypeInt::BOOL; >>> if (t->higher_equal(TypeInt::BYTE)) return TypeInt::BYTE; >>> ... >>>> We probably need to run a bunch of code past this to make sure it doesn't break anything. Don't we have a few regressions tests that exercise this pretty well? >>> I doubt we have such tests for vectors. Vectors were introduced eons ago and we hit this bug only with 7u2. Also OptimizeFill optimization reduced number of cases for vectorized loops. I start writing TestVect.java in my big vectors changes to cover common cases but I think we need to ask QE to write more tests for more coverage. Especially for vector arithmetic. >>> It reminds me that I need to add the test from bug report to the compiler regression tests. >>> I will run nsk, full CTW and compiler regression tests tomorrow. >>>>> I will change it to next to verify that all packed input's has the same type (they should, since they come from loop unrolling/node cloning): >>>>> >>>>> DEBUG_ONLY( const Type* opd_t = opd->bottom_type(); >>>>> >>>>> assert(opd_t == in->bottom_type(), "all same type"); >>>> That wouldn't necessarily be true would it? It could be a more precise type but still the same BasicType couldn't it? >>> You are right, may be I should use just BasicType. >>> Vladimir >>>> tom >>>> >>>>> Vladimir >>>>> >>>>>> tom >>>>>> >>>>>>> Thanks, >>>>>>> Vladimir >>>>>>> > From azeem.jiva at oracle.com Mon May 7 12:32:43 2012 From: azeem.jiva at oracle.com (Azeem Jiva) Date: Mon, 07 May 2012 14:32:43 -0500 Subject: Crash when using a built JVM Message-ID: <4FA8235B.9020706@oracle.com> I'm trying to run WLS with a JVM that I built pulled from the openjdk repository. I've made no changes, just pulled the recent source, and I get the crash (attached). Looks like some mismatch between the JRockit library and HotSpot? Ideas? -- Azeem Jiva @javawithjiva -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20120507/085494ab/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: hs_err_pid5605.log Type: text/x-log Size: 33933 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20120507/085494ab/hs_err_pid5605-0001.log From rednaxelafx at gmail.com Mon May 7 17:54:48 2012 From: rednaxelafx at gmail.com (Krystal Mok) Date: Tue, 8 May 2012 08:54:48 +0800 Subject: Crash when using a built JVM In-Reply-To: <4FA8235B.9020706@oracle.com> References: <4FA8235B.9020706@oracle.com> Message-ID: Hi Azeem, Did you build the HotSpot VM only, and put it in a Oracle JDK7u4 installation? This kind of mix-and-match used to work without problems (mostly), but in JDK7u4 there are new proprietary features in Oracle JDK (e.g. Java Flight Recorder) that's not part of OpenJDK. You're getting a segfault caused by null pointer in JFR-related code. You should probably build the entire JDK and use that, instead of mixing it with Oracle JDK on 7u4. P.S. This discussion may be better suited on hotspot-dev, since it's not a compiler problem. Cc'ing. - Kris On 2012-5-8, at 3:32, Azeem Jiva wrote: > I'm trying to run WLS with a JVM that I built pulled from the openjdk repository. I've made no changes, just pulled the recent source, and I get the crash (attached). Looks like some mismatch between the JRockit library and HotSpot? Ideas? > -- > Azeem Jiva > @javawithjiva > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20120508/ed8ce193/attachment.html From vladimir.kozlov at oracle.com Mon May 7 18:54:24 2012 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Tue, 08 May 2012 01:54:24 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7160610: Unknown Native Code compilation issue Message-ID: <20120508015429.A8F09471AB@hg.openjdk.java.net> Changeset: dc682d9431f3 Author: kvn Date: 2012-05-07 12:37 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/dc682d9431f3 7160610: Unknown Native Code compilation issue Summary: When constructing input vector use type of vector's operation which use it since element's sizes should match. Reviewed-by: never, twisti ! src/share/vm/opto/superword.cpp + test/compiler/7160610/Test7160610.java From vladimir.kozlov at oracle.com Tue May 8 11:45:29 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 08 May 2012 11:45:29 -0700 Subject: Request for reviews (XS): 7167266: missing copyright notes in 3rd party code Message-ID: <4FA969C9.4090003@oracle.com> http://cr.openjdk.java.net/~kvn/7167266/webrev 7167266: missing copyright notes in 3rd party code Add missing copyright notes in PorterStemmer test. Thanks, Vladimir From christian.thalinger at oracle.com Tue May 8 15:45:28 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 8 May 2012 15:45:28 -0700 Subject: Request for reviews (XS): 7167266: missing copyright notes in 3rd party code In-Reply-To: <4FA969C9.4090003@oracle.com> References: <4FA969C9.4090003@oracle.com> Message-ID: <438205AA-E01D-4A81-95A4-ECD34AC0D8FE@oracle.com> Looks good. -- Chris On May 8, 2012, at 11:45 AM, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/7167266/webrev > > 7167266: missing copyright notes in 3rd party code > > Add missing copyright notes in PorterStemmer test. > > Thanks, > Vladimir From vladimir.kozlov at oracle.com Tue May 8 15:46:18 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 08 May 2012 15:46:18 -0700 Subject: Request for reviews (XS): 7167266: missing copyright notes in 3rd party code In-Reply-To: <438205AA-E01D-4A81-95A4-ECD34AC0D8FE@oracle.com> References: <4FA969C9.4090003@oracle.com> <438205AA-E01D-4A81-95A4-ECD34AC0D8FE@oracle.com> Message-ID: <4FA9A23A.9010604@oracle.com> Thank you, Christian Vladimir Christian Thalinger wrote: > Looks good. -- Chris > > On May 8, 2012, at 11:45 AM, Vladimir Kozlov wrote: > >> http://cr.openjdk.java.net/~kvn/7167266/webrev >> >> 7167266: missing copyright notes in 3rd party code >> >> Add missing copyright notes in PorterStemmer test. >> >> Thanks, >> Vladimir > From vladimir.kozlov at oracle.com Tue May 8 18:08:23 2012 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Wed, 09 May 2012 01:08:23 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7167266: missing copyright notes in 3rd party code Message-ID: <20120509010829.539D5471D7@hg.openjdk.java.net> Changeset: 3a97daec1b34 Author: kvn Date: 2012-05-08 15:47 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/3a97daec1b34 7167266: missing copyright notes in 3rd party code Summary: add missing copyright notes to the regression test file. Reviewed-by: twisti, johnc ! test/compiler/7070134/Stemmer.java From vladimir.kozlov at oracle.com Wed May 9 18:30:39 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 09 May 2012 18:30:39 -0700 Subject: RFR(M): 7133857: exp() and pow() should use the x87 ISA on x86 In-Reply-To: <4F9522B8.1070708@oracle.com> References: <5C1A90BE-857A-475E-B894-870A098E9BFE@oracle.com> <4F9522B8.1070708@oracle.com> Message-ID: <4FAB1A3F.90008@oracle.com> Nils, May be I misunderstand your question but we can't "retire x87". Some instructions we use are present only in x87, like in these changes. Vladimir Nils Eliasson wrote: > Just curious, have there ever been any discussion about retiring x87 > support? For server, there can't be many non-SSE2 user > (JRockit retired x87 in the R28.0 release in 2010), for client some P3s > and Athlon XPs are probably still out there. For embedded, I have no > clue at all, except that there are some Geodes without SSE2. > > Do we have any download count for different x86/x64 hardware? > > If we agree that server and client can do without, then we should start > with removing x87 from c2. > > //Nils > > Roland Westrelin skrev 2012-04-02 10:56: >> Implements Math.exp() and Math.pow() using the x87 ISA. It is based on an existing implementation in C2 that was disabled because it was found to be broken. This change fixes some corner cases of the previous implementation and uses the same code in the interpreter, c1 and c2 so that consistent results are obtained from exp() and pow(). >> >> http://cr.openjdk.java.net/~roland/7133857/webrev.00/ >> >> Roland. >> > From vladimir.kozlov at oracle.com Wed May 9 18:34:11 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 09 May 2012 18:34:11 -0700 Subject: RFR(M): 7133857: exp() and pow() should use the x87 ISA on x86 In-Reply-To: <0256DCF1-3821-4D14-908F-24B993A0BBC4@oracle.com> References: <5C1A90BE-857A-475E-B894-870A098E9BFE@oracle.com> <469CFA3E-F018-438D-9CD4-E6865DBC56C8@oracle.com> <7D201702-4FD7-4AAE-9CB5-3EC2710DC878@oracle.com> <4F7F324B.7080609@oracle.com> <0256DCF1-3821-4D14-908F-24B993A0BBC4@oracle.com> Message-ID: <4FAB1B13.8060303@oracle.com> Roland Westrelin wrote: > Thanks for taking another look at this. > >> Why you need the next move?: >> >> + mov(rcx, tmp2); >> + Label integer; > > You're right, I don't need it. Must be some debugging code that I forgot to remove. > > Here is a new webrev that implements your suggestions: > http://cr.openjdk.java.net/~roland/7133857/webrev.04/ Looks good. Vladimir > > Roland. > From roland.westrelin at oracle.com Thu May 10 10:22:56 2012 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Thu, 10 May 2012 19:22:56 +0200 Subject: RFR(M): 7133857: exp() and pow() should use the x87 ISA on x86 In-Reply-To: <4FAB1A3F.90008@oracle.com> References: <5C1A90BE-857A-475E-B894-870A098E9BFE@oracle.com> <4F9522B8.1070708@oracle.com> <4FAB1A3F.90008@oracle.com> Message-ID: <502349CD-4AFB-4765-84CE-44A83A932002@oracle.com> > May be I misunderstand your question but we can't "retire x87". Some instructions we use are present only in x87, like in these changes. Maybe Nils meant dropping the code for UseSSE < 1. Roland. From vladimir.kozlov at oracle.com Thu May 10 11:00:57 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 10 May 2012 11:00:57 -0700 Subject: RFR(M): 7133857: exp() and pow() should use the x87 ISA on x86 In-Reply-To: <502349CD-4AFB-4765-84CE-44A83A932002@oracle.com> References: <5C1A90BE-857A-475E-B894-870A098E9BFE@oracle.com> <4F9522B8.1070708@oracle.com> <4FAB1A3F.90008@oracle.com> <502349CD-4AFB-4765-84CE-44A83A932002@oracle.com> Message-ID: <4FAC0259.3070401@oracle.com> Roland Westrelin wrote: >> May be I misunderstand your question but we can't "retire x87". Some instructions we use are present only in x87, like in these changes. > > Maybe Nils meant dropping the code for UseSSE < 1. I think it will be more pain to remove it cleanly than keep it. Vladimir > > Roland. From john.coomes at oracle.com Thu May 10 20:38:26 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 11 May 2012 03:38:26 +0000 Subject: hg: hsx/hotspot-comp: 6 new changesets Message-ID: <20120511033826.882DB4725D@hg.openjdk.java.net> Changeset: afeeed8e5f8c Author: ihse Date: 2012-04-30 12:13 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/afeeed8e5f8c 7165277: Fix missing execute permission issue running logger.sh Reviewed-by: ohair ! common/autoconf/configure ! common/autoconf/configure.ac Changeset: b2972095a4b1 Author: katleman Date: 2012-05-02 15:46 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/b2972095a4b1 Merge Changeset: 2eeb9fac7dfc Author: katleman Date: 2012-05-09 13:07 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/2eeb9fac7dfc Added tag jdk8-b37 for changeset b2972095a4b1 ! .hgtags Changeset: 2f06b15e2439 Author: ewendeli Date: 2012-05-03 14:17 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/2f06b15e2439 7154130: Add Mac OS X Instructions to README-builds.html Reviewed-by: ohair Contributed-by: edvard.wendelin at oracle.com ! README-builds.html Changeset: d939bd0ab13c Author: katleman Date: 2012-05-09 16:12 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/d939bd0ab13c Merge Changeset: b67bdaca36c2 Author: katleman Date: 2012-05-10 10:24 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/b67bdaca36c2 Added tag jdk8-b38 for changeset d939bd0ab13c ! .hgtags From john.coomes at oracle.com Thu May 10 20:38:32 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 11 May 2012 03:38:32 +0000 Subject: hg: hsx/hotspot-comp/corba: 7 new changesets Message-ID: <20120511033837.660804725F@hg.openjdk.java.net> Changeset: c6c0b1047985 Author: jmelvin Date: 2012-04-16 17:10 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/corba/rev/c6c0b1047985 7130404: [macosx] "os.arch" value should be "x86_64" for compatibility with Apple JDK6 Summary: On Mac OS X, align system property "os.arch" with Apple legacy JDKs. Also, improve os.name string matching by using .contains() method instead of .startsWith(). This fix spans multiple repositories. Reviewed-by: dcubed, phh, ohair, katleman ! make/common/shared/Platform.gmk Changeset: 9cdcc0152526 Author: coffeys Date: 2012-04-20 17:34 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/corba/rev/9cdcc0152526 7161925: sjava files in corba don't have copyright string and legal notice Reviewed-by: chegar Contributed-by: misha.bykov at oracle.com ! src/share/classes/com/sun/corba/se/impl/orbutil/DefineWrapper.sjava ! src/share/classes/com/sun/corba/se/impl/presentation/rmi/IDLTypesUtil_save.sjava Changeset: df0c7369a86b Author: lana Date: 2012-04-26 14:14 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/corba/rev/df0c7369a86b Merge Changeset: 4a653e435441 Author: lana Date: 2012-05-01 11:29 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/corba/rev/4a653e435441 Merge Changeset: 2d2f6b0f855b Author: katleman Date: 2012-05-09 13:07 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/corba/rev/2d2f6b0f855b Added tag jdk8-b37 for changeset 83fac66442cf ! .hgtags Changeset: b8cbfb31139f Author: katleman Date: 2012-05-09 13:11 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/corba/rev/b8cbfb31139f Merge Changeset: 785af00e2827 Author: katleman Date: 2012-05-10 10:24 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/corba/rev/785af00e2827 Added tag jdk8-b38 for changeset b8cbfb31139f ! .hgtags From john.coomes at oracle.com Thu May 10 20:38:42 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 11 May 2012 03:38:42 +0000 Subject: hg: hsx/hotspot-comp/jaxp: 4 new changesets Message-ID: <20120511033857.9E3A247260@hg.openjdk.java.net> Changeset: aabc08ea546f Author: ohair Date: 2012-04-30 16:03 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxp/rev/aabc08ea546f 7165312: Fix jaxp source movement for new build-infra Reviewed-by: ohrstrom ! makefiles/Makefile Changeset: 90204bfab4e2 Author: katleman Date: 2012-05-02 15:47 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxp/rev/90204bfab4e2 Merge Changeset: 5bbe0cb6f2f2 Author: katleman Date: 2012-05-09 13:07 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxp/rev/5bbe0cb6f2f2 Added tag jdk8-b37 for changeset 90204bfab4e2 ! .hgtags Changeset: f95fdbe525c8 Author: katleman Date: 2012-05-10 10:25 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxp/rev/f95fdbe525c8 Added tag jdk8-b38 for changeset 5bbe0cb6f2f2 ! .hgtags From john.coomes at oracle.com Thu May 10 20:39:03 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 11 May 2012 03:39:03 +0000 Subject: hg: hsx/hotspot-comp/jaxws: 2 new changesets Message-ID: <20120511033909.7580D47261@hg.openjdk.java.net> Changeset: ac1ba3b56775 Author: katleman Date: 2012-05-09 13:07 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxws/rev/ac1ba3b56775 Added tag jdk8-b37 for changeset b05a948db1b6 ! .hgtags Changeset: 7f6b44fd3034 Author: katleman Date: 2012-05-10 10:25 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxws/rev/7f6b44fd3034 Added tag jdk8-b38 for changeset ac1ba3b56775 ! .hgtags From john.coomes at oracle.com Thu May 10 20:41:12 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 11 May 2012 03:41:12 +0000 Subject: hg: hsx/hotspot-comp/jdk: 49 new changesets Message-ID: <20120511035013.9581C47267@hg.openjdk.java.net> Changeset: 8e3fb7dd21cd Author: skovatch Date: 2012-04-25 12:18 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/8e3fb7dd21cd 7128699: Fix bundle name so it contains the bugfix number in the name. Reviewed-by: robilad ! make/common/Release-macosx.gmk Changeset: 919be2f7fd6e Author: cgruszka Date: 2012-04-27 14:37 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/919be2f7fd6e Merge Changeset: 762661efef30 Author: jgodinez Date: 2012-04-24 13:29 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/762661efef30 7157659: [macosx] Landscape Printing orientation doesn't work Reviewed-by: bae, prr ! src/macosx/native/sun/awt/PrinterView.m Changeset: cdaadcc2c6a4 Author: jgodinez Date: 2012-04-26 13:16 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/cdaadcc2c6a4 7013850: Please change the mnemonic assignment system to avoid translation issue Reviewed-by: prr, mfang ! src/share/classes/sun/print/ServiceDialog.java ! src/share/classes/sun/print/resources/serviceui.properties ! src/share/classes/sun/print/resources/serviceui_de.properties ! src/share/classes/sun/print/resources/serviceui_es.properties ! src/share/classes/sun/print/resources/serviceui_fr.properties ! src/share/classes/sun/print/resources/serviceui_it.properties ! src/share/classes/sun/print/resources/serviceui_ja.properties ! src/share/classes/sun/print/resources/serviceui_ko.properties ! src/share/classes/sun/print/resources/serviceui_pt_BR.properties ! src/share/classes/sun/print/resources/serviceui_sv.properties ! src/share/classes/sun/print/resources/serviceui_zh_CN.properties ! src/share/classes/sun/print/resources/serviceui_zh_TW.properties Changeset: c2d29a375871 Author: lana Date: 2012-04-26 18:25 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/c2d29a375871 Merge Changeset: 4a19075bb989 Author: lana Date: 2012-05-02 09:53 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/4a19075bb989 Merge Changeset: 44beb8a52aec Author: zhouyx Date: 2012-04-20 10:34 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/44beb8a52aec 7129742: Unable to view focus in Non-Editable TextArea Summary: Make sure the cursor is visible by setVisible(true) Reviewed-by: rupashka, alexp ! src/solaris/classes/sun/awt/X11/XTextAreaPeer.java ! src/solaris/classes/sun/awt/X11/XTextFieldPeer.java + test/java/awt/TextArea/TextAreaCaretVisibilityTest/bug7129742.java Changeset: dfa2ea47257d Author: luchsh Date: 2012-04-20 13:13 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/dfa2ea47257d 7055065: NullPointerException when sorting JTable with empty cell Reviewed-by: rupashka ! src/share/classes/javax/swing/JTable.java + test/javax/swing/JTable/7055065/bug7055065.java Changeset: 738b32fc3ef1 Author: anthony Date: 2012-04-24 17:47 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/738b32fc3ef1 7150109: [macosx] the Frame showed incomplete. Summary: Open-source the tests Reviewed-by: art + test/java/awt/Frame/FrameStateTest/FrameStateTest.html + test/java/awt/Frame/FrameStateTest/FrameStateTest.java Changeset: 9ed029a0326d Author: anthony Date: 2012-04-24 19:12 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/9ed029a0326d 7163898: add isLoggable() check to doLog() Summary: Add the check and return immediately if it's false Reviewed-by: anthony, mchung, sla Contributed-by: Nicolas Carranza ! src/share/classes/sun/util/logging/PlatformLogger.java Changeset: 4a0f6ef43a09 Author: anthony Date: 2012-04-24 20:39 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/4a0f6ef43a09 7131021: [macosx] Consider using system properties to pass arguments from the launcher to AWT/SplashScreen Summary: Document the environment variables and add tests Reviewed-by: ksrini ! src/macosx/bin/java_md_macosx.c + test/tools/launcher/EnvironmentVariables.java ! test/tools/launcher/TestHelper.java + test/tools/launcher/TestSpecialArgs.java Changeset: 36fd5078198b Author: alexsch Date: 2012-04-25 16:48 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/36fd5078198b 7163482: [macosx] Regtest closed/javax/swing/JTree/4908142/bug4908142.java intermittent failure Reviewed-by: rupashka + test/javax/swing/JTree/4908142/bug4908142.java Changeset: f1d1dab11a06 Author: leonidr Date: 2012-04-25 18:15 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/f1d1dab11a06 7154480: [macosx] Not all popup menu items are visible Reviewed-by: art ! src/macosx/classes/sun/lwawt/macosx/LWCToolkit.java ! src/share/classes/javax/swing/JPopupMenu.java ! src/share/classes/sun/awt/SunToolkit.java Changeset: 340cda7e1430 Author: luchsh Date: 2012-04-26 12:39 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/340cda7e1430 7154030: java.awt.Component.hide() does not repaint parent component Reviewed-by: rupashka ! src/share/classes/javax/swing/JComponent.java + test/javax/swing/JComponent/7154030/bug7154030.java Changeset: 6314933aeaa9 Author: alexp Date: 2012-04-26 21:16 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/6314933aeaa9 7124210: [macosx] Replacing text in a TextField does generate an extra TextEvent Reviewed-by: serb ! src/macosx/classes/sun/lwawt/LWTextAreaPeer.java ! src/macosx/classes/sun/lwawt/LWTextComponentPeer.java ! src/macosx/classes/sun/lwawt/LWTextFieldPeer.java Changeset: 4184e5cbf46e Author: alexp Date: 2012-04-26 21:25 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/4184e5cbf46e 7124328: [macosx] javax.swing.JDesktopPane.getAllFramesInLayer returns unexpected value Reviewed-by: anthony ! src/share/classes/javax/swing/JDesktopPane.java Changeset: d148d3d194af Author: lana Date: 2012-04-26 18:15 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/d148d3d194af Merge Changeset: bbbf4e63562b Author: dcherepanov Date: 2012-05-02 13:53 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/bbbf4e63562b 7154062: [macosx] Mouse cursor isn't updated in applets Reviewed-by: anthony, art ! src/macosx/classes/sun/lwawt/macosx/CCursorManager.java ! src/macosx/classes/sun/lwawt/macosx/CEmbeddedFrame.java ! src/macosx/native/sun/awt/CCursorManager.m Changeset: 0fad89bd606b Author: alexsch Date: 2012-05-02 17:54 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/0fad89bd606b 7154048: [macosx] At least drag twice, the toolbar can be dragged to the left side Reviewed-by: anthony, leonidr ! src/macosx/classes/sun/lwawt/LWWindowPeer.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java ! src/macosx/native/sun/awt/AWTView.h ! src/macosx/native/sun/awt/AWTView.m ! src/macosx/native/sun/awt/AWTWindow.h ! src/macosx/native/sun/awt/AWTWindow.m + test/java/awt/Mouse/EnterExitEvents/DragWindowOutOfFrameTest.java + test/java/awt/Mouse/EnterExitEvents/DragWindowTest.java + test/java/awt/Mouse/EnterExitEvents/ResizingFrameTest.java ! test/java/awt/regtesthelpers/Util.java Changeset: f906d6068b43 Author: lana Date: 2012-05-02 09:54 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/f906d6068b43 Merge Changeset: 7b023213681c Author: psandoz Date: 2012-04-19 14:05 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/7b023213681c 7162262: (fs) Typo in java.nio.file.Path class description Reviewed-by: alanb ! src/share/classes/java/nio/file/Path.java Changeset: 77b35c5c4b95 Author: jmelvin Date: 2012-04-16 18:09 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/77b35c5c4b95 7130404: [macosx] "os.arch" value should be "x86_64" for compatibility with Apple JDK6 Summary: On Mac OS X, align system property "os.arch" with Apple legacy JDKs. Also, improve os.name string matching by using .contains() method instead of .startsWith(). This fix spans multiple repositories. Reviewed-by: dcubed, phh, ohair, katleman ! make/common/Defs-macosx.gmk ! make/common/shared/Platform.gmk ! src/share/classes/java/net/AbstractPlainDatagramSocketImpl.java ! src/share/classes/java/nio/Bits.java ! src/share/classes/java/util/prefs/Preferences.java ! src/share/classes/sun/awt/OSInfo.java ! src/share/classes/sun/font/FontUtilities.java ! src/share/classes/sun/launcher/LauncherHelper.java ! src/share/classes/sun/nio/cs/ext/ExtendedCharsets.java ! src/share/classes/sun/print/PSPrinterJob.java ! src/share/classes/sun/security/jgss/wrapper/SunNativeProvider.java ! src/share/classes/sun/security/krb5/Config.java ! src/share/classes/sun/security/krb5/Credentials.java ! src/share/classes/sun/security/provider/ByteArrayAccess.java ! src/solaris/classes/sun/nio/ch/DefaultAsynchronousChannelProvider.java ! src/solaris/classes/sun/nio/fs/DefaultFileSystemProvider.java ! src/solaris/classes/sun/print/UnixPrintServiceLookup.java ! test/demo/jvmti/DemoRun.java ! test/java/io/File/GetXSpace.java ! test/java/lang/ProcessBuilder/Basic.java ! test/java/lang/ProcessBuilder/Zombies.java ! test/java/lang/invoke/InvokeGenericTest.java ! test/java/lang/management/OperatingSystemMXBean/GetSystemLoadAverage.java ! test/java/nio/channels/FileChannel/Size.java ! test/java/nio/channels/FileChannel/Transfer.java ! test/java/nio/file/FileSystem/Basic.java ! test/sun/nio/ch/SelProvider.java ! test/tools/launcher/TestHelper.java Changeset: 079bb040b2ee Author: coleenp Date: 2012-04-19 10:53 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/079bb040b2ee Merge Changeset: 404c8e097ae9 Author: vinnie Date: 2012-04-19 16:58 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/404c8e097ae9 7162823: Modify the list of excluded tests (ProblemList Reviewed-by: alanb ! test/ProblemList.txt Changeset: bc51d0569ccd Author: khazra Date: 2012-04-19 13:26 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/bc51d0569ccd 7162385: TEST_BUG: sun/net/www/protocol/jar/B4957695.java failing again Summary: Enable finding "foo1.jar" Reviewed-by: chegar ! test/sun/net/www/protocol/jar/B4957695.java Changeset: 715f50872ae7 Author: khazra Date: 2012-04-19 18:11 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/715f50872ae7 7158636: InterfaceAddress.getBroadcast() returns invalid broadcast address on WLAN Summary: Update Windows native code to infer WLAN interface type in Windows Vista and later Reviewed-by: chegar, alanb ! src/windows/native/java/net/NetworkInterface.c ! src/windows/native/java/net/NetworkInterface.h Changeset: c3905c1f5da7 Author: zhouyx Date: 2012-04-20 16:11 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/c3905c1f5da7 7159982: ZipFile uses static for error message when malformed zip file encountered Reviewed-by: alanb, dholmes ! src/share/native/java/util/zip/ZipFile.c ! src/share/native/java/util/zip/zip_util.c Changeset: ec9876082b4e Author: ksrini Date: 2012-04-22 06:54 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/ec9876082b4e 6981776: Pack200 must support -target 7 bytecodes Summary: pack200 implementation of JSR-200 updated for JSR-292 changes Reviewed-by: jrose, ksrini Contributed-by: john.r.rose at oracle.com, kumar.x.srinivasan at oracle.com ! src/share/classes/com/sun/java/util/jar/pack/Attribute.java ! src/share/classes/com/sun/java/util/jar/pack/BandStructure.java ! src/share/classes/com/sun/java/util/jar/pack/ClassReader.java ! src/share/classes/com/sun/java/util/jar/pack/ClassWriter.java ! src/share/classes/com/sun/java/util/jar/pack/ConstantPool.java ! src/share/classes/com/sun/java/util/jar/pack/Constants.java ! src/share/classes/com/sun/java/util/jar/pack/Instruction.java ! src/share/classes/com/sun/java/util/jar/pack/Package.java ! src/share/classes/com/sun/java/util/jar/pack/PackageReader.java ! src/share/classes/com/sun/java/util/jar/pack/PackageWriter.java ! src/share/classes/com/sun/java/util/jar/pack/TLGlobals.java ! src/share/classes/com/sun/java/util/jar/pack/Utils.java ! src/share/native/com/sun/java/util/jar/pack/bands.cpp ! src/share/native/com/sun/java/util/jar/pack/bands.h ! src/share/native/com/sun/java/util/jar/pack/constants.h ! src/share/native/com/sun/java/util/jar/pack/defines.h ! src/share/native/com/sun/java/util/jar/pack/unpack.cpp ! src/share/native/com/sun/java/util/jar/pack/unpack.h ! test/tools/pack200/AttributeTests.java ! test/tools/pack200/PackageVersionTest.java ! test/tools/pack200/Utils.java - test/tools/pack200/dyn.jar ! test/tools/pack200/pack200-verifier/data/README ! test/tools/pack200/pack200-verifier/data/golden.jar ! test/tools/pack200/pack200-verifier/make/build.xml ! test/tools/pack200/pack200-verifier/src/xmlkit/ClassReader.java - test/tools/pack200/pack200-verifier/src/xmlkit/ClassSyntax.java - test/tools/pack200/pack200-verifier/src/xmlkit/ClassWriter.java - test/tools/pack200/pack200-verifier/src/xmlkit/InstructionAssembler.java - test/tools/pack200/pack200-verifier/src/xmlkit/InstructionSyntax.java Changeset: c2da01f0bdc1 Author: alanb Date: 2012-04-22 19:09 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/c2da01f0bdc1 7163395: jdk8/tl no longer builds on Mac Reviewed-by: chegar, ohair, ksrini - src/macosx/bin/amd64/jvm.cfg + src/macosx/bin/x86_64/jvm.cfg Changeset: 07dab8d9e34a Author: alanb Date: 2012-04-22 19:12 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/07dab8d9e34a Merge - test/tools/pack200/dyn.jar - test/tools/pack200/pack200-verifier/src/xmlkit/ClassSyntax.java - test/tools/pack200/pack200-verifier/src/xmlkit/ClassWriter.java - test/tools/pack200/pack200-verifier/src/xmlkit/InstructionAssembler.java - test/tools/pack200/pack200-verifier/src/xmlkit/InstructionSyntax.java Changeset: 1980be18d0f8 Author: alanb Date: 2012-04-22 21:22 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/1980be18d0f8 7132924: (dc) DatagramChannel.disconnect throws SocketException with IPv4 socket and IPv6 enabled [macosx] Reviewed-by: chegar ! src/share/classes/sun/nio/ch/DatagramChannelImpl.java ! src/solaris/native/sun/nio/ch/DatagramChannelImpl.c ! src/windows/native/sun/nio/ch/DatagramChannelImpl.c + test/java/nio/channels/DatagramChannel/Disconnect.java Changeset: fd22345bf1bf Author: sla Date: 2012-04-23 16:34 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/fd22345bf1bf 7163524: Add SecTaskAccess attribute to jstack [macosx] Reviewed-by: dholmes ! make/launchers/Makefile.launcher Changeset: 2c35304e885a Author: youdwei Date: 2012-04-24 21:06 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/2c35304e885a 7163865: Performance improvement for DateFormatSymbols.getZoneIndex(String) Reviewed-by: okutsu ! src/share/classes/java/text/DateFormatSymbols.java Changeset: f68c854fa584 Author: ksrini Date: 2012-04-24 10:37 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/f68c854fa584 7151434: java -jar -XX crashes java launcher Reviewed-by: mchung, darcy ! src/share/bin/java.c ! test/tools/launcher/Arrrghs.java ! test/tools/launcher/TestHelper.java Changeset: fcdbd1f34309 Author: khazra Date: 2012-04-24 14:59 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/fcdbd1f34309 7144274: [macosx] Default IPv6 multicast interface is not being set when calling MulticastSocket.joinGroup() Summary: Get default interface for Mac OS X when interface is not set Reviewed-by: chegar ! src/solaris/native/java/net/PlainDatagramSocketImpl.c ! src/solaris/native/java/net/net_util_md.c Changeset: 3e398b549cea Author: khazra Date: 2012-04-25 12:31 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/3e398b549cea 7160242: (prefs) Preferences.remove(null) does not throw NPE [macosx] Summary: Insert null check of argument in remove()'s implementation Reviewed-by: forax, chegar, alanb ! src/macosx/classes/java/util/prefs/MacOSXPreferences.java + test/java/util/prefs/RemoveNullKeyCheck.java Changeset: 108a02a57b75 Author: khazra Date: 2012-04-26 12:04 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/108a02a57b75 7118100: (prefs) Inconsistency when using system and user preference on OSX Lion Summary: Enable user to read/write preferences to persistent storage Reviewed-by: alanb ! src/macosx/classes/java/util/prefs/MacOSXPreferences.java ! src/macosx/classes/java/util/prefs/MacOSXPreferencesFile.java Changeset: 1cdcca9f3530 Author: lana Date: 2012-04-26 14:21 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/1cdcca9f3530 Merge Changeset: f0842ed897c3 Author: xuelei Date: 2012-04-27 04:25 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/f0842ed897c3 6996372: synchronizing handshaking hash Summary: remove the unnecessary synchronization. Also reviewed by David Schlosnagle (schlosna at gmail.com) Reviewed-by: weijun ! src/share/classes/sun/security/util/DisabledAlgorithmConstraints.java Changeset: c22b2f9066dd Author: alanb Date: 2012-05-01 11:17 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/c22b2f9066dd 7164570: (fs) WatchService queues CREATE event but not DELETE event for very short lived files [sol11] Reviewed-by: chegar ! src/solaris/classes/sun/nio/fs/SolarisWatchService.java + test/java/nio/file/WatchService/MayFlies.java Changeset: 71fdf32fdc65 Author: xuelei Date: 2012-05-01 03:48 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/71fdf32fdc65 7158688: Typo in SSLContext Spec Reviewed-by: weijun, wetmore ! src/share/classes/javax/net/ssl/SSLContext.java Changeset: 6c9c3d7ce9e2 Author: lana Date: 2012-05-01 11:30 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/6c9c3d7ce9e2 Merge Changeset: 46e0bd218fcc Author: mchung Date: 2012-05-01 19:45 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/46e0bd218fcc 7164376: Replace use of sun.security.action.LoadLibraryAction with System.loadLibrary Reviewed-by: alanb, mullan, prr ! src/macosx/classes/apple/launcher/JavaAppLauncher.java ! src/macosx/classes/apple/security/KeychainStore.java ! src/macosx/classes/com/apple/concurrent/LibDispatchNative.java ! src/macosx/classes/com/apple/eawt/Application.java ! src/macosx/classes/com/apple/eio/FileManager.java ! src/macosx/classes/com/apple/laf/AquaFileView.java ! src/macosx/classes/com/apple/laf/AquaLookAndFeel.java ! src/macosx/classes/com/apple/laf/AquaNativeResources.java ! src/macosx/classes/com/apple/laf/ScreenMenu.java ! src/macosx/classes/com/apple/laf/ScreenPopupFactory.java ! src/macosx/classes/java/util/prefs/MacOSXPreferencesFile.java ! src/macosx/classes/sun/awt/CGraphicsEnvironment.java ! src/macosx/classes/sun/lwawt/macosx/CAccessibility.java ! src/share/classes/com/sun/imageio/plugins/jpeg/JPEGImageReader.java ! src/share/classes/com/sun/imageio/plugins/jpeg/JPEGImageWriter.java ! src/share/classes/com/sun/java/util/jar/pack/NativeUnpack.java ! src/share/classes/java/awt/SplashScreen.java ! src/share/classes/java/awt/Toolkit.java ! src/share/classes/java/awt/event/NativeLibLoader.java ! src/share/classes/java/awt/image/ColorModel.java ! src/share/classes/java/net/AbstractPlainDatagramSocketImpl.java ! src/share/classes/java/net/AbstractPlainSocketImpl.java ! src/share/classes/java/net/DatagramPacket.java ! src/share/classes/java/net/InetAddress.java ! src/share/classes/java/net/NetworkInterface.java ! src/share/classes/sun/awt/NativeLibLoader.java ! src/share/classes/sun/awt/image/JPEGImageDecoder.java ! src/share/classes/sun/awt/image/NativeLibLoader.java ! src/share/classes/sun/java2d/Disposer.java ! src/share/classes/sun/management/ManagementFactoryHelper.java ! src/share/classes/sun/net/sdp/SdpSupport.java ! src/share/classes/sun/net/spi/DefaultProxySelector.java ! src/share/classes/sun/nio/ch/Util.java - src/share/classes/sun/security/action/LoadLibraryAction.java ! src/share/classes/sun/security/krb5/SCDynamicStoreConfig.java ! src/share/classes/sun/security/smartcardio/PCSC.java ! src/share/classes/sun/tracing/dtrace/JVM.java ! src/solaris/classes/sun/management/FileSystemImpl.java ! src/solaris/classes/sun/net/dns/ResolverConfigurationImpl.java ! src/solaris/classes/sun/nio/ch/sctp/SctpChannelImpl.java ! src/solaris/classes/sun/nio/ch/sctp/SctpMultiChannelImpl.java ! src/solaris/classes/sun/nio/ch/sctp/SctpServerChannelImpl.java ! src/solaris/classes/sun/print/CUPSPrinter.java ! src/windows/classes/sun/awt/shell/Win32ShellFolderManager2.java ! src/windows/classes/sun/awt/windows/WToolkit.java ! src/windows/classes/sun/management/FileSystemImpl.java ! src/windows/classes/sun/net/dns/ResolverConfigurationImpl.java ! src/windows/classes/sun/print/Win32PrintServiceLookup.java ! src/windows/classes/sun/security/smartcardio/PlatformPCSC.java Changeset: d78c6095dc98 Author: vinnie Date: 2012-05-02 14:50 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/d78c6095dc98 7087021: TEST: com/sun/crypto/provider/Mac/MacClone.java failed on Solaris sparc 5.10 Reviewed-by: mullan ! test/com/sun/crypto/provider/Mac/MacClone.java Changeset: 717582c056f3 Author: lana Date: 2012-05-02 10:17 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/717582c056f3 Merge - src/macosx/bin/amd64/jvm.cfg - src/share/classes/sun/security/action/LoadLibraryAction.java ! test/tools/launcher/TestHelper.java - test/tools/pack200/dyn.jar - test/tools/pack200/pack200-verifier/src/xmlkit/ClassSyntax.java - test/tools/pack200/pack200-verifier/src/xmlkit/ClassWriter.java - test/tools/pack200/pack200-verifier/src/xmlkit/InstructionAssembler.java - test/tools/pack200/pack200-verifier/src/xmlkit/InstructionSyntax.java Changeset: bc0f9e693620 Author: lana Date: 2012-05-08 13:08 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/bc0f9e693620 Merge - src/macosx/bin/amd64/jvm.cfg - src/share/classes/sun/security/action/LoadLibraryAction.java - test/tools/pack200/dyn.jar - test/tools/pack200/pack200-verifier/src/xmlkit/ClassSyntax.java - test/tools/pack200/pack200-verifier/src/xmlkit/ClassWriter.java - test/tools/pack200/pack200-verifier/src/xmlkit/InstructionAssembler.java - test/tools/pack200/pack200-verifier/src/xmlkit/InstructionSyntax.java Changeset: 185821106403 Author: katleman Date: 2012-05-09 13:07 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/185821106403 Added tag jdk8-b37 for changeset 9e82ac15ab80 ! .hgtags Changeset: c45f3509a707 Author: katleman Date: 2012-05-09 13:13 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/c45f3509a707 Merge - src/macosx/bin/amd64/jvm.cfg - src/share/classes/sun/security/action/LoadLibraryAction.java - test/tools/pack200/dyn.jar - test/tools/pack200/pack200-verifier/src/xmlkit/ClassSyntax.java - test/tools/pack200/pack200-verifier/src/xmlkit/ClassWriter.java - test/tools/pack200/pack200-verifier/src/xmlkit/InstructionAssembler.java - test/tools/pack200/pack200-verifier/src/xmlkit/InstructionSyntax.java Changeset: b5726775b0d8 Author: katleman Date: 2012-05-10 10:25 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/b5726775b0d8 Added tag jdk8-b38 for changeset c45f3509a707 ! .hgtags From john.coomes at oracle.com Fri May 11 07:01:34 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 11 May 2012 14:01:34 +0000 Subject: hg: hsx/hotspot-comp/langtools: 9 new changesets Message-ID: <20120511140155.DF23D47286@hg.openjdk.java.net> Changeset: 55ae94116e89 Author: jjg Date: 2012-04-06 10:10 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/55ae94116e89 7157626: Create a new test to check major version for a class file Reviewed-by: jjg Contributed-by: sonali.goel at oracle.com + test/tools/javac/classfiles/ClassVersionChecker.java Changeset: 9c429f38ca7e Author: ksrini Date: 2012-04-09 14:31 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/9c429f38ca7e 7156633: (javac) incorrect errors when parsing variable declaration in block statements. Reviewed-by: jjg Contributed-by: jan.lahoda at oracle.com ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties + test/tools/javac/diags/examples/IllegalStartOfStmt.java + test/tools/javac/diags/examples/NotAllowedClass.java + test/tools/javac/diags/examples/NotAllowedVariable.java ! test/tools/javac/parser/JavacParserTest.java Changeset: c35b158e2290 Author: lana Date: 2012-04-10 23:19 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/c35b158e2290 Merge Changeset: 6f0ed5a89c25 Author: mcimadamore Date: 2012-04-11 10:50 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/6f0ed5a89c25 7154127: Inference cleanup: remove bound check analysis from visitors in Types.java Summary: Remove bound checking rules from recursive subtype visitors in Types.java and replace with centralized bound-checking logic Reviewed-by: jjg, dlsmith ! src/share/classes/com/sun/tools/javac/code/Type.java ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/Infer.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/share/classes/com/sun/tools/javac/util/RichDiagnosticFormatter.java ! test/tools/javac/Diagnostics/6722234/T6722234b_1.out ! test/tools/javac/Diagnostics/6722234/T6722234b_2.out ! test/tools/javac/Diagnostics/6799605/T6799605.out ! test/tools/javac/cast/7123100/T7123100a.out ! test/tools/javac/diags/examples.not-yet.txt ! test/tools/javac/diags/examples/CantApplyDiamond1.java ! test/tools/javac/diags/examples/IncompatibleTypes1.java + test/tools/javac/diags/examples/InferNoConformingAssignment.java - test/tools/javac/diags/examples/InferredDoNotConformToBounds.java + test/tools/javac/diags/examples/InferredDoNotConformToEq.java + test/tools/javac/diags/examples/InferredDoNotConformToLower.java + test/tools/javac/diags/examples/InferredDoNotConformToUpper.java ! test/tools/javac/diags/examples/InvalidInferredTypes.java ! test/tools/javac/diags/examples/WhereCaptured.java ! test/tools/javac/diags/examples/WhereCaptured1.java + test/tools/javac/diags/examples/WhereFreshTvar.java ! test/tools/javac/generics/diamond/neg/Neg06.out ! test/tools/javac/generics/diamond/neg/Neg07.out ! test/tools/javac/generics/inference/6315770/T6315770.out ! test/tools/javac/generics/inference/6611449/T6611449.out ! test/tools/javac/generics/inference/6638712/T6638712b.out ! test/tools/javac/generics/inference/6638712/T6638712d.out ! test/tools/javac/generics/inference/6638712/T6638712e.out ! test/tools/javac/generics/inference/6650759/T6650759m.out ! test/tools/javac/generics/inference/7086601/T7086601a.out + test/tools/javac/generics/inference/7154127/T7154127.java + test/tools/javac/generics/inference/7154127/T7154127.out Changeset: d023d5c3fbd2 Author: lana Date: 2012-04-18 10:22 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/d023d5c3fbd2 Merge - test/tools/javac/diags/examples/InferredDoNotConformToBounds.java Changeset: 94bbaa67686f Author: lana Date: 2012-04-23 16:59 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/94bbaa67686f Merge - test/tools/javac/diags/examples/InferredDoNotConformToBounds.java Changeset: 5891b38985e8 Author: katleman Date: 2012-04-26 14:07 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/5891b38985e8 Added tag jdk8-b36 for changeset 94bbaa67686f ! .hgtags Changeset: 1f224f160aa8 Author: katleman Date: 2012-05-09 13:08 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/1f224f160aa8 Added tag jdk8-b37 for changeset 5891b38985e8 ! .hgtags Changeset: a9f547c218d9 Author: katleman Date: 2012-05-10 10:25 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/a9f547c218d9 Added tag jdk8-b38 for changeset 1f224f160aa8 ! .hgtags From tom.deneau at amd.com Fri May 11 13:05:56 2012 From: tom.deneau at amd.com (Deneau, Tom) Date: Fri, 11 May 2012 20:05:56 +0000 Subject: RFR(M): 7133857: exp() and pow() should use the x87 ISA Message-ID: Vladimir -- On a related topic, newer processors may tend to downplay the performance of x87, so for better performance it would be good to have equivalent SSE routines for those things which are currently only in x87. -- Tom Vladimir Kozlov wrote: >Nils, > >May be I misunderstand your question but we can't "retire x87". Some >instructions we use are present only in x87, like in these changes. > >Vladimir > >Nils Eliasson wrote: >> Just curious, have there ever been any discussion about retiring >> x87 support? For server, there can't be many non-SSE2 user (JRockit >> retired x87 in the R28.0 release in 2010), for client some P3s and >> Athlon XPs are probably still out there. For embedded, I have no clue >> at all, except that there are some Geodes without SSE2. >> >> Do we have any download count for different x86/x64 hardware? >> >> If we agree that server and client can do without, then we should >> start with removing x87 from c2. >> >> //Nils >> >> Roland Westrelin skrev 2012-04-02 10:56: >>> Implements Math.exp() and Math.pow() using the x87 ISA. It is based on an existing implementation in C2 that was disabled because it was found to be broken. This change fixes some corner cases of the previous implementation and uses the same code in the interpreter, c1 and c2 so that consistent results are obtained from exp() and pow(). >>> >>> http://cr.openjdk.java.net/~roland/7133857/webrev.00/ >>> >>> Roland. >>> >> > From vladimir.kozlov at oracle.com Fri May 11 13:51:39 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 11 May 2012 13:51:39 -0700 Subject: RFR(M): 7133857: exp() and pow() should use the x87 ISA In-Reply-To: References: Message-ID: <4FAD7BDB.7080601@oracle.com> Deneau, Tom wrote: > Vladimir -- > > On a related topic, newer processors may tend to downplay the > performance of x87, so for better performance it would be good > to have equivalent SSE routines for those things which are currently > only in x87. I agree, it would be nice and it would simplify/improve generated code. Vladimir > > -- Tom > > Vladimir Kozlov wrote: > >> Nils, >> >> May be I misunderstand your question but we can't "retire x87". Some >> instructions we use are present only in x87, like in these changes. >> >> Vladimir >> >> Nils Eliasson wrote: >>> Just curious, have there ever been any discussion about retiring >>> x87 support? For server, there can't be many non-SSE2 user (JRockit >>> retired x87 in the R28.0 release in 2010), for client some P3s and >>> Athlon XPs are probably still out there. For embedded, I have no clue >>> at all, except that there are some Geodes without SSE2. >>> >>> Do we have any download count for different x86/x64 hardware? >>> >>> If we agree that server and client can do without, then we should >>> start with removing x87 from c2. >>> >>> //Nils >>> >>> Roland Westrelin skrev 2012-04-02 10:56: >>>> Implements Math.exp() and Math.pow() using the x87 ISA. It is based on an existing implementation in C2 that was disabled because it was found to be broken. This change fixes some corner cases of the previous implementation and uses the same code in the interpreter, c1 and c2 so that consistent results are obtained from exp() and pow(). >>>> >>>> http://cr.openjdk.java.net/~roland/7133857/webrev.00/ >>>> >>>> Roland. >>>> >> > From alejandro.murillo at oracle.com Sat May 12 17:56:40 2012 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Sun, 13 May 2012 00:56:40 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 54 new changesets Message-ID: <20120513005829.4C98B472C5@hg.openjdk.java.net> Changeset: f621660a297b Author: katleman Date: 2012-04-12 09:34 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/f621660a297b Added tag jdk8-b34 for changeset f284b0883558 ! .hgtags Changeset: dce0525b7ee5 Author: katleman Date: 2012-04-19 12:18 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/dce0525b7ee5 Added tag jdk8-b35 for changeset f621660a297b ! .hgtags Changeset: 19e197e2a1af Author: coleenp Date: 2012-04-05 12:17 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/19e197e2a1af 7158988: jvm crashes while debugging on x86_32 and x86_64 Summary: Object pointer is pushed more than once on stack, where GC doesn't expect it. Reviewed-by: coleenp, kvn Contributed-by: axel.siebenborn at sap.com ! src/cpu/x86/vm/templateTable_x86_32.cpp ! src/cpu/x86/vm/templateTable_x86_64.cpp + test/runtime/7158988/FieldMonitor.java + test/runtime/7158988/TestFieldMonitor.sh + test/runtime/7158988/TestPostFieldModification.java Changeset: a4b63a58d295 Author: dcubed Date: 2012-04-09 08:38 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/a4b63a58d295 Merge Changeset: 10c12fb36ed2 Author: sla Date: 2012-04-05 14:16 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/10c12fb36ed2 7133111: libsaproc debug print should be printed as unsigned long to fit large numbers on 64bit platform Reviewed-by: dcubed, mgronlun, dsamersoff ! agent/src/os/linux/ps_core.c Changeset: 49036505ab5f Author: jiangli Date: 2012-03-29 22:18 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/49036505ab5f 7154670: The instanceKlass _implementors[] and _nof_implementors are not needed for non-interface klass. Summary: Change implementor to embedded instanceKlass field. Reviewed-by: sspitsyn, minqi, coleenp ! agent/src/share/classes/sun/jvm/hotspot/jdi/VirtualMachineImpl.java ! agent/src/share/classes/sun/jvm/hotspot/oops/InstanceKlass.java ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/ci/ciInstanceKlass.cpp ! src/share/vm/ci/ciInstanceKlass.hpp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/code/dependencies.cpp ! src/share/vm/memory/oopFactory.cpp ! src/share/vm/memory/oopFactory.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/instanceKlassKlass.cpp ! src/share/vm/oops/instanceKlassKlass.hpp ! src/share/vm/runtime/vmStructs.cpp Changeset: 5809bf572ba3 Author: jcoomes Date: 2012-03-31 00:05 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/5809bf572ba3 Merge Changeset: 08f8d00f2ae3 Author: bobv Date: 2012-04-10 13:27 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/08f8d00f2ae3 Merge ! src/share/vm/classfile/classFileParser.cpp Changeset: 0cea7f13029e Author: dlong Date: 2012-04-12 18:41 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/0cea7f13029e Merge Changeset: df4cd4aac5c1 Author: rbackman Date: 2012-04-12 13:24 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/df4cd4aac5c1 7160924: jvmti: GetPhase returns incorrect phase before VMInit event is issued Reviewed-by: acorn, dcubed ! src/share/vm/runtime/thread.cpp Changeset: 27dab8a7c762 Author: coleenp Date: 2012-04-12 22:03 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/27dab8a7c762 7160467: Fix test for 7158988 Summary: Ended up checking in FieldMonitor.java as TestPostFieldModification.java Reviewed-by: kamg ! test/runtime/7158988/TestPostFieldModification.java Changeset: 0f701f572aed Author: coleenp Date: 2012-04-13 08:11 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/0f701f572aed Merge Changeset: c263e0e9f14b Author: dcubed Date: 2012-04-15 15:37 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/c263e0e9f14b Merge Changeset: 0105f367a14c Author: rbackman Date: 2012-03-06 12:36 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/0105f367a14c 7160570: Intrinsification support for tracing framework Reviewed-by: sla, never ! src/os/bsd/vm/osThread_bsd.hpp ! src/os/linux/vm/osThread_linux.hpp ! src/os/solaris/vm/osThread_solaris.hpp ! src/os/windows/vm/osThread_windows.hpp ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/c1/c1_LIRGenerator.hpp ! src/share/vm/c1/c1_Runtime1.cpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/runtime.cpp ! src/share/vm/opto/runtime.hpp ! src/share/vm/runtime/osThread.hpp ! src/share/vm/trace/traceMacros.hpp Changeset: 5c86f8211d1e Author: brutisso Date: 2012-04-13 01:59 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/5c86f8211d1e 7160728: Introduce an extra logging level for G1 logging Summary: Added log levels "fine", "finer" and "finest". Let PrintGC map to "fine" and PrintGCDetails map to "finer". Separated out the per worker information in the G1 logging to the "finest" level. Reviewed-by: stefank, jwilhelm, tonyp, johnc ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMarkThread.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp + src/share/vm/gc_implementation/g1/g1Log.cpp + src/share/vm/gc_implementation/g1/g1Log.hpp ! src/share/vm/gc_implementation/g1/g1MarkSweep.cpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp ! src/share/vm/gc_implementation/g1/vm_operations_g1.cpp Changeset: b632e80fc9dc Author: brutisso Date: 2012-04-16 08:57 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/b632e80fc9dc 4988100: oop_verify_old_oop appears to be dead Summary: removed oop_verify_old_oop and allow_dirty. Also reviewed by: alexlamsl at gmail.com Reviewed-by: jmasa, jwilhelm ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1MarkSweep.cpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.cpp ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.hpp ! src/share/vm/gc_implementation/parallelScavenge/psOldGen.cpp ! src/share/vm/gc_implementation/parallelScavenge/psOldGen.hpp ! src/share/vm/gc_implementation/parallelScavenge/psYoungGen.cpp ! src/share/vm/gc_implementation/parallelScavenge/psYoungGen.hpp ! src/share/vm/gc_implementation/shared/immutableSpace.cpp ! src/share/vm/gc_implementation/shared/immutableSpace.hpp ! src/share/vm/gc_implementation/shared/mutableNUMASpace.cpp ! src/share/vm/gc_implementation/shared/mutableNUMASpace.hpp ! src/share/vm/gc_implementation/shared/mutableSpace.cpp ! src/share/vm/gc_implementation/shared/mutableSpace.hpp ! src/share/vm/gc_interface/collectedHeap.hpp ! src/share/vm/memory/compactingPermGenGen.cpp ! src/share/vm/memory/compactingPermGenGen.hpp ! src/share/vm/memory/defNewGeneration.cpp ! src/share/vm/memory/defNewGeneration.hpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/genCollectedHeap.hpp ! src/share/vm/memory/generation.cpp ! src/share/vm/memory/generation.hpp ! src/share/vm/memory/space.cpp ! src/share/vm/memory/space.hpp ! src/share/vm/memory/universe.cpp ! src/share/vm/memory/universe.hpp ! src/share/vm/oops/instanceRefKlass.cpp ! src/share/vm/oops/klass.cpp ! src/share/vm/oops/klass.hpp ! src/share/vm/oops/objArrayKlass.cpp ! src/share/vm/oops/objArrayKlass.hpp ! src/share/vm/oops/oop.cpp ! src/share/vm/oops/oop.hpp ! src/share/vm/runtime/vmThread.cpp Changeset: dde53abda3d6 Author: stefank Date: 2012-04-11 16:18 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/dde53abda3d6 7160613: VerifyRememberedSets doesn't work with CompressedOops Summary: use load_decode_heap_oop instead of load_decode_heap_oop_not_null Reviewed-by: tonyp, brutisso ! src/share/vm/gc_implementation/parallelScavenge/cardTableExtension.cpp Changeset: 720b6a76dd9d Author: tonyp Date: 2012-04-18 07:21 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/720b6a76dd9d 7157073: G1: type change size_t -> uint for region counts / indexes Summary: Change the type of fields / variables / etc. that represent region counts and indeces from size_t to uint. Reviewed-by: iveresov, brutisso, jmasa, jwilhelm ! agent/src/share/classes/sun/jvm/hotspot/gc_implementation/g1/HeapRegionSeq.java ! agent/src/share/classes/sun/jvm/hotspot/gc_implementation/g1/HeapRegionSetBase.java ! src/share/vm/gc_implementation/g1/collectionSetChooser.cpp ! src/share/vm/gc_implementation/g1/collectionSetChooser.hpp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp ! src/share/vm/gc_implementation/g1/concurrentMark.inline.hpp ! src/share/vm/gc_implementation/g1/g1AllocRegion.cpp ! src/share/vm/gc_implementation/g1/g1AllocRegion.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/gc_implementation/g1/g1ErgoVerbose.hpp ! src/share/vm/gc_implementation/g1/g1MonitoringSupport.cpp ! src/share/vm/gc_implementation/g1/g1MonitoringSupport.hpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.hpp ! src/share/vm/gc_implementation/g1/heapRegionSeq.cpp ! src/share/vm/gc_implementation/g1/heapRegionSeq.hpp ! src/share/vm/gc_implementation/g1/heapRegionSeq.inline.hpp ! src/share/vm/gc_implementation/g1/heapRegionSet.cpp ! src/share/vm/gc_implementation/g1/heapRegionSet.hpp ! src/share/vm/gc_implementation/g1/heapRegionSet.inline.hpp ! src/share/vm/gc_implementation/g1/sparsePRT.cpp ! src/share/vm/gc_implementation/g1/vmStructs_g1.hpp Changeset: f7a8920427a6 Author: tonyp Date: 2012-04-18 13:39 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/f7a8920427a6 7145441: G1: collection set chooser-related cleanup Summary: Cleanup of the CSet chooser class: standardize on uints for region num and indexes (instead of int, jint, etc.), make the method / field naming style more consistent, remove a lot of dead code. Reviewed-by: johnc, brutisso ! src/share/vm/gc_implementation/g1/collectionSetChooser.cpp ! src/share/vm/gc_implementation/g1/collectionSetChooser.hpp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp Changeset: f3f101a5e59b Author: johnc Date: 2012-04-20 11:41 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/f3f101a5e59b Merge Changeset: dff6e3459210 Author: amurillo Date: 2012-04-20 16:23 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/dff6e3459210 Merge Changeset: 50b4400ca1ec Author: amurillo Date: 2012-04-20 16:23 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/50b4400ca1ec Added tag hs24-b08 for changeset dff6e3459210 ! .hgtags Changeset: bfcf92bfefb8 Author: katleman Date: 2012-04-26 14:05 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/bfcf92bfefb8 Added tag jdk8-b36 for changeset 50b4400ca1ec ! .hgtags Changeset: 4ee58fcab520 Author: katleman Date: 2012-05-09 13:07 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/4ee58fcab520 Added tag jdk8-b37 for changeset bfcf92bfefb8 ! .hgtags Changeset: 3c91f2c9fd21 Author: amurillo Date: 2012-04-20 17:13 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/3c91f2c9fd21 7163193: new hotspot build - hs24-b09 Reviewed-by: jcoomes ! make/hotspot_version Changeset: f3a4ee95783b Author: kevinw Date: 2012-04-20 14:55 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/f3a4ee95783b 7162488: VM not printing unknown -XX options Reviewed-by: dholmes, kamg ! src/share/vm/runtime/arguments.cpp + test/runtime/7162488/Test7162488.sh Changeset: 29ee40a082d3 Author: sla Date: 2012-04-23 13:30 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/29ee40a082d3 7162063: libsaproc debug print should format size_t correctly on 64bit platform Reviewed-by: rbackman, mgronlun, dholmes ! agent/src/os/linux/ps_core.c Changeset: f33c4d0f4c9e Author: dcubed Date: 2012-04-23 11:03 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/f33c4d0f4c9e Merge Changeset: d652a62d6e03 Author: dcubed Date: 2012-03-23 11:50 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/d652a62d6e03 7102323: RFE: enable Full Debug Symbols Phase 1 on Solaris Summary: Add support for ENABLE_FULL_DEBUG_SYMBOLS and ZIP_DEBUGINFO_FILES build flags. Add support for .diz files. Reviewed-by: dholmes, ohair, sspitsyn ! make/Makefile ! make/linux/Makefile ! make/linux/makefiles/buildtree.make ! make/linux/makefiles/defs.make ! make/linux/makefiles/gcc.make ! make/linux/makefiles/jsig.make ! make/linux/makefiles/saproc.make ! make/linux/makefiles/vm.make ! make/solaris/Makefile ! make/solaris/makefiles/buildtree.make ! make/solaris/makefiles/defs.make ! make/solaris/makefiles/dtrace.make ! make/solaris/makefiles/jsig.make ! make/solaris/makefiles/saproc.make ! make/solaris/makefiles/sparcWorks.make ! make/solaris/makefiles/vm.make ! make/windows/build.make ! make/windows/makefiles/compile.make ! make/windows/makefiles/debug.make ! make/windows/makefiles/defs.make ! make/windows/makefiles/fastdebug.make ! make/windows/makefiles/product.make ! make/windows/makefiles/sa.make Changeset: 744728c16316 Author: dcubed Date: 2012-04-03 09:48 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/744728c16316 7158067: FDS: ENABLE_FULL_DEBUG_SYMBOLS flag should only affect product builds Summary: Build option FULL_DEBUG_SYMBOLS=0 only affects product builds. Reviewed-by: ohair, jmelvin, sspitsyn ! make/Makefile ! make/linux/Makefile ! make/linux/makefiles/defs.make ! make/solaris/Makefile ! make/solaris/makefiles/defs.make ! make/windows/makefiles/defs.make Changeset: 74c359c4a9e5 Author: dcubed Date: 2012-04-24 15:20 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/74c359c4a9e5 Merge ! make/Makefile ! make/linux/Makefile ! make/linux/makefiles/buildtree.make ! make/linux/makefiles/defs.make ! make/linux/makefiles/gcc.make ! make/linux/makefiles/vm.make ! make/solaris/makefiles/buildtree.make ! make/solaris/makefiles/defs.make ! make/solaris/makefiles/sparcWorks.make ! make/solaris/makefiles/vm.make ! make/windows/build.make ! make/windows/makefiles/compile.make ! make/windows/makefiles/debug.make ! make/windows/makefiles/defs.make ! make/windows/makefiles/fastdebug.make ! make/windows/makefiles/product.make Changeset: d6c393b0164b Author: dcubed Date: 2012-04-25 15:06 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/d6c393b0164b 7164344: enabling ZIP_DEBUGINFO_FILES causes unexpected test failures on Solaris and Windows Summary: Disable FDS by default on Solaris; disable ZIP_DEBUGINFO_FILES by default on Windows. Reviewed-by: acorn, sspitsyn ! make/solaris/makefiles/defs.make ! make/windows/makefiles/defs.make Changeset: 973046802b6f Author: dlong Date: 2012-04-26 16:24 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/973046802b6f 7162955: Attach api on Solaris, too many open files Summary: Release server-side socket after client receives it. Reviewed-by: sla, dsamersoff, dcubed, acorn Contributed-by: dean.long at oracle.com ! src/os/solaris/vm/attachListener_solaris.cpp Changeset: 6f0612ea55ce Author: jprovino Date: 2012-05-02 15:47 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/6f0612ea55ce Merge Changeset: 9f059abe8cf2 Author: jmasa Date: 2012-03-29 19:46 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/9f059abe8cf2 7131629: Generalize the CMS free list code Summary: Make the FreeChunk, FreeList, TreeList, and BinaryTreeDictionary classes usable outside CMS. Reviewed-by: brutisso, johnc, jwilhelm Contributed-by: coleen.phillimore at oracle.com - src/share/vm/gc_implementation/concurrentMarkSweep/binaryTreeDictionary.cpp - src/share/vm/gc_implementation/concurrentMarkSweep/binaryTreeDictionary.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsPermGen.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsPermGen.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp - src/share/vm/gc_implementation/concurrentMarkSweep/freeBlockDictionary.cpp - src/share/vm/gc_implementation/concurrentMarkSweep/freeBlockDictionary.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/freeChunk.cpp - src/share/vm/gc_implementation/concurrentMarkSweep/freeList.cpp - src/share/vm/gc_implementation/concurrentMarkSweep/freeList.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/vmStructs_cms.hpp + src/share/vm/memory/binaryTreeDictionary.cpp + src/share/vm/memory/binaryTreeDictionary.hpp + src/share/vm/memory/freeBlockDictionary.cpp + src/share/vm/memory/freeBlockDictionary.hpp + src/share/vm/memory/freeList.cpp + src/share/vm/memory/freeList.hpp ! src/share/vm/memory/generationSpec.cpp ! src/share/vm/precompiled/precompiled.hpp ! src/share/vm/runtime/vmStructs.cpp Changeset: 8a2e5a6a19a4 Author: johnc Date: 2012-04-25 10:23 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/8a2e5a6a19a4 7143490: G1: Remove HeapRegion::_top_at_conc_mark_count Summary: Removed the HeapRegion::_top_at_conc_mark_count field. It is no longer needed as a result of the changes for 6888336 and 7127706. Refactored the closures that finalize and verify the liveness counting data so that common functionality was placed into a base class. Reviewed-by: brutisso, tonyp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp ! src/share/vm/gc_implementation/g1/heapRegion.inline.hpp Changeset: f69a5d43dc19 Author: jmasa Date: 2012-04-25 09:55 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/f69a5d43dc19 7164144: Fix variable naming style in freeBlockDictionary.* and binaryTreeDictionary* Summary: Fix naming style to be consistent with the predominant hotspot style. Reviewed-by: ysr, brutisso ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/freeChunk.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/promotionInfo.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/promotionInfo.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/vmStructs_cms.hpp ! src/share/vm/gc_implementation/shared/allocationStats.hpp ! src/share/vm/memory/binaryTreeDictionary.cpp ! src/share/vm/memory/binaryTreeDictionary.hpp ! src/share/vm/memory/freeBlockDictionary.cpp ! src/share/vm/memory/freeBlockDictionary.hpp ! src/share/vm/memory/freeList.cpp ! src/share/vm/memory/freeList.hpp Changeset: ee89f2110312 Author: jmasa Date: 2012-04-25 15:51 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/ee89f2110312 Merge Changeset: 48fac5d60c3c Author: brutisso Date: 2012-04-25 12:36 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/48fac5d60c3c 7163848: G1: Log GC Cause for a GC Reviewed-by: johnc, jwilhelm, jmasa ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp Changeset: bb18e8eecb7e Author: jcoomes Date: 2012-05-04 10:46 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/bb18e8eecb7e Merge - src/share/vm/gc_implementation/concurrentMarkSweep/binaryTreeDictionary.cpp - src/share/vm/gc_implementation/concurrentMarkSweep/binaryTreeDictionary.hpp - src/share/vm/gc_implementation/concurrentMarkSweep/freeBlockDictionary.cpp - src/share/vm/gc_implementation/concurrentMarkSweep/freeBlockDictionary.hpp - src/share/vm/gc_implementation/concurrentMarkSweep/freeList.cpp - src/share/vm/gc_implementation/concurrentMarkSweep/freeList.hpp Changeset: 7d5ec8bf38d1 Author: amurillo Date: 2012-05-04 14:10 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/7d5ec8bf38d1 Merge - src/share/vm/gc_implementation/concurrentMarkSweep/binaryTreeDictionary.cpp - src/share/vm/gc_implementation/concurrentMarkSweep/binaryTreeDictionary.hpp - src/share/vm/gc_implementation/concurrentMarkSweep/freeBlockDictionary.cpp - src/share/vm/gc_implementation/concurrentMarkSweep/freeBlockDictionary.hpp - src/share/vm/gc_implementation/concurrentMarkSweep/freeList.cpp - src/share/vm/gc_implementation/concurrentMarkSweep/freeList.hpp Changeset: 4e6554041847 Author: amurillo Date: 2012-05-04 14:10 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/4e6554041847 Added tag hs24-b09 for changeset 7d5ec8bf38d1 ! .hgtags Changeset: 637c3f5f068f Author: amurillo Date: 2012-05-09 14:06 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/637c3f5f068f Merge ! .hgtags Changeset: 3c394919ca69 Author: katleman Date: 2012-05-10 10:25 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/3c394919ca69 Added tag jdk8-b38 for changeset 637c3f5f068f ! .hgtags Changeset: 36538fd1225e Author: amurillo Date: 2012-05-04 15:26 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/36538fd1225e 7166615: new hotspot build - hs24-b10 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 8bafad97cd26 Author: jiangli Date: 2012-05-02 13:21 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/8bafad97cd26 7158552: The instanceKlsss::_host_klass is only needed for anonymous class for JSR 292 support. Summary: Change the _host_klass to be conditionally created embedded instanceKlass field. Reviewed-by: jrose, coleenp, dholmes ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/memory/oopFactory.cpp ! src/share/vm/memory/oopFactory.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/instanceKlassKlass.cpp ! src/share/vm/oops/instanceKlassKlass.hpp Changeset: 38b4116b6766 Author: jprovino Date: 2012-05-05 10:24 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/38b4116b6766 Merge Changeset: 2766551175a0 Author: kvn Date: 2012-05-09 10:54 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/2766551175a0 Merge ! src/share/vm/oops/instanceKlass.hpp Changeset: a05a695ea044 Author: stefank Date: 2012-05-10 11:27 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/a05a695ea044 7167437: Can't build on linux without precompiled headers Reviewed-by: brutisso, mgerdin ! src/share/vm/memory/space.hpp ! src/share/vm/memory/space.inline.hpp Changeset: f47478089efc Author: brutisso Date: 2012-05-10 14:16 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/f47478089efc 7167069: 6 VM flags crash the VM when queried via jinfo Summary: Added missing double format to Flag::print_as_flag() Reviewed-by: dholmes, stefank, coleenp ! src/share/vm/runtime/globals.cpp + test/runtime/7167069/PrintAsFlag.java Changeset: 5799726c54d7 Author: jcoomes Date: 2012-05-11 06:37 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/5799726c54d7 Merge Changeset: 73147e6c4881 Author: amurillo Date: 2012-05-11 14:47 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/73147e6c4881 Merge Changeset: 96a403721094 Author: amurillo Date: 2012-05-11 14:47 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/96a403721094 Added tag hs24-b10 for changeset 73147e6c4881 ! .hgtags Changeset: 56d1af561395 Author: amurillo Date: 2012-05-11 14:54 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/56d1af561395 7168247: new hotspot build - hs24-b11 Reviewed-by: jcoomes ! make/hotspot_version From roland.westrelin at oracle.com Mon May 14 04:30:42 2012 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Mon, 14 May 2012 13:30:42 +0200 Subject: SIGBUS or SIGSEGV on OSX? Message-ID: <679676EE-E328-4D4C-8830-91E3F1F99013@oracle.com> Hi, We (the compiler team) had a couple of bugs reported on OSX where the crash is caused by a SIGBUS in a compiled method: siginfo:si_signo=SIGBUS: si_errno=0, si_code=2 (BUS_ADRERR), si_addr=0x0000000115d4f018 The 64 bit VM is running in "compressed oops with base" mode. The base is 0x0000000115d4f000. The address of the erroneous memory access is 8 byte aligned and falls in the first page of the heap which is used for implicit null checks. So this access is not expected to trigger a SIGBUS but rather a SIGSEGV and should then be handled by hotspot rather than lead to a crash. I see in JVM_handle_bsd_signal() that there's a number of places where a test for SIGSEGV was replaced by test for a SIGSEGV or a SIGBUS. In particular, I think this: #if defined(__APPLE__) && !defined(AMD64) // 32-bit Darwin reports a SIGBUS for nearly all memory access exceptions. // Catching SIGBUS here prevents the implicit SIGBUS NULL check below from // being called, so only do so if the implicit NULL check is not necessary. } else if (sig == SIGBUS && MacroAssembler::needs_explicit_null_check((int)info->si_addr)) { #else } else if (sig == SIGBUS /* && info->si_code == BUS_OBJERR */) { #endif would fix the problem on 64 bit as well. Should I make this change? Roland. From bob.vandette at oracle.com Mon May 14 05:54:03 2012 From: bob.vandette at oracle.com (Bob Vandette) Date: Mon, 14 May 2012 05:54:03 -0700 (PDT) Subject: SIGBUS or SIGSEGV on OSX? In-Reply-To: <679676EE-E328-4D4C-8830-91E3F1F99013@oracle.com> References: <679676EE-E328-4D4C-8830-91E3F1F99013@oracle.com> Message-ID: <0fc7227b-fb94-484c-80c0-ea5839698642@default> I had to fix the same problem in the signal handler for iOS. I had problems with implicit null checks and safepoint polling exceptions when running our JDK7 Embedded build on iPads and iPhones. Make sure you check all cases of SIGSEGV. Bob. -----Original Message----- From: Roland Westrelin Sent: Monday, May 14, 2012 7:31 AM To: hotspot-runtime-dev at openjdk.java.net; macosx-port-dev at openjdk.java.net Cc: hotspot compiler Subject: SIGBUS or SIGSEGV on OSX? Hi, We (the compiler team) had a couple of bugs reported on OSX where the crash is caused by a SIGBUS in a compiled method: siginfo:si_signo=SIGBUS: si_errno=0, si_code=2 (BUS_ADRERR), si_addr=0x0000000115d4f018 The 64 bit VM is running in "compressed oops with base" mode. The base is 0x0000000115d4f000. The address of the erroneous memory access is 8 byte aligned and falls in the first page of the heap which is used for implicit null checks. So this access is not expected to trigger a SIGBUS but rather a SIGSEGV and should then be handled by hotspot rather than lead to a crash. I see in JVM_handle_bsd_signal() that there's a number of places where a test for SIGSEGV was replaced by test for a SIGSEGV or a SIGBUS. In particular, I think this: #if defined(__APPLE__) && !defined(AMD64) // 32-bit Darwin reports a SIGBUS for nearly all memory access exceptions. // Catching SIGBUS here prevents the implicit SIGBUS NULL check below from // being called, so only do so if the implicit NULL check is not necessary. } else if (sig == SIGBUS && MacroAssembler::needs_explicit_null_check((int)info->si_addr)) { #else } else if (sig == SIGBUS /* && info->si_code == BUS_OBJERR */) { #endif would fix the problem on 64 bit as well. Should I make this change? Roland. From karen.kinnear at oracle.com Mon May 14 06:59:38 2012 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Mon, 14 May 2012 09:59:38 -0400 Subject: SIGBUS or SIGSEGV on OSX? In-Reply-To: <0fc7227b-fb94-484c-80c0-ea5839698642@default> References: <679676EE-E328-4D4C-8830-91E3F1F99013@oracle.com> <0fc7227b-fb94-484c-80c0-ea5839698642@default> Message-ID: <2110EEBC-2818-45CA-8437-4C1D99C87ABA@oracle.com> Roland, Yes please. I also think we are seeing a similar problem on stack overflow handling - so let us know if you are also fixing that or if we want to do a separate additional modification for that case as well. thanks, Karen On May 14, 2012, at 8:54 AM, Bob Vandette wrote: > I had to fix the same problem in the signal handler for iOS. I had > problems with implicit null checks and safepoint polling exceptions > when running our JDK7 Embedded build on iPads and iPhones. > > Make sure you check all cases of SIGSEGV. > > Bob. > > > -----Original Message----- > From: Roland Westrelin > Sent: Monday, May 14, 2012 7:31 AM > To: hotspot-runtime-dev at openjdk.java.net; macosx-port-dev at openjdk.java.net > Cc: hotspot compiler > Subject: SIGBUS or SIGSEGV on OSX? > > Hi, > > We (the compiler team) had a couple of bugs reported on OSX where the crash is caused by a SIGBUS in a compiled method: > > siginfo:si_signo=SIGBUS: si_errno=0, si_code=2 (BUS_ADRERR), si_addr=0x0000000115d4f018 > > The 64 bit VM is running in "compressed oops with base" mode. The base is 0x0000000115d4f000. > The address of the erroneous memory access is 8 byte aligned and falls in the first page of the heap which is used for implicit null checks. So this access is not expected to trigger a SIGBUS but rather a SIGSEGV and should then be handled by hotspot rather than lead to a crash. > > I see in JVM_handle_bsd_signal() that there's a number of places where a test for SIGSEGV was replaced by test for a SIGSEGV or a SIGBUS. In particular, I think this: > > #if defined(__APPLE__) && !defined(AMD64) > // 32-bit Darwin reports a SIGBUS for nearly all memory access exceptions. > // Catching SIGBUS here prevents the implicit SIGBUS NULL check below from > // being called, so only do so if the implicit NULL check is not necessary. > } else if (sig == SIGBUS && MacroAssembler::needs_explicit_null_check((int)info->si_addr)) { #else > } else if (sig == SIGBUS /* && info->si_code == BUS_OBJERR */) { #endif > > would fix the problem on 64 bit as well. > > Should I make this change? > > Roland. From roland.westrelin at oracle.com Mon May 14 09:03:06 2012 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Mon, 14 May 2012 18:03:06 +0200 Subject: SIGBUS or SIGSEGV on OSX? In-Reply-To: <2110EEBC-2818-45CA-8437-4C1D99C87ABA@oracle.com> References: <679676EE-E328-4D4C-8830-91E3F1F99013@oracle.com> <0fc7227b-fb94-484c-80c0-ea5839698642@default> <2110EEBC-2818-45CA-8437-4C1D99C87ABA@oracle.com> Message-ID: Hi Karen, > Yes please. I also think we are seeing a similar problem on stack overflow handling - so let us know if > you are also fixing that or if we want to do a separate additional modification for that case as well. Sure, I can make the other fix as well but I don't see where there is something missing for stack overflow handling. Roland. From vladimir.kozlov at oracle.com Mon May 14 09:09:45 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 14 May 2012 09:09:45 -0700 Subject: SIGBUS or SIGSEGV on OSX? In-Reply-To: <679676EE-E328-4D4C-8830-91E3F1F99013@oracle.com> References: <679676EE-E328-4D4C-8830-91E3F1F99013@oracle.com> Message-ID: <4FB12E49.7070005@oracle.com> So we have it in BSD port but not in OSX? That would explain it, I did review of BSD port and thought that OSX will use the same code. Thank you, Roland, for finding it. Vladimir Roland Westrelin wrote: > Hi, > > We (the compiler team) had a couple of bugs reported on OSX where the crash is caused by a SIGBUS in a compiled method: > > siginfo:si_signo=SIGBUS: si_errno=0, si_code=2 (BUS_ADRERR), si_addr=0x0000000115d4f018 > > The 64 bit VM is running in "compressed oops with base" mode. The base is 0x0000000115d4f000. > The address of the erroneous memory access is 8 byte aligned and falls in the first page of the heap which is used for implicit null checks. So this access is not expected to trigger a SIGBUS but rather a SIGSEGV and should then be handled by hotspot rather than lead to a crash. > > I see in JVM_handle_bsd_signal() that there's a number of places where a test for SIGSEGV was replaced by test for a SIGSEGV or a SIGBUS. In particular, I think this: > > #if defined(__APPLE__) && !defined(AMD64) > // 32-bit Darwin reports a SIGBUS for nearly all memory access exceptions. > // Catching SIGBUS here prevents the implicit SIGBUS NULL check below from > // being called, so only do so if the implicit NULL check is not necessary. > } else if (sig == SIGBUS && MacroAssembler::needs_explicit_null_check((int)info->si_addr)) { > #else > } else if (sig == SIGBUS /* && info->si_code == BUS_OBJERR */) { > #endif > > would fix the problem on 64 bit as well. > > Should I make this change? > > Roland. From roland.westrelin at oracle.com Mon May 14 09:24:05 2012 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Mon, 14 May 2012 18:24:05 +0200 Subject: SIGBUS or SIGSEGV on OSX? In-Reply-To: <4FB12E49.7070005@oracle.com> References: <679676EE-E328-4D4C-8830-91E3F1F99013@oracle.com> <4FB12E49.7070005@oracle.com> Message-ID: > So we have it in BSD port but not in OSX? That would explain it, I did review of > BSD port and thought that OSX will use the same code. Not exactly: we have it for OSX and not BSD but only on 32 bit. Roland. From vladimir.kozlov at oracle.com Mon May 14 15:37:36 2012 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Mon, 14 May 2012 22:37:36 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 6924259: Remove String.count/String.offset Message-ID: <20120514223740.34BC247300@hg.openjdk.java.net> Changeset: 8f972594effc Author: kvn Date: 2012-05-14 09:36 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/8f972594effc 6924259: Remove String.count/String.offset Summary: Allow a version of String class that doesn't have count and offset fields. Reviewed-by: never, coleenp ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/memory/dump.cpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/graphKit.hpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/stringopts.cpp ! src/share/vm/opto/stringopts.hpp From roland.westrelin at oracle.com Tue May 15 04:26:56 2012 From: roland.westrelin at oracle.com (roland.westrelin at oracle.com) Date: Tue, 15 May 2012 11:26:56 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7133857: exp() and pow() should use the x87 ISA on x86 Message-ID: <20120515112700.47A4D47318@hg.openjdk.java.net> Changeset: 6759698e3140 Author: roland Date: 2012-05-15 10:10 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/6759698e3140 7133857: exp() and pow() should use the x87 ISA on x86 Summary: use x87 instructions to implement exp() and pow() in interpreter/c1/c2. Reviewed-by: kvn, never, twisti ! src/cpu/sparc/vm/c1_LIRGenerator_sparc.cpp ! src/cpu/sparc/vm/interpreter_sparc.cpp ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/cpu/x86/vm/c1_LIRGenerator_x86.cpp ! src/cpu/x86/vm/c1_LinearScan_x86.cpp ! src/cpu/x86/vm/interpreter_x86_32.cpp ! src/cpu/x86/vm/interpreter_x86_64.cpp ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_LIR.cpp ! src/share/vm/c1/c1_LIR.hpp ! src/share/vm/c1/c1_LIRAssembler.cpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/c1/c1_LinearScan.cpp ! src/share/vm/interpreter/abstractInterpreter.hpp ! src/share/vm/interpreter/interpreter.cpp ! src/share/vm/interpreter/templateInterpreter.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/subnode.cpp From roland.westrelin at oracle.com Tue May 15 05:38:33 2012 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Tue, 15 May 2012 14:38:33 +0200 Subject: RFR (S): 7167254: Crash on OSX in Enumerator.nextElement() with compressed oops Message-ID: http://cr.openjdk.java.net/~roland/7167254/webrev.00/ Crashes were reported for 64 bit VMs on OSX running in "compressed oops with base" mode. The crash is caused by a SIGBUS on a correctly aligned access to the first page of the heap which is used for implicit null checks. With this change hotspot on OSX expects either a SIGBUS or SIGSEGV for implicit null checks. Roland. From Dmitry.Samersoff at oracle.com Tue May 15 06:13:39 2012 From: Dmitry.Samersoff at oracle.com (Dmitry Samersoff) Date: Tue, 15 May 2012 17:13:39 +0400 Subject: RFR (S): 7167254: Crash on OSX in Enumerator.nextElement() with compressed oops In-Reply-To: References: Message-ID: <4FB25683.7050104@oracle.com> Roland, Could you fix comments as well? Otherwise looks good for me. -Dmitry On 2012-05-15 16:38, Roland Westrelin wrote: > http://cr.openjdk.java.net/~roland/7167254/webrev.00/ > > Crashes were reported for 64 bit VMs on OSX running in "compressed oops with base" mode. The crash is caused by a SIGBUS on a correctly aligned access to the first page of the heap which is used for implicit null checks. With this change hotspot on OSX expects either a SIGBUS or SIGSEGV for implicit null checks. > > Roland. -- Dmitry Samersoff Java Hotspot development team, SPB04 * There will come soft rains ... From rickard.backman at oracle.com Tue May 15 06:15:10 2012 From: rickard.backman at oracle.com (=?ISO-8859-1?Q?Rickard_B=E4ckman?=) Date: Tue, 15 May 2012 15:15:10 +0200 Subject: RFR (S): 7167254: Crash on OSX in Enumerator.nextElement() with compressed oops In-Reply-To: References: Message-ID: <4FB256DE.6030402@oracle.com> Roland, the change looks good. /R On 05/15/2012 02:38 PM, Roland Westrelin wrote: > http://cr.openjdk.java.net/~roland/7167254/webrev.00/ > > Crashes were reported for 64 bit VMs on OSX running in "compressed oops with base" mode. The crash is caused by a SIGBUS on a correctly aligned access to the first page of the heap which is used for implicit null checks. With this change hotspot on OSX expects either a SIGBUS or SIGSEGV for implicit null checks. > > Roland. From roland.westrelin at oracle.com Tue May 15 06:22:43 2012 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Tue, 15 May 2012 15:22:43 +0200 Subject: RFR (S): 7167254: Crash on OSX in Enumerator.nextElement() with compressed oops In-Reply-To: <4FB25683.7050104@oracle.com> References: <4FB25683.7050104@oracle.com> Message-ID: <2EC32919-52F5-43AE-8742-67FEA777FEB6@oracle.com> Hi Dmitry > Could you fix comments as well? Otherwise looks good for me. You're right. Here it is again with a comment: http://cr.openjdk.java.net/~roland/7167254/webrev.01 Roland. From Dmitry.Samersoff at oracle.com Tue May 15 06:34:56 2012 From: Dmitry.Samersoff at oracle.com (Dmitry Samersoff) Date: Tue, 15 May 2012 17:34:56 +0400 Subject: RFR (S): 7167254: Crash on OSX in Enumerator.nextElement() with compressed oops In-Reply-To: <2EC32919-52F5-43AE-8742-67FEA777FEB6@oracle.com> References: <4FB25683.7050104@oracle.com> <2EC32919-52F5-43AE-8742-67FEA777FEB6@oracle.com> Message-ID: <4FB25B80.1050205@oracle.com> Looks good for me. On 2012-05-15 17:22, Roland Westrelin wrote: > Hi Dmitry > >> Could you fix comments as well? Otherwise looks good for me. > > You're right. Here it is again with a comment: > > http://cr.openjdk.java.net/~roland/7167254/webrev.01 > > Roland. -- Dmitry Samersoff Java Hotspot development team, SPB04 * There will come soft rains ... From daniel.daugherty at oracle.com Tue May 15 06:48:47 2012 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 15 May 2012 07:48:47 -0600 Subject: RFR (S): 7167254: Crash on OSX in Enumerator.nextElement() with compressed oops In-Reply-To: <2EC32919-52F5-43AE-8742-67FEA777FEB6@oracle.com> References: <4FB25683.7050104@oracle.com> <2EC32919-52F5-43AE-8742-67FEA777FEB6@oracle.com> Message-ID: <4FB25EBF.4020501@oracle.com> On 5/15/12 7:22 AM, Roland Westrelin wrote: > Hi Dmitry > >> Could you fix comments as well? Otherwise looks good for me. > You're right. Here it is again with a comment: > > http://cr.openjdk.java.net/~roland/7167254/webrev.01 > > Roland. Thumbs up. src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp No comments Dan From vladimir.kozlov at oracle.com Tue May 15 08:44:41 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 15 May 2012 08:44:41 -0700 Subject: RFR (S): 7167254: Crash on OSX in Enumerator.nextElement() with compressed oops In-Reply-To: References: Message-ID: <4FB279E9.5040408@oracle.com> Looks good. So other places where we check SIGSEG/SIGBUS signal are fine? Thanks, Vladimir On 5/15/12 5:38 AM, Roland Westrelin wrote: > http://cr.openjdk.java.net/~roland/7167254/webrev.00/ > > Crashes were reported for 64 bit VMs on OSX running in "compressed oops with base" mode. The crash is caused by a SIGBUS on a correctly aligned access to the first page of the heap which is used for implicit null checks. With this change hotspot on OSX expects either a SIGBUS or SIGSEGV for implicit null checks. > > Roland. From roland.westrelin at oracle.com Tue May 15 08:44:55 2012 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Tue, 15 May 2012 17:44:55 +0200 Subject: RFR (S): 7167254: Crash on OSX in Enumerator.nextElement() with compressed oops In-Reply-To: <4FB279E9.5040408@oracle.com> References: <4FB279E9.5040408@oracle.com> Message-ID: > Looks good. So other places where we check SIGSEG/SIGBUS signal are fine? Other places where SIGSEGV is tested for in this method already has a test for SIGBUS. Roland. From vladimir.kozlov at oracle.com Tue May 15 08:49:08 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 15 May 2012 08:49:08 -0700 Subject: RFR (S): 7167254: Crash on OSX in Enumerator.nextElement() with compressed oops In-Reply-To: References: <4FB279E9.5040408@oracle.com> Message-ID: <4FB27AF4.8000401@oracle.com> On 5/15/12 8:44 AM, Roland Westrelin wrote: >> Looks good. So other places where we check SIGSEG/SIGBUS signal are fine? > > Other places where SIGSEGV is tested for in this method already has a test for SIGBUS. Good. Vladimir > > Roland. From roland.westrelin at oracle.com Tue May 15 09:10:06 2012 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Tue, 15 May 2012 18:10:06 +0200 Subject: RFR (M): 7023898: Intrinsify AtomicLongFieldUpdater.getAndIncrement() Message-ID: <13AE9B3D-2AB6-4F42-9820-C2DEE87B86D4@oracle.com> http://cr.openjdk.java.net/~roland/7023898/ This change provides intrinsics when optimized instruction sequences for the new Unsafe methods below exist (the change to the libraries will get in as a separate piece of work). Roland. /** * Atomically update Java variable by delta returning * the previous value. * @return the previous value */ public int getAndAddInt(Object o, long offset, int delta) { for (;;) { int current = getInt(obj, offset); int next = current + delta; if (compareAndSwapInt(obj, offset, current, next)) { return current; } } } /** * Atomically update Java variable by delta returning * the previous value. * @return the previous value */ public long getAndAddLong(Object o, long offset, long delta) { for (;;) { long current = getLongVolatile(obj, offset); long next = current + delta; if (compareAndSwapLong(obj, offset, current, next)) { return current; } } } /** * Atomically sets the field of the given object at the given offset * to the given value and returns the old value. * * @param obj An object whose field to get and set * @param newValue the new value * @return the previous value */ int getAndSet(Object o, long offset, int newValue) { for (;;) { int current = getInt(obj, offset); if (compareAndSwapInt(obj, offset, current, newValue)) { return current; } } } /** * Atomically sets the field of the given object at the given offset * to the given value and returns the old value. * * @param obj An object whose field to get and set * @param newValue the new value * @return the previous value */ long getAndSet(Object o, long offset, long newValue) { for (;;) { long current = getLongVolatile(obj, offset); if (compareAndSwapLong(obj, offset, current, newValue)) { return current; } } } /** * Atomically sets the field of the given object at the given offset * to the given value and returns the old value. * * @param obj An object whose field to get and set * @param newValue the new value * @return the previous value */ Object getAndSet(Object o, long offset, Object newValue) { for (;;) { Object current = getObject(obj, offset); if (compareAndSwapObject(obj, offset, current, newValue)) { return current; } } } From karen.kinnear at oracle.com Tue May 15 10:52:54 2012 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Tue, 15 May 2012 13:52:54 -0400 Subject: RFR (S): 7167254: Crash on OSX in Enumerator.nextElement() with compressed oops In-Reply-To: References: Message-ID: Roland, Does this fix either of the following SIGBUS on Mac bugs? 7129715 (this is the one where it also lists "An irrecoverable stack overflow has occurred, which is where my other question came from - is there a place where we look for SIGSEGV for stack overflow and also need to look for SIGBUS" - I didn't track the code path yet) Test name: gc/gctests/JumbleGC002 ( see the jira link) 7129716 (probably just a duplicate of the one you just fixed) Hotspot regression tests compiler/6865031/Test.java fails on MacOS if run with -Xcomp: Any chance you could run these tests with your new fix? thanks very much, Karen On May 15, 2012, at 8:38 AM, Roland Westrelin wrote: > http://cr.openjdk.java.net/~roland/7167254/webrev.00/ > > Crashes were reported for 64 bit VMs on OSX running in "compressed oops with base" mode. The crash is caused by a SIGBUS on a correctly aligned access to the first page of the heap which is used for implicit null checks. With this change hotspot on OSX expects either a SIGBUS or SIGSEGV for implicit null checks. > > Roland. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20120515/de3b2655/attachment.html From vladimir.kozlov at oracle.com Tue May 15 11:23:32 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 15 May 2012 11:23:32 -0700 Subject: RFR (M): 7023898: Intrinsify AtomicLongFieldUpdater.getAndIncrement() In-Reply-To: <13AE9B3D-2AB6-4F42-9820-C2DEE87B86D4@oracle.com> References: <13AE9B3D-2AB6-4F42-9820-C2DEE87B86D4@oracle.com> Message-ID: <4FB29F24.5010204@oracle.com> In c1_LIRAssembler_sparc.cpp move assert(code == lir_xchg) to the beginning of method since on sparc we have only swap for all types and change "xadd for oops" --> "no xadd on sparc". In c1_LIR.cpp fix comment: + // destroy inputs. On the other platform that implements those + // (x86, sparc), the extra constrainsts are armless. ---- + // destroy inputs. On other platforms that implement those + // (x86, sparc), the extra constraints are harmless. In escape.cpp move add_obload_* call up with cases for GetAndSet and then fallthrough: + case Op_GetAndSetP: + case Op_GetAndSetN: { + add_objload_to_connection_graph(n, delayed_worklist); + // fallthrough + } case Op_StoreP: case Op_StoreN: case Op_StorePConditional: case Op_CompareAndSwapP: case Op_CompareAndSwapN: { The rest looks good. Vladimir On 5/15/12 9:10 AM, Roland Westrelin wrote: > http://cr.openjdk.java.net/~roland/7023898/ > > This change provides intrinsics when optimized instruction sequences for the new Unsafe methods below exist (the change to the libraries will get in as a separate piece of work). > > Roland. > > /** > * Atomically update Java variable bydelta returning > * the previous value. > * @return the previous value > */ > public int getAndAddInt(Object o, long offset, int delta) { > for (;;) { > int current = getInt(obj, offset); > int next = current + delta; > if (compareAndSwapInt(obj, offset, current, next)) { > return current; > } > } > } > > /** > * Atomically update Java variable bydelta returning > * the previous value. > * @return the previous value > */ > public long getAndAddLong(Object o, long offset, long delta) { > for (;;) { > long current = getLongVolatile(obj, offset); > long next = current + delta; > if (compareAndSwapLong(obj, offset, current, next)) { > return current; > } > } > } > > /** > * Atomically sets the field of the given object at the given offset > * to the given value and returns the old value. > * > * @param obj An object whose field to get and set > * @param newValue the new value > * @return the previous value > */ > int getAndSet(Object o, long offset, int newValue) { > for (;;) { > int current = getInt(obj, offset); > if (compareAndSwapInt(obj, offset, current, newValue)) { > return current; > } > } > } > /** > * Atomically sets the field of the given object at the given offset > * to the given value and returns the old value. > * > * @param obj An object whose field to get and set > * @param newValue the new value > * @return the previous value > */ > long getAndSet(Object o, long offset, long newValue) { > for (;;) { > long current = getLongVolatile(obj, offset); > if (compareAndSwapLong(obj, offset, current, newValue)) { > return current; > } > } > } > /** > * Atomically sets the field of the given object at the given offset > * to the given value and returns the old value. > * > * @param obj An object whose field to get and set > * @param newValue the new value > * @return the previous value > */ > Object getAndSet(Object o, long offset, Object newValue) { > for (;;) { > Object current = getObject(obj, offset); > if (compareAndSwapObject(obj, offset, current, newValue)) { > return current; > } > } > } From roland.westrelin at oracle.com Tue May 15 11:40:49 2012 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Tue, 15 May 2012 20:40:49 +0200 Subject: RFR (S): 7167254: Crash on OSX in Enumerator.nextElement() with compressed oops In-Reply-To: References: Message-ID: <32B96BC8-7170-462D-8C63-4AC874E6C716@oracle.com> Hi Karen, > Any chance you could run these tests with your new fix? Sure. I'll see if they still reproduce. Roland. From david.holmes at oracle.com Tue May 15 20:22:38 2012 From: david.holmes at oracle.com (David Holmes) Date: Wed, 16 May 2012 13:22:38 +1000 Subject: RFR (S): 7167254: Crash on OSX in Enumerator.nextElement() with compressed oops In-Reply-To: References: <4FB279E9.5040408@oracle.com> Message-ID: <4FB31D7E.6050108@oracle.com> On 16/05/2012 1:44 AM, Roland Westrelin wrote: >> Looks good. So other places where we check SIGSEG/SIGBUS signal are fine? > > Other places where SIGSEGV is tested for in this method already has a test for SIGBUS. Is there any possibility we will mistake a real SIGBUS for a NullPointerException ? David > Roland. From rednaxelafx at gmail.com Wed May 16 06:02:02 2012 From: rednaxelafx at gmail.com (Krystal Mok) Date: Wed, 16 May 2012 21:02:02 +0800 Subject: Request for review (XS): crash in C2 when using -XX:+CountCompiledCalls Message-ID: Hi all, Could I get some reviews for this patch, please? https://gist.github.com/2710000#file_count_compiled_calls.patch Description: C2 may crash when compiling methods with -XX:+CountCompiledCalls turned on. The cause is in Parse::count_compiled_calls(), where it made a TypeInstPtr from a ciMethod: const TypeInstPtr* addr_type = TypeInstPtr::make(method()); Since the klass of a ciMethod is a ciMethodKlass, which isn't a ciInstanceKlass, an assertion is hit later in Compile::flatten_alias_type(), where it's expecting a TypeInstPtr to have a ciInstanceKlass: ciInstanceKlass *k = to->klass()->as_instance_klass(); An example of the crash is available here: https://gist.github.com/2710000 In the example, I started a Groovy shell with -XX:+CountCompiledCalls set, and it crashed quickly when compiling java.lang.String.charAt(). The fix is to use TypeOopPtr::make_from_constant(method()) instead of TypeInstPtr::make(method()). I did check the hg history, and looks like it's been like this since duke at 0.Wonder if there's any history behind this. Note that this fix may have to be changed again when methodOopDesc's are moved out of PermGen. Regards, Kris -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20120516/f74f7b84/attachment.html From roland.westrelin at oracle.com Wed May 16 06:49:02 2012 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Wed, 16 May 2012 15:49:02 +0200 Subject: RFR (S): 7167254: Crash on OSX in Enumerator.nextElement() with compressed oops In-Reply-To: References: Message-ID: Hi Karen, > Does this fix either of the following SIGBUS on Mac bugs? > > 7129715 (this is the one where it also lists "An irrecoverable stack overflow has occurred, > which is where my other question came from - is there a place where we look for > SIGSEGV for stack overflow and also need to look for SIGBUS" - I didn't track the code > path yet) > Test name: gc/gctests/JumbleGC002 ( see the jira link) This one still reproduces with my change. > 7129716 (probably just a duplicate of the one you just fixed) >Hotspot regression tests compiler/6865031/Test.java > fails on MacOS if run with -Xcomp: This one is a duplicate of my bug. I closed it. Roland. From roland.westrelin at oracle.com Wed May 16 07:21:12 2012 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Wed, 16 May 2012 16:21:12 +0200 Subject: RFR (S): 7167254: Crash on OSX in Enumerator.nextElement() with compressed oops In-Reply-To: <4FB31D7E.6050108@oracle.com> References: <4FB279E9.5040408@oracle.com> <4FB31D7E.6050108@oracle.com> Message-ID: > Is there any possibility we will mistake a real SIGBUS for a > NullPointerException ? A SIGBUS caused by a bug in generated code for instance? Yes, there is a risk, the same way there is a risk a SIGSEGV becomes a NPE. A SIGBUS that should be caught by the VM rather than be converted to a NPE. It doesn't look possible to me. Roland. From roland.westrelin at oracle.com Wed May 16 07:25:30 2012 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Wed, 16 May 2012 16:25:30 +0200 Subject: RFR (S): 7167254: Crash on OSX in Enumerator.nextElement() with compressed oops In-Reply-To: References: Message-ID: One more webrev: http://cr.openjdk.java.net/~roland/7167254/webrev.02/ I forgot to cast the MacroAssembler::needs_explicit_null_check() argument to intptr_t rather than int. Roland. From roland.westrelin at oracle.com Wed May 16 07:32:20 2012 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Wed, 16 May 2012 16:32:20 +0200 Subject: RFR (M): 7023898: Intrinsify AtomicLongFieldUpdater.getAndIncrement() In-Reply-To: <4FB29F24.5010204@oracle.com> References: <13AE9B3D-2AB6-4F42-9820-C2DEE87B86D4@oracle.com> <4FB29F24.5010204@oracle.com> Message-ID: > In c1_LIRAssembler_sparc.cpp move assert(code == lir_xchg) to the beginning of method since on sparc we have only swap > for all types and change "xadd for oops" --> "no xadd on sparc". > > In c1_LIR.cpp fix comment: > > + // destroy inputs. On the other platform that implements those > + // (x86, sparc), the extra constrainsts are armless. > ---- > + // destroy inputs. On other platforms that implement those > + // (x86, sparc), the extra constraints are harmless. > > In escape.cpp move add_obload_* call up with cases for GetAndSet and then fallthrough: > > + case Op_GetAndSetP: > + case Op_GetAndSetN: { > + add_objload_to_connection_graph(n, delayed_worklist); > + // fallthrough > + } > case Op_StoreP: > case Op_StoreN: > case Op_StorePConditional: > case Op_CompareAndSwapP: > case Op_CompareAndSwapN: { > > The rest looks good. Ok. Thanks for the review. Roland. From vladimir.kozlov at oracle.com Wed May 16 08:44:24 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 16 May 2012 08:44:24 -0700 Subject: RFR (S): 7167254: Crash on OSX in Enumerator.nextElement() with compressed oops In-Reply-To: References: Message-ID: <4FB3CB58.7020302@oracle.com> Good. Vladimir On 5/16/12 7:25 AM, Roland Westrelin wrote: > One more webrev: > http://cr.openjdk.java.net/~roland/7167254/webrev.02/ > > I forgot to cast the MacroAssembler::needs_explicit_null_check() argument to intptr_t rather than int. > > Roland. From vladimir.kozlov at oracle.com Wed May 16 09:12:53 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 16 May 2012 09:12:53 -0700 Subject: Request for review (XS): crash in C2 when using -XX:+CountCompiledCalls In-Reply-To: References: Message-ID: <4FB3D205.2020505@oracle.com> Kris, Changes looks good. I will push it tomorrow. Thanks, Vladimir On 5/16/12 6:02 AM, Krystal Mok wrote: > Hi all, > > Could I get some reviews for this patch, please? > https://gist.github.com/2710000#file_count_compiled_calls.patch > > Description: > > C2 may crash when compiling methods with -XX:+CountCompiledCalls turned on. The cause is > in Parse::count_compiled_calls(), where it made a TypeInstPtr from a ciMethod: > > const TypeInstPtr* addr_type = TypeInstPtr::make(method()); > > Since the klass of a ciMethod is a ciMethodKlass, which isn't a ciInstanceKlass, an assertion is hit later in > Compile::flatten_alias_type(), where it's expecting a TypeInstPtr to have a ciInstanceKlass: > > ciInstanceKlass *k = to->klass()->as_instance_klass(); > > An example of the crash is available here: https://gist.github.com/2710000 > In the example, I started a Groovy shell with -XX:+CountCompiledCalls set, and it crashed quickly when compiling > java.lang.String.charAt(). > > The fix is to use TypeOopPtr::make_from_constant(method()) instead of TypeInstPtr::make(method()). > I did check the hg history, and looks like it's been like this since duke at 0. Wonder if there's any history behind this. > > Note that this fix may have to be changed again when methodOopDesc's are moved out of PermGen. > > Regards, > Kris From rednaxelafx at gmail.com Wed May 16 09:13:41 2012 From: rednaxelafx at gmail.com (Krystal Mok) Date: Thu, 17 May 2012 00:13:41 +0800 Subject: Request for review (XS): crash in C2 when using -XX:+CountCompiledCalls In-Reply-To: <4FB3D205.2020505@oracle.com> References: <4FB3D205.2020505@oracle.com> Message-ID: Thank you, Vladimir :-) - Kris On Thu, May 17, 2012 at 12:12 AM, Vladimir Kozlov < vladimir.kozlov at oracle.com> wrote: > Kris, > > Changes looks good. I will push it tomorrow. > > Thanks, > Vladimir > > > On 5/16/12 6:02 AM, Krystal Mok wrote: > >> Hi all, >> >> Could I get some reviews for this patch, please? >> https://gist.github.com/**2710000#file_count_compiled_**calls.patch >> >> Description: >> >> C2 may crash when compiling methods with -XX:+CountCompiledCalls turned >> on. The cause is >> in Parse::count_compiled_calls(), where it made a TypeInstPtr from a >> ciMethod: >> >> const TypeInstPtr* addr_type = TypeInstPtr::make(method()); >> >> Since the klass of a ciMethod is a ciMethodKlass, which isn't a >> ciInstanceKlass, an assertion is hit later in >> Compile::flatten_alias_type(), where it's expecting a TypeInstPtr to have >> a ciInstanceKlass: >> >> ciInstanceKlass *k = to->klass()->as_instance_**klass(); >> >> An example of the crash is available here: https://gist.github.com/** >> 2710000 >> In the example, I started a Groovy shell with -XX:+CountCompiledCalls >> set, and it crashed quickly when compiling >> java.lang.String.charAt(). >> >> The fix is to use TypeOopPtr::make_from_**constant(method()) instead of >> TypeInstPtr::make(method()). >> I did check the hg history, and looks like it's been like this since >> duke at 0. Wonder if there's any history behind this. >> >> Note that this fix may have to be changed again when methodOopDesc's are >> moved out of PermGen. >> >> Regards, >> Kris >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20120517/a819278e/attachment-0001.html From karen.kinnear at oracle.com Wed May 16 11:42:18 2012 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Wed, 16 May 2012 14:42:18 -0400 Subject: RFR (S): 7167254: Crash on OSX in Enumerator.nextElement() with compressed oops In-Reply-To: References: Message-ID: Roland, Many thanks for testing and closing 7129716. I did look at the code path for stack overflow and there is no obvious place where we look for SEGV and also need to look for SIGBUS. We will follow up on 7129715. many thanks, Karen On May 16, 2012, at 9:49 AM, Roland Westrelin wrote: > Hi Karen, > >> Does this fix either of the following SIGBUS on Mac bugs? >> >> 7129715 (this is the one where it also lists "An irrecoverable stack overflow has occurred, >> which is where my other question came from - is there a place where we look for >> SIGSEGV for stack overflow and also need to look for SIGBUS" - I didn't track the code >> path yet) >> Test name: gc/gctests/JumbleGC002 ( see the jira link) > > This one still reproduces with my change. > >> 7129716 (probably just a duplicate of the one you just fixed) >> Hotspot regression tests compiler/6865031/Test.java >> fails on MacOS if run with -Xcomp: > > This one is a duplicate of my bug. I closed it. > > Roland. From vitalyd at gmail.com Wed May 16 12:12:25 2012 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Wed, 16 May 2012 15:12:25 -0400 Subject: [concurrency-interest] a volatile bug? In-Reply-To: References: Message-ID: It can be a compiler (mis)optimization that causes this, and not x86 memory ordering. Someone posted the assembly output in the comments on SO and it does seem like there's a place that loads 'b' from the stack rather than memory. Hans' theory of CSE sounds plausible - can someone repro this without that "int tt = b;" line? Adding hotspot compiler guys in case they want to chime in. Sent from my phone On May 16, 2012 3:07 PM, "Aleksey Shipilev" wrote: > On Wed, May 16, 2012 at 10:40 PM, Boehm, Hans wrote: > > A JDK bug AND a serious test suite omission? > > Stress tests would probably JIT-compile the code in question. See below. > > > But is the problem real? Can it be reproduced on a mainstream JVM? > > Same question. > > > Note that the example in the original posting also read b before the > loop, > > so na?ve common subexpression elimination would cause the bug. Hopefully > > nobody does CSE in cases like this. > > FWIW, the test case in SO would probably not hit any compilation > threshold in HotSpot, so it could be executed in interpreter. Then, > assuming the interpreter does not reorder Java code, and assuming > original SO poster runs Windows, and hence x86, and hence has TSO, > this bug seems very unlikely. I would be surprised if it actually > *can* be reproduced. That makes the whole story rather interesting. > > -Aleksey. > > _______________________________________________ > Concurrency-interest mailing list > Concurrency-interest at cs.oswego.edu > http://cs.oswego.edu/mailman/listinfo/concurrency-interest > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20120516/251fcb51/attachment.html From vitalyd at gmail.com Wed May 16 13:34:17 2012 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Wed, 16 May 2012 16:34:17 -0400 Subject: [concurrency-interest] a volatile bug? In-Reply-To: References: Message-ID: I looked at the assembly on SO again (the pastebin link) and it seems to be correct actually: after 'a' is cmp'ed against zero, 'b' is read from memory. But now someone is saying there that it sometimes generates the correct assembly and other times not - very strange. 0x025bd2b9: cmp $0x0,%edx 30. 0x025bd2bc: je 0x025bd2a8 ; 32. 0x025bd2be: mov $0x147062e8,%edx ; {oop('test/TestVolatile')} 33. 0x025bd2c3: mov 0x1c4(%edx),%edx ;*getstatic b 34. ; - test.TestVolatile::run at 10 (line 17) 35. 0x025bd2c9: cmp $0x0,%edx Sent from my phone On May 16, 2012 3:55 PM, "Aleksey Shipilev" wrote: > Update. GVN is clearly under suspicion -XX:-UseGlobalValueNumbering > mitigates the bug in my setup. Digging through C1 codebase to see > rules for volatiles. > > -Aleksey. > > On Wed, May 16, 2012 at 11:23 PM, Aleksey Shipilev > wrote: > > All right, here's what is on the table. > > > > This bug is reproduced for me on Linux i686 with: > > java version "1.7.0_04" > > Java(TM) SE Runtime Environment (build 1.7.0_04-b20) > > Java HotSpot(TM) Client VM (build 23.0-b21, mixed mode) > > > > It reproduces immediately only with -client. > > Both -server and -Xint do NOT reproduce the bug. > > The code is there in original SO post > > > http://stackoverflow.com/questions/10620680/why-volatile-in-java-5-doesnt-synchronize-cached-copies-of-variables-with-main > > > > C1 seems to miscompile run(), and indeed does CSE for local: > > > > # {method} 'run' '()V' in 'Test$1' > > [Verified Entry Point] > > 0xb4a91e80: mov %eax,-0x4000(%esp) > > 0xb4a91e87: push %ebp > > 0xb4a91e88: sub $0x18,%esp ;*invokestatic access$000 > > ; - Test$1::run at 0 (line 11) > > 0xb4a91e8b: mov $0xa09c4270,%edx ; {oop(a 'java/lang/Class' = > 'Test')} > >>>>>>> 0xb4a91e90: mov 0x74(%edx),%edx ;*getstatic b <<<<<---- > loads $b to %edx > > ; - Test::access$000 at 0 (line 1) > > ; - Test$1::run at 0 (line 11) > > 0xb4a91e93: jmp 0xb4a91e9e ; OopMap{off=40} > > ;*goto > > ; - Test$1::run at 10 (line 13) > > 0xb4a91e98: test %eax,0xb77a9100 ;*goto > > ; - Test$1::run at 10 (line 13) > > ; {poll} > > 0xb4a91e9e: mov $0xa09c4270,%ecx ; {oop(a 'java/lang/Class' = > 'Test')} > >>>>>> 0xb4a91ea3: mov 0x70(%ecx),%ecx ;*getstatic a <<<<< > volatile read for $a > > ; - Test::access$100 at 0 (line 1) > > ; - Test$1::run at 4 (line 13) > > 0xb4a91ea6: cmp $0x0,%ecx // <---- $a is at %ecx > > 0xb4a91ea9: je 0xb4a91e98 ;*ifne > > ; - Test$1::run at 7 (line 13) > > >>>> 0xb4a91eab: cmp $0x0,%edx // <<<<<<---- $b is cached in > %edx here > > 0xb4a91eae: jne 0xb4a91ed8 ;*ifne > > ; - Test$1::run at 16 (line 17) > > 0xb4a91eb4: nopl 0x0(%eax) > > 0xb4a91eb8: jmp 0xb4a91f0e ; {no_reloc} > > 0xb4a91ebd: xchg %ax,%ax > > 0xb4a91ec0: jmp 0xb4a91f28 ; implicit exception: > > dispatches to 0xb4a91f18 > > 0xb4a91ec5: nop ;*getstatic out > > ; - Test$1::run at 19 (line 18) > > 0xb4a91ec6: cmp (%ecx),%eax ; implicit exception: > > dispatches to 0xb4a91f32 > > 0xb4a91ec8: mov $0xa09c6488,%edx ;*invokevirtual println > > ; - Test$1::run at 24 (line 18) > > ; {oop("error")} > > > > > > Thanks, > > Aleksey. > > > > On Wed, May 16, 2012 at 11:12 PM, Vitaly Davidovich > wrote: > >> It can be a compiler (mis)optimization that causes this, and not x86 > memory > >> ordering. > >> > >> Someone posted the assembly output in the comments on SO and it does > seem > >> like there's a place that loads 'b' from the stack rather than memory. > >> Hans' theory of CSE sounds plausible - can someone repro this without > that > >> "int tt = b;" line? > >> > >> Adding hotspot compiler guys in case they want to chime in. > >> > >> Sent from my phone > >> > >> On May 16, 2012 3:07 PM, "Aleksey Shipilev" > > >> wrote: > >>> > >>> On Wed, May 16, 2012 at 10:40 PM, Boehm, Hans > wrote: > >>> > A JDK bug AND a serious test suite omission? > >>> > >>> Stress tests would probably JIT-compile the code in question. See > below. > >>> > >>> > But is the problem real? Can it be reproduced on a mainstream JVM? > >>> > >>> Same question. > >>> > >>> > Note that the example in the original posting also read b before the > >>> > loop, > >>> > so na?ve common subexpression elimination would cause the bug. > >>> > Hopefully > >>> > nobody does CSE in cases like this. > >>> > >>> FWIW, the test case in SO would probably not hit any compilation > >>> threshold in HotSpot, so it could be executed in interpreter. Then, > >>> assuming the interpreter does not reorder Java code, and assuming > >>> original SO poster runs Windows, and hence x86, and hence has TSO, > >>> this bug seems very unlikely. I would be surprised if it actually > >>> *can* be reproduced. That makes the whole story rather interesting. > >>> > >>> -Aleksey. > >>> > >>> _______________________________________________ > >>> Concurrency-interest mailing list > >>> Concurrency-interest at cs.oswego.edu > >>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20120516/a006b643/attachment.html From aleksey.shipilev at gmail.com Wed May 16 12:23:14 2012 From: aleksey.shipilev at gmail.com (Aleksey Shipilev) Date: Wed, 16 May 2012 23:23:14 +0400 Subject: [concurrency-interest] a volatile bug? In-Reply-To: References: Message-ID: All right, here's what is on the table. This bug is reproduced for me on Linux i686 with: java version "1.7.0_04" Java(TM) SE Runtime Environment (build 1.7.0_04-b20) Java HotSpot(TM) Client VM (build 23.0-b21, mixed mode) It reproduces immediately only with -client. Both -server and -Xint do NOT reproduce the bug. The code is there in original SO post http://stackoverflow.com/questions/10620680/why-volatile-in-java-5-doesnt-synchronize-cached-copies-of-variables-with-main C1 seems to miscompile run(), and indeed does CSE for local: # {method} 'run' '()V' in 'Test$1' [Verified Entry Point] 0xb4a91e80: mov %eax,-0x4000(%esp) 0xb4a91e87: push %ebp 0xb4a91e88: sub $0x18,%esp ;*invokestatic access$000 ; - Test$1::run at 0 (line 11) 0xb4a91e8b: mov $0xa09c4270,%edx ; {oop(a 'java/lang/Class' = 'Test')} >>>>>> 0xb4a91e90: mov 0x74(%edx),%edx ;*getstatic b <<<<<---- loads $b to %edx ; - Test::access$000 at 0 (line 1) ; - Test$1::run at 0 (line 11) 0xb4a91e93: jmp 0xb4a91e9e ; OopMap{off=40} ;*goto ; - Test$1::run at 10 (line 13) 0xb4a91e98: test %eax,0xb77a9100 ;*goto ; - Test$1::run at 10 (line 13) ; {poll} 0xb4a91e9e: mov $0xa09c4270,%ecx ; {oop(a 'java/lang/Class' = 'Test')} >>>>> 0xb4a91ea3: mov 0x70(%ecx),%ecx ;*getstatic a <<<<< volatile read for $a ; - Test::access$100 at 0 (line 1) ; - Test$1::run at 4 (line 13) 0xb4a91ea6: cmp $0x0,%ecx // <---- $a is at %ecx 0xb4a91ea9: je 0xb4a91e98 ;*ifne ; - Test$1::run at 7 (line 13) >>>> 0xb4a91eab: cmp $0x0,%edx // <<<<<<---- $b is cached in %edx here 0xb4a91eae: jne 0xb4a91ed8 ;*ifne ; - Test$1::run at 16 (line 17) 0xb4a91eb4: nopl 0x0(%eax) 0xb4a91eb8: jmp 0xb4a91f0e ; {no_reloc} 0xb4a91ebd: xchg %ax,%ax 0xb4a91ec0: jmp 0xb4a91f28 ; implicit exception: dispatches to 0xb4a91f18 0xb4a91ec5: nop ;*getstatic out ; - Test$1::run at 19 (line 18) 0xb4a91ec6: cmp (%ecx),%eax ; implicit exception: dispatches to 0xb4a91f32 0xb4a91ec8: mov $0xa09c6488,%edx ;*invokevirtual println ; - Test$1::run at 24 (line 18) ; {oop("error")} Thanks, Aleksey. On Wed, May 16, 2012 at 11:12 PM, Vitaly Davidovich wrote: > It can be a compiler (mis)optimization that causes this, and not x86 memory > ordering. > > Someone posted the assembly output in the comments on SO and it does seem > like there's a place that loads 'b' from the stack rather than memory. > Hans' theory of CSE sounds plausible - can someone repro this without that > "int tt = b;" line? > > Adding hotspot compiler guys in case they want to chime in. > > Sent from my phone > > On May 16, 2012 3:07 PM, "Aleksey Shipilev" > wrote: >> >> On Wed, May 16, 2012 at 10:40 PM, Boehm, Hans wrote: >> > A JDK bug AND a serious test suite omission? >> >> Stress tests would probably JIT-compile the code in question. See below. >> >> > But is the problem real? ?Can it be reproduced on a mainstream JVM? >> >> Same question. >> >> > Note that the example in the original posting also read b before the >> > loop, >> > so na?ve common subexpression elimination would cause the bug. >> > ?Hopefully >> > nobody does CSE in cases like this. >> >> FWIW, the test case in SO would probably not hit any compilation >> threshold in HotSpot, so it could be executed in interpreter. Then, >> assuming the interpreter does not reorder Java code, and assuming >> original SO poster runs Windows, and hence x86, and hence has TSO, >> this bug seems very unlikely. I would be surprised if it actually >> *can* be reproduced. That makes the whole story rather interesting. >> >> -Aleksey. >> >> _______________________________________________ >> Concurrency-interest mailing list >> Concurrency-interest at cs.oswego.edu >> http://cs.oswego.edu/mailman/listinfo/concurrency-interest From aleksey.shipilev at gmail.com Wed May 16 12:55:13 2012 From: aleksey.shipilev at gmail.com (Aleksey Shipilev) Date: Wed, 16 May 2012 23:55:13 +0400 Subject: [concurrency-interest] a volatile bug? In-Reply-To: References: Message-ID: Update. GVN is clearly under suspicion -XX:-UseGlobalValueNumbering mitigates the bug in my setup. Digging through C1 codebase to see rules for volatiles. -Aleksey. On Wed, May 16, 2012 at 11:23 PM, Aleksey Shipilev wrote: > All right, here's what is on the table. > > This bug is reproduced for me on Linux i686 with: > java version "1.7.0_04" > Java(TM) SE Runtime Environment (build 1.7.0_04-b20) > Java HotSpot(TM) Client VM (build 23.0-b21, mixed mode) > > It reproduces immediately only with -client. > Both -server and -Xint do NOT reproduce the bug. > The code is there in original SO post > http://stackoverflow.com/questions/10620680/why-volatile-in-java-5-doesnt-synchronize-cached-copies-of-variables-with-main > > C1 seems to miscompile run(), and indeed does CSE for local: > > ?# {method} 'run' '()V' in 'Test$1' > [Verified Entry Point] > ?0xb4a91e80: mov ? ?%eax,-0x4000(%esp) > ?0xb4a91e87: push ? %ebp > ?0xb4a91e88: sub ? ?$0x18,%esp ? ? ? ? ;*invokestatic access$000 > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?; - Test$1::run at 0 (line 11) > ?0xb4a91e8b: mov ? ?$0xa09c4270,%edx ? ; ? {oop(a 'java/lang/Class' = 'Test')} >>>>>>> ?0xb4a91e90: mov ? ?0x74(%edx),%edx ? ?;*getstatic b <<<<<---- loads $b to %edx > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?; - Test::access$000 at 0 (line 1) > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?; - Test$1::run at 0 (line 11) > ?0xb4a91e93: jmp ? ?0xb4a91e9e ? ? ? ? ; OopMap{off=40} > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?;*goto > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?; - Test$1::run at 10 (line 13) > ?0xb4a91e98: test ? %eax,0xb77a9100 ? ?;*goto > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?; - Test$1::run at 10 (line 13) > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?; ? {poll} > ?0xb4a91e9e: mov ? ?$0xa09c4270,%ecx ? ; ? {oop(a 'java/lang/Class' = 'Test')} >>>>>> ?0xb4a91ea3: mov ? ?0x70(%ecx),%ecx ? ?;*getstatic a ?<<<<< volatile read for $a > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?; - Test::access$100 at 0 (line 1) > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?; - Test$1::run at 4 (line 13) > ?0xb4a91ea6: cmp ? ?$0x0,%ecx ? ? // <---- $a is at %ecx > ?0xb4a91ea9: je ? ? 0xb4a91e98 ? ? ? ? ;*ifne > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?; - Test$1::run at 7 (line 13) > ?>>>> 0xb4a91eab: cmp ? ?$0x0,%edx ? ? // <<<<<<---- $b is cached in %edx here > ?0xb4a91eae: jne ? ?0xb4a91ed8 ? ? ? ? ;*ifne > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?; - Test$1::run at 16 (line 17) > ?0xb4a91eb4: nopl ? 0x0(%eax) > ?0xb4a91eb8: jmp ? ?0xb4a91f0e ? ? ? ? ; ? {no_reloc} > ?0xb4a91ebd: xchg ? %ax,%ax > ?0xb4a91ec0: jmp ? ?0xb4a91f28 ? ? ? ? ; implicit exception: > dispatches to 0xb4a91f18 > ?0xb4a91ec5: nop ? ? ? ? ? ? ? ? ? ? ? ;*getstatic out > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?; - Test$1::run at 19 (line 18) > ?0xb4a91ec6: cmp ? ?(%ecx),%eax ? ? ? ?; implicit exception: > dispatches to 0xb4a91f32 > ?0xb4a91ec8: mov ? ?$0xa09c6488,%edx ? ;*invokevirtual println > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?; - Test$1::run at 24 (line 18) > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?; ? {oop("error")} > > > Thanks, > Aleksey. > > On Wed, May 16, 2012 at 11:12 PM, Vitaly Davidovich wrote: >> It can be a compiler (mis)optimization that causes this, and not x86 memory >> ordering. >> >> Someone posted the assembly output in the comments on SO and it does seem >> like there's a place that loads 'b' from the stack rather than memory. >> Hans' theory of CSE sounds plausible - can someone repro this without that >> "int tt = b;" line? >> >> Adding hotspot compiler guys in case they want to chime in. >> >> Sent from my phone >> >> On May 16, 2012 3:07 PM, "Aleksey Shipilev" >> wrote: >>> >>> On Wed, May 16, 2012 at 10:40 PM, Boehm, Hans wrote: >>> > A JDK bug AND a serious test suite omission? >>> >>> Stress tests would probably JIT-compile the code in question. See below. >>> >>> > But is the problem real? ?Can it be reproduced on a mainstream JVM? >>> >>> Same question. >>> >>> > Note that the example in the original posting also read b before the >>> > loop, >>> > so na?ve common subexpression elimination would cause the bug. >>> > ?Hopefully >>> > nobody does CSE in cases like this. >>> >>> FWIW, the test case in SO would probably not hit any compilation >>> threshold in HotSpot, so it could be executed in interpreter. Then, >>> assuming the interpreter does not reorder Java code, and assuming >>> original SO poster runs Windows, and hence x86, and hence has TSO, >>> this bug seems very unlikely. I would be surprised if it actually >>> *can* be reproduced. That makes the whole story rather interesting. >>> >>> -Aleksey. >>> >>> _______________________________________________ >>> Concurrency-interest mailing list >>> Concurrency-interest at cs.oswego.edu >>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest From aleksey.shipilev at gmail.com Wed May 16 13:41:15 2012 From: aleksey.shipilev at gmail.com (Aleksey Shipilev) Date: Thu, 17 May 2012 00:41:15 +0400 Subject: [concurrency-interest] a volatile bug? In-Reply-To: References: Message-ID: In my case, there are always two compiled versions for Test$1.run, one with cached $b, second one is with correct read for $b. I'd guess pastebin version had the second one. -Aleksey. On Thu, May 17, 2012 at 12:34 AM, Vitaly Davidovich wrote: > I looked at the assembly on SO again (the pastebin link) and it seems to be > correct actually: after 'a' is cmp'ed against zero, 'b' is read from > memory.? But now someone is saying there that it sometimes generates the > correct assembly and other times not - very strange. > 0x025bd2b9: cmp $0x0,%edx > > 30. 0x025bd2bc: je 0x025bd2a8 ; > > 32. 0x025bd2be: mov $0x147062e8,%edx ; {oop('test/TestVolatile')} > > 33. 0x025bd2c3: mov 0x1c4(%edx),%edx ;*getstatic b > > 34. ; - test.TestVolatile::run at 10 (line 17) > > 35. 0x025bd2c9: cmp $0x0,%edx > > Sent from my phone > > On May 16, 2012 3:55 PM, "Aleksey Shipilev" > wrote: >> >> Update. GVN is clearly under suspicion -XX:-UseGlobalValueNumbering >> mitigates the bug in my setup. Digging through C1 codebase to see >> rules for volatiles. >> >> -Aleksey. >> >> On Wed, May 16, 2012 at 11:23 PM, Aleksey Shipilev >> wrote: >> > All right, here's what is on the table. >> > >> > This bug is reproduced for me on Linux i686 with: >> > java version "1.7.0_04" >> > Java(TM) SE Runtime Environment (build 1.7.0_04-b20) >> > Java HotSpot(TM) Client VM (build 23.0-b21, mixed mode) >> > >> > It reproduces immediately only with -client. >> > Both -server and -Xint do NOT reproduce the bug. >> > The code is there in original SO post >> > >> > http://stackoverflow.com/questions/10620680/why-volatile-in-java-5-doesnt-synchronize-cached-copies-of-variables-with-main >> > >> > C1 seems to miscompile run(), and indeed does CSE for local: >> > >> > ?# {method} 'run' '()V' in 'Test$1' >> > [Verified Entry Point] >> > ?0xb4a91e80: mov ? ?%eax,-0x4000(%esp) >> > ?0xb4a91e87: push ? %ebp >> > ?0xb4a91e88: sub ? ?$0x18,%esp ? ? ? ? ;*invokestatic access$000 >> > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?; - Test$1::run at 0 (line 11) >> > ?0xb4a91e8b: mov ? ?$0xa09c4270,%edx ? ; ? {oop(a 'java/lang/Class' = >> > 'Test')} >> >>>>>>> ?0xb4a91e90: mov ? ?0x74(%edx),%edx ? ?;*getstatic b <<<<<---- >> >>>>>>> loads $b to %edx >> > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?; - Test::access$000 at 0 (line 1) >> > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?; - Test$1::run at 0 (line 11) >> > ?0xb4a91e93: jmp ? ?0xb4a91e9e ? ? ? ? ; OopMap{off=40} >> > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?;*goto >> > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?; - Test$1::run at 10 (line 13) >> > ?0xb4a91e98: test ? %eax,0xb77a9100 ? ?;*goto >> > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?; - Test$1::run at 10 (line 13) >> > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?; ? {poll} >> > ?0xb4a91e9e: mov ? ?$0xa09c4270,%ecx ? ; ? {oop(a 'java/lang/Class' = >> > 'Test')} >> >>>>>> ?0xb4a91ea3: mov ? ?0x70(%ecx),%ecx ? ?;*getstatic a ?<<<<< >> >>>>>> volatile read for $a >> > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?; - Test::access$100 at 0 (line 1) >> > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?; - Test$1::run at 4 (line 13) >> > ?0xb4a91ea6: cmp ? ?$0x0,%ecx ? ? // <---- $a is at %ecx >> > ?0xb4a91ea9: je ? ? 0xb4a91e98 ? ? ? ? ;*ifne >> > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?; - Test$1::run at 7 (line 13) >> > ?>>>> 0xb4a91eab: cmp ? ?$0x0,%edx ? ? // <<<<<<---- $b is cached in >> > %edx here >> > ?0xb4a91eae: jne ? ?0xb4a91ed8 ? ? ? ? ;*ifne >> > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?; - Test$1::run at 16 (line 17) >> > ?0xb4a91eb4: nopl ? 0x0(%eax) >> > ?0xb4a91eb8: jmp ? ?0xb4a91f0e ? ? ? ? ; ? {no_reloc} >> > ?0xb4a91ebd: xchg ? %ax,%ax >> > ?0xb4a91ec0: jmp ? ?0xb4a91f28 ? ? ? ? ; implicit exception: >> > dispatches to 0xb4a91f18 >> > ?0xb4a91ec5: nop ? ? ? ? ? ? ? ? ? ? ? ;*getstatic out >> > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?; - Test$1::run at 19 (line 18) >> > ?0xb4a91ec6: cmp ? ?(%ecx),%eax ? ? ? ?; implicit exception: >> > dispatches to 0xb4a91f32 >> > ?0xb4a91ec8: mov ? ?$0xa09c6488,%edx ? ;*invokevirtual println >> > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?; - Test$1::run at 24 (line 18) >> > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?; ? {oop("error")} >> > >> > >> > Thanks, >> > Aleksey. >> > >> > On Wed, May 16, 2012 at 11:12 PM, Vitaly Davidovich >> > wrote: >> >> It can be a compiler (mis)optimization that causes this, and not x86 >> >> memory >> >> ordering. >> >> >> >> Someone posted the assembly output in the comments on SO and it does >> >> seem >> >> like there's a place that loads 'b' from the stack rather than memory. >> >> Hans' theory of CSE sounds plausible - can someone repro this without >> >> that >> >> "int tt = b;" line? >> >> >> >> Adding hotspot compiler guys in case they want to chime in. >> >> >> >> Sent from my phone >> >> >> >> On May 16, 2012 3:07 PM, "Aleksey Shipilev" >> >> >> >> wrote: >> >>> >> >>> On Wed, May 16, 2012 at 10:40 PM, Boehm, Hans >> >>> wrote: >> >>> > A JDK bug AND a serious test suite omission? >> >>> >> >>> Stress tests would probably JIT-compile the code in question. See >> >>> below. >> >>> >> >>> > But is the problem real? ?Can it be reproduced on a mainstream JVM? >> >>> >> >>> Same question. >> >>> >> >>> > Note that the example in the original posting also read b before the >> >>> > loop, >> >>> > so na?ve common subexpression elimination would cause the bug. >> >>> > ?Hopefully >> >>> > nobody does CSE in cases like this. >> >>> >> >>> FWIW, the test case in SO would probably not hit any compilation >> >>> threshold in HotSpot, so it could be executed in interpreter. Then, >> >>> assuming the interpreter does not reorder Java code, and assuming >> >>> original SO poster runs Windows, and hence x86, and hence has TSO, >> >>> this bug seems very unlikely. I would be surprised if it actually >> >>> *can* be reproduced. That makes the whole story rather interesting. >> >>> >> >>> -Aleksey. >> >>> >> >>> _______________________________________________ >> >>> Concurrency-interest mailing list >> >>> Concurrency-interest at cs.oswego.edu >> >>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest From aleksey.shipilev at gmail.com Wed May 16 14:22:17 2012 From: aleksey.shipilev at gmail.com (Aleksey Shipilev) Date: Thu, 17 May 2012 01:22:17 +0400 Subject: [concurrency-interest] a volatile bug? In-Reply-To: References: Message-ID: Well, I do not want to sound alarming, but... if I understand the C1 code correctly, then C1 GVN does not account prior volatile reads at all. I can not find any code in C1 GVN code which actually prevents killing second non-volatile read after volatile one, which is required by JMM semantics. I think I'll stop here. The impact of this issue is limited, given most of the guys run -server (even by default on most machines), so there is always the workaround for running with -server. Also, I would *speculate* turning off GVN with -XX:-UseGlobalValueNumbering when running with -client is still a workaround, but kind of insane one, since it can *severely* degrade performance. Words of wisdom: I'm using this command-line to print out GVN tracing: $ ~/Install/jdk7u4/fastdebug/bin/java -XX:+PrintCompilation -XX:+PrintDominators -XX:+PrintCompilation -XX:+PrintValueNumbering -Xbatch -XX:CompileOnly=Test.$1,Test -client Test 2>&1 | tee asm.log Can anyone more proficient in C1 code confirm this? -Aleksey. On Thu, May 17, 2012 at 12:41 AM, Aleksey Shipilev wrote: > In my case, there are always two compiled versions for Test$1.run, one > with cached $b, second one is with correct read for $b. I'd guess > pastebin version had the second one. > > -Aleksey. > > On Thu, May 17, 2012 at 12:34 AM, Vitaly Davidovich wrote: >> I looked at the assembly on SO again (the pastebin link) and it seems to be >> correct actually: after 'a' is cmp'ed against zero, 'b' is read from >> memory.? But now someone is saying there that it sometimes generates the >> correct assembly and other times not - very strange. >> 0x025bd2b9: cmp $0x0,%edx >> >> 30. 0x025bd2bc: je 0x025bd2a8 ; >> >> 32. 0x025bd2be: mov $0x147062e8,%edx ; {oop('test/TestVolatile')} >> >> 33. 0x025bd2c3: mov 0x1c4(%edx),%edx ;*getstatic b >> >> 34. ; - test.TestVolatile::run at 10 (line 17) >> >> 35. 0x025bd2c9: cmp $0x0,%edx >> >> Sent from my phone >> >> On May 16, 2012 3:55 PM, "Aleksey Shipilev" >> wrote: >>> >>> Update. GVN is clearly under suspicion -XX:-UseGlobalValueNumbering >>> mitigates the bug in my setup. Digging through C1 codebase to see >>> rules for volatiles. >>> >>> -Aleksey. >>> >>> On Wed, May 16, 2012 at 11:23 PM, Aleksey Shipilev >>> wrote: >>> > All right, here's what is on the table. >>> > >>> > This bug is reproduced for me on Linux i686 with: >>> > java version "1.7.0_04" >>> > Java(TM) SE Runtime Environment (build 1.7.0_04-b20) >>> > Java HotSpot(TM) Client VM (build 23.0-b21, mixed mode) >>> > >>> > It reproduces immediately only with -client. >>> > Both -server and -Xint do NOT reproduce the bug. >>> > The code is there in original SO post >>> > >>> > http://stackoverflow.com/questions/10620680/why-volatile-in-java-5-doesnt-synchronize-cached-copies-of-variables-with-main >>> > >>> > C1 seems to miscompile run(), and indeed does CSE for local: >>> > >>> > ?# {method} 'run' '()V' in 'Test$1' >>> > [Verified Entry Point] >>> > ?0xb4a91e80: mov ? ?%eax,-0x4000(%esp) >>> > ?0xb4a91e87: push ? %ebp >>> > ?0xb4a91e88: sub ? ?$0x18,%esp ? ? ? ? ;*invokestatic access$000 >>> > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?; - Test$1::run at 0 (line 11) >>> > ?0xb4a91e8b: mov ? ?$0xa09c4270,%edx ? ; ? {oop(a 'java/lang/Class' = >>> > 'Test')} >>> >>>>>>> ?0xb4a91e90: mov ? ?0x74(%edx),%edx ? ?;*getstatic b <<<<<---- >>> >>>>>>> loads $b to %edx >>> > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?; - Test::access$000 at 0 (line 1) >>> > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?; - Test$1::run at 0 (line 11) >>> > ?0xb4a91e93: jmp ? ?0xb4a91e9e ? ? ? ? ; OopMap{off=40} >>> > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?;*goto >>> > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?; - Test$1::run at 10 (line 13) >>> > ?0xb4a91e98: test ? %eax,0xb77a9100 ? ?;*goto >>> > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?; - Test$1::run at 10 (line 13) >>> > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?; ? {poll} >>> > ?0xb4a91e9e: mov ? ?$0xa09c4270,%ecx ? ; ? {oop(a 'java/lang/Class' = >>> > 'Test')} >>> >>>>>> ?0xb4a91ea3: mov ? ?0x70(%ecx),%ecx ? ?;*getstatic a ?<<<<< >>> >>>>>> volatile read for $a >>> > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?; - Test::access$100 at 0 (line 1) >>> > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?; - Test$1::run at 4 (line 13) >>> > ?0xb4a91ea6: cmp ? ?$0x0,%ecx ? ? // <---- $a is at %ecx >>> > ?0xb4a91ea9: je ? ? 0xb4a91e98 ? ? ? ? ;*ifne >>> > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?; - Test$1::run at 7 (line 13) >>> > ?>>>> 0xb4a91eab: cmp ? ?$0x0,%edx ? ? // <<<<<<---- $b is cached in >>> > %edx here >>> > ?0xb4a91eae: jne ? ?0xb4a91ed8 ? ? ? ? ;*ifne >>> > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?; - Test$1::run at 16 (line 17) >>> > ?0xb4a91eb4: nopl ? 0x0(%eax) >>> > ?0xb4a91eb8: jmp ? ?0xb4a91f0e ? ? ? ? ; ? {no_reloc} >>> > ?0xb4a91ebd: xchg ? %ax,%ax >>> > ?0xb4a91ec0: jmp ? ?0xb4a91f28 ? ? ? ? ; implicit exception: >>> > dispatches to 0xb4a91f18 >>> > ?0xb4a91ec5: nop ? ? ? ? ? ? ? ? ? ? ? ;*getstatic out >>> > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?; - Test$1::run at 19 (line 18) >>> > ?0xb4a91ec6: cmp ? ?(%ecx),%eax ? ? ? ?; implicit exception: >>> > dispatches to 0xb4a91f32 >>> > ?0xb4a91ec8: mov ? ?$0xa09c6488,%edx ? ;*invokevirtual println >>> > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?; - Test$1::run at 24 (line 18) >>> > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?; ? {oop("error")} >>> > >>> > >>> > Thanks, >>> > Aleksey. >>> > >>> > On Wed, May 16, 2012 at 11:12 PM, Vitaly Davidovich >>> > wrote: >>> >> It can be a compiler (mis)optimization that causes this, and not x86 >>> >> memory >>> >> ordering. >>> >> >>> >> Someone posted the assembly output in the comments on SO and it does >>> >> seem >>> >> like there's a place that loads 'b' from the stack rather than memory. >>> >> Hans' theory of CSE sounds plausible - can someone repro this without >>> >> that >>> >> "int tt = b;" line? >>> >> >>> >> Adding hotspot compiler guys in case they want to chime in. >>> >> >>> >> Sent from my phone >>> >> >>> >> On May 16, 2012 3:07 PM, "Aleksey Shipilev" >>> >> >>> >> wrote: >>> >>> >>> >>> On Wed, May 16, 2012 at 10:40 PM, Boehm, Hans >>> >>> wrote: >>> >>> > A JDK bug AND a serious test suite omission? >>> >>> >>> >>> Stress tests would probably JIT-compile the code in question. See >>> >>> below. >>> >>> >>> >>> > But is the problem real? ?Can it be reproduced on a mainstream JVM? >>> >>> >>> >>> Same question. >>> >>> >>> >>> > Note that the example in the original posting also read b before the >>> >>> > loop, >>> >>> > so na?ve common subexpression elimination would cause the bug. >>> >>> > ?Hopefully >>> >>> > nobody does CSE in cases like this. >>> >>> >>> >>> FWIW, the test case in SO would probably not hit any compilation >>> >>> threshold in HotSpot, so it could be executed in interpreter. Then, >>> >>> assuming the interpreter does not reorder Java code, and assuming >>> >>> original SO poster runs Windows, and hence x86, and hence has TSO, >>> >>> this bug seems very unlikely. I would be surprised if it actually >>> >>> *can* be reproduced. That makes the whole story rather interesting. >>> >>> >>> >>> -Aleksey. >>> >>> >>> >>> _______________________________________________ >>> >>> Concurrency-interest mailing list >>> >>> Concurrency-interest at cs.oswego.edu >>> >>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest From christian.thalinger at oracle.com Wed May 16 16:42:22 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 16 May 2012 16:42:22 -0700 Subject: [concurrency-interest] a volatile bug? In-Reply-To: References: Message-ID: On May 16, 2012, at 2:22 PM, Aleksey Shipilev wrote: > Well, I do not want to sound alarming, but... if I understand the C1 > code correctly, then C1 GVN does not account prior volatile reads at > all. I can not find any code in C1 GVN code which actually prevents > killing second non-volatile read after volatile one, which is required > by JMM semantics. Good investigation. That seems to be the case. > > I think I'll stop here. The impact of this issue is limited, given > most of the guys run -server (even by default on most machines), so > there is always the workaround for running with -server. Also, I would > *speculate* turning off GVN with -XX:-UseGlobalValueNumbering when > running with -client is still a workaround, but kind of insane one, > since it can *severely* degrade performance. > > Words of wisdom: I'm using this command-line to print out GVN tracing: > $ ~/Install/jdk7u4/fastdebug/bin/java -XX:+PrintCompilation > -XX:+PrintDominators -XX:+PrintCompilation -XX:+PrintValueNumbering > -Xbatch -XX:CompileOnly=Test.$1,Test -client Test 2>&1 | tee asm.log > > Can anyone more proficient in C1 code confirm this? I can confirm the bug and I have a fix for it. -- Chris > > -Aleksey. > > On Thu, May 17, 2012 at 12:41 AM, Aleksey Shipilev > wrote: >> In my case, there are always two compiled versions for Test$1.run, one >> with cached $b, second one is with correct read for $b. I'd guess >> pastebin version had the second one. >> >> -Aleksey. >> >> On Thu, May 17, 2012 at 12:34 AM, Vitaly Davidovich wrote: >>> I looked at the assembly on SO again (the pastebin link) and it seems to be >>> correct actually: after 'a' is cmp'ed against zero, 'b' is read from >>> memory. But now someone is saying there that it sometimes generates the >>> correct assembly and other times not - very strange. >>> 0x025bd2b9: cmp $0x0,%edx >>> >>> 30. 0x025bd2bc: je 0x025bd2a8 ; >>> >>> 32. 0x025bd2be: mov $0x147062e8,%edx ; {oop('test/TestVolatile')} >>> >>> 33. 0x025bd2c3: mov 0x1c4(%edx),%edx ;*getstatic b >>> >>> 34. ; - test.TestVolatile::run at 10 (line 17) >>> >>> 35. 0x025bd2c9: cmp $0x0,%edx >>> >>> Sent from my phone >>> >>> On May 16, 2012 3:55 PM, "Aleksey Shipilev" >>> wrote: >>>> >>>> Update. GVN is clearly under suspicion -XX:-UseGlobalValueNumbering >>>> mitigates the bug in my setup. Digging through C1 codebase to see >>>> rules for volatiles. >>>> >>>> -Aleksey. >>>> >>>> On Wed, May 16, 2012 at 11:23 PM, Aleksey Shipilev >>>> wrote: >>>>> All right, here's what is on the table. >>>>> >>>>> This bug is reproduced for me on Linux i686 with: >>>>> java version "1.7.0_04" >>>>> Java(TM) SE Runtime Environment (build 1.7.0_04-b20) >>>>> Java HotSpot(TM) Client VM (build 23.0-b21, mixed mode) >>>>> >>>>> It reproduces immediately only with -client. >>>>> Both -server and -Xint do NOT reproduce the bug. >>>>> The code is there in original SO post >>>>> >>>>> http://stackoverflow.com/questions/10620680/why-volatile-in-java-5-doesnt-synchronize-cached-copies-of-variables-with-main >>>>> >>>>> C1 seems to miscompile run(), and indeed does CSE for local: >>>>> >>>>> # {method} 'run' '()V' in 'Test$1' >>>>> [Verified Entry Point] >>>>> 0xb4a91e80: mov %eax,-0x4000(%esp) >>>>> 0xb4a91e87: push %ebp >>>>> 0xb4a91e88: sub $0x18,%esp ;*invokestatic access$000 >>>>> ; - Test$1::run at 0 (line 11) >>>>> 0xb4a91e8b: mov $0xa09c4270,%edx ; {oop(a 'java/lang/Class' = >>>>> 'Test')} >>>>>>>>>>> 0xb4a91e90: mov 0x74(%edx),%edx ;*getstatic b <<<<<---- >>>>>>>>>>> loads $b to %edx >>>>> ; - Test::access$000 at 0 (line 1) >>>>> ; - Test$1::run at 0 (line 11) >>>>> 0xb4a91e93: jmp 0xb4a91e9e ; OopMap{off=40} >>>>> ;*goto >>>>> ; - Test$1::run at 10 (line 13) >>>>> 0xb4a91e98: test %eax,0xb77a9100 ;*goto >>>>> ; - Test$1::run at 10 (line 13) >>>>> ; {poll} >>>>> 0xb4a91e9e: mov $0xa09c4270,%ecx ; {oop(a 'java/lang/Class' = >>>>> 'Test')} >>>>>>>>>> 0xb4a91ea3: mov 0x70(%ecx),%ecx ;*getstatic a <<<<< >>>>>>>>>> volatile read for $a >>>>> ; - Test::access$100 at 0 (line 1) >>>>> ; - Test$1::run at 4 (line 13) >>>>> 0xb4a91ea6: cmp $0x0,%ecx // <---- $a is at %ecx >>>>> 0xb4a91ea9: je 0xb4a91e98 ;*ifne >>>>> ; - Test$1::run at 7 (line 13) >>>>> >>>> 0xb4a91eab: cmp $0x0,%edx // <<<<<<---- $b is cached in >>>>> %edx here >>>>> 0xb4a91eae: jne 0xb4a91ed8 ;*ifne >>>>> ; - Test$1::run at 16 (line 17) >>>>> 0xb4a91eb4: nopl 0x0(%eax) >>>>> 0xb4a91eb8: jmp 0xb4a91f0e ; {no_reloc} >>>>> 0xb4a91ebd: xchg %ax,%ax >>>>> 0xb4a91ec0: jmp 0xb4a91f28 ; implicit exception: >>>>> dispatches to 0xb4a91f18 >>>>> 0xb4a91ec5: nop ;*getstatic out >>>>> ; - Test$1::run at 19 (line 18) >>>>> 0xb4a91ec6: cmp (%ecx),%eax ; implicit exception: >>>>> dispatches to 0xb4a91f32 >>>>> 0xb4a91ec8: mov $0xa09c6488,%edx ;*invokevirtual println >>>>> ; - Test$1::run at 24 (line 18) >>>>> ; {oop("error")} >>>>> >>>>> >>>>> Thanks, >>>>> Aleksey. >>>>> >>>>> On Wed, May 16, 2012 at 11:12 PM, Vitaly Davidovich >>>>> wrote: >>>>>> It can be a compiler (mis)optimization that causes this, and not x86 >>>>>> memory >>>>>> ordering. >>>>>> >>>>>> Someone posted the assembly output in the comments on SO and it does >>>>>> seem >>>>>> like there's a place that loads 'b' from the stack rather than memory. >>>>>> Hans' theory of CSE sounds plausible - can someone repro this without >>>>>> that >>>>>> "int tt = b;" line? >>>>>> >>>>>> Adding hotspot compiler guys in case they want to chime in. >>>>>> >>>>>> Sent from my phone >>>>>> >>>>>> On May 16, 2012 3:07 PM, "Aleksey Shipilev" >>>>>> >>>>>> wrote: >>>>>>> >>>>>>> On Wed, May 16, 2012 at 10:40 PM, Boehm, Hans >>>>>>> wrote: >>>>>>>> A JDK bug AND a serious test suite omission? >>>>>>> >>>>>>> Stress tests would probably JIT-compile the code in question. See >>>>>>> below. >>>>>>> >>>>>>>> But is the problem real? Can it be reproduced on a mainstream JVM? >>>>>>> >>>>>>> Same question. >>>>>>> >>>>>>>> Note that the example in the original posting also read b before the >>>>>>>> loop, >>>>>>>> so na?ve common subexpression elimination would cause the bug. >>>>>>>> Hopefully >>>>>>>> nobody does CSE in cases like this. >>>>>>> >>>>>>> FWIW, the test case in SO would probably not hit any compilation >>>>>>> threshold in HotSpot, so it could be executed in interpreter. Then, >>>>>>> assuming the interpreter does not reorder Java code, and assuming >>>>>>> original SO poster runs Windows, and hence x86, and hence has TSO, >>>>>>> this bug seems very unlikely. I would be surprised if it actually >>>>>>> *can* be reproduced. That makes the whole story rather interesting. >>>>>>> >>>>>>> -Aleksey. >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Concurrency-interest mailing list >>>>>>> Concurrency-interest at cs.oswego.edu >>>>>>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest From heinz at javaspecialists.eu Thu May 17 12:59:10 2012 From: heinz at javaspecialists.eu (Dr Heinz M. Kabutz) Date: Thu, 17 May 2012 22:59:10 +0300 Subject: [concurrency-interest] a volatile bug? In-Reply-To: References: Message-ID: <4FB5588E.1070409@javaspecialists.eu> An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20120517/96600f98/attachment-0001.html From aleksey.shipilev at gmail.com Thu May 17 13:22:43 2012 From: aleksey.shipilev at gmail.com (Aleksey Shipilev) Date: Fri, 18 May 2012 00:22:43 +0400 Subject: [concurrency-interest] a volatile bug? In-Reply-To: <4FB5588E.1070409@javaspecialists.eu> References: <4FB5588E.1070409@javaspecialists.eu> Message-ID: Interesting but unrelated bug, is there a CR already? Basically, if you run the test with safepoint tracing, you will see: $ ~/Install/jdk7u4/bin/java -XX:+SafepointTimeout -server VirtualMachineLiveLock ... temp = 34 temp = 35 temp = 36 temp = 37 temp = 38 temp = 39 # SafepointSynchronize::begin: Timeout detected: # SafepointSynchronize::begin: Timed out while spinning to reach a safepoint. # SafepointSynchronize::begin: Threads which did not reach the safepoint: # "Thread-1" prio=10 tid=0x6bcff000 nid=0x117a runnable [0x00000000] java.lang.Thread.State: RUNNABLE # SafepointSynchronize::begin: (End of list) -Aleksey. On Thu, May 17, 2012 at 11:59 PM, Dr Heinz M. Kabutz wrote: > That's not all. > > Using volatile fields, you can cause a beautiful unbreakable hard spin in > JVM Server Hotspot since 1.6.0_14, basically livelocking the JVM.? It won't > react to any of the usual Java tools, like jconsole, jstack, etc.? Only kill > -9 to shut it down, plus of course the usual C tools. > > https://github.com/kabutz/javaspecialists/blob/master/src/main/java/eu/javaspecialists/tjsn/examples/issue188/VirtualMachineLiveLock.java > > and mentioned (briefly) at the end of > http://www.javaspecialists.eu/archive/Issue188.html > > I discovered this in 2010 already, but have so far not managed to get it > fixed. > > And this is a bug in the Server HotSpot JVM - so that is not necessarily a > refuge where you can hide from volatile bugs! > > As we approach the limits with our clever concurrent code, I believe we will > see issues like this crop up more and more. > > Regards > > Heinz > -- > Dr Heinz M. Kabutz (PhD CompSci) > Author of "The Java(tm) Specialists' Newsletter" > Sun Java Champion > IEEE Certified Software Development Professional > http://www.javaspecialists.eu > Tel: +30 69 75 595 262 > Skype: kabutz > > > > On 5/17/12 1:01 AM, Boehm, Hans wrote: > > Would it make sense to expand a test suite with a bunch of memory model > tests, e.g.: > > no CSE across volatile load > corresponding test for a volatile store: > r1 = x; v = ...; r2 = x; use r1 doesn't replace the use of r1 with r2 > Dekker's example > No fusion of potentially infinite loops > Maybe IRIW/write atomicity > > ? > > My main concern here stems from the fact that this is perhaps the most basic > test of volatiles that fails. Is there any reason to believe the > harder-to-enforce properties of volatiles hold? > > Hans > > > > -----Original Message----- > From: Aleksey Shipilev [mailto:aleksey.shipilev at gmail.com] > Sent: Wednesday, May 16, 2012 2:22 PM > To: Vitaly Davidovich > Cc: Boehm, Hans; hotspot compiler; concurrency-interest at cs.oswego.edu > Subject: Re: [concurrency-interest] a volatile bug? > > Well, I do not want to sound alarming, but... if I understand the C1 > code correctly, then C1 GVN does not account prior volatile reads at > all. I can not find any code in C1 GVN code which actually prevents > killing second non-volatile read after volatile one, which is required > by JMM semantics. > > I think I'll stop here. The impact of this issue is limited, given > most of the guys run -server (even by default on most machines), so > there is always the workaround for running with -server. Also, I would > *speculate* turning off GVN with -XX:-UseGlobalValueNumbering when > running with -client is still a workaround, but kind of insane one, > since it can *severely* degrade performance. > > Words of wisdom: I'm using this command-line to print out GVN tracing: > $ ~/Install/jdk7u4/fastdebug/bin/java -XX:+PrintCompilation > -XX:+PrintDominators -XX:+PrintCompilation -XX:+PrintValueNumbering > -Xbatch -XX:CompileOnly=Test.$1,Test -client Test 2>&1 | tee asm.log > > Can anyone more proficient in C1 code confirm this? > > -Aleksey. > > On Thu, May 17, 2012 at 12:41 AM, Aleksey Shipilev > wrote: > > > In my case, there are always two compiled versions for Test$1.run, > > > one > > > with cached $b, second one is with correct read for $b. I'd guess > pastebin version had the second one. > > -Aleksey. > > On Thu, May 17, 2012 at 12:34 AM, Vitaly Davidovich > > > wrote: > > > I looked at the assembly on SO again (the pastebin link) and it > > > seems to be > > > correct actually: after 'a' is cmp'ed against zero, 'b' is read from > memory.? But now someone is saying there that it sometimes generates > > > the > > > correct assembly and other times not - very strange. > 0x025bd2b9: cmp $0x0,%edx > > 30. 0x025bd2bc: je 0x025bd2a8 ; > > 32. 0x025bd2be: mov $0x147062e8,%edx ; {oop('test/TestVolatile')} > > 33. 0x025bd2c3: mov 0x1c4(%edx),%edx ;*getstatic b > > 34. ; - test.TestVolatile::run at 10 (line 17) > > 35. 0x025bd2c9: cmp $0x0,%edx > > Sent from my phone > > On May 16, 2012 3:55 PM, "Aleksey Shipilev" > > > > > > wrote: > > > Update. GVN is clearly under suspicion -XX:-UseGlobalValueNumbering > mitigates the bug in my setup. Digging through C1 codebase to see > rules for volatiles. > > -Aleksey. > > On Wed, May 16, 2012 at 11:23 PM, Aleksey Shipilev > wrote: > > > All right, here's what is on the table. > > This bug is reproduced for me on Linux i686 with: > java version "1.7.0_04" > Java(TM) SE Runtime Environment (build 1.7.0_04-b20) > Java HotSpot(TM) Client VM (build 23.0-b21, mixed mode) > > It reproduces immediately only with -client. > Both -server and -Xint do NOT reproduce the bug. > The code is there in original SO post > > http://stackoverflow.com/questions/10620680/why-volatile-in-java- > > > 5-doesnt-synchronize-cached-copies-of-variables-with-main > > > C1 seems to miscompile run(), and indeed does CSE for local: > > ?# {method} 'run' '()V' in 'Test$1' > [Verified Entry Point] > ?0xb4a91e80: mov ? ?%eax,-0x4000(%esp) > ?0xb4a91e87: push ? %ebp > ?0xb4a91e88: sub ? ?$0x18,%esp ? ? ? ? ;*invokestatic access$000 > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?; - Test$1::run at 0 (line > > > 11) > > > ?0xb4a91e8b: mov ? ?$0xa09c4270,%edx ? ; ? {oop(a > > > 'java/lang/Class' = > > > 'Test')} > > > ?0xb4a91e90: mov ? ?0x74(%edx),%edx ? ?;*getstatic b <<<<<- > > > --- > > > loads $b to %edx > > > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?; - Test::access$000 at 0 > > > (line 1) > > > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?; - Test$1::run at 0 (line > > > 11) > > > ?0xb4a91e93: jmp ? ?0xb4a91e9e ? ? ? ? ; OopMap{off=40} > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?;*goto > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?; - Test$1::run at 10 (line > > > 13) > > > ?0xb4a91e98: test ? %eax,0xb77a9100 ? ?;*goto > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?; - Test$1::run at 10 (line > > > 13) > > > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?; ? {poll} > ?0xb4a91e9e: mov ? ?$0xa09c4270,%ecx ? ; ? {oop(a > > > 'java/lang/Class' = > > > 'Test')} > > > ?0xb4a91ea3: mov ? ?0x70(%ecx),%ecx ? ?;*getstatic a ?<<<<< > volatile read for $a > > > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?; - Test::access$100 at 0 > > > (line 1) > > > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?; - Test$1::run at 4 (line > > > 13) > > > ?0xb4a91ea6: cmp ? ?$0x0,%ecx ? ? // <---- $a is at %ecx > ?0xb4a91ea9: je ? ? 0xb4a91e98 ? ? ? ? ;*ifne > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?; - Test$1::run at 7 (line > > > 13) > > > ?>>>> 0xb4a91eab: cmp ? ?$0x0,%edx ? ? // <<<<<<---- $b is cached > > > in > > > %edx here > ?0xb4a91eae: jne ? ?0xb4a91ed8 ? ? ? ? ;*ifne > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?; - Test$1::run at 16 (line > > > 17) > > > ?0xb4a91eb4: nopl ? 0x0(%eax) > ?0xb4a91eb8: jmp ? ?0xb4a91f0e ? ? ? ? ; ? {no_reloc} > ?0xb4a91ebd: xchg ? %ax,%ax > ?0xb4a91ec0: jmp ? ?0xb4a91f28 ? ? ? ? ; implicit exception: > dispatches to 0xb4a91f18 > ?0xb4a91ec5: nop ? ? ? ? ? ? ? ? ? ? ? ;*getstatic out > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?; - Test$1::run at 19 (line > > > 18) > > > ?0xb4a91ec6: cmp ? ?(%ecx),%eax ? ? ? ?; implicit exception: > dispatches to 0xb4a91f32 > ?0xb4a91ec8: mov ? ?$0xa09c6488,%edx ? ;*invokevirtual println > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?; - Test$1::run at 24 (line > > > 18) > > > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?; ? {oop("error")} > > > Thanks, > Aleksey. > > On Wed, May 16, 2012 at 11:12 PM, Vitaly Davidovich > > > > > > wrote: > > > It can be a compiler (mis)optimization that causes this, and not > > > x86 > > > memory > ordering. > > Someone posted the assembly output in the comments on SO and it > > > does > > > seem > like there's a place that loads 'b' from the stack rather than > > > memory. > > > Hans' theory of CSE sounds plausible - can someone repro this > > > without > > > that > "int tt = b;" line? > > Adding hotspot compiler guys in case they want to chime in. > > Sent from my phone > > On May 16, 2012 3:07 PM, "Aleksey Shipilev" > > wrote: > > > On Wed, May 16, 2012 at 10:40 PM, Boehm, Hans > > > > > > wrote: > > > A JDK bug AND a serious test suite omission? > > > Stress tests would probably JIT-compile the code in question. > > > See > > > below. > > > > But is the problem real? ?Can it be reproduced on a > > > mainstream JVM? > > > Same question. > > > > Note that the example in the original posting also read b > > > before the > > > loop, > so na?ve common subexpression elimination would cause the > > > bug. > > > ?Hopefully > nobody does CSE in cases like this. > > > FWIW, the test case in SO would probably not hit any > > > compilation > > > threshold in HotSpot, so it could be executed in interpreter. > > > Then, > > > assuming the interpreter does not reorder Java code, and > > > assuming > > > original SO poster runs Windows, and hence x86, and hence has > > > TSO, > > > this bug seems very unlikely. I would be surprised if it > > > actually > > > *can* be reproduced. That makes the whole story rather > > > interesting. > > > -Aleksey. > > _______________________________________________ > Concurrency-interest mailing list > Concurrency-interest at cs.oswego.edu > http://cs.oswego.edu/mailman/listinfo/concurrency-interest > > > _______________________________________________ > Concurrency-interest mailing list > Concurrency-interest at cs.oswego.edu > http://cs.oswego.edu/mailman/listinfo/concurrency-interest > From christian.thalinger at oracle.com Thu May 17 17:40:50 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 17 May 2012 17:40:50 -0700 Subject: Request for review (XS): crash in C2 when using -XX:+CountCompiledCalls In-Reply-To: References: Message-ID: <95719E5F-6E9D-4784-B240-CB04E9910A3D@oracle.com> Looks good. -- Chris On May 16, 2012, at 6:02 AM, Krystal Mok wrote: > Hi all, > > Could I get some reviews for this patch, please? > https://gist.github.com/2710000#file_count_compiled_calls.patch > > Description: > > C2 may crash when compiling methods with -XX:+CountCompiledCalls turned on. The cause is in Parse::count_compiled_calls(), where it made a TypeInstPtr from a ciMethod: > > const TypeInstPtr* addr_type = TypeInstPtr::make(method()); > > Since the klass of a ciMethod is a ciMethodKlass, which isn't a ciInstanceKlass, an assertion is hit later in Compile::flatten_alias_type(), where it's expecting a TypeInstPtr to have a ciInstanceKlass: > > ciInstanceKlass *k = to->klass()->as_instance_klass(); > > An example of the crash is available here: https://gist.github.com/2710000 > In the example, I started a Groovy shell with -XX:+CountCompiledCalls set, and it crashed quickly when compiling java.lang.String.charAt(). > > The fix is to use TypeOopPtr::make_from_constant(method()) instead of TypeInstPtr::make(method()). > I did check the hg history, and looks like it's been like this since duke at 0. Wonder if there's any history behind this. > > Note that this fix may have to be changed again when methodOopDesc's are moved out of PermGen. > > Regards, > Kris -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20120517/88dcba4d/attachment.html From john.coomes at oracle.com Thu May 17 20:38:50 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 18 May 2012 03:38:50 +0000 Subject: hg: hsx/hotspot-comp: 4 new changesets Message-ID: <20120518033851.36E4D473B5@hg.openjdk.java.net> Changeset: 955a3e8ed4f0 Author: ohair Date: 2012-05-10 08:26 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/955a3e8ed4f0 7167593: Changed get_source.sh to allow for getting full oracle jdk repo forest Reviewed-by: erikj, asaha, chegar, sla, dholmes, mbykov, coleenp ! get_source.sh ! make/scripts/hgforest.sh Changeset: 8a4e92c10a9a Author: ohair Date: 2012-05-11 17:52 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/8a4e92c10a9a 7167976: Fix broken get_source.sh script Reviewed-by: tbell ! make/scripts/hgforest.sh Changeset: 8927dd68aee3 Author: katleman Date: 2012-05-16 22:06 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/8927dd68aee3 Merge Changeset: a2b2d435f1d2 Author: katleman Date: 2012-05-17 06:20 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/a2b2d435f1d2 Added tag jdk8-b39 for changeset 8927dd68aee3 ! .hgtags From john.coomes at oracle.com Thu May 17 20:38:56 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 18 May 2012 03:38:56 +0000 Subject: hg: hsx/hotspot-comp/corba: Added tag jdk8-b39 for changeset 785af00e2827 Message-ID: <20120518033858.72E2A473B6@hg.openjdk.java.net> Changeset: 56d030e5035f Author: katleman Date: 2012-05-17 06:20 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/corba/rev/56d030e5035f Added tag jdk8-b39 for changeset 785af00e2827 ! .hgtags From john.coomes at oracle.com Thu May 17 20:39:04 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 18 May 2012 03:39:04 +0000 Subject: hg: hsx/hotspot-comp/jaxp: Added tag jdk8-b39 for changeset f95fdbe525c8 Message-ID: <20120518033910.A3693473B7@hg.openjdk.java.net> Changeset: 9ecfdbd6aed4 Author: katleman Date: 2012-05-17 06:20 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxp/rev/9ecfdbd6aed4 Added tag jdk8-b39 for changeset f95fdbe525c8 ! .hgtags From john.coomes at oracle.com Thu May 17 20:39:16 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 18 May 2012 03:39:16 +0000 Subject: hg: hsx/hotspot-comp/jaxws: Added tag jdk8-b39 for changeset 7f6b44fd3034 Message-ID: <20120518033920.DF1A9473B8@hg.openjdk.java.net> Changeset: 09a0ddda03cb Author: katleman Date: 2012-05-17 06:20 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxws/rev/09a0ddda03cb Added tag jdk8-b39 for changeset 7f6b44fd3034 ! .hgtags From john.coomes at oracle.com Thu May 17 20:39:30 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 18 May 2012 03:39:30 +0000 Subject: hg: hsx/hotspot-comp/jdk: 4 new changesets Message-ID: <20120518034039.69381473B9@hg.openjdk.java.net> Changeset: c2d9166f3284 Author: ihse Date: 2012-05-11 08:21 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/c2d9166f3284 7168208: Change use of @ in one sed command involving paths to different character Reviewed-by: ohair ! make/common/Release.gmk Changeset: 8d665b69ebf1 Author: mfang Date: 2012-05-15 11:46 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/8d665b69ebf1 7157855: jvisualvm.1 not included in binaries Reviewed-by: katleman, thurka ! make/common/Release.gmk Changeset: b6f529117521 Author: katleman Date: 2012-05-16 22:07 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/b6f529117521 Merge Changeset: 47cd90bf0f66 Author: katleman Date: 2012-05-17 06:20 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/47cd90bf0f66 Added tag jdk8-b39 for changeset b6f529117521 ! .hgtags From john.coomes at oracle.com Thu May 17 20:42:05 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 18 May 2012 03:42:05 +0000 Subject: hg: hsx/hotspot-comp/langtools: Added tag jdk8-b39 for changeset a9f547c218d9 Message-ID: <20120518034211.E0040473BA@hg.openjdk.java.net> Changeset: 8b869afd2eb4 Author: katleman Date: 2012-05-17 06:20 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/8b869afd2eb4 Added tag jdk8-b39 for changeset a9f547c218d9 ! .hgtags From roland.westrelin at oracle.com Fri May 18 04:16:05 2012 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Fri, 18 May 2012 13:16:05 +0200 Subject: RFS (XS): 7169934: pow(x, y) or x64 computes incorrect result when x<0 and y is an odd integer Message-ID: <8877CEF5-85A2-47AD-A51A-A1035744780C@oracle.com> http://cr.openjdk.java.net/~roland/7169934/webrev.00/ A last minute code clean-up broke the check for the parity of y in pow(x,y) in debug builds. Roland. From vladimir.kozlov at oracle.com Fri May 18 06:51:02 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 18 May 2012 06:51:02 -0700 Subject: RFS (XS): 7169934: pow(x, y) or x64 computes incorrect result when x<0 and y is an odd integer In-Reply-To: <8877CEF5-85A2-47AD-A51A-A1035744780C@oracle.com> References: <8877CEF5-85A2-47AD-A51A-A1035744780C@oracle.com> Message-ID: <4FB653C6.9040707@oracle.com> Good. Vladimir On 5/18/12 4:16 AM, Roland Westrelin wrote: > http://cr.openjdk.java.net/~roland/7169934/webrev.00/ > > A last minute code clean-up broke the check for the parity of y in pow(x,y) in debug builds. > > Roland. From roland.westrelin at oracle.com Fri May 18 09:05:01 2012 From: roland.westrelin at oracle.com (roland.westrelin at oracle.com) Date: Fri, 18 May 2012 16:05:01 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7167254: Crash on OSX in Enumerator.nextElement() with compressed oops Message-ID: <20120518160506.E83AC473DF@hg.openjdk.java.net> Changeset: 4073d9478a90 Author: roland Date: 2012-05-18 15:50 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/4073d9478a90 7167254: Crash on OSX in Enumerator.nextElement() with compressed oops Summary: null checks in "compressed oops with base" mode may trigger a SIGBUS rather than a SIGSEGV. Reviewed-by: dsamersoff, dcubed, rbackman, kvn ! src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp From vladimir.kozlov at oracle.com Fri May 18 10:10:58 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 18 May 2012 10:10:58 -0700 Subject: Request for review (S): C2 should recognize "obj.getClass() == A.class" code pattern In-Reply-To: References: <6FD39DAC-B2F5-4811-984C-645EED80900D@oracle.com> <06859214-B092-4484-8CB1-879F6D5009EF@oracle.com> Message-ID: <4FB682A2.50008@oracle.com> I finally have time to look on it and it looks good. I will work on it next week (CR, testing, push). Thanks, Vladimir On 5/6/12 7:08 PM, Krystal Mok wrote: > Hi all, > > Updated the patch again, posted at: https://gist.github.com/2622617#file_class_eq_ver_5.patch > Could I get some reviews for this new version, please? And, would anyone sponsor this patch, pleae? > > Per John's suggestion, in Parse::adjust_map_after_if(), I've factored the logic from "int val_in_map" downward into a > new subroutine sharpen_type_after_if(), which handles comparison with constant klass as well as the old cases. I tried a > few times but I just can't find a clean factoring. > > Tested SPECjvm2008 with default arguments on a jvmg build, and it ran okay. > > Regards, > Kris From christian.thalinger at oracle.com Fri May 18 11:05:32 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 18 May 2012 11:05:32 -0700 Subject: RFS (XS): 7169934: pow(x, y) or x64 computes incorrect result when x<0 and y is an odd integer In-Reply-To: <8877CEF5-85A2-47AD-A51A-A1035744780C@oracle.com> References: <8877CEF5-85A2-47AD-A51A-A1035744780C@oracle.com> Message-ID: Looks good. -- Chris On May 18, 2012, at 4:16 AM, Roland Westrelin wrote: > http://cr.openjdk.java.net/~roland/7169934/webrev.00/ > > A last minute code clean-up broke the check for the parity of y in pow(x,y) in debug builds. > > Roland. From christian.thalinger at oracle.com Fri May 18 12:16:06 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 18 May 2012 12:16:06 -0700 Subject: Request for review (XS): crash in C2 when using -XX:+CountCompiledCalls In-Reply-To: <4FB3D205.2020505@oracle.com> References: <4FB3D205.2020505@oracle.com> Message-ID: On May 16, 2012, at 9:12 AM, Vladimir Kozlov wrote: > Kris, > > Changes looks good. I will push it tomorrow. I created: 7170053: crash in C2 when using -XX:+CountCompiledCalls and will push it in a minute. Thanks for the fix. -- Chris > > Thanks, > Vladimir > > On 5/16/12 6:02 AM, Krystal Mok wrote: >> Hi all, >> >> Could I get some reviews for this patch, please? >> https://gist.github.com/2710000#file_count_compiled_calls.patch >> >> Description: >> >> C2 may crash when compiling methods with -XX:+CountCompiledCalls turned on. The cause is >> in Parse::count_compiled_calls(), where it made a TypeInstPtr from a ciMethod: >> >> const TypeInstPtr* addr_type = TypeInstPtr::make(method()); >> >> Since the klass of a ciMethod is a ciMethodKlass, which isn't a ciInstanceKlass, an assertion is hit later in >> Compile::flatten_alias_type(), where it's expecting a TypeInstPtr to have a ciInstanceKlass: >> >> ciInstanceKlass *k = to->klass()->as_instance_klass(); >> >> An example of the crash is available here: https://gist.github.com/2710000 >> In the example, I started a Groovy shell with -XX:+CountCompiledCalls set, and it crashed quickly when compiling >> java.lang.String.charAt(). >> >> The fix is to use TypeOopPtr::make_from_constant(method()) instead of TypeInstPtr::make(method()). >> I did check the hg history, and looks like it's been like this since duke at 0. Wonder if there's any history behind this. >> >> Note that this fix may have to be changed again when methodOopDesc's are moved out of PermGen. >> >> Regards, >> Kris From christian.thalinger at oracle.com Fri May 18 12:19:39 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 18 May 2012 12:19:39 -0700 Subject: Request for review (XS): crash in C2 when using -XX:+CountCompiledCalls In-Reply-To: References: <4FB3D205.2020505@oracle.com> Message-ID: <2A7B00C4-E996-40B5-8CA2-C9D0BE7952C6@oracle.com> On May 18, 2012, at 12:16 PM, Christian Thalinger wrote: > > On May 16, 2012, at 9:12 AM, Vladimir Kozlov wrote: > >> Kris, >> >> Changes looks good. I will push it tomorrow. > > I created: > > 7170053: crash in C2 when using -XX:+CountCompiledCalls > > and will push it in a minute. Thanks for the fix. Here is the webrev (for the record): http://cr.openjdk.java.net/~twisti/7170053/ -- Chris > > -- Chris > >> >> Thanks, >> Vladimir >> >> On 5/16/12 6:02 AM, Krystal Mok wrote: >>> Hi all, >>> >>> Could I get some reviews for this patch, please? >>> https://gist.github.com/2710000#file_count_compiled_calls.patch >>> >>> Description: >>> >>> C2 may crash when compiling methods with -XX:+CountCompiledCalls turned on. The cause is >>> in Parse::count_compiled_calls(), where it made a TypeInstPtr from a ciMethod: >>> >>> const TypeInstPtr* addr_type = TypeInstPtr::make(method()); >>> >>> Since the klass of a ciMethod is a ciMethodKlass, which isn't a ciInstanceKlass, an assertion is hit later in >>> Compile::flatten_alias_type(), where it's expecting a TypeInstPtr to have a ciInstanceKlass: >>> >>> ciInstanceKlass *k = to->klass()->as_instance_klass(); >>> >>> An example of the crash is available here: https://gist.github.com/2710000 >>> In the example, I started a Groovy shell with -XX:+CountCompiledCalls set, and it crashed quickly when compiling >>> java.lang.String.charAt(). >>> >>> The fix is to use TypeOopPtr::make_from_constant(method()) instead of TypeInstPtr::make(method()). >>> I did check the hg history, and looks like it's been like this since duke at 0. Wonder if there's any history behind this. >>> >>> Note that this fix may have to be changed again when methodOopDesc's are moved out of PermGen. >>> >>> Regards, >>> Kris > From vladimir.kozlov at oracle.com Fri May 18 12:40:20 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 18 May 2012 12:40:20 -0700 Subject: Request for review (XS): crash in C2 when using -XX:+CountCompiledCalls In-Reply-To: <2A7B00C4-E996-40B5-8CA2-C9D0BE7952C6@oracle.com> References: <4FB3D205.2020505@oracle.com> <2A7B00C4-E996-40B5-8CA2-C9D0BE7952C6@oracle.com> Message-ID: <4FB6A5A4.9080606@oracle.com> For records, change is good. Vladimir On 5/18/12 12:19 PM, Christian Thalinger wrote: > > On May 18, 2012, at 12:16 PM, Christian Thalinger wrote: > >> >> On May 16, 2012, at 9:12 AM, Vladimir Kozlov wrote: >> >>> Kris, >>> >>> Changes looks good. I will push it tomorrow. >> >> I created: >> >> 7170053: crash in C2 when using -XX:+CountCompiledCalls >> >> and will push it in a minute. Thanks for the fix. > > Here is the webrev (for the record): > > http://cr.openjdk.java.net/~twisti/7170053/ > > -- Chris > >> >> -- Chris >> >>> >>> Thanks, >>> Vladimir >>> >>> On 5/16/12 6:02 AM, Krystal Mok wrote: >>>> Hi all, >>>> >>>> Could I get some reviews for this patch, please? >>>> https://gist.github.com/2710000#file_count_compiled_calls.patch >>>> >>>> Description: >>>> >>>> C2 may crash when compiling methods with -XX:+CountCompiledCalls turned on. The cause is >>>> in Parse::count_compiled_calls(), where it made a TypeInstPtr from a ciMethod: >>>> >>>> const TypeInstPtr* addr_type = TypeInstPtr::make(method()); >>>> >>>> Since the klass of a ciMethod is a ciMethodKlass, which isn't a ciInstanceKlass, an assertion is hit later in >>>> Compile::flatten_alias_type(), where it's expecting a TypeInstPtr to have a ciInstanceKlass: >>>> >>>> ciInstanceKlass *k = to->klass()->as_instance_klass(); >>>> >>>> An example of the crash is available here: https://gist.github.com/2710000 >>>> In the example, I started a Groovy shell with -XX:+CountCompiledCalls set, and it crashed quickly when compiling >>>> java.lang.String.charAt(). >>>> >>>> The fix is to use TypeOopPtr::make_from_constant(method()) instead of TypeInstPtr::make(method()). >>>> I did check the hg history, and looks like it's been like this since duke at 0. Wonder if there's any history behind this. >>>> >>>> Note that this fix may have to be changed again when methodOopDesc's are moved out of PermGen. >>>> >>>> Regards, >>>> Kris >> > From christian.thalinger at oracle.com Fri May 18 16:31:51 2012 From: christian.thalinger at oracle.com (christian.thalinger at oracle.com) Date: Fri, 18 May 2012 23:31:51 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7170053: crash in C2 when using -XX:+CountCompiledCalls Message-ID: <20120518233154.2EA63473FA@hg.openjdk.java.net> Changeset: cdd249497b34 Author: twisti Date: 2012-05-18 12:20 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/cdd249497b34 7170053: crash in C2 when using -XX:+CountCompiledCalls Reviewed-by: kvn, twisti Contributed-by: Krystal Mok ! src/share/vm/opto/doCall.cpp From rednaxelafx at gmail.com Fri May 18 19:42:34 2012 From: rednaxelafx at gmail.com (Krystal Mok) Date: Sat, 19 May 2012 10:42:34 +0800 Subject: Request for review (XS): crash in C2 when using -XX:+CountCompiledCalls In-Reply-To: <4FB6A5A4.9080606@oracle.com> References: <4FB3D205.2020505@oracle.com> <2A7B00C4-E996-40B5-8CA2-C9D0BE7952C6@oracle.com> <4FB6A5A4.9080606@oracle.com> Message-ID: <9FAFA924-9259-4AD6-8CE2-E0160CA822CC@gmail.com> Thanks Chris and Vladimir! Kris On 2012-5-19, at 3:40, Vladimir Kozlov wrote: > For records, change is good. > > Vladimir > > On 5/18/12 12:19 PM, Christian Thalinger wrote: >> >> On May 18, 2012, at 12:16 PM, Christian Thalinger wrote: >> >>> >>> On May 16, 2012, at 9:12 AM, Vladimir Kozlov wrote: >>> >>>> Kris, >>>> >>>> Changes looks good. I will push it tomorrow. >>> >>> I created: >>> >>> 7170053: crash in C2 when using -XX:+CountCompiledCalls >>> >>> and will push it in a minute. Thanks for the fix. >> >> Here is the webrev (for the record): >> >> http://cr.openjdk.java.net/~twisti/7170053/ >> >> -- Chris >> >>> >>> -- Chris >>> >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 5/16/12 6:02 AM, Krystal Mok wrote: >>>>> Hi all, >>>>> >>>>> Could I get some reviews for this patch, please? >>>>> https://gist.github.com/2710000#file_count_compiled_calls.patch >>>>> >>>>> Description: >>>>> >>>>> C2 may crash when compiling methods with -XX:+CountCompiledCalls turned on. The cause is >>>>> in Parse::count_compiled_calls(), where it made a TypeInstPtr from a ciMethod: >>>>> >>>>> const TypeInstPtr* addr_type = TypeInstPtr::make(method()); >>>>> >>>>> Since the klass of a ciMethod is a ciMethodKlass, which isn't a ciInstanceKlass, an assertion is hit later in >>>>> Compile::flatten_alias_type(), where it's expecting a TypeInstPtr to have a ciInstanceKlass: >>>>> >>>>> ciInstanceKlass *k = to->klass()->as_instance_klass(); >>>>> >>>>> An example of the crash is available here: https://gist.github.com/2710000 >>>>> In the example, I started a Groovy shell with -XX:+CountCompiledCalls set, and it crashed quickly when compiling >>>>> java.lang.String.charAt(). >>>>> >>>>> The fix is to use TypeOopPtr::make_from_constant(method()) instead of TypeInstPtr::make(method()). >>>>> I did check the hg history, and looks like it's been like this since duke at 0. Wonder if there's any history behind this. >>>>> >>>>> Note that this fix may have to be changed again when methodOopDesc's are moved out of PermGen. >>>>> >>>>> Regards, >>>>> Kris >>> >> From roland.westrelin at oracle.com Mon May 21 00:39:54 2012 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Mon, 21 May 2012 09:39:54 +0200 Subject: RFS (XS): 7169934: pow(x, y) or x64 computes incorrect result when x<0 and y is an odd integer In-Reply-To: References: <8877CEF5-85A2-47AD-A51A-A1035744780C@oracle.com> Message-ID: <23D51B68-4FCA-42DD-B9BE-439F4E37646E@oracle.com> Thanks Vladimir & Christian. Roland. From roland.westrelin at oracle.com Mon May 21 04:20:18 2012 From: roland.westrelin at oracle.com (roland.westrelin at oracle.com) Date: Mon, 21 May 2012 11:20:18 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7169934: pow(x, y) or x64 computes incorrect result when x<0 and y is an odd integer Message-ID: <20120521112026.9D86A47430@hg.openjdk.java.net> Changeset: e2961d14584b Author: roland Date: 2012-05-21 09:46 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/e2961d14584b 7169934: pow(x,y) or x64 computes incorrect result when x<0 and y is an odd integer Summary: bad test for parity of y in pow(x,y) (c1, interpreter) Reviewed-by: kvn, twisti ! src/cpu/x86/vm/assembler_x86.cpp From john.r.rose at oracle.com Mon May 21 09:29:20 2012 From: john.r.rose at oracle.com (John Rose) Date: Mon, 21 May 2012 09:29:20 -0700 Subject: RFR (M): 7023898: Intrinsify AtomicLongFieldUpdater.getAndIncrement() In-Reply-To: <13AE9B3D-2AB6-4F42-9820-C2DEE87B86D4@oracle.com> References: <13AE9B3D-2AB6-4F42-9820-C2DEE87B86D4@oracle.com> Message-ID: <5E3B4B1B-6336-44B5-996F-74082BAD51D5@oracle.com> On May 15, 2012, at 9:10 AM, Roland Westrelin wrote: > http://cr.openjdk.java.net/~roland/7023898/ The C2 part looks good. I have a few small suggestions. 1. Replace push(cas) by push_node(type, load_store). 2. I don't understand why the (kind = cmpxchg) case doesn't push a result. Does't the original push(cas) do that? 3. In the if/else chain testing 'kind', change the bare 'else' to 'else if (kind ? cmpxchg)' and follow up with 'else ShouldNotReachHere()'. At least put an "assert(kind ? cmpxchg)". This will ease maintenance, in case somebody adds a new case to load_store_kind. 4. Naming: Consider using a more type-like name for load_store_kind, such as LoadStoreKind. Compare ReexecuteState and NodeType enums. Also, the enum names themselves could use a prefix or camel-case, e.g., LS_xadd or _xadd or XAdd. Since the names are private to library_call.cpp, it doesn't matter as much as in other places, but it still improves readability of code that contains the names. (Reason: an all-lower-case simple name like xadd appears at first glance to be a local variable. Manifest constants should look different.) Overall, it is a nicely rounded extension, with good reuse of previously existing code. Thanks! ? John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20120521/b6e7c69b/attachment.html From xerox.time.tech at gmail.com Mon May 21 12:14:13 2012 From: xerox.time.tech at gmail.com (Xin Tong) Date: Mon, 21 May 2012 15:14:13 -0400 Subject: inliner heuristics Message-ID: I am investigating the inliner heuristics in C2 compiler of hotspot. There are a few things i do not get. 1. The inliner heuristics depend on 2 parameters - the call_site_count and the invocation_count. The invocation_count is the number of times the method is executed in the previous tier. i.e. interpreter for tier 1 compilation and tier 1 for tier 2 compilation. But what does call_site_count represent. the number of callsites of this method within the all callers of the method ? It seems it is calculated based on MD0, what is the method data ? 2. Is it true that in theory all methods can be inlined in Java ? how about in the hotspot JVM ? Thanks Xin -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20120521/b80959c6/attachment.html From xerox.time.tech at gmail.com Mon May 21 14:30:44 2012 From: xerox.time.tech at gmail.com (Xin Tong) Date: Mon, 21 May 2012 17:30:44 -0400 Subject: debug in hotspot In-Reply-To: References: Message-ID: On Thu, May 3, 2012 at 9:35 PM, Krystal Mok wrote: > > > On Fri, May 4, 2012 at 8:48 AM, Xin Tong wrote: > >> On Thu, May 3, 2012 at 8:45 PM, Xin Tong >> wrote: >> > On Thu, May 3, 2012 at 8:29 PM, Krystal Mok >> wrote: >> >> On 2012-5-4, at 8:16, Xin Tong wrote: >> >> >> >>> i would like to know how to debug in hotspot, what are some of the >> >>> standard procedures ? Lets say, the hotspot fails to run a Java >> >>> program. a few steps to triage the problem. >> >>> >> >>> 1. disable JIT compilers. hotspot has 2 compilers c1 and c2. they are >> >>> both used if TieredCompilation is enabled. How do I disable both of >> >>> them. >> >> >> >> It's there in the globals.hpp file: -XX:-UseCompiler >> > > I forgot to mention there's a shorter (and better supported) equivalent to > this: -Xint > > >> >> >> >>> 2. if the Java program passes after the JIT is disabled. There is a >> >>> good chance that the problem is cause by the JIT. I want to narrow >> >>> down to a specific method, I can use PrintCompilation to find out all >> >>> the method compiled, but how can I disable one specific method from >> >>> being compiled. >> >> >> >> -XX:CompileCommand='exclude,your/class,yourMethod' >> >> Or an equivalent .hotspot_compiler configuration file. >> >> Read this thread for example (in Chinese): >> http://hllvm.group.iteye.com/group/topic/28201 >> >> By the way, one thing we can do here is to force c1 to compile a >> method. i.e. c2 is more likely to fail than c1 as it does more >> optimizations. how do i force c1 to compile a method ? > > > What platform and version of JDK are you using? > If there's a Client VM for your platform, use that; > If you're using JDK7 or JDK8, try -XX:+TieredCompilation > -XX:TieredStopAtLevel=1, which effectively disables C2 in tiered mode. > Otherwise, if you have to use the Server VM (for instance, on amd64 where > Oracle doesn't provide a Client VM build), and you're using an old version > of JDK6, I'm not sure if there's a way to force compilation with C1. > And, there's no way (yet) to force compilation with C1/C2 on a > per-method granularity. > There is no way to force the compilation with C1/C2 on a per-method granularity. But methods are compiled with C1 and then C2 in a tiered compilation , right ? Xin > > >> and how do i >> know which compiler is used to compile a method in the >> PrintCompilation log or through any other options ? >> > > Please refer to this note: https://gist.github.com/1165804#file_notes.md > I was supposed to put this up in the HotSpotInternals wiki, but somehow I > haven't done it yet...oops. > > - Kris > > >> >> >> >> >>> 3. if i am able to limit down to a specific method, i want to start >> >>> disabling optimizations, is there an option to disable all >> >>> optimizations in the c1 and c2 compilers, or i need to do it manually >> >>> ? >> >>> >> >> >> >> I don't think there's an all-in-one flag to turn all optimizations >> off. At least not for now. >> >> See c1_globals.hpp and c2_globals.hpp to get an idea of what >> optimizations you can turn off. >> >> >> >> - Kris >> >> >> >>> Thanks >> > >> > Thank you very much Kris. This is very helpful. >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20120521/474750cc/attachment.html From xerox.time.tech at gmail.com Mon May 21 15:22:12 2012 From: xerox.time.tech at gmail.com (Xin Tong) Date: Mon, 21 May 2012 18:22:12 -0400 Subject: inliner heuristics In-Reply-To: References: Message-ID: I am also looking at inlining of a polymorphic site. Why is there no guard inserted which encloses the method that is inlined ? The receiver objects could vary. // Try using the type profile. if (call_is_virtual && site_count > 0 && receiver_count > 0) { // The major receiver's count >= TypeProfileMajorReceiverPercent of site_count. bool have_major_receiver = (100.*profile.receiver_prob(0) >= (float)TypeProfileMajorReceiverPercent); ciMethod* receiver_method = NULL; if (have_major_receiver || profile.morphism() == 1 || (profile.morphism() == 2 && UseBimorphicInlining)) { // receiver_method = profile.method(); // Profiles do not suggest methods now. Look it up in the major receiver. // the look up is performed on the profile.receiver(0). The first receiver is the one mostly seen. receiver_method = call_method->resolve_invoke(jvms->method()->holder(), profile.receiver(0)); } if (receiver_method != NULL) { // The single majority receiver sufficiently outweighs the minority. * // Should there be a guard insert to compare the receiver object class with the inlined method class ?* CallGenerator* hit_cg = this->call_generator(receiver_method, vtable_index, !call_is_virtual, jvms, allow_inline, prof_factor); if (hit_cg != NULL) { // Look up second receiver. CallGenerator* next_hit_cg = NULL; ciMethod* next_receiver_method = NULL; if (profile.morphism() == 2 && UseBimorphicInlining) { // XIN TONG, the second virtual call inlined. next_receiver_method = call_method->resolve_invoke(jvms->method()->holder(), profile.receiver(1)); if (next_receiver_method != NULL) { * // Should there be a guard insert to compare the receiver object class with the inlined method class ?* * * next_hit_cg = this->call_generator(next_receiver_method, vtable_index, !call_is_virtual, jvms, allow_inline, prof_factor); if (next_hit_cg != NULL && !next_hit_cg->is_inline() && have_major_receiver && UseOnlyInlinedBimorphic) { // Skip if we can't inline second receiver's method next_hit_cg = NULL; } } On Mon, May 21, 2012 at 3:14 PM, Xin Tong wrote: > I am investigating the inliner heuristics in C2 compiler of hotspot. There > are a few things i do not get. > > 1. The inliner heuristics depend on 2 parameters - the call_site_count and > the invocation_count. The invocation_count is the number of times the > method is executed in the previous tier. i.e. interpreter for tier 1 > compilation and tier 1 for tier 2 compilation. But what does > call_site_count represent. the number of callsites of this method within > the all callers of the method ? It seems it is calculated based on MD0, > what is the method data ? > > 2. Is it true that in theory all methods can be inlined in Java ? how > about in the hotspot JVM ? > > Thanks > > Xin > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20120521/e1b9fe5a/attachment.html From vladimir.kozlov at oracle.com Mon May 21 15:36:15 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 21 May 2012 15:36:15 -0700 Subject: Request for reviews (M): 7170463: C2 should recognize "obj.getClass() == A.class" code pattern Message-ID: <4FBAC35F.6020808@oracle.com> http://cr.openjdk.java.net/~kvn/7170463/webrev 7170463: C2 should recognize "obj.getClass() == A.class" code pattern The idea is to optimize this code pattern: x.getClass() == A.class into x._klass == klassof(A) which shortens the original pattern by 1 load. Tested with NSK, compiler regression tests, CTW. Contributed-by: Krystal Mok From roland.westrelin at oracle.com Tue May 22 01:07:44 2012 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Tue, 22 May 2012 10:07:44 +0200 Subject: RFR (M): 7023898: Intrinsify AtomicLongFieldUpdater.getAndIncrement() In-Reply-To: <5E3B4B1B-6336-44B5-996F-74082BAD51D5@oracle.com> References: <13AE9B3D-2AB6-4F42-9820-C2DEE87B86D4@oracle.com> <5E3B4B1B-6336-44B5-996F-74082BAD51D5@oracle.com> Message-ID: <7C933CB7-09AB-4CFF-A46F-BA53E1A3353D@oracle.com> John, >> http://cr.openjdk.java.net/~roland/7023898/ > > The C2 part looks good. I have a few small suggestions. Thanks for reviewing it. I will implement your suggestions. Roland. From john.r.rose at oracle.com Tue May 22 11:30:07 2012 From: john.r.rose at oracle.com (John Rose) Date: Tue, 22 May 2012 11:30:07 -0700 Subject: Request for reviews (M): 7170463: C2 should recognize "obj.getClass() == A.class" code pattern In-Reply-To: <4FBAC35F.6020808@oracle.com> References: <4FBAC35F.6020808@oracle.com> Message-ID: On May 21, 2012, at 3:36 PM, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/7170463/webrev > > 7170463: C2 should recognize "obj.getClass() == A.class" code pattern > > The idea is to optimize this code pattern: > > x.getClass() == A.class > > into > > x._klass == klassof(A) > > which shortens the original pattern by 1 load. > > Tested with NSK, compiler regression tests, CTW. > > Contributed-by: Krystal Mok Thanks, Kris and Vladimir, for pushing on this, and for dealing with a large number of comments. This new version of the code looks robust and well-structured, except for a couple of small points, which I think are easily addressed. This line: assert(ldk != NULL, "should have found a LoadKlass or LoadNKlass node") could better protect the subsequent code as: assert(ldk != NULL && ldk->is_Load(), "should have found a LoadKlass or LoadNKlass node") (It is unusual, though valid, to say 'tp->isa_instptr() || tp->isa_aryptr()'. This is done twice in the new code. I don't see a better way to go, although I note that ciObject has is_java_ptr, and I thought we used to have TypePtr::isa_javaptr. Perhaps we should put it in type.hpp?) The 'rep = obj / rep = val' stuff at the top of 'sharpen_type_after_if' is reasonable, but I'm uncomfortable with the mixed use of 'rep' and 'val' at the bottom. Redundant information attracts bugs. I would prefer to kill 'val' after 'rep' is defined, perhaps as: debug_only(val = (Node*)badAddress); Later on, only rep should be used. This will fix a probable bug at 'case BoolTest::ne'. Or, better yet, get rid of rep/trep and say: + if (is_klass_cmp) { + tval = gvn.type(obj); + val = obj; + } (If the side effect to the parameters is confusing, call them val0, tval0.) Once this is done, the code for 'case BoolTest::eq' should factor a little bit better. 'tkp' is another bit of redundant information; I would rather see tcon used throughout. This also will allow the 'eq' case to factor better. Perhaps this should be done, to make the treatment of tval/val more consistent: + if (is_klass_cmp) { + tval = gvn.type(obj); + val = obj; + tcon = tcon->is_klassptr()->as_instance_type(); + con = NULL; + } This is stylistic stuff, but it affects bug tail, as in the case of the BoolTest::ne case and any other cases we may add later. ? John From vladimir.kozlov at oracle.com Tue May 22 12:06:47 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 22 May 2012 12:06:47 -0700 Subject: Request for reviews (M): 7170463: C2 should recognize "obj.getClass() == A.class" code pattern In-Reply-To: References: <4FBAC35F.6020808@oracle.com> Message-ID: <4FBBE3C7.2060506@oracle.com> Thank you, John I will try your suggestions. Vladimir John Rose wrote: > On May 21, 2012, at 3:36 PM, Vladimir Kozlov wrote: > >> http://cr.openjdk.java.net/~kvn/7170463/webrev >> >> 7170463: C2 should recognize "obj.getClass() == A.class" code pattern >> >> The idea is to optimize this code pattern: >> >> x.getClass() == A.class >> >> into >> >> x._klass == klassof(A) >> >> which shortens the original pattern by 1 load. >> >> Tested with NSK, compiler regression tests, CTW. >> >> Contributed-by: Krystal Mok > > Thanks, Kris and Vladimir, for pushing on this, and for dealing with a large number of comments. > > This new version of the code looks robust and well-structured, except for a couple of small points, which I think are easily addressed. > > This line: > assert(ldk != NULL, "should have found a LoadKlass or LoadNKlass node") > could better protect the subsequent code as: > assert(ldk != NULL && ldk->is_Load(), "should have found a LoadKlass or LoadNKlass node") > > (It is unusual, though valid, to say 'tp->isa_instptr() || tp->isa_aryptr()'. This is done twice in the new code. I don't see a better way to go, although I note that ciObject has is_java_ptr, and I thought we used to have TypePtr::isa_javaptr. Perhaps we should put it in type.hpp?) > > The 'rep = obj / rep = val' stuff at the top of 'sharpen_type_after_if' is reasonable, but I'm uncomfortable with the mixed use of 'rep' and 'val' at the bottom. Redundant information attracts bugs. I would prefer to kill 'val' after 'rep' is defined, perhaps as: > debug_only(val = (Node*)badAddress); > Later on, only rep should be used. This will fix a probable bug at 'case BoolTest::ne'. > > Or, better yet, get rid of rep/trep and say: > + if (is_klass_cmp) { > + tval = gvn.type(obj); > + val = obj; > + } > (If the side effect to the parameters is confusing, call them val0, tval0.) > > Once this is done, the code for 'case BoolTest::eq' should factor a little bit better. 'tkp' is another bit of redundant information; I would rather see tcon used throughout. This also will allow the 'eq' case to factor better. > > Perhaps this should be done, to make the treatment of tval/val more consistent: > > + if (is_klass_cmp) { > + tval = gvn.type(obj); > + val = obj; > + tcon = tcon->is_klassptr()->as_instance_type(); > + con = NULL; > + } > > This is stylistic stuff, but it affects bug tail, as in the case of the BoolTest::ne case and any other cases we may add later. > > ? John From christian.thalinger at oracle.com Tue May 22 17:35:07 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 22 May 2012 17:35:07 -0700 Subject: Request for reviews (XS): 7170145: C1 doesn't respect the JMM with volatile field loads Message-ID: <83B32D74-8950-4B31-AB43-E778EB0FF0D3@oracle.com> http://cr.openjdk.java.net/~twisti/7170145 7170145: C1 doesn't respect the JMM with volatile field loads Reviewed-by: ValueNumberingVisitor::do_LoadField does not include logic for volatile fields which allows CSE of normal field loads across volatile field loads. That's explicitly prohibited by the JMM. This patch also kills the memory across volatile field stores even it is too strict for now because of volatile field stores and possible future optimizations. src/share/vm/c1/c1_ValueMap.hpp From vladimir.kozlov at oracle.com Tue May 22 18:23:51 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 22 May 2012 18:23:51 -0700 Subject: Request for reviews (XS): 7170145: C1 doesn't respect the JMM with volatile field loads In-Reply-To: <83B32D74-8950-4B31-AB43-E778EB0FF0D3@oracle.com> References: <83B32D74-8950-4B31-AB43-E778EB0FF0D3@oracle.com> Message-ID: <4FBC3C27.70301@oracle.com> Good. Vladimir On 5/22/12 5:35 PM, Christian Thalinger wrote: > http://cr.openjdk.java.net/~twisti/7170145 > > 7170145: C1 doesn't respect the JMM with volatile field loads > Reviewed-by: > > ValueNumberingVisitor::do_LoadField does not include logic for > volatile fields which allows CSE of normal field loads across volatile > field loads. That's explicitly prohibited by the JMM. > > This patch also kills the memory across volatile field stores even it > is too strict for now because of volatile field stores and possible > future optimizations. > > src/share/vm/c1/c1_ValueMap.hpp > From mikael.vidstedt at oracle.com Tue May 22 18:30:26 2012 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Tue, 22 May 2012 18:30:26 -0700 Subject: Request for reviews (XS): 7170145: C1 doesn't respect the JMM with volatile field loads In-Reply-To: <83B32D74-8950-4B31-AB43-E778EB0FF0D3@oracle.com> References: <83B32D74-8950-4B31-AB43-E778EB0FF0D3@oracle.com> Message-ID: <4FBC3DB2.9060005@oracle.com> Two typos: 145 // This is actually too strict and the JMM doesn't requires 146 // this is all cases (e.g. load a; volatile store b; load a) should probably be "JMM doesn't _require_ this _in_ all cases...". Cheers, Mikael On 2012-05-22 17:35, Christian Thalinger wrote: > http://cr.openjdk.java.net/~twisti/7170145 > > 7170145: C1 doesn't respect the JMM with volatile field loads > Reviewed-by: > > ValueNumberingVisitor::do_LoadField does not include logic for > volatile fields which allows CSE of normal field loads across volatile > field loads. That's explicitly prohibited by the JMM. > > This patch also kills the memory across volatile field stores even it > is too strict for now because of volatile field stores and possible > future optimizations. > > src/share/vm/c1/c1_ValueMap.hpp > From christian.thalinger at oracle.com Tue May 22 19:11:15 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 22 May 2012 19:11:15 -0700 Subject: Request for reviews (XS): 7170145: C1 doesn't respect the JMM with volatile field loads In-Reply-To: <4FBC3DB2.9060005@oracle.com> References: <83B32D74-8950-4B31-AB43-E778EB0FF0D3@oracle.com> <4FBC3DB2.9060005@oracle.com> Message-ID: <44076FFB-23C7-4046-9D17-078E5071BED6@oracle.com> On May 22, 2012, at 6:30 PM, Mikael Vidstedt wrote: > > Two typos: > > 145 // This is actually too strict and the JMM doesn't requires > 146 // this is all cases (e.g. load a; volatile store b; load a) > > should probably be "JMM doesn't _require_ this _in_ all cases...". Apparently I had too many versions of that text. Thanks. -- Chris > > Cheers, > Mikael > > > On 2012-05-22 17:35, Christian Thalinger wrote: >> http://cr.openjdk.java.net/~twisti/7170145 >> >> 7170145: C1 doesn't respect the JMM with volatile field loads >> Reviewed-by: >> >> ValueNumberingVisitor::do_LoadField does not include logic for >> volatile fields which allows CSE of normal field loads across volatile >> field loads. That's explicitly prohibited by the JMM. >> >> This patch also kills the memory across volatile field stores even it >> is too strict for now because of volatile field stores and possible >> future optimizations. >> >> src/share/vm/c1/c1_ValueMap.hpp >> > From roland.westrelin at oracle.com Wed May 23 01:49:16 2012 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Wed, 23 May 2012 10:49:16 +0200 Subject: Request for reviews (XS): 7170145: C1 doesn't respect the JMM with volatile field loads In-Reply-To: <83B32D74-8950-4B31-AB43-E778EB0FF0D3@oracle.com> References: <83B32D74-8950-4B31-AB43-E778EB0FF0D3@oracle.com> Message-ID: <1E442844-E4B1-47FA-9D65-24EA981ECC73@oracle.com> Looks ok to me. Roland. From roland.westrelin at oracle.com Wed May 23 07:19:08 2012 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Wed, 23 May 2012 16:19:08 +0200 Subject: RFR (M): 7023898: Intrinsify AtomicLongFieldUpdater.getAndIncrement() In-Reply-To: <5E3B4B1B-6336-44B5-996F-74082BAD51D5@oracle.com> References: <13AE9B3D-2AB6-4F42-9820-C2DEE87B86D4@oracle.com> <5E3B4B1B-6336-44B5-996F-74082BAD51D5@oracle.com> Message-ID: <753BA08C-CAC4-4BD8-95B3-0BAD6401EA33@oracle.com> Hi John, For 1. et 2. below: > 1. Replace push(cas) by push_node(type, load_store). > > 2. I don't understand why the (kind = cmpxchg) case doesn't push a result. Does't the original push(cas) do that? You're commenting this code change: 2866 if ((kind == xchg || kind == xadd) && type == T_LONG) { 2867 push_pair(load_store); 2868 } else { 2869 push(load_store); 2870 } right? Then for 2.: when kind == cmpxchg, then the else part is executed so load_store is pushed as a result. and for 1.: when type is T_LONG for xchg or xadd, a pair is pushed but for cmpxchg a single result is pushed. So push_node wouldn't work, right? > 3. In the if/else chain testing 'kind', change the bare 'else' to 'else if (kind ? cmpxchg)' and follow up with 'else ShouldNotReachHere()'. At least put an "assert(kind ? cmpxchg)". This will ease maintenance, in case somebody adds a new case to load_store_kind. Ok. > 4. Naming: Consider using a more type-like name for load_store_kind, such as LoadStoreKind. Compare ReexecuteState and NodeType enums. Also, the enum names themselves could use a prefix or camel-case, e.g., LS_xadd or _xadd or XAdd. Since the names are private to library_call.cpp, it doesn't matter as much as in other places, but it still improves readability of code that contains the names. (Reason: an all-lower-case simple name like xadd appears at first glance to be a local variable. Manifest constants should look different.) Ok. Roland. From vladimir.kozlov at oracle.com Wed May 23 16:47:00 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 23 May 2012 16:47:00 -0700 Subject: Request for reviews (M): 7170463: C2 should recognize "obj.getClass() == A.class" code pattern In-Reply-To: References: <4FBAC35F.6020808@oracle.com> Message-ID: <4FBD76F4.60503@oracle.com> I updated webrev: http://cr.openjdk.java.net/~kvn/7170463/webrev.01 I found additional issue with original changes. They accidentally removed optimization which replaces LoadKlass node with ConP (klass type) in map. Next code will not be executed: cast = con; // Replace non-constant val by con. New code should do separate map update of object which klass is compared. John Rose wrote: > On May 21, 2012, at 3:36 PM, Vladimir Kozlov wrote: > >> http://cr.openjdk.java.net/~kvn/7170463/webrev >> >> 7170463: C2 should recognize "obj.getClass() == A.class" code pattern >> > This line: > assert(ldk != NULL, "should have found a LoadKlass or LoadNKlass node") > could better protect the subsequent code as: > assert(ldk != NULL && ldk->is_Load(), "should have found a LoadKlass or LoadNKlass node") Done. > > (It is unusual, though valid, to say 'tp->isa_instptr() || tp->isa_aryptr()'. This is done twice in the new code. I don't see a better way to go, although I note that ciObject has is_java_ptr, and I thought we used to have TypePtr::isa_javaptr. Perhaps we should put it in type.hpp?) Base class TypeOopPtr is java pointer type and it currently includes TypeKlassPtr type until PermGen is removed. So for now I leave these checks as it is and late we can replace them with tp->isa_oopptr(). Vladimir > > The 'rep = obj / rep = val' stuff at the top of 'sharpen_type_after_if' is reasonable, but I'm uncomfortable with the mixed use of 'rep' and 'val' at the bottom. Redundant information attracts bugs. I would prefer to kill 'val' after 'rep' is defined, perhaps as: > debug_only(val = (Node*)badAddress); > Later on, only rep should be used. This will fix a probable bug at 'case BoolTest::ne'. > > Or, better yet, get rid of rep/trep and say: > + if (is_klass_cmp) { > + tval = gvn.type(obj); > + val = obj; > + } > (If the side effect to the parameters is confusing, call them val0, tval0.) > > Once this is done, the code for 'case BoolTest::eq' should factor a little bit better. 'tkp' is another bit of redundant information; I would rather see tcon used throughout. This also will allow the 'eq' case to factor better. > > Perhaps this should be done, to make the treatment of tval/val more consistent: > > + if (is_klass_cmp) { > + tval = gvn.type(obj); > + val = obj; > + tcon = tcon->is_klassptr()->as_instance_type(); > + con = NULL; > + } > > This is stylistic stuff, but it affects bug tail, as in the case of the BoolTest::ne case and any other cases we may add later. > > ? John From john.r.rose at oracle.com Wed May 23 22:02:47 2012 From: john.r.rose at oracle.com (John Rose) Date: Wed, 23 May 2012 22:02:47 -0700 Subject: Request for reviews (M): 7170463: C2 should recognize "obj.getClass() == A.class" code pattern In-Reply-To: <4FBD76F4.60503@oracle.com> References: <4FBAC35F.6020808@oracle.com> <4FBD76F4.60503@oracle.com> Message-ID: On May 23, 2012, at 4:47 PM, Vladimir Kozlov wrote: > I updated webrev: > > http://cr.openjdk.java.net/~kvn/7170463/webrev.01 > > I found additional issue with original changes. They accidentally removed optimization which replaces LoadKlass node with ConP (klass type) in map. Next code will not be executed: > > cast = con; // Replace non-constant val by con. > > New code should do separate map update of object which klass is compared. That's fine; I like it. New question: Can the following call return Top? obj_type->join(con_type) E.g., Number x = 5; if (x.getClass() == String.class) System.out.println("fail!"); Perhaps the compare will short-circuit before that happens. If it doesn't, we'll get assertion failures or worse. ? John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20120523/12bd957a/attachment.html From rednaxelafx at gmail.com Thu May 24 01:28:27 2012 From: rednaxelafx at gmail.com (Krystal Mok) Date: Thu, 24 May 2012 16:28:27 +0800 Subject: Request for reviews (M): 7170463: C2 should recognize "obj.getClass() == A.class" code pattern In-Reply-To: References: <4FBAC35F.6020808@oracle.com> <4FBD76F4.60503@oracle.com> Message-ID: Hi Vladimir and John, Thanks for polishing the changes! Comments inline below: On Thu, May 24, 2012 at 1:02 PM, John Rose wrote: > On May 23, 2012, at 4:47 PM, Vladimir Kozlov wrote: > > I updated webrev: > > http://cr.openjdk.java.net/~kvn/7170463/webrev.01 > > I found additional issue with original changes. They accidentally removed > optimization which replaces LoadKlass node with ConP (klass type) in map. > Next code will not be executed: > > cast = con; // Replace non-constant val by con. > > Oops, I didn't notice this assignment handles Longs and Oops too. Thank for the catch! > New code should do separate map update of object which klass is compared. > > > That's fine; I like it. > > Yes, I like it better this way, too. I couldn't get a clean factoring of sharpen_type_after_if() with the new and old code mixed together; now it looks nice. > New question: Can the following call return Top? > obj_type->join(con_type) > > E.g., > Number x = 5; > if (x.getClass() == String.class) > System.out.println("fail!"); > > Perhaps the compare will short-circuit before that happens. If it > doesn't, we'll get assertion failures or worse. > > Maybe we should just do without the join? Thanks, Kris > ? John > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20120524/40ce788d/attachment.html From vladimir.kozlov at oracle.com Thu May 24 10:32:59 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 24 May 2012 10:32:59 -0700 Subject: Request for reviews (M): 7170463: C2 should recognize "obj.getClass() == A.class" code pattern In-Reply-To: References: <4FBAC35F.6020808@oracle.com> <4FBD76F4.60503@oracle.com> Message-ID: <4FBE70CB.1050003@oracle.com> John Rose wrote: > On May 23, 2012, at 4:47 PM, Vladimir Kozlov wrote: > >> I updated webrev: >> >> http://cr.openjdk.java.net/~kvn/7170463/webrev.01 >> >> I found additional issue with original changes. They accidentally >> removed optimization which replaces LoadKlass node with ConP (klass >> type) in map. Next code will not be executed: >> >> cast = con; // Replace non-constant val by con. >> >> New code should do separate map update of object which klass is compared. > > That's fine; I like it. > > New question: Can the following call return Top? > obj_type->join(con_type) Yes, it could but the cast is pinned to True path which is dead (not executed) in such case (we don't change control flow in this code). But current code will assert in TOP case during call to is_oopptr() which is not good: obj_type->join(con_type)->is_oopptr() I am changing this code so it will skip TOP case: const TypeOopPtr* tboth = obj_type->join(con_type)->isa_oopptr(); if (tboth != NULL && tboth != obj_type) { Thanks, Vladimir > > E.g., > Number x = 5; > if (x.getClass() == String.class) > System.out.println("fail!"); > > Perhaps the compare will short-circuit before that happens. If it > doesn't, we'll get assertion failures or worse. > > ? John From john.r.rose at oracle.com Thu May 24 12:22:16 2012 From: john.r.rose at oracle.com (John Rose) Date: Thu, 24 May 2012 12:22:16 -0700 Subject: Request for reviews (M): 7170463: C2 should recognize "obj.getClass() == A.class" code pattern In-Reply-To: <4FBE70CB.1050003@oracle.com> References: <4FBAC35F.6020808@oracle.com> <4FBD76F4.60503@oracle.com> <4FBE70CB.1050003@oracle.com> Message-ID: On May 24, 2012, at 10:32 AM, Vladimir Kozlov wrote: > But current code will assert in TOP case during call to is_oopptr() which is not good: > > obj_type->join(con_type)->is_oopptr() > > I am changing this code so it will skip TOP case: > > const TypeOopPtr* tboth = obj_type->join(con_type)->isa_oopptr(); > if (tboth != NULL && tboth != obj_type) { Yes; it's just another guard for Top. (How many times have we forgotten that guard? :-) ? John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20120524/7f5911ee/attachment.html From john.r.rose at oracle.com Thu May 24 12:23:58 2012 From: john.r.rose at oracle.com (John Rose) Date: Thu, 24 May 2012 12:23:58 -0700 Subject: Request for reviews (M): 7170463: C2 should recognize "obj.getClass() == A.class" code pattern In-Reply-To: References: <4FBAC35F.6020808@oracle.com> <4FBD76F4.60503@oracle.com> Message-ID: <1BA5AD68-A129-4C02-B8CD-0F16583B200F@oracle.com> On May 24, 2012, at 1:28 AM, Krystal Mok wrote: > Maybe we should just do without the join? Kris, the join is important locally to "climb the hill" to a better GVN type assignment; you don't want to lose type information you already have. The join does a set union (normalized by upper bound in lattice) of assertions about the type. There may be assertions unique to either source of information, and we want the output to cover all known assertions. (In the literature the you will often read "meet" where we say "join". But we stand on our heads here in C2. When type domains are narrowed against each other, that is traditionally called a meet. But conversely we can regard the assertion sets over type domains, and those are widened exactly when the value sets are narrowed, hence the name join.) Globally, if you drop assertions on the floor, you may keep climbing to two distinct hilltops, lose confluence, and fail to terminate in the optimizer. Here's a good summary of the global confluence property we rely on: http://en.wikipedia.org/wiki/Abstract_rewriting_system In this particular case, the join ('tboth') may contain every assertion made by obj_type, but we don't want to trust this, because it requires exhaustive knowledge of the C2 type system. In fact, there are cases where obj_type makes a unique contribution, e.g., via instance_id. HTH ? John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20120524/7f82441b/attachment.html From rednaxelafx at gmail.com Thu May 24 15:15:07 2012 From: rednaxelafx at gmail.com (Krystal Mok) Date: Fri, 25 May 2012 06:15:07 +0800 Subject: Request for reviews (M): 7170463: C2 should recognize "obj.getClass() == A.class" code pattern In-Reply-To: <1BA5AD68-A129-4C02-B8CD-0F16583B200F@oracle.com> References: <4FBAC35F.6020808@oracle.com> <4FBD76F4.60503@oracle.com> <1BA5AD68-A129-4C02-B8CD-0F16583B200F@oracle.com> Message-ID: Hi John, Thanks a lot! I added the join() in my patch but I wasn't sure it was nessecary; I debugged through it for a couple of cases and the resulting type seemed to be what I wanted, so I added it. Now I'm getting it :-) Thanks, Kris On 2012-5-25, at 3:23, John Rose wrote: > On May 24, 2012, at 1:28 AM, Krystal Mok wrote: > >> Maybe we should just do without the join? > > > Kris, the join is important locally to "climb the hill" to a better GVN type assignment; you don't want to lose type information you already have. > The join does a set union (normalized by upper bound in lattice) of assertions about the type. There may be assertions unique to either source of information, and we want the output to cover all known assertions. > > (In the literature the you will often read "meet" where we say "join". But we stand on our heads here in C2. When type domains are narrowed against each other, that is traditionally called a meet. But conversely we can regard the assertion sets over type domains, and those are widened exactly when the value sets are narrowed, hence the name join.) > > Globally, if you drop assertions on the floor, you may keep climbing to two distinct hilltops, lose confluence, and fail to terminate in the optimizer. Here's a good summary of the global confluence property we rely on: http://en.wikipedia.org/wiki/Abstract_rewriting_system > > In this particular case, the join ('tboth') may contain every assertion made by obj_type, but we don't want to trust this, because it requires exhaustive knowledge of the C2 type system. In fact, there are cases where obj_type makes a unique contribution, e.g., via instance_id. > > HTH > ? John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20120525/45f67e51/attachment.html From john.coomes at oracle.com Thu May 24 20:36:58 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 25 May 2012 03:36:58 +0000 Subject: hg: hsx/hotspot-comp: Added tag jdk8-b40 for changeset a2b2d435f1d2 Message-ID: <20120525033659.06065474E9@hg.openjdk.java.net> Changeset: 1a8c7c530f8a Author: katleman Date: 2012-05-24 16:15 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/1a8c7c530f8a Added tag jdk8-b40 for changeset a2b2d435f1d2 ! .hgtags From john.coomes at oracle.com Thu May 24 20:37:04 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 25 May 2012 03:37:04 +0000 Subject: hg: hsx/hotspot-comp/corba: Added tag jdk8-b40 for changeset 56d030e5035f Message-ID: <20120525033705.C3F30474EA@hg.openjdk.java.net> Changeset: 113f0d5f0a08 Author: katleman Date: 2012-05-24 16:15 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/corba/rev/113f0d5f0a08 Added tag jdk8-b40 for changeset 56d030e5035f ! .hgtags From john.coomes at oracle.com Thu May 24 20:37:11 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 25 May 2012 03:37:11 +0000 Subject: hg: hsx/hotspot-comp/jaxp: Added tag jdk8-b40 for changeset 9ecfdbd6aed4 Message-ID: <20120525033717.30508474EB@hg.openjdk.java.net> Changeset: 6f5c0e17415d Author: katleman Date: 2012-05-24 16:15 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxp/rev/6f5c0e17415d Added tag jdk8-b40 for changeset 9ecfdbd6aed4 ! .hgtags From john.coomes at oracle.com Thu May 24 20:37:23 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 25 May 2012 03:37:23 +0000 Subject: hg: hsx/hotspot-comp/jaxws: Added tag jdk8-b40 for changeset 09a0ddda03cb Message-ID: <20120525033728.22A59474ED@hg.openjdk.java.net> Changeset: f2072b164b05 Author: katleman Date: 2012-05-24 16:15 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxws/rev/f2072b164b05 Added tag jdk8-b40 for changeset 09a0ddda03cb ! .hgtags From john.coomes at oracle.com Thu May 24 20:38:34 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 25 May 2012 03:38:34 +0000 Subject: hg: hsx/hotspot-comp/jdk: 71 new changesets Message-ID: <20120525035159.8815E474F8@hg.openjdk.java.net> Changeset: 7c4eed4b6c19 Author: bae Date: 2012-05-21 14:04 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/7c4eed4b6c19 7124400: [macosx] CGraphicsDevice.getConfigurations() returns reference to member (does not copy configs) Reviewed-by: anthony, kizune ! src/macosx/classes/sun/awt/CGraphicsDevice.java ! test/java/awt/GraphicsDevice/CloneConfigsTest.java Changeset: 416b3a498e71 Author: bae Date: 2012-05-21 14:53 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/416b3a498e71 7154088: [macosx] Regression: Component.createImage do not inherits component attributes Reviewed-by: art, kizune ! src/macosx/classes/sun/lwawt/LWComponentPeer.java Changeset: 1b90a0113359 Author: lana Date: 2012-05-21 11:20 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/1b90a0113359 Merge Changeset: c31eeeda3ed1 Author: serb Date: 2012-05-03 18:29 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/c31eeeda3ed1 7160623: [macosx] Editable TextArea/TextField are blocking GUI applications from exit Reviewed-by: anthony, art ! src/macosx/classes/sun/lwawt/LWComponentPeer.java ! src/macosx/classes/sun/lwawt/LWTextComponentPeer.java Changeset: a420895ee2c3 Author: leonidr Date: 2012-05-03 19:22 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/a420895ee2c3 7124376: [macosx] Modal dialog lost focus Reviewed-by: anthony ! src/macosx/classes/sun/lwawt/LWWindowPeer.java ! src/macosx/classes/sun/lwawt/PlatformWindow.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformEmbeddedFrame.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java ! src/macosx/native/sun/awt/AWTView.m ! src/macosx/native/sun/awt/AWTWindow.h ! src/macosx/native/sun/awt/AWTWindow.m Changeset: 95c8b63a3c47 Author: kizune Date: 2012-05-03 21:54 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/95c8b63a3c47 7148289: [macosx] Deadlock in sun.lwawt.macosx.CWrapper$NSScreen.visibleFrame Reviewed-by: leonidr ! src/macosx/classes/sun/lwawt/macosx/CToolkitThreadBlockedHandler.java ! src/macosx/classes/sun/lwawt/macosx/LWCToolkit.java ! src/macosx/native/sun/awt/LWCToolkit.m Changeset: a714e2e2b257 Author: alexsch Date: 2012-05-04 13:15 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/a714e2e2b257 7024963: Notepad demo: remove non-translatable resources from Notepad.properties file Reviewed-by: rupashka ! src/share/demo/jfc/Notepad/Notepad.java ! src/share/demo/jfc/Notepad/resources/Notepad.properties + src/share/demo/jfc/Notepad/resources/system.properties Changeset: 4cc873e28c78 Author: bagiras Date: 2012-05-04 18:42 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/4cc873e28c78 7146237: closed/java/awt/Focus/SetFocusTraversalKeysTest/SetFocusTraversalTest.html failed since 1.8.0b19 Reviewed-by: art, anthony ! src/share/classes/java/awt/Component.java ! src/share/classes/java/awt/Container.java ! src/share/classes/java/awt/KeyboardFocusManager.java ! src/share/classes/javax/swing/JComponent.java Changeset: 0feee4541f67 Author: serb Date: 2012-05-04 21:25 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/0feee4541f67 7147055: [macosx] Cursors are changing over a blocked window; also blinking Reviewed-by: art, kizune ! src/macosx/classes/sun/lwawt/LWCursorManager.java Changeset: 912e666b4e1d Author: serb Date: 2012-05-10 20:05 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/912e666b4e1d 7080109: Dialog.show() lacks doPrivileged() to access system event queue Reviewed-by: art, anthony ! src/share/classes/java/awt/Dialog.java + test/java/awt/Dialog/ModalDialogPermission/ModalDialogPermission.java + test/java/awt/Dialog/ModalDialogPermission/java.policy Changeset: 18842bb6676a Author: lana Date: 2012-05-10 11:47 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/18842bb6676a Merge - src/macosx/bin/amd64/jvm.cfg - src/share/classes/sun/security/action/LoadLibraryAction.java - test/tools/pack200/dyn.jar - test/tools/pack200/pack200-verifier/src/xmlkit/ClassSyntax.java - test/tools/pack200/pack200-verifier/src/xmlkit/ClassWriter.java - test/tools/pack200/pack200-verifier/src/xmlkit/InstructionAssembler.java - test/tools/pack200/pack200-verifier/src/xmlkit/InstructionSyntax.java Changeset: 4f39a13e74c6 Author: anthony Date: 2012-05-11 16:11 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/4f39a13e74c6 7166437: [macosx] Support for Window.Type.UTILITY on the Mac Summary: Apply the native UTILITY style for UTILITY Java windows Reviewed-by: art ! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java Changeset: 689c0cd214e8 Author: anthony Date: 2012-05-11 20:37 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/689c0cd214e8 7149062: [macosx] dock menu don't show available frames Summary: Inherit from either NSWindow for normal windows or NSPanel for utility windows Reviewed-by: skovatch, swingler ! src/macosx/native/sun/awt/AWTView.m ! src/macosx/native/sun/awt/AWTWindow.h ! src/macosx/native/sun/awt/AWTWindow.m Changeset: 3b8635e357e9 Author: alexsch Date: 2012-05-12 12:01 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/3b8635e357e9 7024965: Stylepad demo: remove non-translatable resources from Stylepad.properties file Reviewed-by: alexp ! src/share/demo/jfc/Notepad/Notepad.java + src/share/demo/jfc/Notepad/resources/NotepadSystem.properties - src/share/demo/jfc/Notepad/resources/system.properties Changeset: cc8d1cc533bf Author: alexp Date: 2012-05-12 17:46 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/cc8d1cc533bf 7149005: [macosx] Java Control Panel's UI controls are distorted when draging scroll bar. Reviewed-by: serb ! src/macosx/classes/com/apple/laf/AquaButtonLabeledUI.java Changeset: 69301efaac91 Author: ant Date: 2012-05-12 18:50 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/69301efaac91 7110683: Issues with some KeyboardFocusManager method Reviewed-by: ahgross ! src/share/classes/java/awt/Component.java ! src/share/classes/java/awt/DefaultKeyboardFocusManager.java ! src/share/classes/java/awt/KeyboardFocusManager.java ! src/share/classes/java/awt/Window.java Changeset: 28ec5b811aa2 Author: dcherepanov Date: 2012-05-15 15:04 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/28ec5b811aa2 7168550: [macosx] duplicate OGL context state changes related to vertex cache Reviewed-by: bae, swingler ! src/macosx/native/sun/java2d/opengl/CGLSurfaceData.m ! src/share/native/sun/java2d/opengl/OGLContext.h ! src/share/native/sun/java2d/opengl/OGLTextRenderer.c ! src/share/native/sun/java2d/opengl/OGLVertexCache.c ! src/share/native/sun/java2d/opengl/OGLVertexCache.h Changeset: cad0bb1a9bdb Author: dcherepanov Date: 2012-05-16 13:15 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/cad0bb1a9bdb 7124337: [macosx] FileDialog fails to select multiple files Reviewed-by: anthony, swingler ! src/macosx/classes/sun/lwawt/macosx/CFileDialog.java ! src/macosx/native/sun/awt/CFileDialog.h ! src/macosx/native/sun/awt/CFileDialog.m ! src/share/classes/java/awt/FileDialog.java ! src/share/classes/sun/awt/AWTAccessor.java ! src/solaris/classes/sun/awt/X11/GtkFileDialogPeer.java ! src/solaris/classes/sun/awt/X11/XFileDialogPeer.java ! src/windows/classes/sun/awt/windows/WFileDialogPeer.java Changeset: 7c0b390ab5f9 Author: anthony Date: 2012-05-16 14:28 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/7c0b390ab5f9 7168851: [macosx] Netbeans crashes in CImage.nativeCreateNSImageFromArray Summary: Eliminate unnecessary -release call Reviewed-by: dcherepanov ! src/macosx/native/sun/awt/CImage.m Changeset: 3c819d638e36 Author: alexsch Date: 2012-05-16 16:27 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/3c819d638e36 7169226: NLS: Please change the mnemonic assignment system for windows and motif properties Reviewed-by: rupashka ! src/share/classes/com/sun/java/swing/plaf/motif/resources/motif.properties ! src/share/classes/com/sun/java/swing/plaf/motif/resources/motif_de.properties ! src/share/classes/com/sun/java/swing/plaf/motif/resources/motif_es.properties ! src/share/classes/com/sun/java/swing/plaf/motif/resources/motif_fr.properties ! src/share/classes/com/sun/java/swing/plaf/motif/resources/motif_it.properties ! src/share/classes/com/sun/java/swing/plaf/motif/resources/motif_ja.properties ! src/share/classes/com/sun/java/swing/plaf/motif/resources/motif_ko.properties ! src/share/classes/com/sun/java/swing/plaf/motif/resources/motif_pt_BR.properties ! src/share/classes/com/sun/java/swing/plaf/motif/resources/motif_sv.properties ! src/share/classes/com/sun/java/swing/plaf/motif/resources/motif_zh_CN.properties ! src/share/classes/com/sun/java/swing/plaf/motif/resources/motif_zh_TW.properties ! src/share/classes/com/sun/java/swing/plaf/windows/resources/windows.properties ! src/share/classes/com/sun/java/swing/plaf/windows/resources/windows_de.properties ! src/share/classes/com/sun/java/swing/plaf/windows/resources/windows_es.properties ! src/share/classes/com/sun/java/swing/plaf/windows/resources/windows_fr.properties ! src/share/classes/com/sun/java/swing/plaf/windows/resources/windows_it.properties ! src/share/classes/com/sun/java/swing/plaf/windows/resources/windows_ja.properties ! src/share/classes/com/sun/java/swing/plaf/windows/resources/windows_ko.properties ! src/share/classes/com/sun/java/swing/plaf/windows/resources/windows_pt_BR.properties ! src/share/classes/com/sun/java/swing/plaf/windows/resources/windows_sv.properties ! src/share/classes/com/sun/java/swing/plaf/windows/resources/windows_zh_CN.properties ! src/share/classes/com/sun/java/swing/plaf/windows/resources/windows_zh_TW.properties Changeset: 19edcc438203 Author: alexsch Date: 2012-05-16 18:11 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/19edcc438203 7158928: [macosx] NLS: Please change the mnemonic assignment system Reviewed-by: rupashka, serb ! make/com/apple/osxui/Makefile ! make/common/internal/Resources.gmk ! src/macosx/classes/com/apple/laf/AquaLookAndFeel.java ! src/macosx/classes/com/apple/laf/resources/aqua.properties Changeset: 731ee59c6ba2 Author: alexsch Date: 2012-05-17 14:27 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/731ee59c6ba2 7148281: [macosx] JTabbedPane tabs with HTML text do not render correctly Reviewed-by: kizune ! src/macosx/classes/com/apple/laf/AquaTabbedPaneUI.java Changeset: f9217bd87199 Author: rupashka Date: 2012-05-17 15:41 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/f9217bd87199 7166322: closed/javax/swing/text/html/HTMLEditorKit/4242228/bug4242228.java failed since 1.8.0b36 Reviewed-by: alexsch + test/javax/swing/text/html/HTMLEditorKit/4242228/bug4242228.java Changeset: c00d6508afce Author: ant Date: 2012-05-17 21:27 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/c00d6508afce 7142565: [macosx] Many special keys processed twice in text fields Summary: forward port from 7u4 Reviewed-by: anthony ! src/macosx/native/sun/awt/AWTView.m Changeset: 17c5e1a12965 Author: ant Date: 2012-05-17 21:31 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/17c5e1a12965 7154072: [macosx] swallowing key events Summary: forward posrt from 7u4 Reviewed-by: anthony ! src/macosx/native/sun/awt/AWTView.m Changeset: ef77fa799b34 Author: ant Date: 2012-05-17 21:48 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/ef77fa799b34 7125044: [macosx] Test failure because Component.transferFocus() works differently in applet and application. Summary: forward port from 7u4 Reviewed-by: art ! src/share/classes/java/awt/Dialog.java ! src/share/classes/java/awt/Frame.java ! src/share/classes/java/awt/Window.java ! src/share/classes/javax/swing/JApplet.java ! src/share/classes/javax/swing/JDialog.java ! src/share/classes/javax/swing/JFrame.java ! src/share/classes/javax/swing/JInternalFrame.java ! src/share/classes/javax/swing/JWindow.java ! src/share/classes/javax/swing/UIManager.java ! src/share/classes/sun/awt/SunToolkit.java + test/java/awt/Focus/FocusTraversalPolicy/InitialFTP.java + test/java/awt/Focus/FocusTraversalPolicy/InitialFTP_AWT.java + test/java/awt/Focus/FocusTraversalPolicy/InitialFTP_Swing.java + test/java/awt/event/KeyEvent/SwallowKeyEvents/SwallowKeyEvents.java Changeset: 5976b5848554 Author: ant Date: 2012-05-17 22:10 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/5976b5848554 7145768: [macosx] Regression: failure in b11 of ModalDialogInFocusEventTest Summary: forward port from 7u4 Reviewed-by: art ! src/macosx/classes/sun/lwawt/LWComponentPeer.java ! src/macosx/classes/sun/lwawt/LWWindowPeer.java Changeset: 1d75ff45586e Author: ant Date: 2012-05-17 22:21 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/1d75ff45586e 7145827: [macosx] JCK failure in b11: FocusableWindow3 Summary: forward posrt from 7u4 Reviewed-by: art ! src/macosx/classes/sun/lwawt/LWWindowPeer.java Changeset: 2eca75e0a063 Author: dcherepanov Date: 2012-05-18 19:39 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/2eca75e0a063 7156191: [macosx] Can't type into applet demos in Pivot Reviewed-by: art ! src/macosx/classes/sun/lwawt/macosx/CEmbeddedFrame.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformResponder.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformView.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java Changeset: 1ee12bca4823 Author: rupashka Date: 2012-05-21 18:55 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/1ee12bca4823 7168144: No appropriate CCC request for changes introduced by 7154030 Reviewed-by: alexsch ! src/share/classes/javax/swing/JComponent.java Changeset: 967b38bfd5c1 Author: ant Date: 2012-05-22 01:12 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/967b38bfd5c1 7170427: setGlobalCurrentFocusCycleRoot unexpectedly throws SecurityException Reviewed-by: art ! src/share/classes/java/awt/Component.java ! src/share/classes/java/awt/Container.java ! src/share/classes/java/awt/KeyboardFocusManager.java Changeset: 5b2095d7a60b Author: lana Date: 2012-05-21 11:41 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/5b2095d7a60b Merge ! src/macosx/classes/sun/lwawt/LWComponentPeer.java Changeset: bb2cefc89bc0 Author: forax Date: 2012-05-02 20:01 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/bb2cefc89bc0 7165102: Only run assertion on Integer autoboxing cache size once Reviewed-by: darcy, alanb ! src/share/classes/java/lang/Integer.java Changeset: 531ebfd8eb65 Author: jgish Date: 2012-05-02 21:46 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/531ebfd8eb65 7160714: Strange or obsolete @see tags in some exception java.util javadoc Reviewed-by: mduigou, dholmes, alanb ! src/share/classes/java/util/NoSuchElementException.java Changeset: 4580652d9828 Author: lancea Date: 2012-05-04 16:00 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/4580652d9828 7166598: FilteredRowSetImpl can result in Invalid Cursor Position Reviewed-by: lancea Contributed-by: Knut Anders Hatlen ! src/share/classes/com/sun/rowset/FilteredRowSetImpl.java Changeset: 41d3f7509e00 Author: xuelei Date: 2012-05-04 17:28 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/41d3f7509e00 7153184: NullPointerException when calling SSLEngineImpl.getSupportedCipherSuites Reviewed-by: weijun ! src/share/classes/sun/security/ssl/SSLContextImpl.java Changeset: 62557a1336c0 Author: zhouyx Date: 2012-05-07 16:43 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/62557a1336c0 7166048: Remove the embeded epoll data structure. Reviewed-by: alanb ! src/solaris/native/sun/nio/ch/EPollArrayWrapper.c Changeset: b26c04717735 Author: robm Date: 2012-05-07 13:34 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/b26c04717735 7166687: InetAddress.getLocalHost().getHostName() returns FQDN Reviewed-by: chegar ! src/solaris/native/java/net/Inet6AddressImpl.c Changeset: 48513d156965 Author: dholmes Date: 2012-05-08 02:59 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/48513d156965 7103570: AtomicIntegerFieldUpdater does not work when SecurityManager is installed Summary: Perform class.getField inside a doPrivileged block Reviewed-by: chegar, psandoz ! src/share/classes/java/util/concurrent/atomic/AtomicIntegerFieldUpdater.java ! src/share/classes/java/util/concurrent/atomic/AtomicLongFieldUpdater.java ! src/share/classes/java/util/concurrent/atomic/AtomicReferenceFieldUpdater.java + test/java/util/concurrent/atomic/AtomicUpdaters.java Changeset: af209a223b6b Author: sherman Date: 2012-05-08 10:57 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/af209a223b6b 7014640: To add a metachar \R for line ending and character classes for vertical/horizontal ws \v \V \h \H Summary: added propsoed constructs Reviewed-by: alanb ! src/share/classes/java/util/regex/Pattern.java ! test/java/util/regex/RegExTest.java Changeset: 1ece20885be4 Author: sherman Date: 2012-05-08 11:16 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/1ece20885be4 7157656: (zipfs) SeekableByteChannel to entry in zip file always reports its position as 0 Summary: updated SeekableByteChannel.read() to count the bytes read correctly Reviewed-by: sherman Contributed-by: paul.sandoz at oracle.com ! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipFileSystem.java ! test/demo/zipfs/ZipFSTester.java ! test/demo/zipfs/basic.sh Changeset: fbf98cbd2e6b Author: xuelei Date: 2012-05-08 17:56 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/fbf98cbd2e6b 7167092: Need to put the return clause in the synchronized block Summary: a regression fix for bug 7153184 Reviewed-by: wetmore ! src/share/classes/sun/security/ssl/SSLContextImpl.java Changeset: 0f63f3390ac9 Author: xuelei Date: 2012-05-08 18:08 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/0f63f3390ac9 7166570: JSSE certificate validation has started to fail for certificate chains Reviewed-by: wetmore ! src/share/classes/sun/security/validator/SimpleValidator.java + test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/BasicConstraints.java Changeset: abb63b7357a1 Author: luchsh Date: 2012-05-09 11:19 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/abb63b7357a1 7165722: Invalid path in MemoryMonitor demo's README.txt Reviewed-by: alanb, sla ! src/share/demo/management/MemoryMonitor/README.txt Changeset: 5e8caf6984f5 Author: ksrini Date: 2012-05-09 07:28 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/5e8caf6984f5 7166955: (pack200) JNI_GetCreatedJavaVMs needs additional checking Reviewed-by: alanb, dholmes, ksrini Contributed-by: youdwei at linux.vnet.ibm.com ! src/share/native/com/sun/java/util/jar/pack/jni.cpp Changeset: 59121a4c71c6 Author: khazra Date: 2012-05-09 11:14 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/59121a4c71c6 7165118: (prefs) AbstractPreferences.remove(null) does not throw NPE Summary: Insert null argument check in AbstractPreferences.remove() Reviewed-by: dholmes, chegar, alanb ! src/share/classes/java/util/prefs/AbstractPreferences.java ! test/java/util/prefs/RemoveNullKeyCheck.java Changeset: 6438f1277df6 Author: wetmore Date: 2012-05-09 16:33 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/6438f1277df6 7167362: SecureRandom.init should be converted, amendment to 7084245 Reviewed-by: sherman ! src/share/classes/sun/security/provider/SecureRandom.java Changeset: 5152c832745a Author: khazra Date: 2012-05-09 16:55 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/5152c832745a 7096436: (sc) SocketChannel.connect fails on Windows 8 when channel configured non-blocking Summary: Set localAddress only when connection is established Reviewed-by: alanb ! src/share/classes/sun/nio/ch/SocketChannelImpl.java Changeset: fdf5e15293e6 Author: coffeys Date: 2012-05-10 10:45 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/fdf5e15293e6 7163470: Build fails if javax.crypto src files not present Reviewed-by: valeriep ! make/com/oracle/security/ucrypto/Makefile ! make/common/shared/Defs-java.gmk ! make/sun/security/ec/Makefile ! make/sun/security/mscapi/Makefile ! make/sun/security/pkcs11/Makefile ! makefiles/com/oracle/security/ucrypto/Makefile ! makefiles/common/shared/Defs-java.gmk ! makefiles/sun/security/ec/Makefile ! makefiles/sun/security/mscapi/Makefile ! makefiles/sun/security/pkcs11/Makefile Changeset: 3e3017eba8ac Author: valeriep Date: 2012-05-08 17:57 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/3e3017eba8ac 4963723: Implement SHA-224 Summary: Add support for SHA-224, SHA224withRSA, SHA224withECDSA, HmacSHA224 and OAEPwithSHA-224AndMGF1Padding. Reviewed-by: vinnie ! src/share/classes/com/sun/crypto/provider/HmacCore.java ! src/share/classes/com/sun/crypto/provider/HmacMD5.java ! src/share/classes/com/sun/crypto/provider/HmacPKCS12PBESHA1.java ! src/share/classes/com/sun/crypto/provider/HmacSHA1.java ! src/share/classes/com/sun/crypto/provider/KeyGeneratorCore.java ! src/share/classes/com/sun/crypto/provider/OAEPParameters.java ! src/share/classes/com/sun/crypto/provider/SunJCE.java ! src/share/classes/java/security/spec/MGF1ParameterSpec.java ! src/share/classes/java/security/spec/PSSParameterSpec.java ! src/share/classes/sun/security/ec/ECDSASignature.java ! src/share/classes/sun/security/ec/SunECEntries.java ! src/share/classes/sun/security/pkcs11/P11Digest.java ! src/share/classes/sun/security/pkcs11/P11Mac.java ! src/share/classes/sun/security/pkcs11/P11Signature.java ! src/share/classes/sun/security/pkcs11/SunPKCS11.java ! src/share/classes/sun/security/pkcs11/wrapper/Functions.java ! src/share/classes/sun/security/provider/DigestBase.java ! src/share/classes/sun/security/provider/MD2.java ! src/share/classes/sun/security/provider/MD4.java ! src/share/classes/sun/security/provider/MD5.java ! src/share/classes/sun/security/provider/SHA.java ! src/share/classes/sun/security/provider/SHA2.java ! src/share/classes/sun/security/provider/SHA5.java ! src/share/classes/sun/security/provider/SunEntries.java ! src/share/classes/sun/security/rsa/RSASignature.java ! src/share/classes/sun/security/rsa/SunRsaSignEntries.java ! src/share/classes/sun/security/x509/AlgorithmId.java ! src/windows/classes/sun/security/mscapi/RSASignature.java ! src/windows/classes/sun/security/mscapi/SunMSCAPI.java ! test/com/sun/crypto/provider/Cipher/RSA/TestOAEP.java ! test/com/sun/crypto/provider/Cipher/RSA/TestOAEPParameterSpec.java ! test/com/sun/crypto/provider/Cipher/RSA/TestOAEPWithParams.java ! test/com/sun/crypto/provider/KeyGenerator/Test4628062.java ! test/com/sun/crypto/provider/Mac/MacClone.java ! test/com/sun/crypto/provider/Mac/MacKAT.java ! test/sun/security/mscapi/SignUsingNONEwithRSA.java ! test/sun/security/mscapi/SignUsingSHA2withRSA.java ! test/sun/security/pkcs11/MessageDigest/DigestKAT.java ! test/sun/security/pkcs11/MessageDigest/TestCloning.java ! test/sun/security/pkcs11/Signature/TestRSAKeyLength.java ! test/sun/security/pkcs11/ec/TestCurves.java ! test/sun/security/pkcs11/rsa/TestKeyPairGenerator.java ! test/sun/security/pkcs11/rsa/TestSignatures.java ! test/sun/security/provider/MessageDigest/DigestKAT.java ! test/sun/security/provider/MessageDigest/Offsets.java ! test/sun/security/provider/MessageDigest/TestSHAClone.java ! test/sun/security/rsa/TestKeyPairGenerator.java ! test/sun/security/rsa/TestSignatures.java Changeset: dfce31760a2f Author: valeriep Date: 2012-05-08 18:57 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/dfce31760a2f Merge Changeset: 9f8210f23773 Author: valeriep Date: 2012-05-10 11:19 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/9f8210f23773 Merge Changeset: c5a07e3dca63 Author: youdwei Date: 2012-05-11 16:20 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/c5a07e3dca63 7163874: InetAddress.isReachable should support pinging 0.0.0.0 Reviewed-by: alanb, chegar ! src/share/native/java/net/net_util.h ! src/solaris/native/java/net/Inet4AddressImpl.c ! src/solaris/native/java/net/Inet6AddressImpl.c ! src/solaris/native/java/net/net_util_md.c + test/java/net/Inet4Address/PingThis.java Changeset: 3e83229a3779 Author: coffeys Date: 2012-05-11 10:09 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/3e83229a3779 7167359: (tz) SEGV on solaris if TZ variable not set Reviewed-by: okutsu ! src/solaris/native/java/util/TimeZone_md.c Changeset: 944676ef3c58 Author: mduigou Date: 2012-05-11 11:31 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/944676ef3c58 7071826: Avoid benign race condition in initialization of UUID Summary: Avoids mostly benign but sometimes expensive race condition on initialization of UUID.numberGenerator which is used by UUID.randomUUID() Reviewed-by: alanb, chegar ! src/share/classes/java/util/UUID.java ! test/java/util/UUID/UUIDTest.java Changeset: 85d7677a75bf Author: lana Date: 2012-05-11 12:53 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/85d7677a75bf Merge Changeset: f131d4361faf Author: olagneau Date: 2012-05-11 14:13 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/f131d4361faf 7144861: speed up RMI activation tests Reviewed-by: alanb, smarks, dholmes, dmocek ! test/java/rmi/activation/checkusage/CheckUsage.java ! test/java/rmi/testlibrary/ActivationLibrary.java ! test/java/rmi/testlibrary/JavaVM.java ! test/java/rmi/testlibrary/RMID.java ! test/java/rmi/testlibrary/StreamPipe.java ! test/sun/rmi/runtime/Log/6409194/NoConsoleOutput.java Changeset: df3152beef2f Author: xuelei Date: 2012-05-14 07:26 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/df3152beef2f 7167988: PKIX CertPathBuilder in reverse mode doesn't work if more than one trust anchor is specified Reviewed-by: mullan ! src/share/classes/sun/security/provider/certpath/SunCertPathBuilder.java + test/sun/security/provider/certpath/ReverseBuilder/ReverseBuild.java Changeset: df33f5f750ec Author: dsamersoff Date: 2012-05-15 16:46 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/df33f5f750ec 7164191: properties.putAll API may fail with ConcurrentModifcationException on multi-thread scenario Reviewed-by: dholmes, sla Contributed-by: Deven You ! src/share/classes/sun/management/Agent.java + test/sun/management/AgentCMETest.java Changeset: 9a18e318f95a Author: khazra Date: 2012-05-15 11:51 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/9a18e318f95a 7164636: (prefs) Cleanup src/macosx/classes/java/util/prefs Summary: Remove rawtype usages and other code cleanup Reviewed-by: chegar, briangoetz ! src/macosx/classes/java/util/prefs/MacOSXPreferences.java ! src/macosx/classes/java/util/prefs/MacOSXPreferencesFactory.java ! src/macosx/classes/java/util/prefs/MacOSXPreferencesFile.java Changeset: 332bebb463d1 Author: alanb Date: 2012-05-16 12:43 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/332bebb463d1 7168505: (bf) MappedByteBuffer.load does not load buffer's content into memory Reviewed-by: mduigou, forax ! src/share/classes/java/nio/MappedByteBuffer.java Changeset: ce165aa48dcb Author: dcubed Date: 2012-05-17 06:26 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/ce165aa48dcb 7168520: No jdk8 TL Nightly linux builds due to broken link in b39-2012-05-13_231 Summary: ZIP libjsig.debuginfo links into libjsig.diz files since aurora doesn't like dangling symlinks Reviewed-by: katleman ! make/java/redist/Makefile Changeset: 178c480998b1 Author: robm Date: 2012-05-17 22:42 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/178c480998b1 7168110: Misleading jstack error message Reviewed-by: alanb, dsamersoff ! src/windows/native/sun/tools/attach/WindowsVirtualMachine.c Changeset: 9fe6ebbe5895 Author: xuelei Date: 2012-05-17 21:59 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/9fe6ebbe5895 7145960: sun/security/mscapi/ShortRSAKey1024.sh failing on windows Reviewed-by: vinnie, wetmore ! test/sun/security/mscapi/ShortRSAKey1024.sh ! test/sun/security/mscapi/ShortRSAKey512.sh ! test/sun/security/mscapi/ShortRSAKey768.sh Changeset: af1030be726a Author: valeriep Date: 2012-05-18 12:29 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/af1030be726a 7169496: Problem with the SHA-224 support for SunMSCAPI provider Summary: Remove SHA224withRSA signature from SunMSCAPI provider due to lack of windows support. Reviewed-by: vinnie ! src/windows/classes/sun/security/mscapi/RSASignature.java ! src/windows/classes/sun/security/mscapi/SunMSCAPI.java ! test/sun/security/mscapi/SignUsingNONEwithRSA.java ! test/sun/security/mscapi/SignUsingSHA2withRSA.java Changeset: 72af24348b2b Author: weijun Date: 2012-05-21 15:40 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/72af24348b2b 7170308: timing error in the krb5 test SSL.java Reviewed-by: xuelei ! test/sun/security/krb5/auto/SSL.java Changeset: 9cb304dd71d4 Author: alanb Date: 2012-05-21 10:41 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/9cb304dd71d4 7170203: TEST_BUG: test/java/nio/MappedByteBuffer/Truncate.java failing intermittently Reviewed-by: chegar ! test/java/nio/MappedByteBuffer/Truncate.java Changeset: f109feb13698 Author: ksrini Date: 2012-05-21 09:40 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/f109feb13698 7170087: tools/launcher/Arrghs.java test has wrong bugID for 7151434 Reviewed-by: ohair ! test/tools/launcher/Arrrghs.java Changeset: 0a1ef7e07e01 Author: sla Date: 2012-05-21 19:28 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/0a1ef7e07e01 7167157: jcmd command file parsing does not respect the "stop" command Reviewed-by: alanb, dsamersoff, nloodin ! src/share/classes/sun/tools/jcmd/JCmd.java Changeset: b88fc3359dc7 Author: lana Date: 2012-05-21 11:44 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/b88fc3359dc7 Merge Changeset: 7def50698e78 Author: katleman Date: 2012-05-24 16:15 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/7def50698e78 Added tag jdk8-b40 for changeset b88fc3359dc7 ! .hgtags From vladimir.kozlov at oracle.com Thu May 24 22:34:53 2012 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Fri, 25 May 2012 05:34:53 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 29 new changesets Message-ID: <20120525053552.2839447506@hg.openjdk.java.net> Changeset: 35e504cb49a6 Author: collins Date: 2012-05-11 11:30 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/35e504cb49a6 7167625: Adjustments for SE-Embedded build process Summary: Simple change to the SE-Embedded build rules that should not affect any other OpenJDK users. Reviewed-by: kvn, dholmes ! make/linux/makefiles/vm.make ! src/share/vm/runtime/arguments.cpp Changeset: fada85d11d92 Author: jprovino Date: 2012-05-16 13:33 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/fada85d11d92 Merge Changeset: de0cc3dd9f10 Author: kvn Date: 2012-05-17 09:50 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/de0cc3dd9f10 Merge Changeset: 3a22b77e755a Author: brutisso Date: 2012-05-14 17:32 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/3a22b77e755a 7161545: G1: Minor cleanups to the G1 logging Summary: Rename "to-space-overflow" to "to-space-exhausted", Introduce one decimal point in the size format, Add Sum to the aggregate and re-order the entries, Add number of GC workers to the log output Reviewed-by: johnc, jwilhelm ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/utilities/globalDefinitions.hpp Changeset: 78a1b285cda8 Author: mikael Date: 2012-05-15 00:56 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/78a1b285cda8 7158457: division by zero in adaptiveweightedaverage Summary: Add ceiling to AdaptiveWeightedAverage Reviewed-by: ysr, iveresov ! src/share/vm/gc_implementation/shared/gcUtil.cpp ! src/share/vm/gc_implementation/shared/gcUtil.hpp Changeset: 33e366609904 Author: johnc Date: 2012-05-14 21:07 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/33e366609904 Merge Changeset: 1096fc5a52eb Author: johnc Date: 2012-05-15 09:49 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/1096fc5a52eb 7168294: G1: Some Full GCs incorrectly report GC cause as "No GC" Summary: GC cause was not being set by the VM_G1CollectForAllocation VM operation. Reviewed-by: jmasa, ysr, brutisso ! src/share/vm/gc_implementation/g1/vm_operations_g1.cpp Changeset: cdfa5139bd58 Author: brutisso Date: 2012-05-15 22:26 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/cdfa5139bd58 7169056: Add gigabyte unit to proper_unit_for_byte_size() and byte_size_in_proper_unit() Reviewed-by: jwilhelm, johnc, dholmes ! src/share/vm/utilities/globalDefinitions.hpp Changeset: 9d679effd28c Author: brutisso Date: 2012-05-15 10:25 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/9d679effd28c 7166894: Add gc cause to GC logging for all collectors Reviewed-by: mgerdin, johnc ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/vmCMSOperations.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp ! src/share/vm/gc_interface/gcCause.hpp ! src/share/vm/memory/defNewGeneration.cpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/genMarkSweep.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/java.hpp Changeset: cdeda3fd141e Author: jcoomes Date: 2012-05-18 10:27 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/cdeda3fd141e Merge ! src/share/vm/runtime/arguments.cpp Changeset: 26423ef693ac Author: katleman Date: 2012-05-17 06:20 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/26423ef693ac Added tag jdk8-b39 for changeset 96a403721094 ! .hgtags Changeset: 14b0e07ab9a6 Author: amurillo Date: 2012-05-18 14:50 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/14b0e07ab9a6 Merge Changeset: ff9decc8235d Author: amurillo Date: 2012-05-18 14:50 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/ff9decc8235d Added tag hs24-b11 for changeset 14b0e07ab9a6 ! .hgtags Changeset: 03d61caacd1e Author: amurillo Date: 2012-05-18 14:57 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/03d61caacd1e 7170006: new hotspot build - hs24-b12 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 0251d217257f Author: sla Date: 2012-05-08 20:28 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/0251d217257f 7162726: Wrong filter predicate of visible locals in SA JSJavaFrame Reviewed-by: sla, dcubed Contributed-by: Krystal Mok ! agent/src/share/classes/sun/jvm/hotspot/utilities/soql/JSJavaFrame.java Changeset: 7f410b6ea66c Author: dholmes Date: 2012-05-09 00:28 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/7f410b6ea66c 7167406: (Zero) Fix for InvokeDynamic needed Reviewed-by: chrisphi, dholmes Contributed-by: Andrew Dinn ! src/cpu/zero/vm/cppInterpreter_zero.cpp Changeset: d506b2cf2ad0 Author: dholmes Date: 2012-05-09 04:32 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/d506b2cf2ad0 Merge Changeset: 78d2ae5ab35b Author: nloodin Date: 2012-05-09 16:24 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/78d2ae5ab35b 7163117: Agent can't connect to process on Mac OSX Reviewed-by: dholmes, coleenp, sla, minqi, kvn ! agent/src/share/classes/sun/jvm/hotspot/HotSpotAgent.java ! agent/src/share/classes/sun/jvm/hotspot/bugspot/BugSpotAgent.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/bsd/BsdCDebugger.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/bsd/BsdThreadContextFactory.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/proc/ProcDebuggerLocal.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/remote/RemoteDebuggerClient.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/Threads.java ! agent/src/share/classes/sun/jvm/hotspot/ui/classbrowser/HTMLGenerator.java Changeset: 037973617842 Author: kevinw Date: 2012-05-11 17:24 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/037973617842 7157734: hotspot test scripts not testing 64-bit JVM under JPRT/JTREG. Reviewed-by: kvn ! test/compiler/6894807/Test6894807.sh ! test/gc/6941923/test6941923.sh ! test/runtime/6626217/Test6626217.sh ! test/runtime/6878713/Test6878713.sh ! test/runtime/6929067/Test6929067.sh ! test/runtime/7020373/Test7020373.sh ! test/runtime/7051189/Xchecksig.sh ! test/runtime/7158988/TestFieldMonitor.sh Changeset: 2f4819f92dc7 Author: zgu Date: 2012-05-10 18:19 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/2f4819f92dc7 Merge - src/share/vm/gc_implementation/concurrentMarkSweep/binaryTreeDictionary.cpp - src/share/vm/gc_implementation/concurrentMarkSweep/binaryTreeDictionary.hpp - src/share/vm/gc_implementation/concurrentMarkSweep/freeBlockDictionary.cpp - src/share/vm/gc_implementation/concurrentMarkSweep/freeBlockDictionary.hpp - src/share/vm/gc_implementation/concurrentMarkSweep/freeList.cpp - src/share/vm/gc_implementation/concurrentMarkSweep/freeList.hpp Changeset: b4f7c4315c36 Author: zgu Date: 2012-05-12 06:50 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/b4f7c4315c36 Merge Changeset: 7d4e6dabc6bf Author: dcubed Date: 2012-05-15 10:52 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/7d4e6dabc6bf 7165060: dtrace tests fail with FDS debug info files Summary: Work around 'gobjcopy --add-gnu-debuglink' failure by adding a temporary tool that adds the '.gnu_debuglink' section and nothing more. Reviewed-by: sspitsyn, acorn + make/solaris/makefiles/add_gnu_debuglink.make ! make/solaris/makefiles/vm.make + src/os/solaris/add_gnu_debuglink/add_gnu_debuglink.c Changeset: 80b9cc90b643 Author: dcubed Date: 2012-05-15 11:27 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/80b9cc90b643 Merge ! make/solaris/makefiles/defs.make ! make/solaris/makefiles/vm.make Changeset: 9793f47cdebc Author: dcubed Date: 2012-05-15 15:16 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/9793f47cdebc 7169102: 7165060 merge lost changes to make/windows/makefiles/defs.make Reviewed-by: sspitsyn, acorn ! make/windows/makefiles/defs.make Changeset: 7432b9db36ff Author: nloodin Date: 2012-05-10 15:44 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/7432b9db36ff 7165755: OS Information much longer on linux than other platforms Reviewed-by: sla, dholmes ! src/os/bsd/vm/os_bsd.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/linux/vm/os_linux.hpp ! src/os/posix/vm/os_posix.cpp + src/os/posix/vm/os_posix.hpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/solaris/vm/os_solaris.hpp ! src/os/windows/vm/os_windows.cpp ! src/os/windows/vm/os_windows.hpp ! src/share/vm/runtime/os.hpp Changeset: 198dcc84088c Author: dcubed Date: 2012-05-16 12:47 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/198dcc84088c 7169409: enabling ZIP_DEBUGINFO_FILES causes unexpected test failures on Windows X86 Summary: Disable ZIP_DEBUGINFO_FILES by default on Windows. Reviewed-by: acorn ! make/windows/makefiles/defs.make Changeset: 4b37c0dafe3a Author: dcubed Date: 2012-05-18 09:15 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/4b37c0dafe3a 7170010: conditional "ZIP_DEBUGINFO_FILES ?= 0" setting is not reliable on Windows Summary: Always disable ZIP_DEBUGINFO_FILES on Windows. Reviewed-by: acorn ! make/windows/makefiles/defs.make Changeset: cee14a6fc5ac Author: zgu Date: 2012-05-22 20:29 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/cee14a6fc5ac Merge Changeset: 7089278210e2 Author: kvn Date: 2012-05-24 18:39 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/7089278210e2 Merge From john.coomes at oracle.com Fri May 25 06:51:31 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 25 May 2012 13:51:31 +0000 Subject: hg: hsx/hotspot-comp/langtools: 6 new changesets Message-ID: <20120525135146.9967D47517@hg.openjdk.java.net> Changeset: d10db3576c08 Author: ksrini Date: 2012-05-04 07:55 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/d10db3576c08 7166010: (javac) JavacMessager incorrectly restores log source file Reviewed-by: jjg Contributed-by: jan.lahoda at oracle.com ! src/share/classes/com/sun/tools/javac/processing/JavacMessager.java + test/tools/javac/processing/messager/MessagerDiags.java Changeset: 833bab705918 Author: ksrini Date: 2012-05-10 12:32 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/833bab705918 7159445: (javac) emits inaccurate diagnostics for enhanced for-loops Reviewed-by: jjg Contributed-by: jan.lahoda at oracle.com ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties + test/tools/javac/diags/examples/ForeachBadInitialization.java ! test/tools/javac/parser/JavacParserTest.java Changeset: 96a8278e323c Author: sundar Date: 2012-05-11 20:06 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/96a8278e323c 7166990: java/compiler Inherited interfaces using generics sometimes looses the generic type Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/comp/Lower.java + test/tools/javac/TryWithResources/T7164542.java Changeset: 885806e74240 Author: lana Date: 2012-05-11 12:53 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/885806e74240 Merge Changeset: 86e0dad6aadf Author: lana Date: 2012-05-21 11:44 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/86e0dad6aadf Merge Changeset: 179fa85aeefa Author: katleman Date: 2012-05-24 16:16 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/179fa85aeefa Added tag jdk8-b40 for changeset 86e0dad6aadf ! .hgtags From vladimir.kozlov at oracle.com Fri May 25 11:05:47 2012 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Fri, 25 May 2012 18:05:47 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7170463: C2 should recognize "obj.getClass() == A.class" code pattern Message-ID: <20120525180550.8C6F647520@hg.openjdk.java.net> Changeset: 8f6ce6f1049b Author: kvn Date: 2012-05-25 07:53 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/8f6ce6f1049b 7170463: C2 should recognize "obj.getClass() == A.class" code pattern Summary: optimize this code pattern obj.getClass() == A.class. Reviewed-by: jrose, kvn Contributed-by: Krystal Mok ! src/share/vm/opto/parse.hpp ! src/share/vm/opto/parse2.cpp ! src/share/vm/opto/subnode.cpp From christian.thalinger at oracle.com Fri May 25 14:52:18 2012 From: christian.thalinger at oracle.com (christian.thalinger at oracle.com) Date: Fri, 25 May 2012 21:52:18 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7170145: C1 doesn't respect the JMM with volatile field loads Message-ID: <20120525215220.A10824752D@hg.openjdk.java.net> Changeset: 4d8787136e08 Author: twisti Date: 2012-05-25 11:39 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/4d8787136e08 7170145: C1 doesn't respect the JMM with volatile field loads Reviewed-by: kvn, roland ! src/share/vm/c1/c1_ValueMap.hpp From rednaxelafx at gmail.com Tue May 29 12:10:34 2012 From: rednaxelafx at gmail.com (Krystal Mok) Date: Wed, 30 May 2012 03:10:34 +0800 Subject: C1: fix "assert(has_printable_bci()) failed: _printable_bci should have been set" when using -XX:+PrintCanonicalization Message-ID: Hi all, Could I have a couple of review for this patch, please: https://gist.github.com/2829978#file_c1_fix_printable_bci.patch I hit the "assert(has_printable_bci()) failed: _printable_bci should have been set" assertion when I was doing some experiment on C1, and needed to use -XX:+PrintCanonicalization for verification. It turns out that this flag is pretty broken, that quite a few places didn't set printable_bci appropriately. This patch tries to fix the missing printable_bcis. The link also includes a simple example before and after applying this patch. c1_Instructions.hpp: Added set_printable_bci() to Local and Phi's constructor. A "Local" instruction models an incoming argument, which gets its value before method entry, so I'm setting all Local's printable_bci to -1. A reasonable printable_bci for a "Phi" instruction is the same as the start bci of the basic block to which it belongs. I had to use a weird cast to get rid of a "invalid use of incomplete type 'struct BlockBegin' error from GCC. c1_Canonicalizer.cpp: Added a default x->set_printable_bci(bci()) to Canonicalizer::set_canonical(). There are quite a few place in Canonicalizer that doesn't specify the printable_bci for the newly created substitution instruction. It's reasonable to just set that to the "current" bci, which is the bci of the instruction to be substituted. Also adjusted the order of a set_bci() call in Canonicalizer::do_If, so that the new code above could pick up the modified bci in set_canonical(). Regards, Kris -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20120530/13ffd0d9/attachment.html From christian.thalinger at oracle.com Tue May 29 17:16:18 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 29 May 2012 17:16:18 -0700 Subject: C1: fix "assert(has_printable_bci()) failed: _printable_bci should have been set" when using -XX:+PrintCanonicalization In-Reply-To: References: Message-ID: <8423EE53-E13E-496D-BEBE-E95A5B34BB22@oracle.com> Looks good. Thanks for fixing this. It hit me quite often while working on C1 and I never had time to fix it. -- Chris On May 29, 2012, at 12:10 PM, Krystal Mok wrote: > Hi all, > > Could I have a couple of review for this patch, please: > https://gist.github.com/2829978#file_c1_fix_printable_bci.patch > > I hit the "assert(has_printable_bci()) failed: _printable_bci should have been > set" assertion when I was doing some experiment on C1, and needed to use > -XX:+PrintCanonicalization for verification. It turns out that this flag is > pretty broken, that quite a few places didn't set printable_bci appropriately. > > This patch tries to fix the missing printable_bcis. > The link also includes a simple example before and after applying this patch. > > c1_Instructions.hpp: > Added set_printable_bci() to Local and Phi's constructor. > A "Local" instruction models an incoming argument, which gets its value before > method entry, so I'm setting all Local's printable_bci to -1. > A reasonable printable_bci for a "Phi" instruction is the same as the start bci > of the basic block to which it belongs. I had to use a weird cast to get rid of > a "invalid use of incomplete type 'struct BlockBegin' error from GCC. > > c1_Canonicalizer.cpp: > Added a default x->set_printable_bci(bci()) to Canonicalizer::set_canonical(). > There are quite a few place in Canonicalizer that doesn't specify the > printable_bci for the newly created substitution instruction. It's reasonable > to just set that to the "current" bci, which is the bci of the instruction to > be substituted. > Also adjusted the order of a set_bci() call in Canonicalizer::do_If, so that > the new code above could pick up the modified bci in set_canonical(). > > Regards, > Kris -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20120529/f7872aa1/attachment.html From rednaxelafx at gmail.com Tue May 29 18:55:24 2012 From: rednaxelafx at gmail.com (Kris Mok) Date: Wed, 30 May 2012 09:55:24 +0800 Subject: C1: fix "assert(has_printable_bci()) failed: _printable_bci should have been set" when using -XX:+PrintCanonicalization In-Reply-To: <8423EE53-E13E-496D-BEBE-E95A5B34BB22@oracle.com> References: <8423EE53-E13E-496D-BEBE-E95A5B34BB22@oracle.com> Message-ID: Hi Chris, Thanks for looking at it. Could you sponsor this change, please? Thanks, Kris On 2012-5-30, at 8:16, Christian Thalinger wrote: > Looks good. Thanks for fixing this. It hit me quite often while working on C1 and I never had time to fix it. > > -- Chris > > On May 29, 2012, at 12:10 PM, Krystal Mok wrote: > >> Hi all, >> >> Could I have a couple of review for this patch, please: >> https://gist.github.com/2829978#file_c1_fix_printable_bci.patch >> >> I hit the "assert(has_printable_bci()) failed: _printable_bci should have been >> set" assertion when I was doing some experiment on C1, and needed to use >> -XX:+PrintCanonicalization for verification. It turns out that this flag is >> pretty broken, that quite a few places didn't set printable_bci appropriately. >> >> This patch tries to fix the missing printable_bcis. >> The link also includes a simple example before and after applying this patch. >> >> c1_Instructions.hpp: >> Added set_printable_bci() to Local and Phi's constructor. >> A "Local" instruction models an incoming argument, which gets its value before >> method entry, so I'm setting all Local's printable_bci to -1. >> A reasonable printable_bci for a "Phi" instruction is the same as the start bci >> of the basic block to which it belongs. I had to use a weird cast to get rid of >> a "invalid use of incomplete type 'struct BlockBegin' error from GCC. >> >> c1_Canonicalizer.cpp: >> Added a default x->set_printable_bci(bci()) to Canonicalizer::set_canonical(). >> There are quite a few place in Canonicalizer that doesn't specify the >> printable_bci for the newly created substitution instruction. It's reasonable >> to just set that to the "current" bci, which is the bci of the instruction to >> be substituted. >> Also adjusted the order of a set_bci() call in Canonicalizer::do_If, so that >> the new code above could pick up the modified bci in set_canonical(). >> >> Regards, >> Kris > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20120530/5120a6b6/attachment.html From rednaxelafx at gmail.com Wed May 30 08:31:52 2012 From: rednaxelafx at gmail.com (Krystal Mok) Date: Wed, 30 May 2012 23:31:52 +0800 Subject: Request for review (M): 7171890: C1: add Class.isInstance intrinsic Message-ID: Hi all, Could I have a couple of review for this change, please? https://gist.github.com/2830194#file_c1_is_instance.patch This patch implements Class.isInstance() intrinsic in C1. As a first cut, the current implementation is pretty straightforward: 1. During HIR construction, Class.isInstance() is inlined as an Intrinsic node in GraphBuilder::try_inline_intrinsics(); 2. Try to canonicalize the Intrinsic node into an InstanceOf node when appending the node to the HIR graph; 3. Generate a leaf call to a runtime helper (Runtime1::is_instance_of) during LIR generation for the remaining Intrinsic nodes for Class.isInstance(). This keeps the change platform-independent. There are several opportunities for more optimizations. e.g. 1. Turn more Intrinsic nodes into InstanceOf nodes during HIR optimizations and during LIR generation; 2. Check the clazz.isInstance(null) case in a couple of places *after* clazz is null-checked or guaranteed to be non-null; turn that into a constant false. 3. Follow the lir_store_check example for better platform-dependent performance These shall be addressed in some future change, if necessary. Regards, Kris -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20120530/124f8486/attachment.html From christian.thalinger at oracle.com Wed May 30 11:30:32 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 30 May 2012 11:30:32 -0700 Subject: C1: fix "assert(has_printable_bci()) failed: _printable_bci should have been set" when using -XX:+PrintCanonicalization In-Reply-To: References: <8423EE53-E13E-496D-BEBE-E95A5B34BB22@oracle.com> Message-ID: <82A461FA-1DEB-4D78-BA93-7CA256ED8486@oracle.com> On May 29, 2012, at 6:55 PM, Kris Mok wrote: > Hi Chris, > > Thanks for looking at it. Could you sponsor this change, please? 7172843: C1: fix "assert(has_printable_bci()) failed: _printable_bci should have been set" Will submit to JPRT shortly. -- Chris > > Thanks, > Kris > > On 2012-5-30, at 8:16, Christian Thalinger wrote: > >> Looks good. Thanks for fixing this. It hit me quite often while working on C1 and I never had time to fix it. >> >> -- Chris >> >> On May 29, 2012, at 12:10 PM, Krystal Mok wrote: >> >>> Hi all, >>> >>> Could I have a couple of review for this patch, please: >>> https://gist.github.com/2829978#file_c1_fix_printable_bci.patch >>> >>> I hit the "assert(has_printable_bci()) failed: _printable_bci should have been >>> set" assertion when I was doing some experiment on C1, and needed to use >>> -XX:+PrintCanonicalization for verification. It turns out that this flag is >>> pretty broken, that quite a few places didn't set printable_bci appropriately. >>> >>> This patch tries to fix the missing printable_bcis. >>> The link also includes a simple example before and after applying this patch. >>> >>> c1_Instructions.hpp: >>> Added set_printable_bci() to Local and Phi's constructor. >>> A "Local" instruction models an incoming argument, which gets its value before >>> method entry, so I'm setting all Local's printable_bci to -1. >>> A reasonable printable_bci for a "Phi" instruction is the same as the start bci >>> of the basic block to which it belongs. I had to use a weird cast to get rid of >>> a "invalid use of incomplete type 'struct BlockBegin' error from GCC. >>> >>> c1_Canonicalizer.cpp: >>> Added a default x->set_printable_bci(bci()) to Canonicalizer::set_canonical(). >>> There are quite a few place in Canonicalizer that doesn't specify the >>> printable_bci for the newly created substitution instruction. It's reasonable >>> to just set that to the "current" bci, which is the bci of the instruction to >>> be substituted. >>> Also adjusted the order of a set_bci() call in Canonicalizer::do_If, so that >>> the new code above could pick up the modified bci in set_canonical(). >>> >>> Regards, >>> Kris >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20120530/93de142f/attachment-0001.html From roland.westrelin at oracle.com Wed May 30 11:43:08 2012 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Wed, 30 May 2012 20:43:08 +0200 Subject: C1: fix "assert(has_printable_bci()) failed: _printable_bci should have been set" when using -XX:+PrintCanonicalization In-Reply-To: <82A461FA-1DEB-4D78-BA93-7CA256ED8486@oracle.com> References: <8423EE53-E13E-496D-BEBE-E95A5B34BB22@oracle.com> <82A461FA-1DEB-4D78-BA93-7CA256ED8486@oracle.com> Message-ID: > 7172843: C1: fix "assert(has_printable_bci()) failed: _printable_bci should have been set" > > Will submit to JPRT shortly. Did you find a better solution to the ugly Value cast? Roland. From forax at univ-mlv.fr Wed May 30 11:49:23 2012 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Wed, 30 May 2012 20:49:23 +0200 Subject: Request for review (M): 7171890: C1: add Class.isInstance intrinsic In-Reply-To: References: Message-ID: <4FC66BB3.5020606@univ-mlv.fr> Hi Krystal, is it also possible to try to trap Class.isAssignableFrom(Class), if one of Class is constant ? R?mi On 05/30/2012 05:31 PM, Krystal Mok wrote: > Hi all, > > Could I have a couple of review for this change, please? > https://gist.github.com/2830194#file_c1_is_instance.patch > > This patch implements Class.isInstance() intrinsic in C1. > As a first cut, the current implementation is pretty straightforward: > 1. During HIR construction, Class.isInstance() is inlined as an > Intrinsic node > in GraphBuilder::try_inline_intrinsics(); > 2. Try to canonicalize the Intrinsic node into an InstanceOf node when > appending the node to the HIR graph; > 3. Generate a leaf call to a runtime helper (Runtime1::is_instance_of) > during > LIR generation for the remaining Intrinsic nodes for > Class.isInstance(). > This keeps the change platform-independent. > > There are several opportunities for more optimizations. e.g. > 1. Turn more Intrinsic nodes into InstanceOf nodes during HIR > optimizations and > during LIR generation; > 2. Check the clazz.isInstance(null) case in a couple of places *after* > clazz is > null-checked or guaranteed to be non-null; turn that into a > constant false. > 3. Follow the lir_store_check example for better platform-dependent > performance > > These shall be addressed in some future change, if necessary. > > Regards, > Kris From christian.thalinger at oracle.com Wed May 30 12:43:34 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 30 May 2012 12:43:34 -0700 Subject: Request for review (M): 7171890: C1: add Class.isInstance intrinsic In-Reply-To: <4FC66BB3.5020606@univ-mlv.fr> References: <4FC66BB3.5020606@univ-mlv.fr> Message-ID: On May 30, 2012, at 11:49 AM, R?mi Forax wrote: > Hi Krystal, > is it also possible to try to trap Class.isAssignableFrom(Class), > if one of Class is constant ? If Kris has time, why not. The Class.isInstance is important now because we will heavily use it in the new JSR 292 implementation. For JRuby's red-black tree it used 67% of the run time (yeah, JNI is expensive). -- Chris > > R?mi > > On 05/30/2012 05:31 PM, Krystal Mok wrote: >> Hi all, >> >> Could I have a couple of review for this change, please? >> https://gist.github.com/2830194#file_c1_is_instance.patch >> >> This patch implements Class.isInstance() intrinsic in C1. >> As a first cut, the current implementation is pretty straightforward: >> 1. During HIR construction, Class.isInstance() is inlined as an Intrinsic node >> in GraphBuilder::try_inline_intrinsics(); >> 2. Try to canonicalize the Intrinsic node into an InstanceOf node when >> appending the node to the HIR graph; >> 3. Generate a leaf call to a runtime helper (Runtime1::is_instance_of) during >> LIR generation for the remaining Intrinsic nodes for Class.isInstance(). >> This keeps the change platform-independent. >> >> There are several opportunities for more optimizations. e.g. >> 1. Turn more Intrinsic nodes into InstanceOf nodes during HIR optimizations and >> during LIR generation; >> 2. Check the clazz.isInstance(null) case in a couple of places *after* clazz is >> null-checked or guaranteed to be non-null; turn that into a constant false. >> 3. Follow the lir_store_check example for better platform-dependent performance >> >> These shall be addressed in some future change, if necessary. >> >> Regards, >> Kris > From rednaxelafx at gmail.com Wed May 30 18:26:14 2012 From: rednaxelafx at gmail.com (Kris Mok) Date: Thu, 31 May 2012 09:26:14 +0800 Subject: C1: fix "assert(has_printable_bci()) failed: _printable_bci should have been set" when using -XX:+PrintCanonicalization In-Reply-To: References: <8423EE53-E13E-496D-BEBE-E95A5B34BB22@oracle.com> <82A461FA-1DEB-4D78-BA93-7CA256ED8486@oracle.com> Message-ID: If there's no better alternative, maybe we should add a comment there? - Kris On 2012-5-31, at 2:43, Roland Westrelin wrote: >> 7172843: C1: fix "assert(has_printable_bci()) failed: _printable_bci should have been set" >> >> Will submit to JPRT shortly. > > Did you find a better solution to the ugly Value cast? > > Roland. From christian.thalinger at oracle.com Wed May 30 19:09:52 2012 From: christian.thalinger at oracle.com (christian.thalinger at oracle.com) Date: Thu, 31 May 2012 02:09:52 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7172843: C1: fix "assert(has_printable_bci()) failed: _printable_bci should have been set" Message-ID: <20120531020957.AF3AC4763B@hg.openjdk.java.net> Changeset: c8289830e172 Author: twisti Date: 2012-05-30 12:17 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/c8289830e172 7172843: C1: fix "assert(has_printable_bci()) failed: _printable_bci should have been set" Reviewed-by: twisti Contributed-by: Krystal Mok ! src/share/vm/c1/c1_Canonicalizer.cpp ! src/share/vm/c1/c1_Instruction.hpp From rednaxelafx at gmail.com Wed May 30 19:55:14 2012 From: rednaxelafx at gmail.com (Krystal Mok) Date: Thu, 31 May 2012 10:55:14 +0800 Subject: Request for review (M): 7171890: C1: add Class.isInstance intrinsic In-Reply-To: References: <4FC66BB3.5020606@univ-mlv.fr> Message-ID: Hi Remi and Chris, Yes, it's doable. I'll just take the same approach for clazz1.isAssignableFrom(clazz2). I'm fine with doing it in this change. But it might take some time as I have some other things that I have to do right now. Meanwhile I'd like to wait for Chris and see how much this patch improves the new JSR 292 implementation performance. If it's not good enough, I'll try again with more complicated solutions. Regards, Kris On Thu, May 31, 2012 at 3:43 AM, Christian Thalinger < christian.thalinger at oracle.com> wrote: > > On May 30, 2012, at 11:49 AM, R?mi Forax wrote: > > > Hi Krystal, > > is it also possible to try to trap Class.isAssignableFrom(Class), > > if one of Class is constant ? > > If Kris has time, why not. The Class.isInstance is important now because > we will heavily use it in the new JSR 292 implementation. For JRuby's > red-black tree it used 67% of the run time (yeah, JNI is expensive). > > -- Chris > > > > > R?mi > > > > On 05/30/2012 05:31 PM, Krystal Mok wrote: > >> Hi all, > >> > >> Could I have a couple of review for this change, please? > >> https://gist.github.com/2830194#file_c1_is_instance.patch > >> > >> This patch implements Class.isInstance() intrinsic in C1. > >> As a first cut, the current implementation is pretty straightforward: > >> 1. During HIR construction, Class.isInstance() is inlined as an > Intrinsic node > >> in GraphBuilder::try_inline_intrinsics(); > >> 2. Try to canonicalize the Intrinsic node into an InstanceOf node when > >> appending the node to the HIR graph; > >> 3. Generate a leaf call to a runtime helper (Runtime1::is_instance_of) > during > >> LIR generation for the remaining Intrinsic nodes for > Class.isInstance(). > >> This keeps the change platform-independent. > >> > >> There are several opportunities for more optimizations. e.g. > >> 1. Turn more Intrinsic nodes into InstanceOf nodes during HIR > optimizations and > >> during LIR generation; > >> 2. Check the clazz.isInstance(null) case in a couple of places *after* > clazz is > >> null-checked or guaranteed to be non-null; turn that into a constant > false. > >> 3. Follow the lir_store_check example for better platform-dependent > performance > >> > >> These shall be addressed in some future change, if necessary. > >> > >> Regards, > >> Kris > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20120531/77e85ddb/attachment.html From john.r.rose at oracle.com Thu May 31 00:10:17 2012 From: john.r.rose at oracle.com (John Rose) Date: Thu, 31 May 2012 00:10:17 -0700 Subject: Request for review (M): 7171890: C1: add Class.isInstance intrinsic In-Reply-To: References: <4FC66BB3.5020606@univ-mlv.fr> Message-ID: On May 30, 2012, at 7:55 PM, Krystal Mok wrote: > Yes, it's doable. I'll just take the same approach for clazz1.isAssignableFrom(clazz2). It's trickier, since you can't just repurpose the C1 InstanceOf node. It looks like you'll have to refactor machine-dependent code to cut in the new logic. For a comparison, see inline_native_subtype_check in C2, versus the "_isInstance" cases of inline_native_Class_query. The intrinsic for Class.isAssignableFrom is surprisingly more complex and specialized than the intrinsic for Class.isInstance. (For C2-ish reasons, the intrinsic logic in library_call.cpp is machine-independent, so it's easier to do than in C1.) Unless you find a simple way to manage the C1 changes, you might want to stick with isInstance only, this time around. In any case, we'll try what you have done already; I am confident it will do good things for our dynamic language codes. Thanks, ? John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20120531/2567dec0/attachment.html From roland.westrelin at oracle.com Thu May 31 01:10:04 2012 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Thu, 31 May 2012 10:10:04 +0200 Subject: C1: fix "assert(has_printable_bci()) failed: _printable_bci should have been set" when using -XX:+PrintCanonicalization In-Reply-To: References: Message-ID: <068DFA78-9B1B-4E6A-89D1-D4FFE7EC0C90@oracle.com> Hi Kris, Why not simply not print the bci in InstructionPrinter::print_line() when is_linked() is false for the instruction? I think this would restore the behavior before the _printable_bci stuff was introduced by 6986046. Roland. From rednaxelafx at gmail.com Thu May 31 06:26:25 2012 From: rednaxelafx at gmail.com (Krystal Mok) Date: Thu, 31 May 2012 21:26:25 +0800 Subject: Request for review (M): 7171890: C1: add Class.isInstance intrinsic In-Reply-To: References: <4FC66BB3.5020606@univ-mlv.fr> Message-ID: On Thu, May 31, 2012 at 3:10 PM, John Rose wrote: > On May 30, 2012, at 7:55 PM, Krystal Mok wrote: > > Yes, it's doable. I'll just take the same approach for > clazz1.isAssignableFrom(clazz2). > > > It's trickier, since you can't just repurpose the C1 InstanceOf node. It > looks like you'll have to refactor machine-dependent code to cut in the new > logic. > > Yes, I have noticed that already. It's not the same as the Class.isInstance(). The (quick-n-dirty) plan was to fold the case where both clazz1 and clazz2 are constants, and emit a leaf runtime call for non-constant cases. Since Class.isAssignableFrom() only throws NPE if any of clazz1 or clazz2 is null, it should be okay to make a leaf call after null-checking them. The complete solution, as you suggested, would have to involve changes to platform-dependent code. > For a comparison, see inline_native_subtype_check in C2, versus the > "_isInstance" cases of inline_native_Class_query. The intrinsic for > Class.isAssignableFrom is surprisingly more complex and specialized than > the intrinsic for Class.isInstance. > > (For C2-ish reasons, the intrinsic logic in library_call.cpp is > machine-independent, so it's easier to do than in C1.) > > I did notice this from the start, too. It's so tempting to add finer-grain IR to C1 so that it can do more optimizations; but that feels against the theme of C1. > Unless you find a simple way to manage the C1 changes, you might want to > stick with isInstance only, this time around. > > Yes, I agree. I wouldn't mind making a more complete solution for C1 Class intrinsics in future changes. > In any case, we'll try what you have done already; I am confident it will > do good things for our dynamic language codes. > > Thanks, really looking forward to the numbers :-) Thanks, Kris > Thanks, > ? John > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20120531/6fee6e85/attachment-0001.html From rednaxelafx at gmail.com Thu May 31 06:31:00 2012 From: rednaxelafx at gmail.com (Krystal Mok) Date: Thu, 31 May 2012 21:31:00 +0800 Subject: C1: fix "assert(has_printable_bci()) failed: _printable_bci should have been set" when using -XX:+PrintCanonicalization In-Reply-To: <068DFA78-9B1B-4E6A-89D1-D4FFE7EC0C90@oracle.com> References: <068DFA78-9B1B-4E6A-89D1-D4FFE7EC0C90@oracle.com> Message-ID: Hi Roland, Thanks for the tip! I didn't notice what the old behavior was before 6986046. I'll take a look and see if that works. Thanks, Kris On Thu, May 31, 2012 at 4:10 PM, Roland Westrelin < roland.westrelin at oracle.com> wrote: > Hi Kris, > > Why not simply not print the bci in InstructionPrinter::print_line() when > is_linked() is false for the instruction? > > I think this would restore the behavior before the _printable_bci stuff > was introduced by 6986046. > > Roland. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20120531/e2bd5ae8/attachment.html From roland.westrelin at oracle.com Thu May 31 06:54:38 2012 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Thu, 31 May 2012 15:54:38 +0200 Subject: C1: fix "assert(has_printable_bci()) failed: _printable_bci should have been set" when using -XX:+PrintCanonicalization In-Reply-To: References: <068DFA78-9B1B-4E6A-89D1-D4FFE7EC0C90@oracle.com> Message-ID: > Thanks for the tip! I didn't notice what the old behavior was > before 6986046. As I understand it before 6986046, the code would always print bcis with -XX:+PrintCanonicalization except the bcis would sometimes be -99 (when the instruction was not yet linked). Roland. From rednaxelafx at gmail.com Thu May 31 08:06:58 2012 From: rednaxelafx at gmail.com (Krystal Mok) Date: Thu, 31 May 2012 23:06:58 +0800 Subject: C1: fix "assert(has_printable_bci()) failed: _printable_bci should have been set" when using -XX:+PrintCanonicalization In-Reply-To: References: <068DFA78-9B1B-4E6A-89D1-D4FFE7EC0C90@oracle.com> Message-ID: On Thu, May 31, 2012 at 9:54 PM, Roland Westrelin < roland.westrelin at oracle.com> wrote: > Thanks for the tip! I didn't notice what the old behavior was >> before 6986046. >> > > As I understand it before 6986046, the code would always print bcis with > -XX:+PrintCanonicalization except the bcis would sometimes be -99 (when the > instruction was not yet linked). > > That sounds like a fair behavior. Yes, you're right that in Canonicalizer::set_canonical(x), it's better to just print bci() when x is not linked, since printable_bci is set when linking the instruction. But Local and Phi instructions are exceptions. They're never "linked" into the instruction list (they're just filled into a ValueStack), but they deserve something better than -99. They're more likely to cause trouble in Canonicalizer::set_canonical(x) by this call: x->input_values_do(&do_print_value); Which is why I did the change in the constructors of Local and Phi. Thanks, Kris > Roland. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20120531/a8cdc023/attachment.html From roland.westrelin at oracle.com Thu May 31 08:19:19 2012 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Thu, 31 May 2012 17:19:19 +0200 Subject: C1: fix "assert(has_printable_bci()) failed: _printable_bci should have been set" when using -XX:+PrintCanonicalization In-Reply-To: References: <068DFA78-9B1B-4E6A-89D1-D4FFE7EC0C90@oracle.com> Message-ID: > But Local and Phi instructions are exceptions. They're never "linked" into > the instruction list (they're just filled into a ValueStack), but they > deserve something better than -99. They're more likely to cause trouble in > Canonicalizer::set_canonical(x) by this call: > > x->input_values_do(&do_print_value); > > Which is why I did the change in the constructors of Local and Phi. That makes sense. Roland. From christian.thalinger at oracle.com Thu May 31 15:05:51 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 31 May 2012 15:05:51 -0700 Subject: Request for review (M): 7171890: C1: add Class.isInstance intrinsic In-Reply-To: References: <4FC66BB3.5020606@univ-mlv.fr> Message-ID: <2D8A9C66-3486-4C95-9B93-0087C5D452B3@oracle.com> On May 31, 2012, at 6:26 AM, Krystal Mok wrote: > On Thu, May 31, 2012 at 3:10 PM, John Rose wrote: > On May 30, 2012, at 7:55 PM, Krystal Mok wrote: > >> Yes, it's doable. I'll just take the same approach for clazz1.isAssignableFrom(clazz2). > > It's trickier, since you can't just repurpose the C1 InstanceOf node. It looks like you'll have to refactor machine-dependent code to cut in the new logic. > > Yes, I have noticed that already. It's not the same as the Class.isInstance(). The (quick-n-dirty) plan was to fold the case where both clazz1 and clazz2 are constants, and emit a leaf runtime call for non-constant cases. Since Class.isAssignableFrom() only throws NPE if any of clazz1 or clazz2 is null, it should be okay to make a leaf call after null-checking them. > > The complete solution, as you suggested, would have to involve changes to platform-dependent code. > > For a comparison, see inline_native_subtype_check in C2, versus the "_isInstance" cases of inline_native_Class_query. The intrinsic for Class.isAssignableFrom is surprisingly more complex and specialized than the intrinsic for Class.isInstance. > > (For C2-ish reasons, the intrinsic logic in library_call.cpp is machine-independent, so it's easier to do than in C1.) > > I did notice this from the start, too. It's so tempting to add finer-grain IR to C1 so that it can do more optimizations; but that feels against the theme of C1. > > Unless you find a simple way to manage the C1 changes, you might want to stick with isInstance only, this time around. > > Yes, I agree. I wouldn't mind making a more complete solution for C1 Class intrinsics in future changes. > > In any case, we'll try what you have done already; I am confident it will do good things for our dynamic language codes. > > Thanks, really looking forward to the numbers :-) The numbers are okay; it shaves off about 9% of run time: cthaling at intelsdv03.us.oracle.com:~/mlvm/jruby$ jruby -J-client -J-showversion -X+C bench/bench_red_black.rb Picked up _JAVA_OPTIONS: -XX:+UnlockExperimentalVMOptions -XX:-AllowChainedMethodHandles -XX:+AllowLambdaForms -Xverify:all -esa -Xbootclasspath/p:/home/cthaling/mlvm/jdk/classes/ java version "1.8.0-ea" Java(TM) SE Runtime Environment (build 1.8.0-ea-b40) Java HotSpot(TM) Client VM (build 24.0-b08-internal, mixed mode) 17.479 GC.count = 46 10.25 GC.count = 54 9.732 GC.count = 61 9.633 GC.count = 68 9.568 GC.count = 74 9.499 GC.count = 81 9.634 GC.count = 87 9.787 GC.count = 94 9.739 GC.count = 101 9.702 GC.count = 107 Flat profile of 114.73 secs (10532 total ticks): main Interpreted + native Method 2.6% 0 + 277 java.io.FileOutputStream.open 2.1% 0 + 221 java.io.FileOutputStream.close0 0.8% 87 + 0 bench.bench_red_black.method__27$RUBY$insert_helper 0.6% 65 + 0 bench.bench_red_black.method__16$RUBY$minimum 0.1% 0 + 15 java.lang.Class.forName0 0.1% 0 + 12 sun.misc.Unsafe.defineAnonymousClass 0.1% 1 + 11 org.jruby.Ruby.initCore 0.1% 10 + 0 bench.bench_red_black.method__25$RUBY$left_rotate 0.1% 7 + 0 bench.bench_red_black.method__14$RUBY$insert 0.1% 3 + 3 java.lang.Class.getDeclaredConstructors0 0.1% 0 + 6 org.jruby.parser.Ruby19Parser. 0.0% 0 + 5 java.io.UnixFileSystem.getBooleanAttributes0 0.0% 2 + 3 java.lang.ClassLoader.defineClass1 0.0% 1 + 2 java.security.AccessController.doPrivileged 0.0% 3 + 0 org.objectweb.asm.Label.a 0.0% 3 + 0 java.lang.invoke.Invokers.lookupInvoker 0.0% 3 + 0 com.sun.xml.internal.ws.org.objectweb.asm.ClassWriter. 0.0% 0 + 2 java.io.FileInputStream.open 0.0% 0 + 2 java.lang.invoke.MethodHandleNatives.resolve 0.0% 0 + 2 java.lang.Throwable.fillInStackTrace 0.0% 0 + 2 java.lang.ClassLoader.findBootstrapClass 0.0% 0 + 2 org.jruby.parser.Ruby19Parser. 0.0% 2 + 0 org.jruby.util.ByteList.bytes 0.0% 2 + 0 org.jruby.internal.runtime.methods.InvocationMethodFactory.invokeCallConfigPost 0.0% 2 + 0 org.objectweb.asm.Frame.d 8.4% 277 + 606 Total interpreted (including elided) Compiled + native Method 2.8% 1 + 295 bench.bench_red_black.method__16$RUBY$minimum 2.5% 3 + 261 bench.bench_red_black.method__27$RUBY$insert_helper 1.5% 0 + 163 bench.bench_red_black.method__25$RUBY$left_rotate 1.0% 0 + 109 bench.bench_red_black.method__14$RUBY$insert 0.0% 0 + 1 java.io.FilterInputStream.read 0.0% 1 + 0 org.jruby.runtime.CompiledBlockLight19.pre 0.0% 0 + 1 org.jruby.internal.runtime.methods.CompiledMethod.call 0.0% 1 + 0 org.jruby.runtime.invokedynamic.InvocationLinker.testRealClass 0.0% 1 + 0 org.jruby.RubyBasicObject.op_not_equal 0.0% 0 + 1 org.jruby.internal.runtime.methods.DynamicMethod.call 0.0% 1 + 0 org.jruby.runtime.scope.ManyVarsDynamicScope.getValueOrNil 0.0% 1 + 0 java.lang.invoke.LambdaForm$LFI39.invoke 0.0% 1 + 0 org.jruby.ast.executable.RuntimeCache.isCachedFrom 0.0% 0 + 1 org.jruby.javasupport.util.RuntimeHelpers.restructureBlockArgs19 0.0% 1 + 0 org.objectweb.asm.ClassWriter.toByteArray 0.0% 0 + 1 bench.bench_red_black.method__17$RUBY$maximum 0.0% 0 + 1 java.lang.String.replace 0.0% 1 + 0 bench.bench_red_black.method__2$RUBY$initialize 0.0% 1 + 0 bench.bench_red_black.method__26$RUBY$right_rotate 8.0% 13 + 834 Total compiled Stub + native Method 80.6% 0 + 8494 java.lang.Class.isInstance 0.8% 1 + 87 java.io.FileOutputStream.open 0.8% 0 + 85 java.io.FileOutputStream.close0 0.3% 0 + 29 java.lang.Class.isPrimitive 0.1% 0 + 15 sun.misc.Unsafe.ensureClassInitialized 0.1% 0 + 9 java.lang.String.intern 0.1% 0 + 8 java.lang.Class.isArray 0.1% 0 + 7 java.lang.invoke.MethodHandleNatives.resolve 0.0% 2 + 3 java.security.AccessController.doPrivileged 0.0% 0 + 5 java.lang.System.arraycopy 0.0% 0 + 4 java.lang.Class.isInterface 0.0% 0 + 3 java.lang.Thread.currentThread 0.0% 0 + 3 java.lang.Throwable.fillInStackTrace 0.0% 0 + 3 sun.misc.Unsafe.defineAnonymousClass 0.0% 0 + 2 java.lang.Object.getClass 0.0% 0 + 2 java.lang.Class.getComponentType 0.0% 0 + 2 java.lang.ClassLoader.findLoadedClass0 0.0% 0 + 2 java.io.FileOutputStream.writeBytes 0.0% 0 + 1 java.lang.Thread.holdsLock 0.0% 0 + 1 sun.reflect.Reflection.getCallerClass 0.0% 0 + 1 java.lang.Class.getEnclosingMethod0 0.0% 0 + 1 java.lang.Object.clone 0.0% 0 + 1 java.lang.reflect.Array.newArray 0.0% 0 + 1 java.lang.invoke.MethodHandleNatives.setCallSiteTargetNormal 0.0% 0 + 1 sun.misc.Unsafe.compareAndSwapInt 83.3% 3 + 8771 Total stub (including elided) cthaling at intelsdv03.us.oracle.com:~/mlvm/jruby$ jruby -J-client -J-showversion -X+C bench/bench_red_black.rb Picked up _JAVA_OPTIONS: -XX:+UnlockExperimentalVMOptions -XX:-AllowChainedMethodHandles -XX:+AllowLambdaForms -Xverify:all -esa -Xbootclasspath/p:/home/cthaling/mlvm/jdk/classes/ java version "1.8.0-ea" Java(TM) SE Runtime Environment (build 1.8.0-ea-b40) Java HotSpot(TM) Client VM (build 24.0-b08-internal, mixed mode) 15.966 GC.count = 46 9.629 GC.count = 54 9.135 GC.count = 61 8.905 GC.count = 68 8.775 GC.count = 74 8.851 GC.count = 80 8.782 GC.count = 87 8.78 GC.count = 93 8.794 GC.count = 100 8.81 GC.count = 106 Flat profile of 108.49 secs (9711 total ticks): main Interpreted + native Method 14.3% 1387 + 0 bench.bench_red_black.method__27$RUBY$insert_helper 13.3% 1294 + 0 bench.bench_red_black.method__16$RUBY$minimum 3.1% 0 + 303 java.io.FileOutputStream.open 2.2% 0 + 210 java.io.FileOutputStream.close0 1.8% 170 + 0 bench.bench_red_black.method__14$RUBY$insert 0.1% 0 + 13 java.lang.Class.forName0 0.1% 0 + 12 sun.misc.Unsafe.defineAnonymousClass 0.1% 2 + 10 org.jruby.Ruby.initCore 0.1% 0 + 8 java.io.UnixFileSystem.getBooleanAttributes0 0.1% 1 + 6 org.jruby.parser.Ruby19Parser. 0.1% 7 + 0 bench.bench_red_black.method__28$RUBY$delete_fixup 0.1% 4 + 2 java.lang.Class.getDeclaredConstructors0 0.1% 2 + 4 java.lang.ClassLoader.defineClass1 0.1% 6 + 0 org.jruby.internal.runtime.methods.DynamicMethod.call 0.1% 5 + 0 org.jruby.RubyArray.eachCommon 0.1% 5 + 0 org.jruby.RubyArray.realloc 0.0% 0 + 4 java.lang.ClassLoader.findBootstrapClass 0.0% 0 + 4 java.io.FileOutputStream.writeBytes 0.0% 0 + 3 java.lang.invoke.MethodHandleNatives.resolve 0.0% 3 + 0 bench.bench_red_black.method__25$RUBY$left_rotate 0.0% 0 + 3 org.jruby.Ruby.initRoot 0.0% 0 + 2 java.lang.Throwable.fillInStackTrace 0.0% 2 + 0 org.jruby.compiler.impl.BaseBodyCompiler.invokeUtilityMethod 0.0% 2 + 0 org.jruby.runtime.opto.OptoFactory.newInvocationCompiler 0.0% 2 + 0 org.jruby.compiler.impl.InvokeDynamicCacheCompiler.cacheClosure19 37.6% 3024 + 623 Total interpreted (including elided) Compiled + native Method 19.7% 321 + 1592 bench.bench_red_black.method__27$RUBY$insert_helper 17.1% 79 + 1586 bench.bench_red_black.method__25$RUBY$left_rotate 5.4% 147 + 374 bench.bench_red_black.method__14$RUBY$insert 4.5% 27 + 409 bench.bench_red_black.method__16$RUBY$minimum 3.8% 371 + 0 bench.bench_red_black.method__22$RUBY$search 1.4% 133 + 0 bench.bench_red_black.method__17$RUBY$maximum 1.1% 102 + 0 org.jruby.RubyBasicObject.op_not_equal 0.9% 90 + 0 org.jruby.RubyBasicObject.setVariable 0.6% 56 + 0 org.jruby.ast.executable.RuntimeCache.isCachedFrom 0.5% 53 + 0 org.jruby.runtime.CompiledBlockLight19.pre 0.5% 49 + 0 org.jruby.runtime.CompiledBlock19.yield 0.3% 28 + 0 org.jruby.runtime.ThreadContext.pushCallFrame 0.3% 25 + 0 org.jruby.runtime.scope.ManyVarsDynamicScope.getValueOrNil 0.2% 24 + 0 org.jruby.MetaClass.getRealClass 0.2% 21 + 0 bench.bench_red_black.method__18$RUBY$successor 0.2% 16 + 0 org.jruby.RubyFixnum.op_plus_one 0.2% 16 + 0 bench.bench_red_black.method__19$RUBY$predecessor 0.1% 14 + 0 bench.bench_red_black.method__2$RUBY$initialize 0.1% 13 + 0 org.jruby.RubyObject$1.allocate 0.1% 13 + 0 bench$bench_red_black$method__13$RUBY$add.call 0.1% 13 + 0 bench.bench_red_black.method__28$RUBY$delete_fixup 0.1% 11 + 0 org.jruby.RubyRandom.randCommon19 0.1% 10 + 0 java.util.concurrent.atomic.AtomicReferenceFieldUpdater$AtomicReferenceFieldUpdaterImpl.compareAndSet 0.1% 9 + 1 org.jruby.RubyFixnum.times 0.1% 10 + 0 bench.bench_red_black.method__20$RUBY$inorder_walk 59.5% 1801 + 3974 Total compiled (including elided) Stub + native Method 0.9% 0 + 86 java.io.FileOutputStream.open 0.7% 0 + 71 java.io.FileOutputStream.close0 0.2% 0 + 22 java.lang.Class.isPrimitive 0.2% 0 + 15 sun.misc.Unsafe.ensureClassInitialized 0.1% 0 + 12 java.lang.Class.isArray 0.1% 0 + 7 java.lang.invoke.MethodHandleNatives.resolve 0.1% 0 + 5 java.lang.String.intern 0.1% 0 + 5 java.lang.Class.isInterface 0.0% 0 + 4 java.lang.Class.getComponentType 0.0% 0 + 4 java.lang.Object.clone 0.0% 1 + 3 java.security.AccessController.doPrivileged 0.0% 0 + 4 sun.misc.Unsafe.defineAnonymousClass 0.0% 0 + 3 java.lang.System.arraycopy 0.0% 0 + 2 java.lang.ClassLoader.findLoadedClass0 0.0% 0 + 2 java.util.zip.Inflater.inflateBytes 0.0% 0 + 1 java.lang.Object.getClass 0.0% 0 + 1 java.lang.Class.getDeclaringClass 0.0% 0 + 1 java.lang.Class.isAssignableFrom 0.0% 0 + 1 java.lang.Throwable.fillInStackTrace 0.0% 0 + 1 java.security.AccessController.doPrivileged 0.0% 0 + 1 sun.misc.Unsafe.getObjectVolatile 0.0% 0 + 1 sun.misc.Unsafe.getInt 0.0% 0 + 1 java.io.FileOutputStream.writeBytes 2.6% 1 + 253 Total stub The problem why we don't see a much bigger improvement is that most of the time (I'd say 99% of the time) Class.cast isn't inlined in C1 because it's too big, e.g.: @ 33 java.lang.invoke.LambdaForm$LFI67/25137260::invoke (32 bytes) @ 15 java.lang.invoke.LambdaForm$LFI1/13330648::invoke (31 bytes) @ 27 sun.invoke.util.ValueConversions::castReference (6 bytes) @ 2 java.lang.Class::cast (27 bytes) callee is too large @ 28 org.jruby.RubyBasicObject::op_not (20 bytes) @ 1 org.jruby.runtime.ThreadContext::getRuntime (5 bytes) @ 5 org.jruby.RubyBasicObject::isTrue (15 bytes) @ 16 org.jruby.Ruby::newBoolean (16 bytes) and we have to go the out-of-line route. -- Chris > > Thanks, > Kris > > Thanks, > ? John > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20120531/7e663666/attachment-0001.html From forax at univ-mlv.fr Thu May 31 15:55:53 2012 From: forax at univ-mlv.fr (=?windows-1252?Q?R=E9mi_Forax?=) Date: Fri, 01 Jun 2012 00:55:53 +0200 Subject: Request for review (M): 7171890: C1: add Class.isInstance intrinsic In-Reply-To: <2D8A9C66-3486-4C95-9B93-0087C5D452B3@oracle.com> References: <4FC66BB3.5020606@univ-mlv.fr> <2D8A9C66-3486-4C95-9B93-0087C5D452B3@oracle.com> Message-ID: <4FC7F6F9.1030600@univ-mlv.fr> On 06/01/2012 12:05 AM, Christian Thalinger wrote: > > On May 31, 2012, at 6:26 AM, Krystal Mok wrote: > >> On Thu, May 31, 2012 at 3:10 PM, John Rose > > wrote: >> >> On May 30, 2012, at 7:55 PM, Krystal Mok wrote: >> >>> Yes, it's doable. I'll just take the same approach for >>> clazz1.isAssignableFrom(clazz2). >> >> It's trickier, since you can't just repurpose the C1 InstanceOf >> node. It looks like you'll have to refactor machine-dependent >> code to cut in the new logic. >> >> Yes, I have noticed that already. It's not the same as the >> Class.isInstance(). The (quick-n-dirty) plan was to fold the case >> where both clazz1 and clazz2 are constants, and emit a leaf runtime >> call for non-constant cases. Since Class.isAssignableFrom() only >> throws NPE if any of clazz1 or clazz2 is null, it should be okay to >> make a leaf call after null-checking them. >> >> The complete solution, as you suggested, would have to involve >> changes to platform-dependent code. >> >> For a comparison, see inline_native_subtype_check in C2, versus >> the "_isInstance" cases of inline_native_Class_query. The >> intrinsic for Class.isAssignableFrom is surprisingly more complex >> and specialized than the intrinsic for Class.isInstance. >> >> (For C2-ish reasons, the intrinsic logic in library_call.cpp is >> machine-independent, so it's easier to do than in C1.) >> >> I did notice this from the start, too. It's so tempting to add >> finer-grain IR to C1 so that it can do more optimizations; but that >> feels against the theme of C1. >> >> Unless you find a simple way to manage the C1 changes, you might >> want to stick with isInstance only, this time around. >> >> Yes, I agree. I wouldn't mind making a more complete solution for C1 >> Class intrinsics in future changes. >> >> In any case, we'll try what you have done already; I am confident >> it will do good things for our dynamic language codes. >> >> Thanks, really looking forward to the numbers :-) > > The numbers are okay; it shaves off about 9% of run time: > > cthaling at intelsdv03.us.oracle.com:~/mlvm/jruby$ jruby -J-client > -J-showversion -X+C bench/bench_red_black.rb > Picked up _JAVA_OPTIONS: -XX:+UnlockExperimentalVMOptions > -XX:-AllowChainedMethodHandles -XX:+AllowLambdaForms -Xverify:all -esa > -Xbootclasspath/p:/home/cthaling/mlvm/jdk/classes/ > java version "1.8.0-ea" > Java(TM) SE Runtime Environment (build 1.8.0-ea-b40) > Java HotSpot(TM) Client VM (build 24.0-b08-internal, mixed mode) > > 17.479 > GC.count = 46 > 10.25 > GC.count = 54 > 9.732 > GC.count = 61 > 9.633 > GC.count = 68 > 9.568 > GC.count = 74 > 9.499 > GC.count = 81 > 9.634 > GC.count = 87 > 9.787 > GC.count = 94 > 9.739 > GC.count = 101 > 9.702 > GC.count = 107 > > > Flat profile of 114.73 secs (10532 total ticks): main > > Interpreted + native Method > 2.6% 0 + 277 java.io.FileOutputStream.open > 2.1% 0 + 221 java.io.FileOutputStream.close0 > 0.8% 87 + 0 > bench.bench_red_black.method__27$RUBY$insert_helper > 0.6% 65 + 0 bench.bench_red_black.method__16$RUBY$minimum > 0.1% 0 + 15 java.lang.Class.forName0 > 0.1% 0 + 12 sun.misc.Unsafe.defineAnonymousClass > 0.1% 1 + 11 org.jruby.Ruby.initCore > 0.1% 10 + 0 bench.bench_red_black.method__25$RUBY$left_rotate > 0.1% 7 + 0 bench.bench_red_black.method__14$RUBY$insert > 0.1% 3 + 3 java.lang.Class.getDeclaredConstructors0 > 0.1% 0 + 6 org.jruby.parser.Ruby19Parser. > 0.0% 0 + 5 java.io.UnixFileSystem.getBooleanAttributes0 > 0.0% 2 + 3 java.lang.ClassLoader.defineClass1 > 0.0% 1 + 2 java.security.AccessController.doPrivileged > 0.0% 3 + 0 org.objectweb.asm.Label.a > 0.0% 3 + 0 java.lang.invoke.Invokers.lookupInvoker > 0.0% 3 + 0 > com.sun.xml.internal.ws.org.objectweb.asm.ClassWriter. > 0.0% 0 + 2 java.io.FileInputStream.open > 0.0% 0 + 2 java.lang.invoke.MethodHandleNatives.resolve > 0.0% 0 + 2 java.lang.Throwable.fillInStackTrace > 0.0% 0 + 2 java.lang.ClassLoader.findBootstrapClass > 0.0% 0 + 2 org.jruby.parser.Ruby19Parser. > 0.0% 2 + 0 org.jruby.util.ByteList.bytes > 0.0% 2 + 0 > org.jruby.internal.runtime.methods.InvocationMethodFactory.invokeCallConfigPost > 0.0% 2 + 0 org.objectweb.asm.Frame.d > 8.4% 277 + 606 Total interpreted (including elided) > > Compiled + native Method > 2.8% 1 + 295 bench.bench_red_black.method__16$RUBY$minimum > 2.5% 3 + 261 > bench.bench_red_black.method__27$RUBY$insert_helper > 1.5% 0 + 163 bench.bench_red_black.method__25$RUBY$left_rotate > 1.0% 0 + 109 bench.bench_red_black.method__14$RUBY$insert > 0.0% 0 + 1 java.io.FilterInputStream.read > 0.0% 1 + 0 org.jruby.runtime.CompiledBlockLight19.pre > 0.0% 0 + 1 > org.jruby.internal.runtime.methods.CompiledMethod.call > 0.0% 1 + 0 > org.jruby.runtime.invokedynamic.InvocationLinker.testRealClass > 0.0% 1 + 0 org.jruby.RubyBasicObject.op_not_equal > 0.0% 0 + 1 > org.jruby.internal.runtime.methods.DynamicMethod.call > 0.0% 1 + 0 > org.jruby.runtime.scope.ManyVarsDynamicScope.getValueOrNil > 0.0% 1 + 0 java.lang.invoke.LambdaForm$LFI39.invoke > 0.0% 1 + 0 > org.jruby.ast.executable.RuntimeCache.isCachedFrom > 0.0% 0 + 1 > org.jruby.javasupport.util.RuntimeHelpers.restructureBlockArgs19 > 0.0% 1 + 0 org.objectweb.asm.ClassWriter.toByteArray > 0.0% 0 + 1 bench.bench_red_black.method__17$RUBY$maximum > 0.0% 0 + 1 java.lang.String.replace > 0.0% 1 + 0 bench.bench_red_black.method__2$RUBY$initialize > 0.0% 1 + 0 > bench.bench_red_black.method__26$RUBY$right_rotate > 8.0% 13 + 834 Total compiled > > Stub + native Method > 80.6% 0 + 8494 java.lang.Class.isInstance > 0.8% 1 + 87 java.io.FileOutputStream.open > 0.8% 0 + 85 java.io.FileOutputStream.close0 > 0.3% 0 + 29 java.lang.Class.isPrimitive > 0.1% 0 + 15 sun.misc.Unsafe.ensureClassInitialized > 0.1% 0 + 9 java.lang.String.intern > 0.1% 0 + 8 java.lang.Class.isArray > 0.1% 0 + 7 java.lang.invoke.MethodHandleNatives.resolve > 0.0% 2 + 3 java.security.AccessController.doPrivileged > 0.0% 0 + 5 java.lang.System.arraycopy > 0.0% 0 + 4 java.lang.Class.isInterface > 0.0% 0 + 3 java.lang.Thread.currentThread > 0.0% 0 + 3 java.lang.Throwable.fillInStackTrace > 0.0% 0 + 3 sun.misc.Unsafe.defineAnonymousClass > 0.0% 0 + 2 java.lang.Object.getClass > 0.0% 0 + 2 java.lang.Class.getComponentType > 0.0% 0 + 2 java.lang.ClassLoader.findLoadedClass0 > 0.0% 0 + 2 java.io.FileOutputStream.writeBytes > 0.0% 0 + 1 java.lang.Thread.holdsLock > 0.0% 0 + 1 sun.reflect.Reflection.getCallerClass > 0.0% 0 + 1 java.lang.Class.getEnclosingMethod0 > 0.0% 0 + 1 java.lang.Object.clone > 0.0% 0 + 1 java.lang.reflect.Array.newArray > 0.0% 0 + 1 > java.lang.invoke.MethodHandleNatives.setCallSiteTargetNormal > 0.0% 0 + 1 sun.misc.Unsafe.compareAndSwapInt > 83.3% 3 + 8771 Total stub (including elided) > > > > cthaling at intelsdv03.us.oracle.com:~/mlvm/jruby$ jruby -J-client > -J-showversion -X+C bench/bench_red_black.rb > Picked up _JAVA_OPTIONS: -XX:+UnlockExperimentalVMOptions > -XX:-AllowChainedMethodHandles -XX:+AllowLambdaForms -Xverify:all -esa > -Xbootclasspath/p:/home/cthaling/mlvm/jdk/classes/ > java version "1.8.0-ea" > Java(TM) SE Runtime Environment (build 1.8.0-ea-b40) > Java HotSpot(TM) Client VM (build 24.0-b08-internal, mixed mode) > > 15.966 > GC.count = 46 > 9.629 > GC.count = 54 > 9.135 > GC.count = 61 > 8.905 > GC.count = 68 > 8.775 > GC.count = 74 > 8.851 > GC.count = 80 > 8.782 > GC.count = 87 > 8.78 > GC.count = 93 > 8.794 > GC.count = 100 > 8.81 > GC.count = 106 > > > Flat profile of 108.49 secs (9711 total ticks): main > > Interpreted + native Method > 14.3% 1387 + 0 > bench.bench_red_black.method__27$RUBY$insert_helper > 13.3% 1294 + 0 bench.bench_red_black.method__16$RUBY$minimum > 3.1% 0 + 303 java.io.FileOutputStream.open > 2.2% 0 + 210 java.io.FileOutputStream.close0 > 1.8% 170 + 0 bench.bench_red_black.method__14$RUBY$insert > 0.1% 0 + 13 java.lang.Class.forName0 > 0.1% 0 + 12 sun.misc.Unsafe.defineAnonymousClass > 0.1% 2 + 10 org.jruby.Ruby.initCore > 0.1% 0 + 8 java.io.UnixFileSystem.getBooleanAttributes0 > 0.1% 1 + 6 org.jruby.parser.Ruby19Parser. > 0.1% 7 + 0 > bench.bench_red_black.method__28$RUBY$delete_fixup > 0.1% 4 + 2 java.lang.Class.getDeclaredConstructors0 > 0.1% 2 + 4 java.lang.ClassLoader.defineClass1 > 0.1% 6 + 0 > org.jruby.internal.runtime.methods.DynamicMethod.call > 0.1% 5 + 0 org.jruby.RubyArray.eachCommon > 0.1% 5 + 0 org.jruby.RubyArray.realloc > 0.0% 0 + 4 java.lang.ClassLoader.findBootstrapClass > 0.0% 0 + 4 java.io.FileOutputStream.writeBytes > 0.0% 0 + 3 java.lang.invoke.MethodHandleNatives.resolve > 0.0% 3 + 0 bench.bench_red_black.method__25$RUBY$left_rotate > 0.0% 0 + 3 org.jruby.Ruby.initRoot > 0.0% 0 + 2 java.lang.Throwable.fillInStackTrace > 0.0% 2 + 0 > org.jruby.compiler.impl.BaseBodyCompiler.invokeUtilityMethod > 0.0% 2 + 0 > org.jruby.runtime.opto.OptoFactory.newInvocationCompiler > 0.0% 2 + 0 > org.jruby.compiler.impl.InvokeDynamicCacheCompiler.cacheClosure19 > 37.6% 3024 + 623 Total interpreted (including elided) > > Compiled + native Method > 19.7% 321 + 1592 > bench.bench_red_black.method__27$RUBY$insert_helper > 17.1% 79 + 1586 bench.bench_red_black.method__25$RUBY$left_rotate > 5.4% 147 + 374 bench.bench_red_black.method__14$RUBY$insert > 4.5% 27 + 409 bench.bench_red_black.method__16$RUBY$minimum > 3.8% 371 + 0 bench.bench_red_black.method__22$RUBY$search > 1.4% 133 + 0 bench.bench_red_black.method__17$RUBY$maximum > 1.1% 102 + 0 org.jruby.RubyBasicObject.op_not_equal > 0.9% 90 + 0 org.jruby.RubyBasicObject.setVariable > 0.6% 56 + 0 > org.jruby.ast.executable.RuntimeCache.isCachedFrom > 0.5% 53 + 0 org.jruby.runtime.CompiledBlockLight19.pre > 0.5% 49 + 0 org.jruby.runtime.CompiledBlock19.yield > 0.3% 28 + 0 org.jruby.runtime.ThreadContext.pushCallFrame > 0.3% 25 + 0 > org.jruby.runtime.scope.ManyVarsDynamicScope.getValueOrNil > 0.2% 24 + 0 org.jruby.MetaClass.getRealClass > 0.2% 21 + 0 bench.bench_red_black.method__18$RUBY$successor > 0.2% 16 + 0 org.jruby.RubyFixnum.op_plus_one > 0.2% 16 + 0 bench.bench_red_black.method__19$RUBY$predecessor > 0.1% 14 + 0 bench.bench_red_black.method__2$RUBY$initialize > 0.1% 13 + 0 org.jruby.RubyObject$1.allocate > 0.1% 13 + 0 bench$bench_red_black$method__13$RUBY$add.call > 0.1% 13 + 0 > bench.bench_red_black.method__28$RUBY$delete_fixup > 0.1% 11 + 0 org.jruby.RubyRandom.randCommon19 > 0.1% 10 + 0 > java.util.concurrent.atomic.AtomicReferenceFieldUpdater$AtomicReferenceFieldUpdaterImpl.compareAndSet > 0.1% 9 + 1 org.jruby.RubyFixnum.times > 0.1% 10 + 0 > bench.bench_red_black.method__20$RUBY$inorder_walk > 59.5% 1801 + 3974 Total compiled (including elided) > > Stub + native Method > 0.9% 0 + 86 java.io.FileOutputStream.open > 0.7% 0 + 71 java.io.FileOutputStream.close0 > 0.2% 0 + 22 java.lang.Class.isPrimitive > 0.2% 0 + 15 sun.misc.Unsafe.ensureClassInitialized > 0.1% 0 + 12 java.lang.Class.isArray > 0.1% 0 + 7 java.lang.invoke.MethodHandleNatives.resolve > 0.1% 0 + 5 java.lang.String.intern > 0.1% 0 + 5 java.lang.Class.isInterface > 0.0% 0 + 4 java.lang.Class.getComponentType > 0.0% 0 + 4 java.lang.Object.clone > 0.0% 1 + 3 java.security.AccessController.doPrivileged > 0.0% 0 + 4 sun.misc.Unsafe.defineAnonymousClass > 0.0% 0 + 3 java.lang.System.arraycopy > 0.0% 0 + 2 java.lang.ClassLoader.findLoadedClass0 > 0.0% 0 + 2 java.util.zip.Inflater.inflateBytes > 0.0% 0 + 1 java.lang.Object.getClass > 0.0% 0 + 1 java.lang.Class.getDeclaringClass > 0.0% 0 + 1 java.lang.Class.isAssignableFrom > 0.0% 0 + 1 java.lang.Throwable.fillInStackTrace > 0.0% 0 + 1 java.security.AccessController.doPrivileged > 0.0% 0 + 1 sun.misc.Unsafe.getObjectVolatile > 0.0% 0 + 1 sun.misc.Unsafe.getInt > 0.0% 0 + 1 java.io.FileOutputStream.writeBytes > 2.6% 1 + 253 Total stub > > The problem why we don't see a much bigger improvement is that most of > the time (I'd say 99% of the time) Class.cast isn't inlined in C1 > because it's too big, e.g.: > > @ 33 > java.lang.invoke.LambdaForm$LFI67/25137260::invoke (32 bytes) > @ 15 > java.lang.invoke.LambdaForm$LFI1/13330648::invoke (31 bytes) > @ 27 > sun.invoke.util.ValueConversions::castReference (6 bytes) > @ 2 java.lang.Class::cast > (27 bytes) callee is too large > @ 28 > org.jruby.RubyBasicObject::op_not (20 bytes) > @ 1 > org.jruby.runtime.ThreadContext::getRuntime (5 bytes) > @ 5 > org.jruby.RubyBasicObject::isTrue (15 bytes) > @ 16 > org.jruby.Ruby::newBoolean (16 bytes) > > and we have to go the out-of-line route. > > -- Chris There are several solutions: - Charles should use invokedynamic for the unary operator '!', so there is no need to cast to a ThreadContext anymore - The cast should not be needed anyway. I have no idea if it's because the threadContext is not declared as ThreadContext in invokedynamic or if your implementation is not able to see that the threadContext object is never altered so its type is constant in the method handle blob, it's maybe because the blob is fully specified in Java (there is no invokeExact anymore ?) - the inlining algorithm should not use the bytecode size but a top-bottom algorithm that doesn't count all codes that throws an exception and their dependency (roughly) or if the code is part of an exception handler (if the classical path and the exception handler path are not shared). - the method metadata (profile) should not be tied to a method so when a method handle blob is interpreted, it can have it's own profile so you will not try to inline the code in the slow path together with the fast path (it will also help to de-virtualize in tiered compilation mode). R?mi From john.r.rose at oracle.com Thu May 31 17:20:18 2012 From: john.r.rose at oracle.com (John Rose) Date: Thu, 31 May 2012 17:20:18 -0700 Subject: Request for review (M): 7171890: C1: add Class.isInstance intrinsic In-Reply-To: <2D8A9C66-3486-4C95-9B93-0087C5D452B3@oracle.com> References: <4FC66BB3.5020606@univ-mlv.fr> <2D8A9C66-3486-4C95-9B93-0087C5D452B3@oracle.com> Message-ID: On May 31, 2012, at 3:05 PM, Christian Thalinger wrote: > The problem why we don't see a much bigger improvement is that most of the time (I'd say 99% of the time) Class.cast isn't inlined in C1 because it's too big, e.g.: That looks like a marginal effect, where Class::cast is just slightly too large. We should remove the effect of NestedInliningSizeRatio on our inlining adapters. We could also clean up Class::cast to take it down to about 20 bytecodes; see below. Still, it's amazing that a JNI call taking 80% of execution time disappears, but takes away only 9% of the runtime. ? John diff --git a/src/share/classes/java/lang/Class.java b/src/share/classes/java/lang/Class.java --- a/src/share/classes/java/lang/Class.java +++ b/src/share/classes/java/lang/Class.java @@ -3004,12 +3004,12 @@ @SuppressWarnings("unchecked") public T cast(Object obj) { if (obj != null && !isInstance(obj)) - throw new ClassCastException(cannotCastMsg(obj)); + throw cannotCastException(obj); return (T) obj; } - private String cannotCastMsg(Object obj) { - return "Cannot cast " + obj.getClass().getName() + " to " + getName(); + private ClassCastException cannotCastException(Object obj) { + return new ClassCastException("Cannot cast " + obj.getClass().getName() + " to " + getName()); } /** -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20120531/1a196c2b/attachment.html