From swhite at aip.de Thu Jul 1 05:17:05 2010 From: swhite at aip.de (Steve White) Date: Thu, 1 Jul 2010 14:17:05 +0200 Subject: speed of simple loops: comparison to other language In-Reply-To: <4C2B45A4.3040203@redhat.com> References: <20100630113752.GA26057@cashmere.aip.de> <4C2B45A4.3040203@redhat.com> Message-ID: <20100701121705.GA12509@cashmere.aip.de> Hi, Andrew, On 30.06.10, Andrew Haley wrote: > On 06/30/2010 12:37 PM, Steve White wrote: > > > > I tried building the Java VM from source for my IA-32 machine, but saw no > > improvement in performance at all from the distribution VM. > > Using the "-server" option? > Would you recommend this for Linux distribution JRE's? Why or why not? Thanks! -- | - - - - - - - - - - - - - - - - - - - - - - - - - | Steve White +49(331)7499-202 | E-Science Zi. 27 Villa Turbulenz | - - - - - - - - - - - - - - - - - - - - - - - - - | Astrophysikalisches Institut Potsdam (AIP) | An der Sternwarte 16, D-14482 Potsdam | | Vorstand: Prof. Dr. Matthias Steinmetz, Peter A. Stolz | | Stiftung privaten Rechts, Stiftungsverzeichnis Brandenburg: III/7-71-026 | - - - - - - - - - - - - - - - - - - - - - - - - - From swhite at aip.de Thu Jul 1 05:22:45 2010 From: swhite at aip.de (Steve White) Date: Thu, 1 Jul 2010 14:22:45 +0200 Subject: speed of simple loops: comparison to other language In-Reply-To: <4C2B7E8D.4070601@oracle.com> References: <20100630113752.GA26057@cashmere.aip.de> <4C2B7E8D.4070601@oracle.com> Message-ID: <20100701122245.GB12509@cashmere.aip.de> Hi, John! Thanks for your input! I think you may have misjudged my intent however. And I don't think this issue should be quickly dismissed. On 30.06.10, John Pampuch wrote: > > If you are using the same code generation (see further down), this may be > a combination of the reduced number of registers available in 32 bit mode, > combined with some anomaly of the benchmarks that allow Java to fit > critical fields more fully into registers in the 64 bit mode. What anomoly would that be? As you can see, the test code is deliberately extremely simple. > This is flaw in micro benchmarks: it is easy to find a simple case which > performs comparatively poorly for either Java or C/C++; you just need to > know a bit about how the underlying technology works. > I did not set out to show Java to be slow. Rather the opposite. This is precisely why I tried several different common tests. But the results were across-the-board. On IA36 machines, using distribution VMs, simple iterated arithmetic is generally several times slower in current Java VMs than similar code in C. As to knowing the underlying technology: I am personally interested, yes. But for the daily compiler user, they *should not* concern themselves with such issues. Precisely the purpose of the optimizer is to remove low-level efficiency concerns, so programmers can freely concentrate on writing effective code. > For more complex code, Java can often perform better than C++. > This is such a vague remark... but OK, let's talk about complex code. The efficiency of complex code hangs on the choice of algorithm, the level where programmers should concern themselves. But if such a simple operation as aritmetic iterations is slow, it will be very hard for Java to compete efficiency-wise on any level. I would maintain that it would behoove Java greatly, if such simple tests showed similar performance in Java as in C. As you said, there is no good reason why it shouldn't. Then one old, tired, ignorant complaint about Java could be easily dismissed. Cheers! -- | - - - - - - - - - - - - - - - - - - - - - - - - - | Steve White +49(331)7499-202 | E-Science Zi. 27 Villa Turbulenz | - - - - - - - - - - - - - - - - - - - - - - - - - | Astrophysikalisches Institut Potsdam (AIP) | An der Sternwarte 16, D-14482 Potsdam | | Vorstand: Prof. Dr. Matthias Steinmetz, Peter A. Stolz | | Stiftung privaten Rechts, Stiftungsverzeichnis Brandenburg: III/7-71-026 | - - - - - - - - - - - - - - - - - - - - - - - - - From aph at redhat.com Thu Jul 1 06:25:43 2010 From: aph at redhat.com (Andrew Haley) Date: Thu, 01 Jul 2010 14:25:43 +0100 Subject: speed of simple loops: comparison to other language In-Reply-To: <20100701121705.GA12509@cashmere.aip.de> References: <20100630113752.GA26057@cashmere.aip.de> <4C2B45A4.3040203@redhat.com> <20100701121705.GA12509@cashmere.aip.de> Message-ID: <4C2C9757.4070000@redhat.com> Hi, On 07/01/2010 01:17 PM, Steve White wrote: > On 30.06.10, Andrew Haley wrote: >> On 06/30/2010 12:37 PM, Steve White wrote: >>> >>> I tried building the Java VM from source for my IA-32 machine, but saw no >>> improvement in performance at all from the distribution VM. >> >> Using the "-server" option? >> > Would you recommend this for Linux distribution JRE's? For benchmarks, certainly. > Why or why not? It generates faster code at the expense of warm-up time. Andrew. From opinali at gmail.com Thu Jul 1 06:30:18 2010 From: opinali at gmail.com (Osvaldo Doederlein) Date: Thu, 1 Jul 2010 10:30:18 -0300 Subject: speed of simple loops: comparison to other language In-Reply-To: <20100701122245.GB12509@cashmere.aip.de> References: <20100630113752.GA26057@cashmere.aip.de> <4C2B7E8D.4070601@oracle.com> <20100701122245.GB12509@cashmere.aip.de> Message-ID: Hi, On 30.06.10, John Pampuch wrote: > > > > If you are using the same code generation (see further down), this may be > > a combination of the reduced number of registers available in 32 bit > mode, > > combined with some anomaly of the benchmarks that allow Java to fit > > critical fields more fully into registers in the 64 bit mode. > > What anomoly would that be? > Perhaps the single "anomaly" in these tests, is the fact that the 64-bit HotSpot doesn't have a Client VM, so it uses the Server VM by default. This is constant cause of benchmark confusion because the 32-bit VM will default to the Client VM, which has a weaker code optimizer. A fair comparison should use "-server" on the 32-bit VM. > The efficiency of complex code hangs on the choice of algorithm, the level > where programmers should concern themselves. > > But if such a simple operation as aritmetic iterations is slow, it will be > very hard for Java to compete efficiency-wise on any level. > > The simpler Client VM is a well-known tradeoff. It has substantial advantages in both memory usage and startup time. The Server VM is the only one that really competes with C/C++, but it's much more heavy-weight. And even with the Client VM being the default in the JRE installed in hundreds of millions of consumer PCs, Java already has a bad rep for its loading time and resource usage (although Sun/Oracle has been sweating to reduce these issues since JDK 6u10). This makes easy to understand the reason that Server is not the default, and it won't be any time soon. In fact, the only reason that a 64-bit port of the Client VM is not available, is that 64-bit consumer/desktop stuff is generally not very widespread yet (most browsers are 32-bit; there's no 64-bit port of other plugins like Adobe flash, etc.). But I hope this will change soon, I'd kill for a 64-bit JRE that includes the Client VM so I can make my Windows7-64 setup more "pure". On Java competitiveness, with the client VM we're talking about desktop software for which resource usage and startup time are at least as critical as speed, so the Client VM is the right choice (or at least, the best possible choice with the Sun/Oracle JDK; for an alternative that approaches a combination of Client-like resource usage with Server-like optimization [but then has other tradeoffs], look at the JET static compiler). People who run Java servers know that they must put "-server" in the launch scripts, then all is well. A+ Osvaldo > -- > | - - - - - - - - - - - - - - - - - - - - - - - - - > | Steve White +49(331)7499-202 > | E-Science Zi. 27 Villa Turbulenz > | - - - - - - - - - - - - - - - - - - - - - - - - - > | Astrophysikalisches Institut Potsdam (AIP) > | An der Sternwarte 16, D-14482 Potsdam > | > | Vorstand: Prof. Dr. Matthias Steinmetz, Peter A. Stolz > | > | Stiftung privaten Rechts, Stiftungsverzeichnis Brandenburg: III/7-71-026 > | - - - - - - - - - - - - - - - - - - - - - - - - - > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20100701/e9a92a17/attachment.html From forax at univ-mlv.fr Thu Jul 1 06:42:27 2010 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Thu, 01 Jul 2010 15:42:27 +0200 Subject: speed of simple loops: comparison to other language In-Reply-To: References: <20100630113752.GA26057@cashmere.aip.de> <4C2B7E8D.4070601@oracle.com> <20100701122245.GB12509@cashmere.aip.de> Message-ID: <4C2C9B43.5050808@univ-mlv.fr> Le 01/07/2010 15:30, Osvaldo Doederlein a ?crit : > Hi, > > On 30.06.10, John Pampuch wrote: > > > > If you are using the same code generation (see further down), > this may be > > a combination of the reduced number of registers available in 32 > bit mode, > > combined with some anomaly of the benchmarks that allow Java to fit > > critical fields more fully into registers in the 64 bit mode. > > What anomoly would that be? > > > Perhaps the single "anomaly" in these tests, is the fact that the > 64-bit HotSpot doesn't have a Client VM, so it uses the Server VM by > default. This is constant cause of benchmark confusion because the > 32-bit VM will default to the Client VM, which has a weaker code > optimizer. A fair comparison should use "-server" on the 32-bit VM. > > The efficiency of complex code hangs on the choice of algorithm, > the level > where programmers should concern themselves. > > But if such a simple operation as aritmetic iterations is slow, it > will be > very hard for Java to compete efficiency-wise on any level. > > > The simpler Client VM is a well-known tradeoff. It has substantial > advantages in both memory usage and startup time. The Server VM is the > only one that really competes with C/C++, but it's much more > heavy-weight. And even with the Client VM being the default in the JRE > installed in hundreds of millions of consumer PCs, Java already has a > bad rep for its loading time and resource usage (although Sun/Oracle > has been sweating to reduce these issues since JDK 6u10). This makes > easy to understand the reason that Server is not the default, and it > won't be any time soon. In fact, the only reason that a 64-bit port of > the Client VM is not available, is that 64-bit consumer/desktop stuff > is generally not very widespread yet (most browsers are 32-bit; > there's no 64-bit port of other plugins like Adobe flash, etc.). But I > hope this will change soon, I'd kill for a 64-bit JRE that includes > the Client VM so I can make my Windows7-64 setup more "pure". no need to kill someone :) jdk7 has a 64bit client VM. http://bugs.sun.com/view_bug.do?bug_id=6459804 > > On Java competitiveness, with the client VM we're talking about > desktop software for which resource usage and startup time are at > least as critical as speed, so the Client VM is the right choice (or > at least, the best possible choice with the Sun/Oracle JDK; for an > alternative that approaches a combination of Client-like resource > usage with Server-like optimization [but then has other tradeoffs], > look at the JET static compiler). People who run Java servers know > that they must put "-server" in the launch scripts, then all is well. > > > A+ > Osvaldo R?mi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20100701/bb7a5dae/attachment.html From swhite at aip.de Thu Jul 1 09:37:23 2010 From: swhite at aip.de (Steve White) Date: Thu, 1 Jul 2010 18:37:23 +0200 Subject: speed of simple loops: comparison to other language In-Reply-To: References: <20100630113752.GA26057@cashmere.aip.de> <4C2B7E8D.4070601@oracle.com> <20100701122245.GB12509@cashmere.aip.de> Message-ID: <20100701163723.GC12509@cashmere.aip.de> Osvaldo, Thanks for this information. I wasn't aware that the distro VM on the x86_64 was compiled with the server option. Certainly, for many applications, start-up time is crucial, and I appreciate efforts to streamline that. However, does better execution time necessarily imply slower start-up time? If the only switches available are -server or -client, then we're stuck. But maybe this just reflects an unfortunate division of the issues. Frankly it surprises me that better optimization necessarily implies substantially slower start-up time. Is it really either/or? Just a thought: it's kind of poor that the determination has to be made when building the VM. It would be much cooler to have launch-time switch that would choose such behavior. I can tell you, coming from scientific and clinical data processing communities, the decision makers frown on a factor of 3 in raw speed. (Even though, of course, we know the real issues are much more complicated!) It would be really cool to show these guys that algorithms written in their beloved Fortran runs at essentially the same speed in Java. (This is mostly the case on my x86-64 tests vs gfortran.) To these guys, it sounds like idiocy to say that much more complex code could be written in Java that might be faster than their Fortran. But one could argue that the same algorithm runs at the same speed in the two environments, and a more sophisticated one written in the more modern language could be yet faster. Anyway, a lot of our machines here happen to be x86_64, and now I have an explanation for the phenomena. Thanks a lot for your help, all of you! On 1.07.10, Osvaldo Doederlein wrote: > Hi, > > On 30.06.10, John Pampuch wrote: > > > > > > If you are using the same code generation (see further down), this may be > > > a combination of the reduced number of registers available in 32 bit > > mode, > > > combined with some anomaly of the benchmarks that allow Java to fit > > > critical fields more fully into registers in the 64 bit mode. > > > > What anomoly would that be? > > > > Perhaps the single "anomaly" in these tests, is the fact that the 64-bit > HotSpot doesn't have a Client VM, so it uses the Server VM by default. This > is constant cause of benchmark confusion because the 32-bit VM will default > to the Client VM, which has a weaker code optimizer. A fair comparison > should use "-server" on the 32-bit VM. > > > > The efficiency of complex code hangs on the choice of algorithm, the level > > where programmers should concern themselves. > > > > But if such a simple operation as aritmetic iterations is slow, it will be > > very hard for Java to compete efficiency-wise on any level. > > > > > The simpler Client VM is a well-known tradeoff. It has substantial > advantages in both memory usage and startup time. The Server VM is the only > one that really competes with C/C++, but it's much more heavy-weight. And > even with the Client VM being the default in the JRE installed in hundreds > of millions of consumer PCs, Java already has a bad rep for its loading time > and resource usage (although Sun/Oracle has been sweating to reduce these > issues since JDK 6u10). This makes easy to understand the reason that Server > is not the default, and it won't be any time soon. In fact, the only reason > that a 64-bit port of the Client VM is not available, is that 64-bit > consumer/desktop stuff is generally not very widespread yet (most browsers > are 32-bit; there's no 64-bit port of other plugins like Adobe flash, etc.). > But I hope this will change soon, I'd kill for a 64-bit JRE that includes > the Client VM so I can make my Windows7-64 setup more "pure". > > On Java competitiveness, with the client VM we're talking about desktop > software for which resource usage and startup time are at least as critical > as speed, so the Client VM is the right choice (or at least, the best > possible choice with the Sun/Oracle JDK; for an alternative that approaches > a combination of Client-like resource usage with Server-like optimization > [but then has other tradeoffs], look at the JET static compiler). People who > run Java servers know that they must put "-server" in the launch scripts, > then all is well. > > > A+ > Osvaldo > > > > -- > > | - - - - - - - - - - - - - - - - - - - - - - - - - > > | Steve White +49(331)7499-202 > > | E-Science Zi. 27 Villa Turbulenz > > | - - - - - - - - - - - - - - - - - - - - - - - - - > > | Astrophysikalisches Institut Potsdam (AIP) > > | An der Sternwarte 16, D-14482 Potsdam > > | > > | Vorstand: Prof. Dr. Matthias Steinmetz, Peter A. Stolz > > | > > | Stiftung privaten Rechts, Stiftungsverzeichnis Brandenburg: III/7-71-026 > > | - - - - - - - - - - - - - - - - - - - - - - - - - > > -- | - - - - - - - - - - - - - - - - - - - - - - - - - | Steve White +49(331)7499-202 | E-Science Zi. 27 Villa Turbulenz | - - - - - - - - - - - - - - - - - - - - - - - - - | Astrophysikalisches Institut Potsdam (AIP) | An der Sternwarte 16, D-14482 Potsdam | | Vorstand: Prof. Dr. Matthias Steinmetz, Peter A. Stolz | | Stiftung privaten Rechts, Stiftungsverzeichnis Brandenburg: III/7-71-026 | - - - - - - - - - - - - - - - - - - - - - - - - - From swhite at aip.de Thu Jul 1 09:45:34 2010 From: swhite at aip.de (Steve White) Date: Thu, 1 Jul 2010 18:45:34 +0200 Subject: speed of simple loops: comparison to other language In-Reply-To: References: <20100630113752.GA26057@cashmere.aip.de> <4C2B7E8D.4070601@oracle.com> <20100701122245.GB12509@cashmere.aip.de> Message-ID: <20100701164534.GD12509@cashmere.aip.de> Hi again, Immediately after sending off the last message, I realize I misunderstood the -server switch to be a compile-time switch. Indeed, with the java run-time -server switch, the Java code is competitive with the C and C++. This is all I need for my purposes. For now I hold by all the other stuff I said, although it just doesn't matter so much! Thank you all very much, again! -- | - - - - - - - - - - - - - - - - - - - - - - - - - | Steve White +49(331)7499-202 | E-Science Zi. 27 Villa Turbulenz | - - - - - - - - - - - - - - - - - - - - - - - - - | Astrophysikalisches Institut Potsdam (AIP) | An der Sternwarte 16, D-14482 Potsdam | | Vorstand: Prof. Dr. Matthias Steinmetz, Peter A. Stolz | | Stiftung privaten Rechts, Stiftungsverzeichnis Brandenburg: III/7-71-026 | - - - - - - - - - - - - - - - - - - - - - - - - - From aph at redhat.com Thu Jul 1 09:42:32 2010 From: aph at redhat.com (Andrew Haley) Date: Thu, 01 Jul 2010 17:42:32 +0100 Subject: speed of simple loops: comparison to other language In-Reply-To: <20100701163723.GC12509@cashmere.aip.de> References: <20100630113752.GA26057@cashmere.aip.de> <4C2B7E8D.4070601@oracle.com> <20100701122245.GB12509@cashmere.aip.de> <20100701163723.GC12509@cashmere.aip.de> Message-ID: <4C2CC578.1080002@redhat.com> On 07/01/2010 05:37 PM, Steve White wrote: > However, does better execution time necessarily imply slower start-up time? > If the only switches available are -server or -client, then we're stuck. > But maybe this just reflects an unfortunate division of the issues. > Frankly it surprises me that better optimization necessarily implies > substantially slower start-up time. > > Is it really either/or? Optimization is a computationally expensive job, so to some extent that can't be helped. > Just a thought: it's kind of poor that the determination has to be made > when building the VM. It would be much cooler to have launch-time switch > that would choose such behavior. Sure, it would, but AFAIK no-one has ever written a client compiler for x86_64, so we're kinda stuck. :-) Andrew. From opinali at gmail.com Thu Jul 1 11:45:07 2010 From: opinali at gmail.com (Osvaldo Doederlein) Date: Thu, 1 Jul 2010 15:45:07 -0300 Subject: speed of simple loops: comparison to other language In-Reply-To: <4C2C9B43.5050808@univ-mlv.fr> References: <20100630113752.GA26057@cashmere.aip.de> <4C2B7E8D.4070601@oracle.com> <20100701122245.GB12509@cashmere.aip.de> <4C2C9B43.5050808@univ-mlv.fr> Message-ID: Hi R?mi, The simpler Client VM is a well-known tradeoff. It has substantial > advantages in both memory usage and startup time. The Server VM is the only > one that really competes with C/C++, but it's much more heavy-weight. And > even with the Client VM being the default in the JRE installed in hundreds > of millions of consumer PCs, Java already has a bad rep for its loading time > and resource usage (although Sun/Oracle has been sweating to reduce these > issues since JDK 6u10). This makes easy to understand the reason that Server > is not the default, and it won't be any time soon. In fact, the only reason > that a 64-bit port of the Client VM is not available, is that 64-bit > consumer/desktop stuff is generally not very widespread yet (most browsers > are 32-bit; there's no 64-bit port of other plugins like Adobe flash, etc.). > But I hope this will change soon, I'd kill for a 64-bit JRE that includes > the Client VM so I can make my Windows7-64 setup more "pure". > > > no need to kill someone :) > jdk7 has a 64bit client VM. > http://bugs.sun.com/view_bug.do?bug_id=6459804 > > This looks great, I didn't notice it because I'm on Windows and the 64-bit Client VM is not yet available for that platform. I guess it is for Linux (which 64-bit JDK download is just as big as the 32-bit one, differently from Windows which 64-bit build is 9Mb smaller because it doesn't include Client). Well, I guess just need to wait a few more builds until C1 comes to Win64? Hopefully that will also have UseCompressedOops on by default when heap size is sufficiently "small", otherwise 64-bit applets or JAWS apps will remain overweight... While we're at this, any idea if Oracle plans to solve the problem of double isolation of plugin2 in new browsers? (Latest versions of most browsers already isolate native plugins in separate processes, so the extra isolation created by plugin2 has become redundant and just adds overhead.) A+ Osvaldo -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20100701/f600c468/attachment.html From tom.rodriguez at oracle.com Thu Jul 1 12:00:40 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 1 Jul 2010 12:00:40 -0700 Subject: speed of simple loops: comparison to other language In-Reply-To: References: <20100630113752.GA26057@cashmere.aip.de> <4C2B7E8D.4070601@oracle.com> <20100701122245.GB12509@cashmere.aip.de> <4C2C9B43.5050808@univ-mlv.fr> Message-ID: <0327CB6C-7E5B-45C1-AAE1-8F6A3DB50079@oracle.com> > no need to kill someone :) > jdk7 has a 64bit client VM. > http://bugs.sun.com/view_bug.do?bug_id=6459804 > > > This looks great, I didn't notice it because I'm on Windows and the 64-bit Client VM is not yet available for that platform. I guess it is for Linux (which 64-bit JDK download is just as big as the 32-bit one, differently from Windows which 64-bit build is 9Mb smaller because it doesn't include Client). > > Well, I guess just need to wait a few more builds until C1 comes to Win64? We'll never ship a stand alone 64 bit client vm. 64 C1 is going to be used as part of a tiered system with both client and server in the same binary so you'll get good startup and good peak performance. > Hopefully that will also have UseCompressedOops on by default when heap size is sufficiently "small", otherwise 64-bit applets or JAWS apps will remain overweight... C1 doesn't currently support compressed oops but it will eventually in the tiered system. tom > > While we're at this, any idea if Oracle plans to solve the problem of double isolation of plugin2 in new browsers? (Latest versions of most browsers already isolate native plugins in separate processes, so the extra isolation created by plugin2 has become redundant and just adds overhead.) > > A+ > Osvaldo From opinali at gmail.com Thu Jul 1 12:45:48 2010 From: opinali at gmail.com (Osvaldo Doederlein) Date: Thu, 1 Jul 2010 16:45:48 -0300 Subject: speed of simple loops: comparison to other language In-Reply-To: <0327CB6C-7E5B-45C1-AAE1-8F6A3DB50079@oracle.com> References: <20100630113752.GA26057@cashmere.aip.de> <4C2B7E8D.4070601@oracle.com> <20100701122245.GB12509@cashmere.aip.de> <4C2C9B43.5050808@univ-mlv.fr> <0327CB6C-7E5B-45C1-AAE1-8F6A3DB50079@oracle.com> Message-ID: Hi Tom, 2010/7/1 Tom Rodriguez > > > Well, I guess just need to wait a few more builds until C1 comes to > Win64? > > We'll never ship a stand alone 64 bit client vm. 64 C1 is going to be used > as part of a tiered system with both client and server in the same binary so > you'll get good startup and good peak performance. > Great news. I've been tracking the tiered compiler effort, indeed I've noticed some time ago that it's already functional (but doesn't have expected performance traits, at least in the 32-bit VM last time I checked - I guess due to heuristics not good enough yet). If the tiered compiler is a release driver for JDK7, that will be an even-more kick-ass release. A+ Osvaldo > > > Hopefully that will also have UseCompressedOops on by default when heap > size is sufficiently "small", otherwise 64-bit applets or JAWS apps will > remain overweight... > > C1 doesn't currently support compressed oops but it will eventually in the > tiered system. > > tom > > > > > While we're at this, any idea if Oracle plans to solve the problem of > double isolation of plugin2 in new browsers? (Latest versions of most > browsers already isolate native plugins in separate processes, so the extra > isolation created by plugin2 has become redundant and just adds overhead.) > > > > A+ > > Osvaldo > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20100701/05188b0e/attachment.html From john.pampuch at oracle.com Thu Jul 1 13:10:06 2010 From: john.pampuch at oracle.com (John Pampuch) Date: Thu, 01 Jul 2010 13:10:06 -0700 Subject: speed of simple loops: comparison to other language In-Reply-To: <20100701122245.GB12509@cashmere.aip.de> References: <20100630113752.GA26057@cashmere.aip.de> <4C2B7E8D.4070601@oracle.com> <20100701122245.GB12509@cashmere.aip.de> Message-ID: <4C2CF61E.3050903@oracle.com> An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20100701/33d36d03/attachment.html From tom.rodriguez at oracle.com Thu Jul 1 13:58:18 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 1 Jul 2010 13:58:18 -0700 Subject: review (S) for 6965671: fatal error: acquiring lock JNIGlobalHandle_lock/16 out of order with lock CodeCache_lock/1 Message-ID: http://cr.openjdk.java.net/~never/6965671/ 6965671: fatal error: acquiring lock JNIGlobalHandle_lock/16 out of order with lock CodeCache_lock/1 Reviewed-by: The jmethodID fix created a deadlock because of lock ordering when walking the CodeCache to generate CompiledMethodLoad events. The walk is performed with the CodeCache_lock held but we need to acquire the JNIGlobalHandle_lock to make a jmethodID. I considered switching back to collecting the methodOop instead of the jmethodID under the lock but inspection of the code made it clear that there's a preexisting problem with GC of the methodOops stored into the nmethodDesc. Instead I switched to a simpler implementation that holds the CodeCache_lock while walking the CodeCache but releases the lock to actually perform the notify. This simplifies the code greatly as well as fixing the bug. Tested with NSK jvmti,jdi,jdb,hprof,jit,regression and JDI_REGRESSION tests. From vladimir.kozlov at oracle.com Thu Jul 1 14:36:56 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 01 Jul 2010 14:36:56 -0700 Subject: review (S) for 6965671: fatal error: acquiring lock JNIGlobalHandle_lock/16 out of order with lock CodeCache_lock/1 In-Reply-To: References: Message-ID: <4C2D0A78.5020906@oracle.com> You did not explain your changes for cb->name(). Why we don't lock nmethod in sweeper during CodeCache walk but lock here? Thanks, Vladimir On 7/1/10 1:58 PM, Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/6965671/ > > 6965671: fatal error: acquiring lock JNIGlobalHandle_lock/16 out of order with lock CodeCache_lock/1 > Reviewed-by: > > The jmethodID fix created a deadlock because of lock ordering when > walking the CodeCache to generate CompiledMethodLoad events. The walk > is performed with the CodeCache_lock held but we need to acquire the > JNIGlobalHandle_lock to make a jmethodID. I considered switching back > to collecting the methodOop instead of the jmethodID under the lock > but inspection of the code made it clear that there's a preexisting > problem with GC of the methodOops stored into the nmethodDesc. > Instead I switched to a simpler implementation that holds the > CodeCache_lock while walking the CodeCache but releases the lock to > actually perform the notify. This simplifies the code greatly as well > as fixing the bug. > > Tested with NSK jvmti,jdi,jdb,hprof,jit,regression and JDI_REGRESSION > tests. From vladimir.kozlov at oracle.com Thu Jul 1 14:39:57 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 01 Jul 2010 14:39:57 -0700 Subject: review (S) for 6965671: fatal error: acquiring lock JNIGlobalHandle_lock/16 out of order with lock CodeCache_lock/1 In-Reply-To: <4C2D0A78.5020906@oracle.com> References: <4C2D0A78.5020906@oracle.com> Message-ID: <4C2D0B2D.3050409@oracle.com> On 7/1/10 2:36 PM, Vladimir Kozlov wrote: > You did not explain your changes for cb->name(). > > Why we don't lock nmethod in sweeper during CodeCache walk but lock here? Because only one (compiler) thread do walking and free nmethods. Right? Vladimir > > Thanks, > Vladimir > > On 7/1/10 1:58 PM, Tom Rodriguez wrote: >> http://cr.openjdk.java.net/~never/6965671/ >> >> 6965671: fatal error: acquiring lock JNIGlobalHandle_lock/16 out of order with lock CodeCache_lock/1 >> Reviewed-by: >> >> The jmethodID fix created a deadlock because of lock ordering when >> walking the CodeCache to generate CompiledMethodLoad events. The walk >> is performed with the CodeCache_lock held but we need to acquire the >> JNIGlobalHandle_lock to make a jmethodID. I considered switching back >> to collecting the methodOop instead of the jmethodID under the lock >> but inspection of the code made it clear that there's a preexisting >> problem with GC of the methodOops stored into the nmethodDesc. >> Instead I switched to a simpler implementation that holds the >> CodeCache_lock while walking the CodeCache but releases the lock to >> actually perform the notify. This simplifies the code greatly as well >> as fixing the bug. >> >> Tested with NSK jvmti,jdi,jdb,hprof,jit,regression and JDI_REGRESSION >> tests. From tom.rodriguez at oracle.com Thu Jul 1 14:41:02 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 1 Jul 2010 14:41:02 -0700 Subject: review (S) for 6965671: fatal error: acquiring lock JNIGlobalHandle_lock/16 out of order with lock CodeCache_lock/1 In-Reply-To: <4C2D0A78.5020906@oracle.com> References: <4C2D0A78.5020906@oracle.com> Message-ID: On Jul 1, 2010, at 2:36 PM, Vladimir Kozlov wrote: > You did not explain your changes for cb->name(). That was just a clean up I've been wanting to do. There was a time then only some of the CodeBlob subclasses had name() methods but now it's part of CodeBlob so that logic is unnecessary. > Why we don't lock nmethod in sweeper during CodeCache walk but lock here? nmethodLocker protects you from the sweeper so the sweeper doesn't need protection. tom > > Thanks, > Vladimir > > On 7/1/10 1:58 PM, Tom Rodriguez wrote: >> http://cr.openjdk.java.net/~never/6965671/ >> >> 6965671: fatal error: acquiring lock JNIGlobalHandle_lock/16 out of order with lock CodeCache_lock/1 >> Reviewed-by: >> >> The jmethodID fix created a deadlock because of lock ordering when >> walking the CodeCache to generate CompiledMethodLoad events. The walk >> is performed with the CodeCache_lock held but we need to acquire the >> JNIGlobalHandle_lock to make a jmethodID. I considered switching back >> to collecting the methodOop instead of the jmethodID under the lock >> but inspection of the code made it clear that there's a preexisting >> problem with GC of the methodOops stored into the nmethodDesc. >> Instead I switched to a simpler implementation that holds the >> CodeCache_lock while walking the CodeCache but releases the lock to >> actually perform the notify. This simplifies the code greatly as well >> as fixing the bug. >> >> Tested with NSK jvmti,jdi,jdb,hprof,jit,regression and JDI_REGRESSION >> tests. From vladimir.kozlov at oracle.com Thu Jul 1 14:55:13 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 01 Jul 2010 14:55:13 -0700 Subject: review (S) for 6965671: fatal error: acquiring lock JNIGlobalHandle_lock/16 out of order with lock CodeCache_lock/1 In-Reply-To: References: <4C2D0A78.5020906@oracle.com> Message-ID: <4C2D0EC1.4090607@oracle.com> Thanks, Tom Changes are good to go. Vladimir On 7/1/10 2:41 PM, Tom Rodriguez wrote: > > On Jul 1, 2010, at 2:36 PM, Vladimir Kozlov wrote: > >> You did not explain your changes for cb->name(). > > That was just a clean up I've been wanting to do. There was a time then only some of the CodeBlob subclasses had name() methods but now it's part of CodeBlob so that logic is unnecessary. > >> Why we don't lock nmethod in sweeper during CodeCache walk but lock here? > > nmethodLocker protects you from the sweeper so the sweeper doesn't need protection. > > tom > >> >> Thanks, >> Vladimir >> >> On 7/1/10 1:58 PM, Tom Rodriguez wrote: >>> http://cr.openjdk.java.net/~never/6965671/ >>> >>> 6965671: fatal error: acquiring lock JNIGlobalHandle_lock/16 out of order with lock CodeCache_lock/1 >>> Reviewed-by: >>> >>> The jmethodID fix created a deadlock because of lock ordering when >>> walking the CodeCache to generate CompiledMethodLoad events. The walk >>> is performed with the CodeCache_lock held but we need to acquire the >>> JNIGlobalHandle_lock to make a jmethodID. I considered switching back >>> to collecting the methodOop instead of the jmethodID under the lock >>> but inspection of the code made it clear that there's a preexisting >>> problem with GC of the methodOops stored into the nmethodDesc. >>> Instead I switched to a simpler implementation that holds the >>> CodeCache_lock while walking the CodeCache but releases the lock to >>> actually perform the notify. This simplifies the code greatly as well >>> as fixing the bug. >>> >>> Tested with NSK jvmti,jdi,jdb,hprof,jit,regression and JDI_REGRESSION >>> tests. > From tom.rodriguez at oracle.com Thu Jul 1 16:02:34 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 1 Jul 2010 16:02:34 -0700 Subject: review (S) for 6965671: fatal error: acquiring lock JNIGlobalHandle_lock/16 out of order with lock CodeCache_lock/1 In-Reply-To: <4C2D0EC1.4090607@oracle.com> References: <4C2D0A78.5020906@oracle.com> <4C2D0EC1.4090607@oracle.com> Message-ID: Thanks. Dan also reviewed this as I was developing it. tom On Jul 1, 2010, at 2:55 PM, Vladimir Kozlov wrote: > Thanks, Tom > > Changes are good to go. > > Vladimir > > On 7/1/10 2:41 PM, Tom Rodriguez wrote: >> >> On Jul 1, 2010, at 2:36 PM, Vladimir Kozlov wrote: >> >>> You did not explain your changes for cb->name(). >> >> That was just a clean up I've been wanting to do. There was a time then only some of the CodeBlob subclasses had name() methods but now it's part of CodeBlob so that logic is unnecessary. >> >>> Why we don't lock nmethod in sweeper during CodeCache walk but lock here? >> >> nmethodLocker protects you from the sweeper so the sweeper doesn't need protection. >> >> tom >> >>> >>> Thanks, >>> Vladimir >>> >>> On 7/1/10 1:58 PM, Tom Rodriguez wrote: >>>> http://cr.openjdk.java.net/~never/6965671/ >>>> >>>> 6965671: fatal error: acquiring lock JNIGlobalHandle_lock/16 out of order with lock CodeCache_lock/1 >>>> Reviewed-by: >>>> >>>> The jmethodID fix created a deadlock because of lock ordering when >>>> walking the CodeCache to generate CompiledMethodLoad events. The walk >>>> is performed with the CodeCache_lock held but we need to acquire the >>>> JNIGlobalHandle_lock to make a jmethodID. I considered switching back >>>> to collecting the methodOop instead of the jmethodID under the lock >>>> but inspection of the code made it clear that there's a preexisting >>>> problem with GC of the methodOops stored into the nmethodDesc. >>>> Instead I switched to a simpler implementation that holds the >>>> CodeCache_lock while walking the CodeCache but releases the lock to >>>> actually perform the notify. This simplifies the code greatly as well >>>> as fixing the bug. >>>> >>>> Tested with NSK jvmti,jdi,jdb,hprof,jit,regression and JDI_REGRESSION >>>> tests. >> From Ulf.Zibis at gmx.de Thu Jul 1 17:23:00 2010 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Fri, 02 Jul 2010 02:23:00 +0200 Subject: speed of simple loops: comparison to other language In-Reply-To: <20100630113752.GA26057@cashmere.aip.de> References: <20100630113752.GA26057@cashmere.aip.de> Message-ID: <4C2D3164.5060609@gmx.de> Steve, there are some pending RFE's, which are related to the performance of arithmetic and loops: Bug Id:6932837 - Better use unsigned jump if one of the range limits is 0 Bug Id:6933327 - Use shifted addressing modes instead of shift instructions Bug Id:6932852 - HotSpot could do much better with do...while loop Bug Id:6932855 - Save superfluous CMP instruction from while loop Bug Id:6914095 - HotSpot should reuse invariant loop parameter Maybe it's interesting you. -Ulf Am 30.06.2010 13:37, schrieb Steve White: > Hi, > > I have some questions regarding the raw computing speed of the Java VM. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20100702/95a234bc/attachment.html From tom.rodriguez at oracle.com Thu Jul 1 18:52:05 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 1 Jul 2010 18:52:05 -0700 Subject: review (S) for 6958668: repeated uncommon trapping for new of klass which is being initialized Message-ID: http://cr.openjdk.java.net/~never/6958668 6958668: repeated uncommon trapping for new of klass which is being initialized Reviewed-by: During the execution of a class initializer only the initializing thread is allowed to create instances of the class. Currently in C2 this is handled by emitting an uncommon trap. If an application creates a lot of instances using this idiom it can lead to long sequences of compile, uncommon trap, recompile, uncommon trap. Instead C2 should emit a guarded new that allows the proper thread to perform allocations throws out the code once initialization is complete. Ideally we should just be able to test that the init_thread is the current thread but the init_thread is never set back to null so the init_state is additionally being checked. I'm planning to separately fix the clearing the init_thread since C1 mistakenly expects it to be cleared. This fix is going to be backported to an update at some point. Tested with users application and test case which I haven't bothered including though it is in the bug report. From vladimir.kozlov at oracle.com Thu Jul 1 19:35:36 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 01 Jul 2010 19:35:36 -0700 Subject: review (S) for 6958668: repeated uncommon trapping for new of klass which is being initialized In-Reply-To: References: Message-ID: <4C2D5078.8070703@oracle.com> Looks good. Vladimir On 7/1/10 6:52 PM, Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/6958668 > > 6958668: repeated uncommon trapping for new of klass which is being initialized > Reviewed-by: > > During the execution of a class initializer only the initializing > thread is allowed to create instances of the class. Currently in C2 > this is handled by emitting an uncommon trap. If an application > creates a lot of instances using this idiom it can lead to long > sequences of compile, uncommon trap, recompile, uncommon trap. > Instead C2 should emit a guarded new that allows the proper thread to > perform allocations throws out the code once initialization is > complete. Ideally we should just be able to test that the init_thread > is the current thread but the init_thread is never set back to null so > the init_state is additionally being checked. I'm planning to > separately fix the clearing the init_thread since C1 mistakenly > expects it to be cleared. This fix is going to be backported to an > update at some point. Tested with users application and test case > which I haven't bothered including though it is in the bug report. From john.coomes at oracle.com Thu Jul 1 21:20:32 2010 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 02 Jul 2010 04:20:32 +0000 Subject: hg: jdk7/hotspot-comp: 4 new changesets Message-ID: <20100702042033.00CB6476D5@hg.openjdk.java.net> Changeset: dc900d5a8e2f Author: mikejwre Date: 2010-06-24 20:02 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/rev/dc900d5a8e2f Added tag jdk7-b99 for changeset e7f18db469a3 ! .hgtags Changeset: 47f6b7db1882 Author: ohair Date: 2010-06-21 11:00 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/rev/47f6b7db1882 6960853: Cleanup makefiles, remove unused vars etc. 6959596: Windows fastdebug build broken 6960335: Add top level 'make test' rule that uses test/Makefile, runs all test batches Reviewed-by: alanb ! Makefile ! make/Defs-internal.gmk ! make/jprt.gmk ! make/sanity-rules.gmk ! test/Makefile Changeset: 3b147bf5a0e9 Author: lana Date: 2010-06-21 22:06 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/rev/3b147bf5a0e9 Merge Changeset: b218a53ec7d3 Author: lana Date: 2010-06-29 22:31 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/rev/b218a53ec7d3 Merge From john.coomes at oracle.com Thu Jul 1 21:20:38 2010 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 02 Jul 2010 04:20:38 +0000 Subject: hg: jdk7/hotspot-comp/corba: 5 new changesets Message-ID: <20100702042044.38BA8476D6@hg.openjdk.java.net> Changeset: ad2aa1f66abf Author: mikejwre Date: 2010-06-24 20:02 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/corba/rev/ad2aa1f66abf Added tag jdk7-b99 for changeset 95db968660e7 ! .hgtags Changeset: 032585ad970d Author: jjg Date: 2010-06-14 11:28 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/corba/rev/032585ad970d 6960831: fix CORBA build warnings Reviewed-by: darcy ! src/share/classes/com/sun/corba/se/impl/orbutil/CorbaResourceUtil.java ! src/share/classes/com/sun/corba/se/impl/orbutil/ObjectUtility.java ! src/share/classes/com/sun/corba/se/impl/presentation/rmi/ExceptionHandlerImpl.java ! src/share/classes/org/omg/CORBA/ORB.java ! src/share/classes/sun/corba/Bridge.java Changeset: 8f0a1a30461d Author: lana Date: 2010-06-16 13:41 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/corba/rev/8f0a1a30461d Merge Changeset: 8eeca6e452de Author: lana Date: 2010-06-21 22:06 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/corba/rev/8eeca6e452de Merge Changeset: a56d734a1e97 Author: lana Date: 2010-06-29 22:31 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/corba/rev/a56d734a1e97 Merge From john.coomes at oracle.com Thu Jul 1 21:31:44 2010 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 02 Jul 2010 04:31:44 +0000 Subject: hg: jdk7/hotspot-comp/jaxp: 5 new changesets Message-ID: <20100702043144.D8ADC476D7@hg.openjdk.java.net> Changeset: 69a11eec2789 Author: mikejwre Date: 2010-06-24 20:03 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxp/rev/69a11eec2789 Added tag jdk7-b99 for changeset 7ef8469021fb ! .hgtags Changeset: 214f47923c24 Author: ohair Date: 2010-06-17 10:43 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxp/rev/214f47923c24 6955301: Update names and references to rebranded drop bundles (jaxp, jaxws, jaf) Reviewed-by: darcy ! jaxp.properties Changeset: 961ad5ff3b19 Author: ohair Date: 2010-06-17 10:50 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxp/rev/961ad5ff3b19 6955292: Workaround ant 1.7.1 package-info.java issue in ant scripts 6960333: Add make level ALLOW_DOWNLOADS=true option 6940241: Change jaxp/jaxws so that the http downloads are not done by default Reviewed-by: darcy ! build-defs.xml ! build-drop-template.xml ! build.properties ! build.xml ! make/Makefile Changeset: 478835e100cd Author: lana Date: 2010-06-21 22:07 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxp/rev/478835e100cd Merge Changeset: d524be5ef62e Author: lana Date: 2010-06-29 22:31 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxp/rev/d524be5ef62e Merge From john.coomes at oracle.com Thu Jul 1 21:31:48 2010 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 02 Jul 2010 04:31:48 +0000 Subject: hg: jdk7/hotspot-comp/jaxws: 5 new changesets Message-ID: <20100702043148.A588D476D8@hg.openjdk.java.net> Changeset: 5bca7bc114a0 Author: mikejwre Date: 2010-06-24 20:03 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxws/rev/5bca7bc114a0 Added tag jdk7-b99 for changeset 818366ce23d8 ! .hgtags Changeset: 38fd32b8e990 Author: ohair Date: 2010-06-17 17:18 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxws/rev/38fd32b8e990 6869741: Integrate JAX-WS 2.2 and JAXB 2.2 in JDK 7 Reviewed-by: darcy, ramap ! jaxws.properties Changeset: 48872561d4b1 Author: ohair Date: 2010-06-17 17:19 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxws/rev/48872561d4b1 6955292: Workaround ant 1.7.1 package-info.java issue in ant scripts 6940241: Change jaxp/jaxws so that the http downloads are not done by default 6960333: Add make level ALLOW_DOWNLOADS=true option Reviewed-by: darcy, ramap ! build-defs.xml ! build-drop-template.xml ! build.properties ! build.xml ! make/Makefile Changeset: db63f482182d Author: lana Date: 2010-06-21 22:07 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxws/rev/db63f482182d Merge Changeset: bd26d0ce0c3c Author: lana Date: 2010-06-29 22:31 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxws/rev/bd26d0ce0c3c Merge From john.coomes at oracle.com Thu Jul 1 21:33:31 2010 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 02 Jul 2010 04:33:31 +0000 Subject: hg: jdk7/hotspot-comp/jdk: 70 new changesets Message-ID: <20100702044502.37B22476DA@hg.openjdk.java.net> Changeset: 3956cdee6712 Author: mikejwre Date: 2010-06-24 20:03 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/3956cdee6712 Added tag jdk7-b99 for changeset 2587c9f0b60d ! .hgtags Changeset: 4d55419ce99e Author: andrew Date: 2010-06-08 17:52 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/4d55419ce99e 6959123: Remove use of obsolete png_check_sig function in splashscreen_png.c Summary: Avoid use of deprecated libpng macro (removed in some 1.4.x releases) Reviewed-by: prr ! src/share/native/sun/awt/splashscreen/splashscreen_png.c Changeset: 2574d999704a Author: igor Date: 2010-06-10 15:00 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/2574d999704a 6952043: Incorrect JNI calls in fontpath.c Reviewed-by: jgodinez, prr ! src/windows/native/sun/font/fontpath.c Changeset: ae887ea4c772 Author: lana Date: 2010-06-10 18:58 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/ae887ea4c772 Merge - make/com/sun/inputmethods/Makefile - make/com/sun/inputmethods/indicim/Makefile - make/com/sun/inputmethods/thaiim/Makefile - src/share/classes/com/sun/inputmethods/internal/indicim/DevanagariInputMethodDescriptor.java - src/share/classes/com/sun/inputmethods/internal/indicim/DevanagariTables.java - src/share/classes/com/sun/inputmethods/internal/indicim/IndicInputMethod.java - src/share/classes/com/sun/inputmethods/internal/indicim/IndicInputMethodImpl.java - src/share/classes/com/sun/inputmethods/internal/indicim/java.awt.im.spi.InputMethodDescriptor - src/share/classes/com/sun/inputmethods/internal/indicim/resources/DisplayNames.properties - src/share/classes/com/sun/inputmethods/internal/indicim/resources/DisplayNames_de.properties - src/share/classes/com/sun/inputmethods/internal/indicim/resources/DisplayNames_es.properties - src/share/classes/com/sun/inputmethods/internal/indicim/resources/DisplayNames_fr.properties - src/share/classes/com/sun/inputmethods/internal/indicim/resources/DisplayNames_it.properties - src/share/classes/com/sun/inputmethods/internal/indicim/resources/DisplayNames_ja.properties - src/share/classes/com/sun/inputmethods/internal/indicim/resources/DisplayNames_ko.properties - src/share/classes/com/sun/inputmethods/internal/indicim/resources/DisplayNames_sv.properties - src/share/classes/com/sun/inputmethods/internal/indicim/resources/DisplayNames_zh_CN.properties - src/share/classes/com/sun/inputmethods/internal/indicim/resources/DisplayNames_zh_TW.properties - src/share/classes/com/sun/inputmethods/internal/thaiim/ThaiInputMethod.java - src/share/classes/com/sun/inputmethods/internal/thaiim/ThaiInputMethodDescriptor.java - src/share/classes/com/sun/inputmethods/internal/thaiim/ThaiInputMethodImpl.java - src/share/classes/com/sun/inputmethods/internal/thaiim/ThaiRules.java - src/share/classes/com/sun/inputmethods/internal/thaiim/java.awt.im.spi.InputMethodDescriptor - src/share/classes/com/sun/inputmethods/internal/thaiim/resources/DisplayNames.properties - src/share/classes/javax/swing/text/html/parser/html32.bdtd - src/share/classes/sun/security/tools/PolicyTool.java Changeset: 8b55669c7b7a Author: neugens Date: 2010-06-16 20:46 +0200 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/8b55669c7b7a 6961732: FontMetrics.getLeading() may be negative in freetype-based OpenJDK builds. Summary: Fix premature integer roundings to preserve correct height, width and descent values for fonts Reviewed-by: prr ! src/share/native/sun/font/freetypeScaler.c Changeset: 83c7768292d7 Author: prr Date: 2010-06-18 11:00 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/83c7768292d7 6961633: gui applications cause a jvm crash on windows Reviewed-by: ceisserer, bae ! make/sun/pisces/Makefile ! src/share/classes/sun/java2d/pisces/META-INF/services/sun.java2d.pipe.RenderingEngine + src/solaris/classes/sun/java2d/pisces/META-INF/services/sun.java2d.pipe.RenderingEngine Changeset: 31d25fccdf1c Author: lana Date: 2010-06-21 22:04 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/31d25fccdf1c Merge Changeset: c02096d7b70e Author: anthony Date: 2010-06-16 11:26 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/c02096d7b70e 6959787: java/awt/FileDialog/FilenameFilterTest/FilenameFilterTest.html failed on 7b94 Summary: Add a delay to the test to make sure the filename filters are called. Reviewed-by: dcherepanov, art ! test/java/awt/FileDialog/FilenameFilterTest/FilenameFilterTest.java Changeset: fa06ad055c43 Author: coffeys Date: 2010-06-16 16:15 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/fa06ad055c43 6860491: WRAP_TIME_MILLIS incorrectly set Summary: Alter WRAP_TIME_MILLIS to be unsigned Reviewed-by: yan ! src/solaris/classes/sun/awt/X11/XToolkit.java Changeset: 8722b75c9ccd Author: anthony Date: 2010-06-18 17:09 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/8722b75c9ccd 6959165: JVM crash during execution FileDialogBufferOverflowTest.html Summary: Add proper synchronization Reviewed-by: art, dcherepanov ! src/solaris/native/sun/awt/sun_awt_X11_GtkFileDialogPeer.c Changeset: 05eb107d6891 Author: anthony Date: 2010-06-18 17:13 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/05eb107d6891 6961754: JCK tests CvsEventTest0001 and CvsEventTest0002 fail under FF 3.5 on OEL 5 Summary: Check the return value of XlibUtil.translateCoordinates() for null Reviewed-by: art, dcherepanov ! src/solaris/classes/sun/awt/X11/XEmbeddedFramePeer.java ! src/solaris/classes/sun/awt/X11/XToolkit.java Changeset: ae16c200341a Author: lana Date: 2010-06-21 22:05 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/ae16c200341a Merge Changeset: ad5f65797249 Author: rupashka Date: 2010-06-02 11:59 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/ad5f65797249 6857057: api/javax_swing/text/GlyphView/index.html#Methods test fails Reviewed-by: peterz ! src/share/classes/javax/swing/text/Utilities.java ! src/share/classes/javax/swing/text/WrappedPlainView.java + test/javax/swing/text/WrappedPlainView/6857057/StubBranchElement.java + test/javax/swing/text/WrappedPlainView/6857057/StubLeafElement.java + test/javax/swing/text/WrappedPlainView/6857057/bug6857057.java Changeset: dc14ee238fe3 Author: rupashka Date: 2010-06-02 12:53 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/dc14ee238fe3 6636983: Japanese text does not display correctly in a JEditorPane Reviewed-by: peterz ! src/share/classes/javax/swing/text/DefaultStyledDocument.java ! src/share/classes/javax/swing/text/GlyphView.java ! src/share/classes/javax/swing/text/html/HTMLDocument.java ! src/share/classes/sun/swing/SwingUtilities2.java + test/javax/swing/text/DefaultStyledDocument/6636983/bug6636983.java Changeset: d1c875d94263 Author: lana Date: 2010-06-10 14:18 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/d1c875d94263 Merge - src/share/classes/sun/security/tools/PolicyTool.java Changeset: 7a3d8fc0d2cd Author: malenkov Date: 2010-06-15 17:39 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/7a3d8fc0d2cd 5066685: BorderFactory lacks SoftBevelBorder support Reviewed-by: alexp ! src/share/classes/javax/swing/BorderFactory.java Changeset: cf13f6389bdd Author: alexp Date: 2010-06-15 19:05 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/cf13f6389bdd 6788484: NPE in DefaultTableCellHeaderRenderer.getColumnSortOrder() with null table Reviewed-by: rupashka ! src/share/classes/sun/swing/table/DefaultTableCellHeaderRenderer.java + test/javax/swing/JTable/6788484/bug6788484.java Changeset: 5e4969391538 Author: alexp Date: 2010-06-15 19:10 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/5e4969391538 6735259: NPE at WindowsComboBoxUI$XPComboBoxButton.getState(WindowsComboBoxUI.java:408) Reviewed-by: rupashka ! src/share/classes/com/sun/java/swing/plaf/windows/WindowsComboBoxUI.java Changeset: cd565c554dc6 Author: alexp Date: 2010-06-15 21:28 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/cd565c554dc6 6771547: SynthParser throws StringIndexOutOfBoundsException parsing custom ColorTypes Reviewed-by: rupashka ! src/share/classes/javax/swing/plaf/synth/SynthParser.java + test/javax/swing/plaf/synth/6771547/SynthTest.java + test/javax/swing/plaf/synth/6771547/synthconfig.xml Changeset: 4d93c409ce87 Author: alexp Date: 2010-06-15 21:32 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/4d93c409ce87 6739756: JToolBar leaves space for non-visible items under Nimbus L&F Reviewed-by: peterz ! src/share/classes/javax/swing/plaf/synth/SynthToolBarUI.java + test/javax/swing/plaf/synth/SynthToolBarUI/6739756/bug6739756.java Changeset: aaa62c1f221e Author: lana Date: 2010-06-21 22:06 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/aaa62c1f221e Merge Changeset: 17870c6c1d4e Author: alanb Date: 2010-06-02 09:29 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/17870c6c1d4e 6950927: Testcase failure sun/management/jmxremote/bootstrap/JvmstatCountersTest.java Reviewed-by: dholmes, dcubed ! src/solaris/classes/sun/tools/attach/LinuxVirtualMachine.java ! src/solaris/classes/sun/tools/attach/SolarisVirtualMachine.java Changeset: 6e57723b3519 Author: alanb Date: 2010-06-02 09:35 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/6e57723b3519 Merge Changeset: 1db252f307b6 Author: martin Date: 2010-06-02 17:53 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/1db252f307b6 6955840: ThreadLocalRandom bug - overriden setSeed(long) method is not invoked for java.util.Random(long) Summary: Allow setSeed only during construction Reviewed-by: dl, dholmes ! src/share/classes/java/util/concurrent/ThreadLocalRandom.java Changeset: ea8c57ec8409 Author: weijun Date: 2010-06-04 19:28 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/ea8c57ec8409 6951366: kerberos login failure on win2008 with AD set to win2000 compat mode Reviewed-by: valeriep, xuelei ! src/share/classes/sun/security/krb5/Credentials.java ! src/share/classes/sun/security/krb5/EncryptionKey.java ! src/share/classes/sun/security/krb5/KrbAsReq.java ! src/windows/classes/sun/security/krb5/internal/tools/Kinit.java ! test/sun/security/krb5/auto/Context.java ! test/sun/security/krb5/auto/KDC.java + test/sun/security/krb5/auto/W83.java Changeset: 489c1720757b Author: chegar Date: 2010-06-08 10:46 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/489c1720757b 6957375: java/net/ResponseCache getResponseCode and ResponseCacheTest fail after rebranding Reviewed-by: ohair, wetmore, alanb ! test/java/net/ResponseCache/file1.cache Changeset: a21e3a29ca9d Author: darcy Date: 2010-06-08 18:52 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/a21e3a29ca9d 6935997: Please add a nested throwable constructor to AssertionError Reviewed-by: martin, forax, wetmore ! src/share/classes/java/lang/AssertionError.java ! src/share/classes/java/security/Security.java Changeset: af68ad345389 Author: alanb Date: 2010-06-09 18:51 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/af68ad345389 6935563: (dc) Improve connection reset/port unreachable handling [win] Reviewed-by: chegar ! src/windows/native/sun/nio/ch/DatagramChannelImpl.c ! src/windows/native/sun/nio/ch/Net.c + test/java/nio/channels/DatagramChannel/SelectWhenRefused.java Changeset: 1474dfa499e3 Author: mchung Date: 2010-06-10 14:14 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/1474dfa499e3 6959965: jstat: Add new -classload option to print class loading statistics Summary: Add a new jstat -classload option Reviewed-by: alanb ! make/sun/tools/Makefile ! src/share/classes/sun/tools/jstat/Arguments.java ! src/share/classes/sun/tools/jstat/OptionFinder.java ! src/share/classes/sun/tools/jstat/OptionLister.java ! src/share/classes/sun/tools/jstat/resources/jstat_options + src/share/classes/sun/tools/jstat/resources/jstat_unsupported_options + test/sun/tools/jstat/classloadOutput1.awk + test/sun/tools/jstat/jstatClassloadOutput1.sh ! test/sun/tools/jstat/jstatOptions1.sh + test/sun/tools/jstat/options2.out Changeset: af827b7eb81d Author: mchung Date: 2010-06-10 14:21 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/af827b7eb81d Merge Changeset: f7a69b261b1d Author: martin Date: 2010-06-10 15:54 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/f7a69b261b1d 6960394: Stop linking with -lnsl on Linux Summary: Define LIBNSL (like LIBSOCKET), non-empty only on Solaris Reviewed-by: ohair ! make/common/Defs-linux.gmk ! make/common/Defs-solaris.gmk ! make/java/hpi/hpi_common.gmk ! make/java/java/Makefile ! make/java/java_hprof_demo/Makefile ! make/java/net/Makefile ! make/jpda/transport/socket/Makefile ! make/mkdemo/jvmti/hprof/Makefile ! src/share/demo/jvmti/hprof/sample.makefile.txt Changeset: aa8effe6bb54 Author: martin Date: 2010-06-10 15:55 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/aa8effe6bb54 6959259: Minor improvements to static Random field caching Summary: Cache fields in locals; small javadoc clarifications Reviewed-by: emcmanus, dholmes, forax, dl ! src/share/classes/java/lang/Math.java ! src/share/classes/java/lang/StrictMath.java ! src/share/classes/java/util/Collections.java Changeset: b1ec20722051 Author: weijun Date: 2010-06-11 11:38 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/b1ec20722051 6958869: regression: PKIXValidator fails when multiple trust anchors have same dn Reviewed-by: xuelei, wetmore, mullan ! src/share/classes/sun/security/validator/PKIXValidator.java ! test/sun/security/validator/CertReplace.java ! test/sun/security/validator/certreplace.sh + test/sun/security/validator/samedn.sh Changeset: 06699a990ac7 Author: alanb Date: 2010-06-11 14:31 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/06699a990ac7 6934585: TEST_BUG: java/nio/channels/AsynchronousSocketChannel/Basic.java Reviewed-by: chegar ! test/ProblemList.txt ! test/java/nio/channels/AsynchronousSocketChannel/Basic.java Changeset: 7079585d6e0e Author: alanb Date: 2010-06-11 14:47 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/7079585d6e0e 6938230: (so) SocketAdaptor.close() does not translate IOException resulting in Error Reviewed-by: chegar ! src/share/classes/sun/nio/ch/ServerSocketAdaptor.java ! src/share/classes/sun/nio/ch/SocketAdaptor.java Changeset: c849dc20dc85 Author: andrew Date: 2010-06-12 01:32 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/c849dc20dc85 6959197: When building with JAVAC_MAX_WARNINGS=true, the build fails in sun/nio/cs due to the use of -Werror Summary: Remove unneeded casts, add generic types and make better use of static data Reviewed-by: sherman ! make/sun/nio/cs/Makefile ! src/share/classes/sun/io/ByteToCharISO2022.java ! src/share/classes/sun/io/ByteToCharISO2022JP.java ! src/share/classes/sun/io/ByteToCharJISAutoDetect.java ! src/share/classes/sun/io/CharToBytePCK.java ! src/share/classes/sun/nio/cs/ext/DoubleByte.java ! src/share/classes/sun/nio/cs/ext/EUC_JP.java ! src/share/classes/sun/nio/cs/ext/EUC_JP_LINUX.java ! src/share/classes/sun/nio/cs/ext/EUC_JP_Open.java ! src/share/classes/sun/nio/cs/ext/EUC_TW.java ! src/share/classes/sun/nio/cs/ext/GB18030.java ! src/share/classes/sun/nio/cs/ext/HKSCS.java ! src/share/classes/sun/nio/cs/ext/ISO2022.java ! src/share/classes/sun/nio/cs/ext/JISAutoDetect.java ! src/share/classes/sun/nio/cs/ext/PCK.java ! src/share/classes/sun/nio/cs/ext/SJIS.java ! src/solaris/classes/sun/nio/cs/ext/COMPOUND_TEXT_Encoder.java ! src/solaris/classes/sun/nio/cs/ext/CompoundTextSupport.java Changeset: 422531c98ba5 Author: martin Date: 2010-06-11 18:55 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/422531c98ba5 6944584: Improvements to subprocess handling on Unix Summary: use thread pool for reaper thread; move most I/O operations out of reaper thread Reviewed-by: michaelm, hiroshi ! src/share/classes/java/lang/ProcessBuilder.java ! src/solaris/classes/java/lang/UNIXProcess.java.linux ! test/java/lang/ProcessBuilder/Basic.java Changeset: 5a61a4f65c9c Author: martin Date: 2010-06-13 17:19 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/5a61a4f65c9c 6960898: Regression due to src/share/classes/java/lang/ProcessBuilder.java changes Summary: Use Null{In,Out}putStream.INSTANCE as with Linux code Reviewed-by: ohair ! src/solaris/classes/java/lang/UNIXProcess.java.solaris ! src/windows/classes/java/lang/ProcessImpl.java Changeset: 76a9c90e9019 Author: alanb Date: 2010-06-15 10:03 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/76a9c90e9019 6961062: (dc) Several DatagramChannel tests timeout or fail with "address already in use" Reviewed-by: chegar ! test/ProblemList.txt ! test/java/nio/channels/DatagramChannel/Connect.java ! test/java/nio/channels/DatagramChannel/EmptyBuffer.java ! test/java/nio/channels/DatagramChannel/NoSender.java ! test/java/nio/channels/DatagramChannel/SRTest.java ! test/java/nio/channels/DatagramChannel/Sender.java Changeset: fb2d88134382 Author: mchung Date: 2010-06-14 14:44 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/fb2d88134382 6960789: com.sun.servicetag API needs to be added in ct.sym Summary: Include com.sun.servicetag classes when generating ct.sym Reviewed-by: alanb, jjg ! make/common/Release.gmk ! test/ProblemList.txt Changeset: c1f7ff3447ba Author: mchung Date: 2010-06-15 09:49 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/c1f7ff3447ba 6952161: Rebranding: Registration html for servicetag Summary: Rebrand register.html and jdk_header.png Reviewed-by: ohair, asaha, ogino, mfang ! src/share/classes/com/sun/servicetag/resources/jdk_header.png ! src/share/classes/com/sun/servicetag/resources/register.html ! src/share/classes/com/sun/servicetag/resources/register_ja.html ! src/share/classes/com/sun/servicetag/resources/register_zh_CN.html Changeset: 915ca65d1db7 Author: mchung Date: 2010-06-15 09:52 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/915ca65d1db7 Merge ! test/ProblemList.txt Changeset: 8d7438dede10 Author: mchung Date: 2010-06-15 09:54 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/8d7438dede10 6959641: testcase failing java/util/Locale/Bug4184873Test.java Summary: Revert the Bug4184873_{he,id,yi} files to revision 0 (before rebranding) Reviewed-by: naoto ! test/ProblemList.txt ! test/java/util/Locale/Bug4184873_he ! test/java/util/Locale/Bug4184873_id ! test/java/util/Locale/Bug4184873_yi Changeset: 72022d7d4578 Author: alanb Date: 2010-06-15 16:36 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/72022d7d4578 6932744: TEST_BUG: java/nio/channels/Selector/OpRead.java failing Reviewed-by: chegar ! test/ProblemList.txt ! test/java/nio/channels/Selector/OpRead.java Changeset: 91124d60b2ed Author: alanb Date: 2010-06-15 16:42 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/91124d60b2ed 6961358: TEST_BUG: java/nio/channels/SocketChannel/OpenLeak.java can't run in samevm mode Reviewed-by: chegar ! test/ProblemList.txt ! test/java/nio/channels/SocketChannel/OpenLeak.java Changeset: 125ec775c9d1 Author: alanb Date: 2010-06-15 21:43 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/125ec775c9d1 Merge ! test/ProblemList.txt Changeset: 1b7879ca3e74 Author: mchung Date: 2010-06-15 20:29 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/1b7879ca3e74 6961518: TEST_BUG: add @run main/othervm in tests that call setSecurityManager Summary: Mark tests to run in othervm Reviewed-by: ohair ! test/ProblemList.txt ! test/java/beans/Beans/Test4080522.java ! test/java/beans/EventHandler/Test6277246.java ! test/java/beans/EventHandler/Test6277266.java ! test/java/beans/Introspector/Test6277246.java ! test/java/lang/ClassLoader/UninitializedParent.java ! test/java/lang/ClassLoader/findSystemClass/Loader.java ! test/java/lang/System/IgnoreNullSecurityManager.java ! test/java/lang/annotation/ParameterAnnotations.java ! test/java/util/ResourceBundle/Bug6359330.java ! test/java/util/ResourceBundle/Test4300693.java Changeset: 55e512967525 Author: mchung Date: 2010-06-15 20:34 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/55e512967525 6961506: TEST_BUG: ResourceBundle/Bug4168625Test.java and TestBug4179766.java fails in samevm mode Summary: Set the proper parent class loader of Loader and SimpleLoader Reviewed-by: naoto ! test/ProblemList.txt ! test/java/util/ResourceBundle/Bug4168625Test.java ! test/java/util/ResourceBundle/TestBug4179766.java Changeset: 8a4557c5dfa1 Author: alanb Date: 2010-06-16 14:24 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/8a4557c5dfa1 6961630: TEST_BUG: Several SocketChannel and Selector tests can fail with "address already in use" Reviewed-by: chegar ! test/ProblemList.txt ! test/java/nio/channels/Selector/ByteServer.java ! test/java/nio/channels/Selector/CloseThenRegister.java ! test/java/nio/channels/Selector/ReadAfterConnect.java ! test/java/nio/channels/Selector/SelectAfterRead.java ! test/java/nio/channels/Selector/SelectWrite.java ! test/java/nio/channels/SocketChannel/BigReadWrite.java ! test/java/nio/channels/SocketChannel/VectorIO.java ! test/java/nio/channels/SocketChannel/Write.java ! test/java/nio/channels/spi/SelectorProvider/inheritedChannel/EchoTest.java Changeset: 8a286789de96 Author: ksrini Date: 2010-06-16 12:36 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/8a286789de96 6575373: Error verifying signatures of pack200 files in some cases Reviewed-by: jrose, forax ! src/share/classes/com/sun/java/util/jar/pack/PropMap.java ! src/share/classes/java/util/jar/Pack200.java ! test/tools/pack200/Pack200Test.java + test/tools/pack200/SegmentLimit.java Changeset: 705777f990cf Author: mchung Date: 2010-06-16 12:40 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/705777f990cf 6961502: TEST_BUG: test/java/lang/ClassLoader/defineClass/DefineClassByteBuffer.java fails Summary: Fix the test to define TestClass by DummyClassLoader as it intends to do Reviewed-by: alanb ! test/ProblemList.txt ! test/java/lang/ClassLoader/defineClass/DefineClassByteBuffer.java Changeset: 94404fea2067 Author: lana Date: 2010-06-16 14:07 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/94404fea2067 Merge - make/com/sun/inputmethods/Makefile - make/com/sun/inputmethods/indicim/Makefile - make/com/sun/inputmethods/thaiim/Makefile ! make/common/Defs-linux.gmk ! make/common/Defs-solaris.gmk ! make/common/Release.gmk - src/share/classes/com/sun/inputmethods/internal/indicim/DevanagariInputMethodDescriptor.java - src/share/classes/com/sun/inputmethods/internal/indicim/DevanagariTables.java - src/share/classes/com/sun/inputmethods/internal/indicim/IndicInputMethod.java - src/share/classes/com/sun/inputmethods/internal/indicim/IndicInputMethodImpl.java - src/share/classes/com/sun/inputmethods/internal/indicim/java.awt.im.spi.InputMethodDescriptor - src/share/classes/com/sun/inputmethods/internal/indicim/resources/DisplayNames.properties - src/share/classes/com/sun/inputmethods/internal/indicim/resources/DisplayNames_de.properties - src/share/classes/com/sun/inputmethods/internal/indicim/resources/DisplayNames_es.properties - src/share/classes/com/sun/inputmethods/internal/indicim/resources/DisplayNames_fr.properties - src/share/classes/com/sun/inputmethods/internal/indicim/resources/DisplayNames_it.properties - src/share/classes/com/sun/inputmethods/internal/indicim/resources/DisplayNames_ja.properties - src/share/classes/com/sun/inputmethods/internal/indicim/resources/DisplayNames_ko.properties - src/share/classes/com/sun/inputmethods/internal/indicim/resources/DisplayNames_sv.properties - src/share/classes/com/sun/inputmethods/internal/indicim/resources/DisplayNames_zh_CN.properties - src/share/classes/com/sun/inputmethods/internal/indicim/resources/DisplayNames_zh_TW.properties - src/share/classes/com/sun/inputmethods/internal/thaiim/ThaiInputMethod.java - src/share/classes/com/sun/inputmethods/internal/thaiim/ThaiInputMethodDescriptor.java - src/share/classes/com/sun/inputmethods/internal/thaiim/ThaiInputMethodImpl.java - src/share/classes/com/sun/inputmethods/internal/thaiim/ThaiRules.java - src/share/classes/com/sun/inputmethods/internal/thaiim/java.awt.im.spi.InputMethodDescriptor - src/share/classes/com/sun/inputmethods/internal/thaiim/resources/DisplayNames.properties ! src/share/classes/com/sun/servicetag/resources/register.html ! src/share/classes/com/sun/servicetag/resources/register_ja.html ! src/share/classes/com/sun/servicetag/resources/register_zh_CN.html - src/share/classes/javax/swing/text/html/parser/html32.bdtd ! test/java/util/ResourceBundle/Bug4168625Test.java Changeset: 3df25d0680f3 Author: weijun Date: 2010-06-17 13:46 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/3df25d0680f3 6959292: regression: cannot login if session key and preauth does not use the same etype Reviewed-by: xuelei, valeriep ! src/share/classes/sun/security/krb5/Credentials.java ! src/share/classes/sun/security/krb5/EncryptionKey.java ! src/share/classes/sun/security/krb5/KrbAsReq.java ! src/share/classes/sun/security/krb5/internal/KRBError.java ! src/windows/classes/sun/security/krb5/internal/tools/Kinit.java ! test/sun/security/krb5/auto/KDC.java ! test/sun/security/krb5/auto/W83.java Changeset: c995607e7719 Author: mchung Date: 2010-06-16 23:27 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/c995607e7719 6961408: test/java/util/logging/ParentLoggersTest.java fails in samevm mode Summary: Check against the list of loggers added since the test begins to run Reviewed-by: dcubed ! test/ProblemList.txt ! test/java/util/logging/ParentLoggersTest.java Changeset: 1281181df71b Author: alanb Date: 2010-06-17 17:49 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/1281181df71b 6395224: (so) SocketChannel writer blocked on large buffer is not preempted by close method (vista) Reviewed-by: chegar ! src/windows/native/sun/nio/ch/SocketDispatcher.c ! src/windows/native/sun/nio/ch/nio_util.h ! test/ProblemList.txt ! test/java/nio/channels/AsyncCloseAndInterrupt.java Changeset: 5e4547833379 Author: sherman Date: 2010-06-17 13:21 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/5e4547833379 6962067: TEST_BUG: Tests in java/util/zip/ZipFile leave file open Summary: Close zipfile and io stream when done Reviewed-by: alanb ! test/ProblemList.txt ! test/java/util/zip/InfoZip.java ! test/java/util/zip/ZipFile/Comment.java ! test/java/util/zip/ZipFile/CorruptedZipFiles.java ! test/java/util/zip/ZipFile/ManyEntries.java Changeset: 006e852b692e Author: ohair Date: 2010-06-17 14:42 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/006e852b692e 6869741: Integrate JAX-WS 2.2 and JAXB 2.2 in JDK 7 Reviewed-by: ramap ! make/docs/CORE_PKGS.gmk Changeset: 6c188df7bfef Author: alanb Date: 2010-06-18 16:16 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/6c188df7bfef 4981129: (dc) DatagramSocket created by DatagramChannel does not provide sender info Reviewed-by: chegar ! src/share/classes/sun/nio/ch/DatagramSocketAdaptor.java ! test/java/nio/channels/DatagramChannel/AdaptDatagramSocket.java Changeset: 7526d0b9aab0 Author: mchung Date: 2010-06-18 09:35 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/7526d0b9aab0 6961894: TEST_BUG: jdk_lang tests fail in samevm mode Summary: Fixed jdk_lang tests to run in samevm mode or mark to run in othervm Reviewed-by: alanb ! test/ProblemList.txt ! test/java/lang/System/ExitFinalizersAndJIT.java ! test/java/lang/Thread/GenerifyStackTraces.java ! test/java/lang/Thread/StackTraces.java ! test/java/lang/management/ClassLoadingMXBean/LoadCounts.java ! test/java/lang/management/ManagementFactory/MXBeanProxyTest.java ! test/java/lang/management/MemoryMXBean/CollectionUsageThreshold.java ! test/java/lang/management/MemoryMXBean/LowMemoryTest.java ! test/java/lang/management/MemoryMXBean/MemoryManagement.java ! test/java/lang/management/MemoryMXBean/Pending.java ! test/java/lang/management/MemoryMXBean/ResetPeakMemoryUsage.java ! test/java/lang/management/MemoryPoolMXBean/ThresholdTest.java ! test/java/lang/management/RuntimeMXBean/UpTime.java ! test/java/lang/management/ThreadMXBean/AllThreadIds.java ! test/java/lang/management/ThreadMXBean/DisableTest.java ! test/java/lang/management/ThreadMXBean/EnableTest.java ! test/java/lang/management/ThreadMXBean/FindDeadlocks.java ! test/java/lang/management/ThreadMXBean/FindMonitorDeadlock.java ! test/java/lang/management/ThreadMXBean/Locks.java ! test/java/lang/reflect/Proxy/Boxing.java ! test/java/lang/reflect/Proxy/ClassRestrictions.java ! test/java/lang/reflect/Proxy/returnTypes/Test.java Changeset: ac93014a4d78 Author: alanb Date: 2010-06-18 20:59 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/ac93014a4d78 6962045: TEST_BUG: Tests in test/java/io/Serializable leave files open Reviewed-by: mchung ! test/ProblemList.txt ! test/java/io/Serializable/ClassCastExceptionDetail/Read.java ! test/java/io/Serializable/auditStreamSubclass/AuditStreamSubclass.java ! test/java/io/Serializable/backRefCNFException/Read.java ! test/java/io/Serializable/checkModifiers/CheckModifiers.java ! test/java/io/Serializable/classDescFlagConflict/Read.java ! test/java/io/Serializable/classDescHooks/ClassDescHooks.java ! test/java/io/Serializable/duplicateSerialFields/Test.java ! test/java/io/Serializable/enum/badResolve/Read.java ! test/java/io/Serializable/enum/constantSubclasses/Read.java ! test/java/io/Serializable/enum/missingConstant/Read.java ! test/java/io/Serializable/fieldTypeString/Read.java ! test/java/io/Serializable/illegalHandle/Test.java ! test/java/io/Serializable/longString/LongString.java ! test/java/io/Serializable/oldTests/AnnotateClass.java ! test/java/io/Serializable/oldTests/ArrayFields.java ! test/java/io/Serializable/oldTests/ArraysOfArrays.java ! test/java/io/Serializable/oldTests/BinaryTree.java ! test/java/io/Serializable/oldTests/CircularList.java ! test/java/io/Serializable/oldTests/SimpleArrays.java ! test/java/io/Serializable/oldTests/WritePrimitive.java ! test/java/io/Serializable/packageAccess/Test.java ! test/java/io/Serializable/parents/EvolvedClass.java ! test/java/io/Serializable/parents/OriginalClass.java ! test/java/io/Serializable/proxy/Basic.java ! test/java/io/Serializable/proxy/skipMissing/Read.java ! test/java/io/Serializable/proxy/skipMissing/Write.java ! test/java/io/Serializable/readObjectNoData/Read.java ! test/java/io/Serializable/skipWriteObject/Read.java ! test/java/io/Serializable/skippedObjCNFException/Read.java ! test/java/io/Serializable/stopCustomDeserialization/Read.java ! test/java/io/Serializable/unresolvedClassDesc/Read.java ! test/java/io/Serializable/unshared/Read.java ! test/java/io/Serializable/wrongReturnTypes/Read.java Changeset: 5919f0c72c0b Author: alanb Date: 2010-06-19 15:17 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/5919f0c72c0b 6962419: TEST_BUG: java_io tests fails in samevm mode Reviewed-by: ohair, sherman ! test/ProblemList.txt ! test/java/io/BufferedReader/BigMark.java ! test/java/io/BufferedReader/ReadLineSync.java ! test/java/io/DataInputStream/OpsAfterClose.java ! test/java/io/DataInputStream/ReadFully.java ! test/java/io/File/DeleteOnExit.java ! test/java/io/File/DeleteOnExitNPE.java ! test/java/io/File/IsHidden.java ! test/java/io/FileInputStream/LeadingSlash.java ! test/java/io/InputStream/OpsAfterClose.java ! test/java/io/InputStream/ReadParams.java ! test/java/io/InputStreamReader/GrowAfterEOF.java ! test/java/io/ObjectInputStream/ResolveProxyClass.java ! test/java/io/RandomAccessFile/EOF.java ! test/java/io/RandomAccessFile/ParameterCheck.java ! test/java/io/RandomAccessFile/ReadLine.java ! test/java/io/RandomAccessFile/Seek.java ! test/java/io/RandomAccessFile/WriteBytesChars.java ! test/java/io/RandomAccessFile/WriteUTF.java ! test/java/io/RandomAccessFile/skipBytes/SkipBytes.java ! test/java/io/Reader/Skip.java ! test/java/io/Reader/SkipNegative.java ! test/java/io/StreamTokenizer/Comment.java ! test/java/io/readBytes/ReadBytesBounds.java Changeset: 43dfa39686a1 Author: ksrini Date: 2010-06-19 17:42 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/43dfa39686a1 6712743: pack200: should default to 150.7 pack format for classfiles without any classes. Reviewed-by: jrose ! src/share/classes/com/sun/java/util/jar/pack/Constants.java ! src/share/classes/com/sun/java/util/jar/pack/Package.java ! src/share/classes/java/util/jar/Pack200.java + test/tools/pack200/PackageVersionTest.java Changeset: a086a3d98711 Author: ohair Date: 2010-06-20 14:51 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/a086a3d98711 6960853: Cleanup makefiles, remove unused vars etc. Reviewed-by: alanb ! make/common/shared/Defs-control.gmk ! make/netbeans/README ! make/netbeans/world/README ! make/netbeans/world/build.xml Changeset: 840265545bc3 Author: ohair Date: 2010-06-20 14:53 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/840265545bc3 6962617: Testcase changes, cleanup of problem list for jdk_tools targets Reviewed-by: alanb ! test/Makefile ! test/ProblemList.txt ! test/com/sun/jdi/PopAndInvokeTest.java ! test/com/sun/servicetag/JavaServiceTagTest1.java ! test/com/sun/servicetag/SystemRegistryTest.java ! test/com/sun/tools/attach/BasicTests.sh ! test/com/sun/tracing/BasicFunctionality.java ! test/sun/jvmstat/testlibrary/utils.sh ! test/sun/tools/jps/jps-Vvml_2.sh ! test/sun/tools/jps/jps-m_2.sh ! test/sun/tools/jstatd/jstatdDefaults.sh ! test/sun/tools/jstatd/jstatdExternalRegistry.sh ! test/sun/tools/jstatd/jstatdPort.sh ! test/sun/tools/jstatd/jstatdServerName.sh ! test/tools/jar/UpdateManifest.java ! test/tools/jar/index/MetaInf.java Changeset: 2366c2a5624c Author: mchung Date: 2010-06-20 19:56 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/2366c2a5624c 6962478: Privacy page referenced in register_ja.html is incorrect Summary: Fix the URL for the privacy page Reviewed-by: ogino ! src/share/classes/com/sun/servicetag/resources/register_ja.html Changeset: fe7271b4aeea Author: mchung Date: 2010-06-21 15:02 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/fe7271b4aeea 6962815: support enable and disable of the servicetag's system registry for testing purpose Summary: Allow the system registry to be disabled/enabled at runtime Reviewed-by: ksrini ! src/share/classes/com/sun/servicetag/Registry.java ! test/com/sun/servicetag/FindServiceTags.java ! test/com/sun/servicetag/JavaServiceTagTest1.java ! test/com/sun/servicetag/SystemRegistryTest.java ! test/com/sun/servicetag/Util.java Changeset: 5438223734aa Author: lana Date: 2010-06-21 22:08 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/5438223734aa Merge Changeset: 10a6319c9c15 Author: lana Date: 2010-06-29 22:34 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/10a6319c9c15 Merge Changeset: 861213cb02c3 Author: prr Date: 2010-06-29 16:34 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/861213cb02c3 6964882: 32 bit JDK does not build on 64 bit Windows platforms Reviewed-by: ohair, valeriep ! make/sun/security/mscapi/Makefile ! make/sun/security/pkcs11/Makefile Changeset: 511ddf6938ea Author: mikejwre Date: 2010-06-30 18:57 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/511ddf6938ea Merge From john.coomes at oracle.com Thu Jul 1 22:05:26 2010 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 02 Jul 2010 05:05:26 +0000 Subject: hg: jdk7/hotspot-comp/langtools: 18 new changesets Message-ID: <20100702050558.886B3476DC@hg.openjdk.java.net> Changeset: 9d02c4ce4275 Author: mikejwre Date: 2010-06-24 20:03 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/9d02c4ce4275 Added tag jdk7-b99 for changeset 005bec70ca27 ! .hgtags Changeset: 9a7c998bf2fc Author: darcy Date: 2010-06-02 19:08 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/9a7c998bf2fc 6933147: Provided new utility visitors supporting SourceVersion.RELEASE_7 Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java ! src/share/classes/com/sun/tools/javac/processing/JavacRoundEnvironment.java ! src/share/classes/com/sun/tools/javac/processing/PrintingProcessor.java ! src/share/classes/com/sun/tools/javah/JavahTask.java ! src/share/classes/com/sun/tools/javah/LLNI.java ! src/share/classes/com/sun/tools/javah/TypeSignature.java ! src/share/classes/javax/lang/model/element/ElementVisitor.java ! src/share/classes/javax/lang/model/util/AbstractAnnotationValueVisitor6.java + src/share/classes/javax/lang/model/util/AbstractAnnotationValueVisitor7.java ! src/share/classes/javax/lang/model/util/AbstractElementVisitor6.java + src/share/classes/javax/lang/model/util/AbstractElementVisitor7.java ! src/share/classes/javax/lang/model/util/AbstractTypeVisitor6.java + src/share/classes/javax/lang/model/util/AbstractTypeVisitor7.java ! src/share/classes/javax/lang/model/util/ElementKindVisitor6.java + src/share/classes/javax/lang/model/util/ElementKindVisitor7.java ! src/share/classes/javax/lang/model/util/ElementScanner6.java + src/share/classes/javax/lang/model/util/ElementScanner7.java ! src/share/classes/javax/lang/model/util/SimpleAnnotationValueVisitor6.java + src/share/classes/javax/lang/model/util/SimpleAnnotationValueVisitor7.java ! src/share/classes/javax/lang/model/util/SimpleElementVisitor6.java + src/share/classes/javax/lang/model/util/SimpleElementVisitor7.java ! src/share/classes/javax/lang/model/util/SimpleTypeVisitor6.java + src/share/classes/javax/lang/model/util/SimpleTypeVisitor7.java ! src/share/classes/javax/lang/model/util/TypeKindVisitor6.java + src/share/classes/javax/lang/model/util/TypeKindVisitor7.java ! src/share/sample/javac/processing/src/CheckNamesProcessor.java ! test/tools/javac/6402516/CheckLocalElements.java ! test/tools/javac/api/TestOperators.java ! test/tools/javac/enum/6424358/T6424358.java ! test/tools/javac/processing/model/6194785/T6194785.java ! test/tools/javac/processing/model/type/NoTypes.java ! test/tools/javac/processing/model/util/deprecation/TestDeprecation.java Changeset: 559c9a37d9f6 Author: jjg Date: 2010-06-03 17:14 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/559c9a37d9f6 6955264: add option to suppress Abort in Check.completionError Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/comp/Check.java Changeset: 852d8bb356bc Author: darcy Date: 2010-06-03 19:56 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/852d8bb356bc 6519115: MirroredTypeException thrown but should be MirroredTypesException Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/model/AnnotationProxyMaker.java ! src/share/classes/javax/lang/model/type/MirroredTypeException.java ! src/share/classes/javax/lang/model/type/MirroredTypesException.java + test/tools/javac/processing/model/type/MirroredTypeEx/Plurality.java Changeset: b7fc560217d3 Author: jjg Date: 2010-06-04 14:54 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/b7fc560217d3 6958391: add vizant support to langtools build Reviewed-by: mcimadamore ! make/build.properties ! make/build.xml Changeset: d33b91f360fc Author: jjg Date: 2010-06-04 17:33 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/d33b91f360fc 6958802: cleanup and doc langtools build.xml file Reviewed-by: ohair ! make/build.properties ! make/build.xml Changeset: 46cf751559ae Author: mcimadamore Date: 2010-06-10 09:29 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/46cf751559ae 6945418: Project Coin: Simplified Varargs Method Invocation Summary: Add new mandatory warning for unsafe vararg method declaration. Warning can be suppressed as usual (@SuppressWarnings("varargs")/-Xlint:-varargs) Reviewed-by: jjg, darcy ! src/share/classes/com/sun/tools/javac/code/Lint.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/comp/Infer.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/share/classes/com/sun/tools/javac/util/List.java ! test/tools/javac/varargs/6730476/T6730476a.java ! test/tools/javac/varargs/6806876/T6806876.out + test/tools/javac/varargs/warning/Warn4.java Changeset: f2fdd52e4e87 Author: jjg Date: 2010-06-10 16:08 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/f2fdd52e4e87 6944312: Potential rebranding issues in openjdk/langtools repository sources Reviewed-by: darcy ! src/share/classes/com/sun/javadoc/package.html ! src/share/classes/com/sun/mirror/overview.html ! src/share/classes/com/sun/source/tree/DisjointTypeTree.java ! src/share/classes/com/sun/tools/apt/comp/Apt.java ! src/share/classes/com/sun/tools/apt/main/CommandLine.java ! src/share/classes/com/sun/tools/apt/main/JavaCompiler.java ! src/share/classes/com/sun/tools/apt/main/Main.java ! src/share/classes/com/sun/tools/apt/util/Bark.java ! src/share/classes/com/sun/tools/classfile/AccessFlags.java ! src/share/classes/com/sun/tools/classfile/Annotation.java ! src/share/classes/com/sun/tools/classfile/AnnotationDefault_attribute.java ! src/share/classes/com/sun/tools/classfile/Attribute.java ! src/share/classes/com/sun/tools/classfile/AttributeException.java ! src/share/classes/com/sun/tools/classfile/Attributes.java ! src/share/classes/com/sun/tools/classfile/CharacterRangeTable_attribute.java ! src/share/classes/com/sun/tools/classfile/ClassFile.java ! src/share/classes/com/sun/tools/classfile/ClassReader.java ! src/share/classes/com/sun/tools/classfile/ClassTranslator.java ! src/share/classes/com/sun/tools/classfile/ClassWriter.java ! src/share/classes/com/sun/tools/classfile/Code_attribute.java ! src/share/classes/com/sun/tools/classfile/CompilationID_attribute.java ! src/share/classes/com/sun/tools/classfile/ConstantPool.java ! src/share/classes/com/sun/tools/classfile/ConstantPoolException.java ! src/share/classes/com/sun/tools/classfile/ConstantValue_attribute.java ! src/share/classes/com/sun/tools/classfile/DefaultAttribute.java ! src/share/classes/com/sun/tools/classfile/Deprecated_attribute.java ! src/share/classes/com/sun/tools/classfile/Descriptor.java ! src/share/classes/com/sun/tools/classfile/DescriptorException.java ! src/share/classes/com/sun/tools/classfile/EnclosingMethod_attribute.java ! src/share/classes/com/sun/tools/classfile/Exceptions_attribute.java ! src/share/classes/com/sun/tools/classfile/ExtendedAnnotation.java ! src/share/classes/com/sun/tools/classfile/Field.java ! src/share/classes/com/sun/tools/classfile/InnerClasses_attribute.java ! src/share/classes/com/sun/tools/classfile/Instruction.java ! src/share/classes/com/sun/tools/classfile/LineNumberTable_attribute.java ! src/share/classes/com/sun/tools/classfile/LocalVariableTable_attribute.java ! src/share/classes/com/sun/tools/classfile/LocalVariableTypeTable_attribute.java ! src/share/classes/com/sun/tools/classfile/Method.java ! src/share/classes/com/sun/tools/classfile/Opcode.java ! src/share/classes/com/sun/tools/classfile/RuntimeAnnotations_attribute.java ! src/share/classes/com/sun/tools/classfile/RuntimeInvisibleAnnotations_attribute.java ! src/share/classes/com/sun/tools/classfile/RuntimeInvisibleParameterAnnotations_attribute.java ! src/share/classes/com/sun/tools/classfile/RuntimeInvisibleTypeAnnotations_attribute.java ! src/share/classes/com/sun/tools/classfile/RuntimeParameterAnnotations_attribute.java ! src/share/classes/com/sun/tools/classfile/RuntimeTypeAnnotations_attribute.java ! src/share/classes/com/sun/tools/classfile/RuntimeVisibleAnnotations_attribute.java ! src/share/classes/com/sun/tools/classfile/RuntimeVisibleParameterAnnotations_attribute.java ! src/share/classes/com/sun/tools/classfile/RuntimeVisibleTypeAnnotations_attribute.java ! src/share/classes/com/sun/tools/classfile/Signature.java ! src/share/classes/com/sun/tools/classfile/Signature_attribute.java ! src/share/classes/com/sun/tools/classfile/SourceDebugExtension_attribute.java ! src/share/classes/com/sun/tools/classfile/SourceFile_attribute.java ! src/share/classes/com/sun/tools/classfile/SourceID_attribute.java ! src/share/classes/com/sun/tools/classfile/StackMapTable_attribute.java ! src/share/classes/com/sun/tools/classfile/StackMap_attribute.java ! src/share/classes/com/sun/tools/classfile/Synthetic_attribute.java ! src/share/classes/com/sun/tools/classfile/Type.java ! src/share/classes/com/sun/tools/javac/Launcher.java ! src/share/classes/com/sun/tools/javac/Server.java ! src/share/classes/com/sun/tools/javac/api/DiagnosticFormatter.java ! src/share/classes/com/sun/tools/javac/api/Formattable.java ! src/share/classes/com/sun/tools/javac/api/JavacScope.java ! src/share/classes/com/sun/tools/javac/api/JavacTaskImpl.java ! src/share/classes/com/sun/tools/javac/api/JavacTool.java ! src/share/classes/com/sun/tools/javac/api/JavacTrees.java ! src/share/classes/com/sun/tools/javac/api/Messages.java ! src/share/classes/com/sun/tools/javac/api/WrappingJavaFileManager.java ! src/share/classes/com/sun/tools/javac/code/Attribute.java ! src/share/classes/com/sun/tools/javac/code/BoundKind.java ! src/share/classes/com/sun/tools/javac/code/Flags.java ! src/share/classes/com/sun/tools/javac/code/Kinds.java ! src/share/classes/com/sun/tools/javac/code/Lint.java ! src/share/classes/com/sun/tools/javac/code/Printer.java ! src/share/classes/com/sun/tools/javac/code/Scope.java ! src/share/classes/com/sun/tools/javac/code/Source.java ! src/share/classes/com/sun/tools/javac/code/Symbol.java ! src/share/classes/com/sun/tools/javac/code/Symtab.java ! src/share/classes/com/sun/tools/javac/code/TargetType.java ! src/share/classes/com/sun/tools/javac/code/Type.java ! src/share/classes/com/sun/tools/javac/code/TypeAnnotationPosition.java ! src/share/classes/com/sun/tools/javac/code/TypeTags.java ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/Annotate.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/AttrContext.java ! src/share/classes/com/sun/tools/javac/comp/AttrContextEnv.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/comp/ConstFold.java ! src/share/classes/com/sun/tools/javac/comp/Enter.java ! src/share/classes/com/sun/tools/javac/comp/Env.java ! src/share/classes/com/sun/tools/javac/comp/Flow.java ! src/share/classes/com/sun/tools/javac/comp/Infer.java ! src/share/classes/com/sun/tools/javac/comp/Lower.java ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/share/classes/com/sun/tools/javac/comp/Todo.java ! src/share/classes/com/sun/tools/javac/comp/TransTypes.java ! src/share/classes/com/sun/tools/javac/file/BaseFileObject.java ! src/share/classes/com/sun/tools/javac/file/CacheFSInfo.java ! src/share/classes/com/sun/tools/javac/file/FSInfo.java ! src/share/classes/com/sun/tools/javac/file/JavacFileManager.java ! src/share/classes/com/sun/tools/javac/file/Paths.java ! src/share/classes/com/sun/tools/javac/file/RegularFileObject.java ! src/share/classes/com/sun/tools/javac/file/RelativePath.java ! src/share/classes/com/sun/tools/javac/file/SymbolArchive.java ! src/share/classes/com/sun/tools/javac/file/ZipArchive.java ! src/share/classes/com/sun/tools/javac/file/ZipFileIndex.java ! src/share/classes/com/sun/tools/javac/file/ZipFileIndexArchive.java ! src/share/classes/com/sun/tools/javac/jvm/ByteCodes.java ! src/share/classes/com/sun/tools/javac/jvm/CRTFlags.java ! src/share/classes/com/sun/tools/javac/jvm/CRTable.java ! src/share/classes/com/sun/tools/javac/jvm/ClassFile.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java ! src/share/classes/com/sun/tools/javac/jvm/Code.java ! src/share/classes/com/sun/tools/javac/jvm/Gen.java ! src/share/classes/com/sun/tools/javac/jvm/Items.java ! src/share/classes/com/sun/tools/javac/jvm/Pool.java ! src/share/classes/com/sun/tools/javac/jvm/Target.java ! src/share/classes/com/sun/tools/javac/jvm/UninitializedType.java ! src/share/classes/com/sun/tools/javac/main/CommandLine.java ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/share/classes/com/sun/tools/javac/main/JavacOption.java ! src/share/classes/com/sun/tools/javac/main/Main.java ! src/share/classes/com/sun/tools/javac/main/OptionName.java ! src/share/classes/com/sun/tools/javac/main/RecognizedOptions.java ! src/share/classes/com/sun/tools/javac/model/AnnotationProxyMaker.java ! src/share/classes/com/sun/tools/javac/model/FilteredMemberList.java ! src/share/classes/com/sun/tools/javac/model/JavacElements.java ! src/share/classes/com/sun/tools/javac/model/JavacSourcePosition.java ! src/share/classes/com/sun/tools/javac/model/JavacTypes.java ! src/share/classes/com/sun/tools/javac/nio/JavacPathFileManager.java ! src/share/classes/com/sun/tools/javac/nio/PathFileManager.java ! src/share/classes/com/sun/tools/javac/nio/PathFileObject.java ! src/share/classes/com/sun/tools/javac/parser/DocCommentScanner.java ! src/share/classes/com/sun/tools/javac/parser/EndPosParser.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/parser/Keywords.java ! src/share/classes/com/sun/tools/javac/parser/Lexer.java ! src/share/classes/com/sun/tools/javac/parser/Parser.java ! src/share/classes/com/sun/tools/javac/parser/ParserFactory.java ! src/share/classes/com/sun/tools/javac/parser/Scanner.java ! src/share/classes/com/sun/tools/javac/parser/Token.java ! src/share/classes/com/sun/tools/javac/processing/AnnotationProcessingError.java ! src/share/classes/com/sun/tools/javac/processing/JavacFiler.java ! src/share/classes/com/sun/tools/javac/processing/JavacMessager.java ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java ! src/share/classes/com/sun/tools/javac/processing/JavacRoundEnvironment.java ! src/share/classes/com/sun/tools/javac/processing/PrintingProcessor.java ! src/share/classes/com/sun/tools/javac/processing/ServiceProxy.java ! src/share/classes/com/sun/tools/javac/sym/CreateSymbols.java ! src/share/classes/com/sun/tools/javac/tree/JCTree.java ! src/share/classes/com/sun/tools/javac/tree/Pretty.java ! src/share/classes/com/sun/tools/javac/tree/TreeCopier.java ! src/share/classes/com/sun/tools/javac/tree/TreeInfo.java ! src/share/classes/com/sun/tools/javac/tree/TreeMaker.java ! src/share/classes/com/sun/tools/javac/tree/TreeScanner.java ! src/share/classes/com/sun/tools/javac/tree/TreeTranslator.java ! src/share/classes/com/sun/tools/javac/util/Abort.java ! src/share/classes/com/sun/tools/javac/util/AbstractDiagnosticFormatter.java ! src/share/classes/com/sun/tools/javac/util/AbstractLog.java ! src/share/classes/com/sun/tools/javac/util/BasicDiagnosticFormatter.java ! src/share/classes/com/sun/tools/javac/util/Bits.java ! src/share/classes/com/sun/tools/javac/util/ByteBuffer.java ! src/share/classes/com/sun/tools/javac/util/ClientCodeException.java ! src/share/classes/com/sun/tools/javac/util/CloseableURLClassLoader.java ! src/share/classes/com/sun/tools/javac/util/Constants.java ! src/share/classes/com/sun/tools/javac/util/Context.java ! src/share/classes/com/sun/tools/javac/util/Convert.java ! src/share/classes/com/sun/tools/javac/util/DiagnosticSource.java ! src/share/classes/com/sun/tools/javac/util/FatalError.java ! src/share/classes/com/sun/tools/javac/util/ForwardingDiagnosticFormatter.java ! src/share/classes/com/sun/tools/javac/util/JCDiagnostic.java ! src/share/classes/com/sun/tools/javac/util/JavacMessages.java ! src/share/classes/com/sun/tools/javac/util/LayoutCharacters.java ! src/share/classes/com/sun/tools/javac/util/List.java ! src/share/classes/com/sun/tools/javac/util/ListBuffer.java ! src/share/classes/com/sun/tools/javac/util/Log.java ! src/share/classes/com/sun/tools/javac/util/MandatoryWarningHandler.java ! src/share/classes/com/sun/tools/javac/util/Name.java ! src/share/classes/com/sun/tools/javac/util/Names.java ! src/share/classes/com/sun/tools/javac/util/Options.java ! src/share/classes/com/sun/tools/javac/util/Pair.java ! src/share/classes/com/sun/tools/javac/util/Position.java ! src/share/classes/com/sun/tools/javac/util/PropagatedException.java ! src/share/classes/com/sun/tools/javac/util/RawDiagnosticFormatter.java ! src/share/classes/com/sun/tools/javac/util/RichDiagnosticFormatter.java ! src/share/classes/com/sun/tools/javac/util/SharedNameTable.java ! src/share/classes/com/sun/tools/javac/util/UnsharedNameTable.java ! src/share/classes/com/sun/tools/javac/util/Warner.java ! src/share/classes/com/sun/tools/javah/Gen.java ! src/share/classes/com/sun/tools/javah/InternalError.java ! src/share/classes/com/sun/tools/javah/JNI.java ! src/share/classes/com/sun/tools/javah/JavahFileManager.java ! src/share/classes/com/sun/tools/javah/JavahTask.java ! src/share/classes/com/sun/tools/javah/JavahTool.java ! src/share/classes/com/sun/tools/javah/LLNI.java ! src/share/classes/com/sun/tools/javah/Main.java ! src/share/classes/com/sun/tools/javah/Mangle.java ! src/share/classes/com/sun/tools/javah/NativeHeaderTool.java ! src/share/classes/com/sun/tools/javah/TypeSignature.java ! src/share/classes/com/sun/tools/javah/Util.java ! src/share/classes/com/sun/tools/javap/AnnotationWriter.java ! src/share/classes/com/sun/tools/javap/AttributeWriter.java ! src/share/classes/com/sun/tools/javap/BasicWriter.java ! src/share/classes/com/sun/tools/javap/ClassWriter.java ! src/share/classes/com/sun/tools/javap/CodeWriter.java ! src/share/classes/com/sun/tools/javap/ConstantWriter.java ! src/share/classes/com/sun/tools/javap/Context.java ! src/share/classes/com/sun/tools/javap/DisassemblerTool.java ! src/share/classes/com/sun/tools/javap/InstructionDetailWriter.java ! src/share/classes/com/sun/tools/javap/InternalError.java ! src/share/classes/com/sun/tools/javap/JavapFileManager.java ! src/share/classes/com/sun/tools/javap/JavapTask.java ! src/share/classes/com/sun/tools/javap/LocalVariableTableWriter.java ! src/share/classes/com/sun/tools/javap/LocalVariableTypeTableWriter.java ! src/share/classes/com/sun/tools/javap/Main.java ! src/share/classes/com/sun/tools/javap/Messages.java ! src/share/classes/com/sun/tools/javap/Options.java ! src/share/classes/com/sun/tools/javap/SourceWriter.java ! src/share/classes/com/sun/tools/javap/StackMapWriter.java ! src/share/classes/com/sun/tools/javap/TryBlockWriter.java ! src/share/classes/com/sun/tools/javap/TypeAnnotationWriter.java ! src/share/classes/javax/lang/model/overview.html ! test/tools/apt/mirror/declaration/pkg1/pkg2/package.html ! test/tools/javac/6948381/T6948381.java ! test/tools/javac/6948381/npe/A.java ! test/tools/javac/6948381/npe/B.java ! test/tools/javac/api/evalexpr/ByteArrayClassLoader.java ! test/tools/javac/api/evalexpr/CompileFromString.java ! test/tools/javac/api/evalexpr/MemoryFileManager.java ! test/tools/javac/generics/diamond/T6951833.java ! test/tools/javac/generics/typevars/T6880344.java ! test/tools/javac/varargs/warning/Warn4.java Changeset: 366a7b9b5627 Author: jjg Date: 2010-06-10 17:09 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/366a7b9b5627 6960407: Potential rebranding issues in openjdk/langtools repository sources Reviewed-by: darcy ! make/Makefile ! make/Makefile-classic ! src/share/classes/com/sun/source/tree/Tree.java ! src/share/classes/com/sun/source/util/JavacTask.java ! src/share/classes/com/sun/source/util/TaskEvent.java ! src/share/classes/com/sun/source/util/TaskListener.java ! src/share/classes/com/sun/tools/doclets/formats/html/package.html ! src/share/classes/com/sun/tools/javac/api/JavacTaskImpl.java ! src/share/classes/com/sun/tools/javac/code/Flags.java ! src/share/classes/com/sun/tools/javac/code/Lint.java ! src/share/classes/com/sun/tools/javac/code/Symtab.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/share/classes/com/sun/tools/javadoc/resources/javadoc.properties ! src/share/classes/com/sun/tools/javadoc/resources/javadoc_zh_CN.properties ! src/share/classes/javax/tools/JavaFileManager.java Changeset: 224533455888 Author: jjg Date: 2010-06-11 07:12 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/224533455888 6877961: langtools build should allow more options when running jtreg Reviewed-by: mcimadamore ! make/build.xml Changeset: d1ea43cb71c1 Author: jjg Date: 2010-06-11 17:24 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/d1ea43cb71c1 6958836: javadoc should support -Xmaxerrs and -Xmaxwarns Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/util/Log.java ! src/share/classes/com/sun/tools/javadoc/DocletInvoker.java ! src/share/classes/com/sun/tools/javadoc/Messager.java ! src/share/classes/com/sun/tools/javadoc/Start.java ! src/share/classes/com/sun/tools/javadoc/resources/javadoc.properties + test/tools/javadoc/6958836/Test.java + test/tools/javadoc/6958836/errs/Errors.java + test/tools/javadoc/6958836/warns/Warnings.java Changeset: 0840dd65b9e2 Author: jjg Date: 2010-06-16 16:23 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/0840dd65b9e2 6956638: JavacTask.generate does not generate all required files Reviewed-by: darcy Contributed-by: joshuamaurice at gmail.com + test/tools/javac/T6956638.java Changeset: 93e1975eea7a Author: lana Date: 2010-06-16 14:09 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/93e1975eea7a Merge ! test/tools/apt/mirror/declaration/pkg1/pkg2/package.html Changeset: e2b845fdc437 Author: lana Date: 2010-06-16 17:52 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/e2b845fdc437 Merge Changeset: 0ba1f80b73a5 Author: jjg Date: 2010-06-18 16:45 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/0ba1f80b73a5 6962540: langtools Makefile sets DEV_NULL incorrectly Reviewed-by: ohair ! make/Makefile Changeset: 4177f5bdd189 Author: jjg Date: 2010-06-18 21:13 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/4177f5bdd189 6961178: Allow doclet.xml to contain XML attributes Reviewed-by: bpatel ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AbstractBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AbstractMemberBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AnnotationTypeBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AnnotationTypeOptionalMemberBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AnnotationTypeRequiredMemberBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/ClassBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/ConstantsSummaryBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/ConstructorBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/EnumConstantBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/FieldBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/LayoutParser.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/MemberSummaryBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/MethodBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/PackageSummaryBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/SerializedFormBuilder.java + src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/XMLNode.java Changeset: 4cca8d7ce6c1 Author: lana Date: 2010-06-21 22:09 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/4cca8d7ce6c1 Merge Changeset: d1d7595fa824 Author: lana Date: 2010-06-29 22:43 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/d1d7595fa824 Merge ! src/share/classes/com/sun/tools/javac/code/Flags.java ! src/share/classes/com/sun/tools/javac/code/Source.java ! src/share/classes/com/sun/tools/javac/code/Symtab.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java ! src/share/classes/com/sun/tools/javac/jvm/Gen.java ! src/share/classes/com/sun/tools/javac/main/Main.java ! src/share/classes/com/sun/tools/javac/util/Names.java From swhite at aip.de Fri Jul 2 03:26:53 2010 From: swhite at aip.de (Steve White) Date: Fri, 2 Jul 2010 12:26:53 +0200 Subject: speed of simple loops: comparison to other language In-Reply-To: <4C2CC578.1080002@redhat.com> References: <20100630113752.GA26057@cashmere.aip.de> <4C2B7E8D.4070601@oracle.com> <20100701122245.GB12509@cashmere.aip.de> <20100701163723.GC12509@cashmere.aip.de> <4C2CC578.1080002@redhat.com> Message-ID: <20100702102653.GB22548@cashmere.aip.de> Hi, Andrew There may be a two-way confusion here, on both topics. On 1.07.10, Andrew Haley wrote: > On 07/01/2010 05:37 PM, Steve White wrote: > > > However, does better execution time necessarily imply slower start-up time? > > If the only switches available are -server or -client, then we're stuck. > > But maybe this just reflects an unfortunate division of the issues. > > Frankly it surprises me that better optimization necessarily implies > > substantially slower start-up time. > > > > Is it really either/or? > > Optimization is a computationally expensive job, so to some extent > that can't be helped. > My point is, that the "server" vs "client" distinction is maybe too coarse-grained for many applications. However, it turns out that for my uses, the "server" compiler works well. I don't care about start-up time. It is so fast as to be humanly insensible in my applications. I care about compute time. Java always worked well on our x86_64 machines, but I was perplexed why I wasn't seeing similar performance on other machines. Now I understand, and I can fix the problem. > > Just a thought: it's kind of poor that the determination has to be made > > when building the VM. It would be much cooler to have launch-time switch > > that would choose such behavior. > > Sure, it would, but AFAIK no-one has ever written a client compiler > for x86_64, so we're kinda stuck. :-) > But for my purposes I wanted the contrary thing, the "server" compiler for IA32. Now I understand this is just a simple matter of the -server java switch (I misunderstood that this was a compiler switch before). Cheers! -- | - - - - - - - - - - - - - - - - - - - - - - - - - | Steve White +49(331)7499-202 | E-Science Zi. 27 Villa Turbulenz | - - - - - - - - - - - - - - - - - - - - - - - - - | Astrophysikalisches Institut Potsdam (AIP) | An der Sternwarte 16, D-14482 Potsdam | | Vorstand: Prof. Dr. Matthias Steinmetz, Peter A. Stolz | | Stiftung privaten Rechts, Stiftungsverzeichnis Brandenburg: III/7-71-026 | - - - - - - - - - - - - - - - - - - - - - - - - - From vladimir.kozlov at oracle.com Fri Jul 2 13:01:09 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 02 Jul 2010 13:01:09 -0700 Subject: Request for reviews (M): 6966411: escape.cpp:450 assert(base->Opcode() == Op_ConP Message-ID: <4C2E4585.5020007@oracle.com> I wanted to do this for long time as EA improvement since IGVN optimization will simplify ideal graph. http://cr.openjdk.java.net/~kvn/6966411/webrev Fixed 6966411: escape.cpp:450 assert(base->Opcode() == Op_ConP OptimizeStringConcat optimization replaces calls with inlined methods during do_late_inline(). It creates dead paths which are not eliminated before Escape Analysis since IGVN optimization is not executed: 62 ConL === 0 [[ 63 92 ]] #long:8 63 AddP === _ 1 1 62 [[ 64 ]] !jvms: CtorTests::StringBuilder0002 @ bci:7 Solution: Execute IGVN optimization before and after Escape Analysis. Use new PhaseIterGVN field ConnectionGraph::_igvn instead of passing phase as EA methods parameter. Failed test, JPRT From tom.rodriguez at oracle.com Fri Jul 2 13:32:45 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Fri, 2 Jul 2010 13:32:45 -0700 Subject: Request for reviews (M): 6966411: escape.cpp:450 assert(base->Opcode() == Op_ConP In-Reply-To: <4C2E4585.5020007@oracle.com> References: <4C2E4585.5020007@oracle.com> Message-ID: <2D96EC6B-CFF0-4B15-8186-D4EA6B89E931@oracle.com> I'm glad you're doing this. Is the oop_null/noop_null stuff still needed? I can't remember the reason for that. Could it be moved into compute_escape? Maybe the PrintEscapeAnalysis stuff could be there too. Otherwise it looks good. tom On Jul 2, 2010, at 1:01 PM, Vladimir Kozlov wrote: > I wanted to do this for long time as EA improvement > since IGVN optimization will simplify ideal graph. > > http://cr.openjdk.java.net/~kvn/6966411/webrev > > Fixed 6966411: escape.cpp:450 assert(base->Opcode() == Op_ConP > > OptimizeStringConcat optimization replaces calls with inlined > methods during do_late_inline(). It creates dead paths which > are not eliminated before Escape Analysis since IGVN optimization > is not executed: > > 62 ConL === 0 [[ 63 92 ]] #long:8 > 63 AddP === _ 1 1 62 [[ 64 ]] !jvms: CtorTests::StringBuilder0002 @ bci:7 > > Solution: > Execute IGVN optimization before and after Escape Analysis. > Use new PhaseIterGVN field ConnectionGraph::_igvn instead of > passing phase as EA methods parameter. > > Failed test, JPRT From tom.rodriguez at oracle.com Fri Jul 2 15:01:16 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Fri, 2 Jul 2010 15:01:16 -0700 Subject: review (S) for 6958668: repeated uncommon trapping for new of klass which is being initialized In-Reply-To: <5BA2ADF2-AABC-4C23-A925-57B68EA2E048@oracle.com> References: <5BA2ADF2-AABC-4C23-A925-57B68EA2E048@oracle.com> Message-ID: <2EBCEB58-F789-4CE6-BCDE-B3B2C56C3B9B@oracle.com> Good suggestions. I've done both. tom On Jul 1, 2010, at 9:12 PM, John Rose wrote: > Nice. I suggest moving the big insertion in parseHelper into a private subroutine. > > Also (as a more borderline thing) consider making a private subroutine for the three near-copies of the shared logic in ciIK.cpp. (Would be parameterized by the variable part, the queried ClassState.) > > -- John > > On Jul 1, 2010, at 6:52 PM, Tom Rodriguez wrote: > >> http://cr.openjdk.java.net/~never/6958668 >> >> 6958668: repeated uncommon trapping for new of klass which is being initialized >> Reviewed-by: >> >> During the execution of a class initializer only the initializing >> thread is allowed to create instances of the class. Currently in C2 >> this is handled by emitting an uncommon trap. If an application >> creates a lot of instances using this idiom it can lead to long >> sequences of compile, uncommon trap, recompile, uncommon trap. >> Instead C2 should emit a guarded new that allows the proper thread to >> perform allocations throws out the code once initialization is >> complete. Ideally we should just be able to test that the init_thread >> is the current thread but the init_thread is never set back to null so >> the init_state is additionally being checked. I'm planning to >> separately fix the clearing the init_thread since C1 mistakenly >> expects it to be cleared. This fix is going to be backported to an >> update at some point. Tested with users application and test case >> which I haven't bothered including though it is in the bug report. > From tom.rodriguez at oracle.com Fri Jul 2 15:05:10 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Fri, 2 Jul 2010 15:05:10 -0700 Subject: review (M) for 6965184: possible races in make_not_entrant_or_zombie Message-ID: <1D1B5C11-75D2-468D-A2E4-F546689B6D60@oracle.com> http://cr.openjdk.java.net/~never/6965184 6965184: possible races in make_not_entrant_or_zombie Reviewed-by: While investigating the sweeper concurrency problems I identified a bunch of minor issues that could lead to races. NMethod groups a bunch of flags into a struct using bitfield which was okay in the past because they were either written by the constructor, at a safepoint or with a single lock held. Now some of those fields are written under one lock and some are written under another so they should be separated. I've done away with nmFlags all together and moved a bunch of common initialization into a new method. I also deleted a other of unused or dead things. In make_not_entrant_or_zombie, all the zombie logic used to be performed at a safepoint but now it can happen concurrently so the logic that is executed outside of the Patching_lock has to be more careful. All the not_entrant logic has been moved into the region protected by the Patching_lock. The link between the nmethod and the methodOop is also broken ealier though a strong reference to the methodOop is maintained to make sure it stays alive. There were problems with the maintenance of _sweep_started and _invocations that could mistakenly allow another thread into possibly_sweep but only if there was no work to be done. Also threads besides the sweeping thread could clear _sweep_started. The sweeper divides the cache based on the number of blobs even though it only works on nmethod, so I added a nof_nmethods count along with a nof_adapters count just for informational purposes. As a cleanup I also deleted the dead and unused VTune logic since it doesn't work and VTune uses JVMTI agents these days. Tested with NSK jvmti,jdi,jdb,hprof,jit,regression and JDI_REGRESSION tests. From vladimir.kozlov at oracle.com Fri Jul 2 15:53:55 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 02 Jul 2010 15:53:55 -0700 Subject: Request for reviews (M): 6966411: escape.cpp:450 assert(base->Opcode() == Op_ConP In-Reply-To: <2D96EC6B-CFF0-4B15-8186-D4EA6B89E931@oracle.com> References: <4C2E4585.5020007@oracle.com> <2D96EC6B-CFF0-4B15-8186-D4EA6B89E931@oracle.com> Message-ID: <4C2E6E03.2060109@oracle.com> Thank you, Tom oop_null/noop_null are generated outside ConnectionGraph constructor which creates array _nodes[] of fixed size C->unique() and it should include space for oop_null/noop_null. When Connection graph is populated escape analysis relies on the fact that no new ideal nodes are created. I moved all Compile code into new method ConnectionGraph::do_analysis() and moved dump() into compute_escape(). http://cr.openjdk.java.net/~kvn/6966411/webrev.01 thanks, Vladimir Tom Rodriguez wrote: > I'm glad you're doing this. Is the oop_null/noop_null stuff still needed? I can't remember the reason for that. Could it be moved into compute_escape? Maybe the PrintEscapeAnalysis stuff could be there too. Otherwise it looks good. > > tom > > On Jul 2, 2010, at 1:01 PM, Vladimir Kozlov wrote: > >> I wanted to do this for long time as EA improvement >> since IGVN optimization will simplify ideal graph. >> >> http://cr.openjdk.java.net/~kvn/6966411/webrev >> >> Fixed 6966411: escape.cpp:450 assert(base->Opcode() == Op_ConP >> >> OptimizeStringConcat optimization replaces calls with inlined >> methods during do_late_inline(). It creates dead paths which >> are not eliminated before Escape Analysis since IGVN optimization >> is not executed: >> >> 62 ConL === 0 [[ 63 92 ]] #long:8 >> 63 AddP === _ 1 1 62 [[ 64 ]] !jvms: CtorTests::StringBuilder0002 @ bci:7 >> >> Solution: >> Execute IGVN optimization before and after Escape Analysis. >> Use new PhaseIterGVN field ConnectionGraph::_igvn instead of >> passing phase as EA methods parameter. >> >> Failed test, JPRT > From vladimir.kozlov at oracle.com Fri Jul 2 17:18:49 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 02 Jul 2010 17:18:49 -0700 Subject: review (M) for 6965184: possible races in make_not_entrant_or_zombie In-Reply-To: <1D1B5C11-75D2-468D-A2E4-F546689B6D60@oracle.com> References: <1D1B5C11-75D2-468D-A2E4-F546689B6D60@oracle.com> Message-ID: <4C2E81E9.8040303@oracle.com> Tom, Nice VTune cleanup :) Thank you for consolidating sweep logging code. In nmethod.cpp why you don't use the_method() in your new code (// Remove nmethod from method) ? In sweeper.cpp why you need second (_invocations > 0) check? Only current thread will modify _invocations now after your changes. Why you replaced next code: ! // We want to visit all nmethods after NmethodSweepFraction invocations. ! // If invocation is 1 we do the rest ! int todo = CodeCache::nof_blobs(); ! if (_invocations > 1) { ! todo = (CodeCache::nof_blobs() - _seen) / _invocations; ! } ... ! for(int i = 0; i < todo && _current != NULL; i++) { whith this: ! int todo = (CodeCache::nof_nmethods() - _seen) / _invocations; ... ! // The last invocation iterates to the end of the code cache ! for (int i = 0; (i < todo || _invocations == 0) && _current != NULL; i++) { First, _invocations can't be 0 according to the code in possibly_sweep() Second, if it was 0 then you will get division by 0 in todo expression. Next assert also looks strange: + assert(_invocations > 0 || _current == NULL, "must have scanned the whole cache"); Vladimir Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/6965184 > > 6965184: possible races in make_not_entrant_or_zombie > Reviewed-by: > > While investigating the sweeper concurrency problems I identified a > bunch of minor issues that could lead to races. NMethod groups a > bunch of flags into a struct using bitfield which was okay in the past > because they were either written by the constructor, at a safepoint or > with a single lock held. Now some of those fields are written under > one lock and some are written under another so they should be > separated. I've done away with nmFlags all together and moved a bunch > of common initialization into a new method. I also deleted a other of > unused or dead things. > > In make_not_entrant_or_zombie, all the zombie logic used to be > performed at a safepoint but now it can happen concurrently so the > logic that is executed outside of the Patching_lock has to be more > careful. All the not_entrant logic has been moved into the region > protected by the Patching_lock. The link between the nmethod and the > methodOop is also broken ealier though a strong reference to the > methodOop is maintained to make sure it stays alive. > > There were problems with the maintenance of _sweep_started and > _invocations that could mistakenly allow another thread into > possibly_sweep but only if there was no work to be done. Also threads > besides the sweeping thread could clear _sweep_started. > > The sweeper divides the cache based on the number of blobs even though > it only works on nmethod, so I added a nof_nmethods count along with a > nof_adapters count just for informational purposes. > > As a cleanup I also deleted the dead and unused VTune logic since it > doesn't work and VTune uses JVMTI agents these days. > > Tested with NSK jvmti,jdi,jdb,hprof,jit,regression and JDI_REGRESSION > tests. From tom.rodriguez at oracle.com Fri Jul 2 17:30:40 2010 From: tom.rodriguez at oracle.com (tom.rodriguez at oracle.com) Date: Sat, 03 Jul 2010 00:30:40 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6965671: fatal error: acquiring lock JNIGlobalHandle_lock/16 out of order with lock CodeCache_lock/1 Message-ID: <20100703003043.EBBBD47713@hg.openjdk.java.net> Changeset: 65b0c03b165d Author: never Date: 2010-07-02 15:01 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/65b0c03b165d 6965671: fatal error: acquiring lock JNIGlobalHandle_lock/16 out of order with lock CodeCache_lock/1 Reviewed-by: kvn, dcubed ! src/share/vm/prims/jvmtiCodeBlobEvents.cpp From tom.rodriguez at oracle.com Fri Jul 2 20:10:02 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Fri, 2 Jul 2010 20:10:02 -0700 Subject: Request for reviews (M): 6966411: escape.cpp:450 assert(base->Opcode() == Op_ConP In-Reply-To: <4C2E6E03.2060109@oracle.com> References: <4C2E4585.5020007@oracle.com> <2D96EC6B-CFF0-4B15-8186-D4EA6B89E931@oracle.com> <4C2E6E03.2060109@oracle.com> Message-ID: <2E8FC7CB-37E1-4649-B228-218894F6B1E0@oracle.com> Looks good. tom On Jul 2, 2010, at 3:53 PM, Vladimir Kozlov wrote: > Thank you, Tom > > oop_null/noop_null are generated outside ConnectionGraph constructor > which creates array _nodes[] of fixed size C->unique() and it should > include space for oop_null/noop_null. When Connection graph is populated > escape analysis relies on the fact that no new ideal nodes are created. > > I moved all Compile code into new method ConnectionGraph::do_analysis() > and moved dump() into compute_escape(). > > http://cr.openjdk.java.net/~kvn/6966411/webrev.01 > > thanks, > Vladimir > > Tom Rodriguez wrote: >> I'm glad you're doing this. Is the oop_null/noop_null stuff still needed? I can't remember the reason for that. Could it be moved into compute_escape? Maybe the PrintEscapeAnalysis stuff could be there too. Otherwise it looks good. >> tom >> On Jul 2, 2010, at 1:01 PM, Vladimir Kozlov wrote: >>> I wanted to do this for long time as EA improvement >>> since IGVN optimization will simplify ideal graph. >>> >>> http://cr.openjdk.java.net/~kvn/6966411/webrev >>> >>> Fixed 6966411: escape.cpp:450 assert(base->Opcode() == Op_ConP >>> >>> OptimizeStringConcat optimization replaces calls with inlined >>> methods during do_late_inline(). It creates dead paths which >>> are not eliminated before Escape Analysis since IGVN optimization >>> is not executed: >>> >>> 62 ConL === 0 [[ 63 92 ]] #long:8 >>> 63 AddP === _ 1 1 62 [[ 64 ]] !jvms: CtorTests::StringBuilder0002 @ bci:7 >>> >>> Solution: >>> Execute IGVN optimization before and after Escape Analysis. >>> Use new PhaseIterGVN field ConnectionGraph::_igvn instead of >>> passing phase as EA methods parameter. >>> >>> Failed test, JPRT From vladimir.kozlov at oracle.com Fri Jul 2 23:45:56 2010 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Sat, 03 Jul 2010 06:45:56 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6966411: escape.cpp:450 assert(base->Opcode() == Op_ConP Message-ID: <20100703064605.9D87647720@hg.openjdk.java.net> Changeset: 60a14ad85270 Author: kvn Date: 2010-07-02 17:30 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/60a14ad85270 6966411: escape.cpp:450 assert(base->Opcode() == Op_ConP Summary: Execute IGVN optimization before and after Escape Analysis Reviewed-by: never ! src/share/vm/opto/callnode.cpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/compile.hpp ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/escape.hpp From Dalibor.Topic at Sun.COM Tue Jul 6 03:20:38 2010 From: Dalibor.Topic at Sun.COM (Dalibor Topic) Date: Tue, 06 Jul 2010 12:20:38 +0200 Subject: [PATCH] openjdk/zero: only use FPU opcodes if FPU is available In-Reply-To: <20100623090305.GA23103@Chamillionaire.breakpoint.cc> References: <20100621195007.GA8283@Chamillionaire.breakpoint.cc> <20100622084750.GA3420@redhat.com> <20100623072138.GA22204@Chamillionaire.breakpoint.cc> <20100623082921.GA3316@redhat.com> <20100623090305.GA23103@Chamillionaire.breakpoint.cc> Message-ID: <4C330376.5010309@sun.com> On 6/23/10 11:03 AM, Sebastian Andrzej Siewior wrote: >>>> Have you signed the SCA? If so I can (or you can) make a webrev >>>> for this and submit it for inclusion. >>> >>> I haven't. >> >> Are you able to sign it? > I clicked that link but I ended somewhere at oracle.com with 404. Please try http://openjdk.java.net/legal/sca.pdf cheers, dalibor topic -- Dalibor Topic Phone: +49 40 23646738 Oracle ORACLE Deutschland B.V. & Co. KG | Nagelsweg 55 | 20097 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Rijnzathe 6, 3454PV De Meern, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: J?rgen Kunz, Marcel van de Molen, Alexander van der Ven Oracle is committed to developing practices and products that help protect the environment From tom.rodriguez at oracle.com Tue Jul 6 10:43:04 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 6 Jul 2010 10:43:04 -0700 Subject: review (M) for 6965184: possible races in make_not_entrant_or_zombie In-Reply-To: <4C2E81E9.8040303@oracle.com> References: <1D1B5C11-75D2-468D-A2E4-F546689B6D60@oracle.com> <4C2E81E9.8040303@oracle.com> Message-ID: On Jul 2, 2010, at 5:18 PM, Vladimir Kozlov wrote: > Tom, > > Nice VTune cleanup :) > > Thank you for consolidating sweep logging code. > > In nmethod.cpp why you don't use the_method() in your new code (// Remove nmethod from method) ? It's only purpose is to make sure the method doesn't get unloaded until the method exits. The nmethodLocker keeps the sweeper from actually freeing the nmethod itself but there's nothing stopping it from actually getting unloaded which would make nmethod::_method become null which could break later code. I considered augmenting the nmethodLocker to also have a strong reference to the method but I think this is the only place that's exposed to that problem. I think the other uses of nmethodLocker are safe because of their context. > > In sweeper.cpp why you need second (_invocations > 0) check? Only current thread will modify _invocations now after your changes. I moved the decrement of _invocations later in my changes and didn't go back to make sure the changes were all consistent. > Why you replaced next code: > > ! // We want to visit all nmethods after NmethodSweepFraction invocations. > ! // If invocation is 1 we do the rest > ! int todo = CodeCache::nof_blobs(); > ! if (_invocations > 1) { > ! todo = (CodeCache::nof_blobs() - _seen) / _invocations; > ! } > ... > ! for(int i = 0; i < todo && _current != NULL; i++) { > > whith this: > > ! int todo = (CodeCache::nof_nmethods() - _seen) / _invocations; > ... > ! // The last invocation iterates to the end of the code cache > ! for (int i = 0; (i < todo || _invocations == 0) && _current != NULL; i++) { The original code relied on nof_blobs() being greater than the number of nmethods remaining to be processed in the code cache on the final pass. If it happens to be less then we won't process the whole code cache. It's very unlikely to happen in practice but I can build a scenario where it would. I decided to make the last pass explicitly process the whole thing but I moved the decrement of _invocations that broke this code. It's should be _invocations == 1 so the last pass will process until _current == NULL. > > First, _invocations can't be 0 according to the code in possibly_sweep() > Second, if it was 0 then you will get division by 0 in todo expression. > > Next assert also looks strange: > + assert(_invocations > 0 || _current == NULL, "must have scanned the whole cache"); Same invocations update problem. I'll fix it and retest and send out a the updated webrev. tom > > Vladimir > > Tom Rodriguez wrote: >> http://cr.openjdk.java.net/~never/6965184 >> 6965184: possible races in make_not_entrant_or_zombie >> Reviewed-by: >> While investigating the sweeper concurrency problems I identified a >> bunch of minor issues that could lead to races. NMethod groups a >> bunch of flags into a struct using bitfield which was okay in the past >> because they were either written by the constructor, at a safepoint or >> with a single lock held. Now some of those fields are written under >> one lock and some are written under another so they should be >> separated. I've done away with nmFlags all together and moved a bunch >> of common initialization into a new method. I also deleted a other of >> unused or dead things. >> In make_not_entrant_or_zombie, all the zombie logic used to be >> performed at a safepoint but now it can happen concurrently so the >> logic that is executed outside of the Patching_lock has to be more >> careful. All the not_entrant logic has been moved into the region >> protected by the Patching_lock. The link between the nmethod and the >> methodOop is also broken ealier though a strong reference to the >> methodOop is maintained to make sure it stays alive. >> There were problems with the maintenance of _sweep_started and >> _invocations that could mistakenly allow another thread into >> possibly_sweep but only if there was no work to be done. Also threads >> besides the sweeping thread could clear _sweep_started. >> The sweeper divides the cache based on the number of blobs even though >> it only works on nmethod, so I added a nof_nmethods count along with a >> nof_adapters count just for informational purposes. >> As a cleanup I also deleted the dead and unused VTune logic since it >> doesn't work and VTune uses JVMTI agents these days. >> Tested with NSK jvmti,jdi,jdb,hprof,jit,regression and JDI_REGRESSION >> tests. From tom.rodriguez at oracle.com Tue Jul 6 11:50:49 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 6 Jul 2010 11:50:49 -0700 Subject: review (M) for 6965184: possible races in make_not_entrant_or_zombie In-Reply-To: <4C2E81E9.8040303@oracle.com> References: <1D1B5C11-75D2-468D-A2E4-F546689B6D60@oracle.com> <4C2E81E9.8040303@oracle.com> Message-ID: <238B245E-CA3F-4102-9C51-34481B0808C8@oracle.com> > > > In sweeper.cpp why you need second (_invocations > 0) check? Only current thread will modify _invocations now after your changes. I forgot to answer this one. There are two variables that are changing but only on atomic operation involved. It's possible for this execution to occur: Thread 1 - 122 if (_invocations > 0) { Thread 2 - 130 _invocations--; Thread 2 - 132 _sweep_started = 0; Thread 1 - 124 jint old = Atomic::cmpxchg( 1, &_sweep_started, 0 ); So thread 1 would enter possibly_sweep with _invocations == 0, so that's why I check it again. The alternative is to always cmpxchg and then check if if _invocations > 0. tom > > Why you replaced next code: > > ! // We want to visit all nmethods after NmethodSweepFraction invocations. > ! // If invocation is 1 we do the rest > ! int todo = CodeCache::nof_blobs(); > ! if (_invocations > 1) { > ! todo = (CodeCache::nof_blobs() - _seen) / _invocations; > ! } > ... > ! for(int i = 0; i < todo && _current != NULL; i++) { > > whith this: > > ! int todo = (CodeCache::nof_nmethods() - _seen) / _invocations; > ... > ! // The last invocation iterates to the end of the code cache > ! for (int i = 0; (i < todo || _invocations == 0) && _current != NULL; i++) { > > First, _invocations can't be 0 according to the code in possibly_sweep() > Second, if it was 0 then you will get division by 0 in todo expression. > > Next assert also looks strange: > + assert(_invocations > 0 || _current == NULL, "must have scanned the whole cache"); > > Vladimir > > Tom Rodriguez wrote: >> http://cr.openjdk.java.net/~never/6965184 >> 6965184: possible races in make_not_entrant_or_zombie >> Reviewed-by: >> While investigating the sweeper concurrency problems I identified a >> bunch of minor issues that could lead to races. NMethod groups a >> bunch of flags into a struct using bitfield which was okay in the past >> because they were either written by the constructor, at a safepoint or >> with a single lock held. Now some of those fields are written under >> one lock and some are written under another so they should be >> separated. I've done away with nmFlags all together and moved a bunch >> of common initialization into a new method. I also deleted a other of >> unused or dead things. >> In make_not_entrant_or_zombie, all the zombie logic used to be >> performed at a safepoint but now it can happen concurrently so the >> logic that is executed outside of the Patching_lock has to be more >> careful. All the not_entrant logic has been moved into the region >> protected by the Patching_lock. The link between the nmethod and the >> methodOop is also broken ealier though a strong reference to the >> methodOop is maintained to make sure it stays alive. >> There were problems with the maintenance of _sweep_started and >> _invocations that could mistakenly allow another thread into >> possibly_sweep but only if there was no work to be done. Also threads >> besides the sweeping thread could clear _sweep_started. >> The sweeper divides the cache based on the number of blobs even though >> it only works on nmethod, so I added a nof_nmethods count along with a >> nof_adapters count just for informational purposes. >> As a cleanup I also deleted the dead and unused VTune logic since it >> doesn't work and VTune uses JVMTI agents these days. >> Tested with NSK jvmti,jdi,jdb,hprof,jit,regression and JDI_REGRESSION >> tests. From tom.rodriguez at oracle.com Tue Jul 6 11:53:20 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 6 Jul 2010 11:53:20 -0700 Subject: review (M) for 6965184: possible races in make_not_entrant_or_zombie In-Reply-To: <4C2E81E9.8040303@oracle.com> References: <1D1B5C11-75D2-468D-A2E4-F546689B6D60@oracle.com> <4C2E81E9.8040303@oracle.com> Message-ID: <91280BBE-D95D-4C7D-B4ED-6C29FBF3E6E9@oracle.com> I've correct those uses of _invocations and regenerated the webrev. I'm rerunning my tests. tom On Jul 2, 2010, at 5:18 PM, Vladimir Kozlov wrote: > Tom, > > Nice VTune cleanup :) > > Thank you for consolidating sweep logging code. > > In nmethod.cpp why you don't use the_method() in your new code (// Remove nmethod from method) ? > > In sweeper.cpp why you need second (_invocations > 0) check? Only current thread will modify _invocations now after your changes. > > Why you replaced next code: > > ! // We want to visit all nmethods after NmethodSweepFraction invocations. > ! // If invocation is 1 we do the rest > ! int todo = CodeCache::nof_blobs(); > ! if (_invocations > 1) { > ! todo = (CodeCache::nof_blobs() - _seen) / _invocations; > ! } > ... > ! for(int i = 0; i < todo && _current != NULL; i++) { > > whith this: > > ! int todo = (CodeCache::nof_nmethods() - _seen) / _invocations; > ... > ! // The last invocation iterates to the end of the code cache > ! for (int i = 0; (i < todo || _invocations == 0) && _current != NULL; i++) { > > First, _invocations can't be 0 according to the code in possibly_sweep() > Second, if it was 0 then you will get division by 0 in todo expression. > > Next assert also looks strange: > + assert(_invocations > 0 || _current == NULL, "must have scanned the whole cache"); > > Vladimir > > Tom Rodriguez wrote: >> http://cr.openjdk.java.net/~never/6965184 >> 6965184: possible races in make_not_entrant_or_zombie >> Reviewed-by: >> While investigating the sweeper concurrency problems I identified a >> bunch of minor issues that could lead to races. NMethod groups a >> bunch of flags into a struct using bitfield which was okay in the past >> because they were either written by the constructor, at a safepoint or >> with a single lock held. Now some of those fields are written under >> one lock and some are written under another so they should be >> separated. I've done away with nmFlags all together and moved a bunch >> of common initialization into a new method. I also deleted a other of >> unused or dead things. >> In make_not_entrant_or_zombie, all the zombie logic used to be >> performed at a safepoint but now it can happen concurrently so the >> logic that is executed outside of the Patching_lock has to be more >> careful. All the not_entrant logic has been moved into the region >> protected by the Patching_lock. The link between the nmethod and the >> methodOop is also broken ealier though a strong reference to the >> methodOop is maintained to make sure it stays alive. >> There were problems with the maintenance of _sweep_started and >> _invocations that could mistakenly allow another thread into >> possibly_sweep but only if there was no work to be done. Also threads >> besides the sweeping thread could clear _sweep_started. >> The sweeper divides the cache based on the number of blobs even though >> it only works on nmethod, so I added a nof_nmethods count along with a >> nof_adapters count just for informational purposes. >> As a cleanup I also deleted the dead and unused VTune logic since it >> doesn't work and VTune uses JVMTI agents these days. >> Tested with NSK jvmti,jdi,jdb,hprof,jit,regression and JDI_REGRESSION >> tests. From vladimir.kozlov at oracle.com Tue Jul 6 12:55:54 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 06 Jul 2010 12:55:54 -0700 Subject: review (M) for 6965184: possible races in make_not_entrant_or_zombie In-Reply-To: <91280BBE-D95D-4C7D-B4ED-6C29FBF3E6E9@oracle.com> References: <1D1B5C11-75D2-468D-A2E4-F546689B6D60@oracle.com> <4C2E81E9.8040303@oracle.com> <91280BBE-D95D-4C7D-B4ED-6C29FBF3E6E9@oracle.com> Message-ID: <4C338A4A.5050101@oracle.com> Looks good. Did you change anything else I need to review in addition to _invocations at lines 161 and 178 in sweeper.cpp? Thanks, Vladimir Tom Rodriguez wrote: > I've correct those uses of _invocations and regenerated the webrev. I'm rerunning my tests. > > tom > > On Jul 2, 2010, at 5:18 PM, Vladimir Kozlov wrote: > >> Tom, >> >> Nice VTune cleanup :) >> >> Thank you for consolidating sweep logging code. >> >> In nmethod.cpp why you don't use the_method() in your new code (// Remove nmethod from method) ? >> >> In sweeper.cpp why you need second (_invocations > 0) check? Only current thread will modify _invocations now after your changes. >> >> Why you replaced next code: >> >> ! // We want to visit all nmethods after NmethodSweepFraction invocations. >> ! // If invocation is 1 we do the rest >> ! int todo = CodeCache::nof_blobs(); >> ! if (_invocations > 1) { >> ! todo = (CodeCache::nof_blobs() - _seen) / _invocations; >> ! } >> ... >> ! for(int i = 0; i < todo && _current != NULL; i++) { >> >> whith this: >> >> ! int todo = (CodeCache::nof_nmethods() - _seen) / _invocations; >> ... >> ! // The last invocation iterates to the end of the code cache >> ! for (int i = 0; (i < todo || _invocations == 0) && _current != NULL; i++) { >> >> First, _invocations can't be 0 according to the code in possibly_sweep() >> Second, if it was 0 then you will get division by 0 in todo expression. >> >> Next assert also looks strange: >> + assert(_invocations > 0 || _current == NULL, "must have scanned the whole cache"); >> >> Vladimir >> >> Tom Rodriguez wrote: >>> http://cr.openjdk.java.net/~never/6965184 >>> 6965184: possible races in make_not_entrant_or_zombie >>> Reviewed-by: >>> While investigating the sweeper concurrency problems I identified a >>> bunch of minor issues that could lead to races. NMethod groups a >>> bunch of flags into a struct using bitfield which was okay in the past >>> because they were either written by the constructor, at a safepoint or >>> with a single lock held. Now some of those fields are written under >>> one lock and some are written under another so they should be >>> separated. I've done away with nmFlags all together and moved a bunch >>> of common initialization into a new method. I also deleted a other of >>> unused or dead things. >>> In make_not_entrant_or_zombie, all the zombie logic used to be >>> performed at a safepoint but now it can happen concurrently so the >>> logic that is executed outside of the Patching_lock has to be more >>> careful. All the not_entrant logic has been moved into the region >>> protected by the Patching_lock. The link between the nmethod and the >>> methodOop is also broken ealier though a strong reference to the >>> methodOop is maintained to make sure it stays alive. >>> There were problems with the maintenance of _sweep_started and >>> _invocations that could mistakenly allow another thread into >>> possibly_sweep but only if there was no work to be done. Also threads >>> besides the sweeping thread could clear _sweep_started. >>> The sweeper divides the cache based on the number of blobs even though >>> it only works on nmethod, so I added a nof_nmethods count along with a >>> nof_adapters count just for informational purposes. >>> As a cleanup I also deleted the dead and unused VTune logic since it >>> doesn't work and VTune uses JVMTI agents these days. >>> Tested with NSK jvmti,jdi,jdb,hprof,jit,regression and JDI_REGRESSION >>> tests. > From tom.rodriguez at oracle.com Tue Jul 6 13:02:48 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 6 Jul 2010 13:02:48 -0700 Subject: review (M) for 6965184: possible races in make_not_entrant_or_zombie In-Reply-To: <4C338A4A.5050101@oracle.com> References: <1D1B5C11-75D2-468D-A2E4-F546689B6D60@oracle.com> <4C2E81E9.8040303@oracle.com> <91280BBE-D95D-4C7D-B4ED-6C29FBF3E6E9@oracle.com> <4C338A4A.5050101@oracle.com> Message-ID: No just those lines testing invocations for 0 changed to 1. Everything else stayed the same. tom On Jul 6, 2010, at 12:55 PM, Vladimir Kozlov wrote: > Looks good. > > Did you change anything else I need to review in addition to _invocations at lines 161 and 178 in sweeper.cpp? > > Thanks, > Vladimir > > Tom Rodriguez wrote: >> I've correct those uses of _invocations and regenerated the webrev. I'm rerunning my tests. >> tom >> On Jul 2, 2010, at 5:18 PM, Vladimir Kozlov wrote: >>> Tom, >>> >>> Nice VTune cleanup :) >>> >>> Thank you for consolidating sweep logging code. >>> >>> In nmethod.cpp why you don't use the_method() in your new code (// Remove nmethod from method) ? >>> >>> In sweeper.cpp why you need second (_invocations > 0) check? Only current thread will modify _invocations now after your changes. >>> >>> Why you replaced next code: >>> >>> ! // We want to visit all nmethods after NmethodSweepFraction invocations. >>> ! // If invocation is 1 we do the rest >>> ! int todo = CodeCache::nof_blobs(); >>> ! if (_invocations > 1) { >>> ! todo = (CodeCache::nof_blobs() - _seen) / _invocations; >>> ! } >>> ... >>> ! for(int i = 0; i < todo && _current != NULL; i++) { >>> >>> whith this: >>> >>> ! int todo = (CodeCache::nof_nmethods() - _seen) / _invocations; >>> ... >>> ! // The last invocation iterates to the end of the code cache >>> ! for (int i = 0; (i < todo || _invocations == 0) && _current != NULL; i++) { >>> >>> First, _invocations can't be 0 according to the code in possibly_sweep() >>> Second, if it was 0 then you will get division by 0 in todo expression. >>> >>> Next assert also looks strange: >>> + assert(_invocations > 0 || _current == NULL, "must have scanned the whole cache"); >>> >>> Vladimir >>> >>> Tom Rodriguez wrote: >>>> http://cr.openjdk.java.net/~never/6965184 >>>> 6965184: possible races in make_not_entrant_or_zombie >>>> Reviewed-by: >>>> While investigating the sweeper concurrency problems I identified a >>>> bunch of minor issues that could lead to races. NMethod groups a >>>> bunch of flags into a struct using bitfield which was okay in the past >>>> because they were either written by the constructor, at a safepoint or >>>> with a single lock held. Now some of those fields are written under >>>> one lock and some are written under another so they should be >>>> separated. I've done away with nmFlags all together and moved a bunch >>>> of common initialization into a new method. I also deleted a other of >>>> unused or dead things. >>>> In make_not_entrant_or_zombie, all the zombie logic used to be >>>> performed at a safepoint but now it can happen concurrently so the >>>> logic that is executed outside of the Patching_lock has to be more >>>> careful. All the not_entrant logic has been moved into the region >>>> protected by the Patching_lock. The link between the nmethod and the >>>> methodOop is also broken ealier though a strong reference to the >>>> methodOop is maintained to make sure it stays alive. >>>> There were problems with the maintenance of _sweep_started and >>>> _invocations that could mistakenly allow another thread into >>>> possibly_sweep but only if there was no work to be done. Also threads >>>> besides the sweeping thread could clear _sweep_started. >>>> The sweeper divides the cache based on the number of blobs even though >>>> it only works on nmethod, so I added a nof_nmethods count along with a >>>> nof_adapters count just for informational purposes. >>>> As a cleanup I also deleted the dead and unused VTune logic since it >>>> doesn't work and VTune uses JVMTI agents these days. >>>> Tested with NSK jvmti,jdi,jdb,hprof,jit,regression and JDI_REGRESSION >>>> tests. From vladimir.kozlov at oracle.com Tue Jul 6 14:06:42 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 06 Jul 2010 14:06:42 -0700 Subject: review (M) for 6965184: possible races in make_not_entrant_or_zombie In-Reply-To: References: <1D1B5C11-75D2-468D-A2E4-F546689B6D60@oracle.com> <4C2E81E9.8040303@oracle.com> <91280BBE-D95D-4C7D-B4ED-6C29FBF3E6E9@oracle.com> <4C338A4A.5050101@oracle.com> Message-ID: <4C339AE2.2060504@oracle.com> Then, I think, it is good to push. Thanks, Vladimir Tom Rodriguez wrote: > No just those lines testing invocations for 0 changed to 1. Everything else stayed the same. > > tom > > On Jul 6, 2010, at 12:55 PM, Vladimir Kozlov wrote: > >> Looks good. >> >> Did you change anything else I need to review in addition to _invocations at lines 161 and 178 in sweeper.cpp? >> >> Thanks, >> Vladimir >> >> Tom Rodriguez wrote: >>> I've correct those uses of _invocations and regenerated the webrev. I'm rerunning my tests. >>> tom >>> On Jul 2, 2010, at 5:18 PM, Vladimir Kozlov wrote: >>>> Tom, >>>> >>>> Nice VTune cleanup :) >>>> >>>> Thank you for consolidating sweep logging code. >>>> >>>> In nmethod.cpp why you don't use the_method() in your new code (// Remove nmethod from method) ? >>>> >>>> In sweeper.cpp why you need second (_invocations > 0) check? Only current thread will modify _invocations now after your changes. >>>> >>>> Why you replaced next code: >>>> >>>> ! // We want to visit all nmethods after NmethodSweepFraction invocations. >>>> ! // If invocation is 1 we do the rest >>>> ! int todo = CodeCache::nof_blobs(); >>>> ! if (_invocations > 1) { >>>> ! todo = (CodeCache::nof_blobs() - _seen) / _invocations; >>>> ! } >>>> ... >>>> ! for(int i = 0; i < todo && _current != NULL; i++) { >>>> >>>> whith this: >>>> >>>> ! int todo = (CodeCache::nof_nmethods() - _seen) / _invocations; >>>> ... >>>> ! // The last invocation iterates to the end of the code cache >>>> ! for (int i = 0; (i < todo || _invocations == 0) && _current != NULL; i++) { >>>> >>>> First, _invocations can't be 0 according to the code in possibly_sweep() >>>> Second, if it was 0 then you will get division by 0 in todo expression. >>>> >>>> Next assert also looks strange: >>>> + assert(_invocations > 0 || _current == NULL, "must have scanned the whole cache"); >>>> >>>> Vladimir >>>> >>>> Tom Rodriguez wrote: >>>>> http://cr.openjdk.java.net/~never/6965184 >>>>> 6965184: possible races in make_not_entrant_or_zombie >>>>> Reviewed-by: >>>>> While investigating the sweeper concurrency problems I identified a >>>>> bunch of minor issues that could lead to races. NMethod groups a >>>>> bunch of flags into a struct using bitfield which was okay in the past >>>>> because they were either written by the constructor, at a safepoint or >>>>> with a single lock held. Now some of those fields are written under >>>>> one lock and some are written under another so they should be >>>>> separated. I've done away with nmFlags all together and moved a bunch >>>>> of common initialization into a new method. I also deleted a other of >>>>> unused or dead things. >>>>> In make_not_entrant_or_zombie, all the zombie logic used to be >>>>> performed at a safepoint but now it can happen concurrently so the >>>>> logic that is executed outside of the Patching_lock has to be more >>>>> careful. All the not_entrant logic has been moved into the region >>>>> protected by the Patching_lock. The link between the nmethod and the >>>>> methodOop is also broken ealier though a strong reference to the >>>>> methodOop is maintained to make sure it stays alive. >>>>> There were problems with the maintenance of _sweep_started and >>>>> _invocations that could mistakenly allow another thread into >>>>> possibly_sweep but only if there was no work to be done. Also threads >>>>> besides the sweeping thread could clear _sweep_started. >>>>> The sweeper divides the cache based on the number of blobs even though >>>>> it only works on nmethod, so I added a nof_nmethods count along with a >>>>> nof_adapters count just for informational purposes. >>>>> As a cleanup I also deleted the dead and unused VTune logic since it >>>>> doesn't work and VTune uses JVMTI agents these days. >>>>> Tested with NSK jvmti,jdi,jdb,hprof,jit,regression and JDI_REGRESSION >>>>> tests. > From tom.rodriguez at oracle.com Tue Jul 6 14:22:15 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 6 Jul 2010 14:22:15 -0700 Subject: review (M) for 6965184: possible races in make_not_entrant_or_zombie In-Reply-To: <4C339AE2.2060504@oracle.com> References: <1D1B5C11-75D2-468D-A2E4-F546689B6D60@oracle.com> <4C2E81E9.8040303@oracle.com> <91280BBE-D95D-4C7D-B4ED-6C29FBF3E6E9@oracle.com> <4C338A4A.5050101@oracle.com> <4C339AE2.2060504@oracle.com> Message-ID: <8C23C036-3D2B-4442-8A4F-0579717D0230@oracle.com> Thanks! tom On Jul 6, 2010, at 2:06 PM, Vladimir Kozlov wrote: > Then, I think, it is good to push. > > Thanks, > Vladimir > > Tom Rodriguez wrote: >> No just those lines testing invocations for 0 changed to 1. Everything else stayed the same. >> tom >> On Jul 6, 2010, at 12:55 PM, Vladimir Kozlov wrote: >>> Looks good. >>> >>> Did you change anything else I need to review in addition to _invocations at lines 161 and 178 in sweeper.cpp? >>> >>> Thanks, >>> Vladimir >>> >>> Tom Rodriguez wrote: >>>> I've correct those uses of _invocations and regenerated the webrev. I'm rerunning my tests. >>>> tom >>>> On Jul 2, 2010, at 5:18 PM, Vladimir Kozlov wrote: >>>>> Tom, >>>>> >>>>> Nice VTune cleanup :) >>>>> >>>>> Thank you for consolidating sweep logging code. >>>>> >>>>> In nmethod.cpp why you don't use the_method() in your new code (// Remove nmethod from method) ? >>>>> >>>>> In sweeper.cpp why you need second (_invocations > 0) check? Only current thread will modify _invocations now after your changes. >>>>> >>>>> Why you replaced next code: >>>>> >>>>> ! // We want to visit all nmethods after NmethodSweepFraction invocations. >>>>> ! // If invocation is 1 we do the rest >>>>> ! int todo = CodeCache::nof_blobs(); >>>>> ! if (_invocations > 1) { >>>>> ! todo = (CodeCache::nof_blobs() - _seen) / _invocations; >>>>> ! } >>>>> ... >>>>> ! for(int i = 0; i < todo && _current != NULL; i++) { >>>>> >>>>> whith this: >>>>> >>>>> ! int todo = (CodeCache::nof_nmethods() - _seen) / _invocations; >>>>> ... >>>>> ! // The last invocation iterates to the end of the code cache >>>>> ! for (int i = 0; (i < todo || _invocations == 0) && _current != NULL; i++) { >>>>> >>>>> First, _invocations can't be 0 according to the code in possibly_sweep() >>>>> Second, if it was 0 then you will get division by 0 in todo expression. >>>>> >>>>> Next assert also looks strange: >>>>> + assert(_invocations > 0 || _current == NULL, "must have scanned the whole cache"); >>>>> >>>>> Vladimir >>>>> >>>>> Tom Rodriguez wrote: >>>>>> http://cr.openjdk.java.net/~never/6965184 >>>>>> 6965184: possible races in make_not_entrant_or_zombie >>>>>> Reviewed-by: >>>>>> While investigating the sweeper concurrency problems I identified a >>>>>> bunch of minor issues that could lead to races. NMethod groups a >>>>>> bunch of flags into a struct using bitfield which was okay in the past >>>>>> because they were either written by the constructor, at a safepoint or >>>>>> with a single lock held. Now some of those fields are written under >>>>>> one lock and some are written under another so they should be >>>>>> separated. I've done away with nmFlags all together and moved a bunch >>>>>> of common initialization into a new method. I also deleted a other of >>>>>> unused or dead things. >>>>>> In make_not_entrant_or_zombie, all the zombie logic used to be >>>>>> performed at a safepoint but now it can happen concurrently so the >>>>>> logic that is executed outside of the Patching_lock has to be more >>>>>> careful. All the not_entrant logic has been moved into the region >>>>>> protected by the Patching_lock. The link between the nmethod and the >>>>>> methodOop is also broken ealier though a strong reference to the >>>>>> methodOop is maintained to make sure it stays alive. >>>>>> There were problems with the maintenance of _sweep_started and >>>>>> _invocations that could mistakenly allow another thread into >>>>>> possibly_sweep but only if there was no work to be done. Also threads >>>>>> besides the sweeping thread could clear _sweep_started. >>>>>> The sweeper divides the cache based on the number of blobs even though >>>>>> it only works on nmethod, so I added a nof_nmethods count along with a >>>>>> nof_adapters count just for informational purposes. >>>>>> As a cleanup I also deleted the dead and unused VTune logic since it >>>>>> doesn't work and VTune uses JVMTI agents these days. >>>>>> Tested with NSK jvmti,jdi,jdb,hprof,jit,regression and JDI_REGRESSION >>>>>> tests. From David.Holmes at oracle.com Tue Jul 6 16:49:21 2010 From: David.Holmes at oracle.com (David Holmes) Date: Wed, 07 Jul 2010 09:49:21 +1000 Subject: New portion of improvements for Dual-Pivot Quicksort In-Reply-To: <4C20B978.1040607@mail.ru> References: <4C20A97C.2050601@mail.ru> <4C20B766.3010202@gmail.com> <4C20B978.1040607@mail.ru> Message-ID: <4C33C101.1010005@oracle.com> I asked someone to take a look at this and it seems that the problem is that a[less++] requires introduction of a temporary to store the pre-incremented index value which in turn increases register pressure and can lead to a register spill. This seems to not only be architecture dependent but even variable on the same architecture (as observed below). As Osvaldo noted C1 does not attempt to decide whether the increment can be reordered with the access and so allow removal of the temporary. You'd need the compiler folk (C1/C2) to comment on whether or not it would be reasonable/possible/practical for C1 to do that - so I've cc'ed them (though I'm not a member of their list so it may be a little while before it gets pushed through to them.) David Holmes Vladimir Iaroslavski said the following on 06/22/10 23:24: > both computers with Intel processor: > > Pentium, Intel, 4 CPU, 3.2 GHz, 2 Gb RAM > Pentium, Intel, 4 CPU, 2.8 GHz, 2 Gb RAM > > Osvaldo Pinali Doederlein wrote: >> Hi Vladimir, >> >>> Hello, >>> >>> I tried with the latest JDK, build 98 and see different behaviour >>> on two computers: 7570 / 8318 and 8560 / 8590, but sorting method >>> works slower with a[less++] instruction on both computers: >> >> Is the first computer (with larger performance diff) an AMD by any >> chance? It's odd that just the a[less++] would make the code so much >> slower. Perhaps the worst compiled code has additional costs in some >> CPUs, e.g. spoiling branch prediction for the bounds checking guards. >> >> Anyway the change is risk-free (including performance) and the >> advantage is important at least in some CPUs, so go ahead (FWIW wrt my >> opinion...). I just wish that C1 would be fixed to not need this kind >> of hacking - as I categorize this as a hack, not even as a "normal" >> low-level Java code optimization - because there are certainly >> millions of uses of the idiom "array[index++/--]" in JavaSE APIs and >> elsewhere. But I'm not familiar with the C1 source so I don't know if >> this is some low hanging fruit that could be addressed quickly (any >> HotSpot engineers there to comment?). >> >> A+ >> Osvaldo >> >>> first second >>> a[less] = ak; less++; / (a[less++] = ak; >>> >>> random: 16371 / 16696 14018 / 14326 >>> ascendant: 2706 / 2762 2884 / 2897 >>> descendant: 2994 / 3108 3170 / 3258 >>> organ pipes: 7073 / 7296 6939 / 7090 >>> stagger(2): 7765 / 8069 7531 / 7731 >>> period(1,2): 653 / 743 719 / 753 >>> random(1..4): 2152 / 2234 1567 / 1591 >>> >>> If I change Test class and populate the array with descendant >>> values, I still see difference in times: 4793 / 5718 >>> see updated attached Test class. >>> >>> Also I'm attaching the latest version of DualPivotQuicksort >>> with minor format changes. If you don't have comments, I'll >>> ask to to integrate the code at the end of this week. >>> >>> Thank you, >>> Vladimir >>> >>> Osvaldo Doederlein wrote: >>>> Hi Vladimir, >>>> >>>> 2010/6/19 Vladimir Iaroslavski >>> > >>>> >>>> Hello Osvaldo, >>>> >>>> I've prepared simple test which scans an array and does assignments >>>> for each element, >>>> see attached Test class: >>>> >>>> a[k] = a[less]; >>>> a[less++] = 0; // or a[less] = 0; less++; >>>> >>>> The result of running "java -client Test" is: >>>> >>>> a[less], less++; Time: 6998 >>>> a[less++]; Time: 8416 >>>> >>>> It is much more than 1%. Is it bug in JVM? Note that under >>>> server VM >>>> >>>> The amount of diff surely depends on the benchmark; your bench >>>> should "zoom" the problem by not having much other work polluting >>>> the measurement. But in my own test with b98 (32-bit), Q6600 CPU, >>>> I've got 5065/5079, so the diff is < 1%. The excessive disadvantage >>>> you report may be something bad in your older b84. >>>> >>>> Anyway I investigated the JIT-compiled code, details in the end >>>> (I've split the benchmark in two classes just to make the comparison >>>> simpler). The problem with "a[less++]" is that "less++" will first >>>> increment "less", _then_ it will use the old value (not-incremented) >>>> to index "a". C1 generates code that is equivalent to: >>>> >>>> int less_incremented = less + 1; >>>> a[less] = 0; >>>> less = less_incremented; >>>> >>>> ...which is a 1-to-1 translation of the IR coming off the bytecode. >>>> C1 is not smart enough to see that the increment can be reordered >>>> after the indexing, maybe because there's a data dependency as the >>>> indexing uses "less"; but due to the semantics of postfix "++" this >>>> dependency is for the before-increment value, so the reordering >>>> would be safe. Maybe that's just some simple missing heuristics that >>>> could be easily added? >>>> >>>> there is no difference between "a[less++]" and "a[less], less++". >>>> >>>> C2 generates completely different code,with 16X unrolling - this is >>>> the inner loop: >>>> >>>> 0x026a6e40: pxor %xmm0,%xmm0 ;*aload_0 >>>> ; - Test1::sort1 at 9 (line 23) >>>> 0x026a6e44: movq %xmm0,0xc(%ecx,%esi,4) >>>> 0x026a6e4a: movq %xmm0,0x14(%ecx,%esi,4) >>>> 0x026a6e50: movq %xmm0,0x1c(%ecx,%esi,4) >>>> 0x026a6e56: movq %xmm0,0x24(%ecx,%esi,4) >>>> 0x026a6e5c: movq %xmm0,0x2c(%ecx,%esi,4) >>>> 0x026a6e62: movq %xmm0,0x34(%ecx,%esi,4) >>>> 0x026a6e68: movq %xmm0,0x3c(%ecx,%esi,4) >>>> 0x026a6e6e: movq %xmm0,0x44(%ecx,%esi,4) ;*iastore >>>> ; - Test1::sort1 at 21 (line 24) >>>> 0x026a6e74: add $0x10,%esi ;*iinc >>>> ; - Test1::sort1 at 22 (line 22) >>>> 0x026a6e77: cmp %ebp,%esi >>>> 0x026a6e79: jl 0x026a6e44 >>>> >>>> There is some extra slow-path code to fill the remaining 1...15 >>>> elements if the loop length is not multiple of 16, and that's all. >>>> C2 detects the redundancy between the "k" and "less" vars, and kills >>>> the also-redundant "a[k] = a[less]" assignment so the net result is >>>> a simple zero-fill of the array. Maybe a different benchmark without >>>> these redundancies would make easier to see that C2 doesn't have a >>>> problem with the postfix "++", but if it had, I think it wouldn't >>>> reach the excellent result above. >>>> >>>> A+ >>>> Osvaldo >>>> >>>> >>>> I'm using JDK 7 on Windows XP: >>>> >>>> java version "1.7.0-ea" >>>> Java(TM) SE Runtime Environment (build 1.7.0-ea-b84) >>>> Java HotSpot(TM) Client VM (build 17.0-b09, mixed mode, sharing) >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> >>>> >>>> This is the C1 code for sort2()'s loop: >>>> >>>> 0x0251c1dc: cmp 0x8(%ecx),%esi ; implicit exception: >>>> dispatches to 0x0251c21e >>>> ;; 30 branch [AE] [RangeCheckStub: 0x454c640] [bci:13] >>>> 0x0251c1df: jae 0x0251c24a >>>> 0x0251c1e5: mov 0xc(%ecx,%esi,4),%ebx ;*iaload: %ebx = a[less]; >>>> ; - Test2::sort2 at 13 (line 23) >>>> 0x0251c1e9: cmp 0x8(%ecx),%edi >>>> ;; 36 branch [AE] [RangeCheckStub: 0x454c7e0] [bci:14] >>>> 0x0251c1ec: jae 0x0251c263 >>>> 0x0251c1f2: mov %ebx,0xc(%ecx,%edi,4) ;*iastore: a[k] = %ebx; >>>> ; - Test2::sort2 at 14 (line 23) >>>> >>>> (sort1/sort2 start to differ here) >>>> >>>> 0x0251c1f6: cmp 0x8(%ecx),%esi >>>> ;; 42 branch [AE] [RangeCheckStub: 0x454c980] [bci:18] >>>> 0x0251c1f9: jae 0x0251c27c >>>> 0x0251c1ff: movl $0x0,0xc(%ecx,%esi,4) ;*iastore: a[less] = 0; >>>> ; - Test2::sort2 at 18 (line 24) >>>> 0x0251c207: inc %esi ; ++less; >>>> 0x0251c208: inc %edi ; OopMap{ecx=Oop off=73} >>>> ;*goto: for k++ >>>> ; - Test2::sort2 at 25 (line 22) >>>> 0x0251c209: test %eax,0x1a0100 ;*goto >>>> ; - Test2::sort2 at 25 (line 22) >>>> ; {poll} >>>> ;; block B1 [4, 6] >>>> >>>> 0x0251c20f: cmp %edx,%edi >>>> ;; 22 branch [LT] [B2] >>>> 0x0251c211: jl 0x0251c1dc ;*if_icmpge: for k < right >>>> ; - Test2::sort2 at 6 (line 22) >>>> >>>> The code looks OK; C1 doesn't do much optimization - no unrolling, >>>> bounds check elimination - but it's otherwise just about the code >>>> you would expect for a simple JITting. >>>> Now, C1 code for sort1()'s loop: >>>> >>>> 0x024bc21c: cmp 0x8(%ecx),%esi ; implicit exception: >>>> dispatches to 0x024bc262 >>>> ;; 30 branch [AE] [RangeCheckStub: 0x44ee3b0] [bci:13] >>>> 0x024bc21f: jae 0x024bc28e >>>> 0x024bc225: mov 0xc(%ecx,%esi,4),%ebx ;*iaload: %ebx = a[less]; >>>> ; - Test1::sort1 at 13 (line 23) >>>> 0x024bc229: cmp 0x8(%ecx),%edi >>>> ;; 36 branch [AE] [RangeCheckStub: 0x44ee550] [bci:14] >>>> 0x024bc22c: jae 0x024bc2a7 >>>> 0x024bc232: mov %ebx,0xc(%ecx,%edi,4) ;*iastore: a[k] = %ebx; >>>> ; - Test1::sort1 at 14 (line 23) >>>> >>>> (sort1/sort2 start to differ here) >>>> >>>> 0x024bc236: mov %esi,%ebx ; Crap! C1 temps 'less' into >>>> %ebx >>>> 0x024bc238: inc %ebx ; ++less; (for the temp >>>> "less from future") >>>> >>>> 0x024bc239: cmp 0x8(%ecx),%esi ; %esi is still the "old >>>> less".... >>>> ;; 46 branch [AE] [RangeCheckStub: 0x44ee7b8] [bci:21] >>>> 0x024bc23c: jae 0x024bc2c0 >>>> 0x024bc242: movl $0x0,0xc(%ecx,%esi,4) ;*iastore: a[less++] = 0; >>>> ; - Test1::sort1 at 21 (line 24) >>>> 0x024bc24a: inc %edi ; OopMap{ecx=Oop off=75} >>>> ;*goto: for k++ >>>> ; - Test1::sort1 at 25 (line 22) >>>> 0x024bc24b: test %eax,0x1a0100 ; {poll} >>>> 0x024bc251: mov %ebx,%esi ;*goto >>>> ; - Test1::sort1 at 25 (line >>>> 22): for... >>>> ;; block B1 [4, 6] >>>> >>>> 0x024bc253: cmp %edx,%edi >>>> ;; 22 branch [LT] [B2] >>>> 0x024bc255: jl 0x024bc21c ;*if_icmpge >>>> ; - Test1::sort1 at 6 (line >>>> 22): for... From opinali at gmail.com Tue Jul 6 18:42:14 2010 From: opinali at gmail.com (Osvaldo Doederlein) Date: Tue, 6 Jul 2010 22:42:14 -0300 Subject: New portion of improvements for Dual-Pivot Quicksort In-Reply-To: <4C33C101.1010005@oracle.com> References: <4C20A97C.2050601@mail.ru> <4C20B766.3010202@gmail.com> <4C20B978.1040607@mail.ru> <4C33C101.1010005@oracle.com> Message-ID: The ironic thing is that these operators were originally introduced in the C language, at least according to well-known folklore, as an optimization - taking advantage of inc/dec instructions from the PDP arch, in the old times when (I suppose) compilers wouldn't do even basic strength-reduction optimizations like x + 1 => inc x. But this works well for pre-inc/dec, but post-increment and post-decrement have a more complex semantics that requires inducing an extra temporary if the compiler is not smart enough. My personal coding style, since my days of C, enforces pre- instead of post- operators; I will always write ++i, never i++, when both choices have the same effect. This is exactly because it's the post- operators that have confusing and error-prone semantics, as soon as the inc/dec operation is used as RHS of a bigger expression (or used a parameter etc.), and not as an isolated statement. I will use post- operators only when I really need its semantics to make my code a little extra terse. And now we discover another gotcha of post- operators: potentially less efficient code generation. It's worth noticing this, because I the post- operators seem to be the preferred style for most people, they can even be found in many Java style guidelines... I wonder why. Perhaps it's just the name of the C++ language that has taught a generation to like this wrong style? In that case, the blame goes to Stroustrup, he should have named it "++C" instead. That would get extra nerd points too ;-) A+ Osvaldo 2010/7/6 David Holmes > I asked someone to take a look at this and it seems that the problem is > that a[less++] requires introduction of a temporary to store the > pre-incremented index value which in turn increases register pressure and > can lead to a register spill. This seems to not only be architecture > dependent but even variable on the same architecture (as observed below). > > As Osvaldo noted C1 does not attempt to decide whether the increment can be > reordered with the access and so allow removal of the temporary. You'd need > the compiler folk (C1/C2) to comment on whether or not it would be > reasonable/possible/practical for C1 to do that - so I've cc'ed them (though > I'm not a member of their list so it may be a little while before it gets > pushed through to them.) > > David Holmes > > Vladimir Iaroslavski said the following on 06/22/10 23:24: > > both computers with Intel processor: >> >> Pentium, Intel, 4 CPU, 3.2 GHz, 2 Gb RAM >> Pentium, Intel, 4 CPU, 2.8 GHz, 2 Gb RAM >> >> Osvaldo Pinali Doederlein wrote: >> >>> Hi Vladimir, >>> >>> Hello, >>>> >>>> I tried with the latest JDK, build 98 and see different behaviour >>>> on two computers: 7570 / 8318 and 8560 / 8590, but sorting method >>>> works slower with a[less++] instruction on both computers: >>>> >>> >>> Is the first computer (with larger performance diff) an AMD by any >>> chance? It's odd that just the a[less++] would make the code so much slower. >>> Perhaps the worst compiled code has additional costs in some CPUs, e.g. >>> spoiling branch prediction for the bounds checking guards. >>> >>> Anyway the change is risk-free (including performance) and the advantage >>> is important at least in some CPUs, so go ahead (FWIW wrt my opinion...). I >>> just wish that C1 would be fixed to not need this kind of hacking - as I >>> categorize this as a hack, not even as a "normal" low-level Java code >>> optimization - because there are certainly millions of uses of the idiom >>> "array[index++/--]" in JavaSE APIs and elsewhere. But I'm not familiar with >>> the C1 source so I don't know if this is some low hanging fruit that could >>> be addressed quickly (any HotSpot engineers there to comment?). >>> >>> A+ >>> Osvaldo >>> >>> first second >>>> a[less] = ak; less++; / (a[less++] = ak; >>>> >>>> random: 16371 / 16696 14018 / 14326 >>>> ascendant: 2706 / 2762 2884 / 2897 >>>> descendant: 2994 / 3108 3170 / 3258 >>>> organ pipes: 7073 / 7296 6939 / 7090 >>>> stagger(2): 7765 / 8069 7531 / 7731 >>>> period(1,2): 653 / 743 719 / 753 >>>> random(1..4): 2152 / 2234 1567 / 1591 >>>> >>>> If I change Test class and populate the array with descendant >>>> values, I still see difference in times: 4793 / 5718 >>>> see updated attached Test class. >>>> >>>> Also I'm attaching the latest version of DualPivotQuicksort >>>> with minor format changes. If you don't have comments, I'll >>>> ask to to integrate the code at the end of this week. >>>> >>>> Thank you, >>>> Vladimir >>>> >>>> Osvaldo Doederlein wrote: >>>> >>>>> Hi Vladimir, >>>>> >>>>> 2010/6/19 Vladimir Iaroslavski >>>> iaroslavski at mail.ru>> >>>>> >>>>> Hello Osvaldo, >>>>> >>>>> I've prepared simple test which scans an array and does assignments >>>>> for each element, >>>>> see attached Test class: >>>>> >>>>> a[k] = a[less]; >>>>> a[less++] = 0; // or a[less] = 0; less++; >>>>> >>>>> The result of running "java -client Test" is: >>>>> >>>>> a[less], less++; Time: 6998 >>>>> a[less++]; Time: 8416 >>>>> >>>>> It is much more than 1%. Is it bug in JVM? Note that under server VM >>>>> >>>>> The amount of diff surely depends on the benchmark; your bench should >>>>> "zoom" the problem by not having much other work polluting the measurement. >>>>> But in my own test with b98 (32-bit), Q6600 CPU, I've got 5065/5079, so the >>>>> diff is < 1%. The excessive disadvantage you report may be something bad in >>>>> your older b84. >>>>> >>>>> Anyway I investigated the JIT-compiled code, details in the end (I've >>>>> split the benchmark in two classes just to make the comparison simpler). The >>>>> problem with "a[less++]" is that "less++" will first increment "less", >>>>> _then_ it will use the old value (not-incremented) to index "a". C1 >>>>> generates code that is equivalent to: >>>>> >>>>> int less_incremented = less + 1; >>>>> a[less] = 0; >>>>> less = less_incremented; >>>>> >>>>> ...which is a 1-to-1 translation of the IR coming off the bytecode. C1 >>>>> is not smart enough to see that the increment can be reordered after the >>>>> indexing, maybe because there's a data dependency as the indexing uses >>>>> "less"; but due to the semantics of postfix "++" this dependency is for the >>>>> before-increment value, so the reordering would be safe. Maybe that's just >>>>> some simple missing heuristics that could be easily added? >>>>> >>>>> there is no difference between "a[less++]" and "a[less], less++". >>>>> >>>>> C2 generates completely different code,with 16X unrolling - this is the >>>>> inner loop: >>>>> >>>>> 0x026a6e40: pxor %xmm0,%xmm0 ;*aload_0 >>>>> ; - Test1::sort1 at 9 (line 23) >>>>> 0x026a6e44: movq %xmm0,0xc(%ecx,%esi,4) >>>>> 0x026a6e4a: movq %xmm0,0x14(%ecx,%esi,4) >>>>> 0x026a6e50: movq %xmm0,0x1c(%ecx,%esi,4) >>>>> 0x026a6e56: movq %xmm0,0x24(%ecx,%esi,4) >>>>> 0x026a6e5c: movq %xmm0,0x2c(%ecx,%esi,4) >>>>> 0x026a6e62: movq %xmm0,0x34(%ecx,%esi,4) >>>>> 0x026a6e68: movq %xmm0,0x3c(%ecx,%esi,4) >>>>> 0x026a6e6e: movq %xmm0,0x44(%ecx,%esi,4) ;*iastore >>>>> ; - Test1::sort1 at 21 (line 24) >>>>> 0x026a6e74: add $0x10,%esi ;*iinc >>>>> ; - Test1::sort1 at 22 (line 22) >>>>> 0x026a6e77: cmp %ebp,%esi >>>>> 0x026a6e79: jl 0x026a6e44 >>>>> >>>>> There is some extra slow-path code to fill the remaining 1...15 >>>>> elements if the loop length is not multiple of 16, and that's all. C2 >>>>> detects the redundancy between the "k" and "less" vars, and kills the >>>>> also-redundant "a[k] = a[less]" assignment so the net result is a simple >>>>> zero-fill of the array. Maybe a different benchmark without these >>>>> redundancies would make easier to see that C2 doesn't have a problem with >>>>> the postfix "++", but if it had, I think it wouldn't reach the excellent >>>>> result above. >>>>> >>>>> A+ >>>>> Osvaldo >>>>> >>>>> >>>>> I'm using JDK 7 on Windows XP: >>>>> >>>>> java version "1.7.0-ea" >>>>> Java(TM) SE Runtime Environment (build 1.7.0-ea-b84) >>>>> Java HotSpot(TM) Client VM (build 17.0-b09, mixed mode, sharing) >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> >>>>> >>>>> This is the C1 code for sort2()'s loop: >>>>> >>>>> 0x0251c1dc: cmp 0x8(%ecx),%esi ; implicit exception: dispatches >>>>> to 0x0251c21e >>>>> ;; 30 branch [AE] [RangeCheckStub: 0x454c640] [bci:13] >>>>> 0x0251c1df: jae 0x0251c24a >>>>> 0x0251c1e5: mov 0xc(%ecx,%esi,4),%ebx ;*iaload: %ebx = a[less]; >>>>> ; - Test2::sort2 at 13 (line 23) >>>>> 0x0251c1e9: cmp 0x8(%ecx),%edi >>>>> ;; 36 branch [AE] [RangeCheckStub: 0x454c7e0] [bci:14] >>>>> 0x0251c1ec: jae 0x0251c263 >>>>> 0x0251c1f2: mov %ebx,0xc(%ecx,%edi,4) ;*iastore: a[k] = %ebx; >>>>> ; - Test2::sort2 at 14 (line 23) >>>>> >>>>> (sort1/sort2 start to differ here) >>>>> >>>>> 0x0251c1f6: cmp 0x8(%ecx),%esi >>>>> ;; 42 branch [AE] [RangeCheckStub: 0x454c980] [bci:18] >>>>> 0x0251c1f9: jae 0x0251c27c >>>>> 0x0251c1ff: movl $0x0,0xc(%ecx,%esi,4) ;*iastore: a[less] = 0; >>>>> ; - Test2::sort2 at 18 (line 24) >>>>> 0x0251c207: inc %esi ; ++less; >>>>> 0x0251c208: inc %edi ; OopMap{ecx=Oop off=73} >>>>> ;*goto: for k++ >>>>> ; - Test2::sort2 at 25 (line 22) >>>>> 0x0251c209: test %eax,0x1a0100 ;*goto >>>>> ; - Test2::sort2 at 25 (line 22) >>>>> ; {poll} >>>>> ;; block B1 [4, 6] >>>>> >>>>> 0x0251c20f: cmp %edx,%edi >>>>> ;; 22 branch [LT] [B2] >>>>> 0x0251c211: jl 0x0251c1dc ;*if_icmpge: for k < right >>>>> ; - Test2::sort2 at 6 (line 22) >>>>> >>>>> The code looks OK; C1 doesn't do much optimization - no unrolling, >>>>> bounds check elimination - but it's otherwise just about the code you would >>>>> expect for a simple JITting. >>>>> Now, C1 code for sort1()'s loop: >>>>> >>>>> 0x024bc21c: cmp 0x8(%ecx),%esi ; implicit exception: dispatches >>>>> to 0x024bc262 >>>>> ;; 30 branch [AE] [RangeCheckStub: 0x44ee3b0] [bci:13] >>>>> 0x024bc21f: jae 0x024bc28e >>>>> 0x024bc225: mov 0xc(%ecx,%esi,4),%ebx ;*iaload: %ebx = a[less]; >>>>> ; - Test1::sort1 at 13 (line 23) >>>>> 0x024bc229: cmp 0x8(%ecx),%edi >>>>> ;; 36 branch [AE] [RangeCheckStub: 0x44ee550] [bci:14] >>>>> 0x024bc22c: jae 0x024bc2a7 >>>>> 0x024bc232: mov %ebx,0xc(%ecx,%edi,4) ;*iastore: a[k] = %ebx; >>>>> ; - Test1::sort1 at 14 (line 23) >>>>> >>>>> (sort1/sort2 start to differ here) >>>>> >>>>> 0x024bc236: mov %esi,%ebx ; Crap! C1 temps 'less' into >>>>> %ebx >>>>> 0x024bc238: inc %ebx ; ++less; (for the temp "less >>>>> from future") >>>>> >>>>> 0x024bc239: cmp 0x8(%ecx),%esi ; %esi is still the "old >>>>> less".... >>>>> ;; 46 branch [AE] [RangeCheckStub: 0x44ee7b8] [bci:21] >>>>> 0x024bc23c: jae 0x024bc2c0 >>>>> 0x024bc242: movl $0x0,0xc(%ecx,%esi,4) ;*iastore: a[less++] = 0; >>>>> ; - Test1::sort1 at 21 (line 24) >>>>> 0x024bc24a: inc %edi ; OopMap{ecx=Oop off=75} >>>>> ;*goto: for k++ >>>>> ; - Test1::sort1 at 25 (line 22) >>>>> 0x024bc24b: test %eax,0x1a0100 ; {poll} >>>>> 0x024bc251: mov %ebx,%esi ;*goto >>>>> ; - Test1::sort1 at 25 (line 22): >>>>> for... >>>>> ;; block B1 [4, 6] >>>>> >>>>> 0x024bc253: cmp %edx,%edi >>>>> ;; 22 branch [LT] [B2] >>>>> 0x024bc255: jl 0x024bc21c ;*if_icmpge >>>>> ; - Test1::sort1 at 6 (line 22): >>>>> for... >>>>> >>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20100706/975f9c80/attachment.html From tom.rodriguez at oracle.com Tue Jul 6 20:27:22 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 6 Jul 2010 20:27:22 -0700 Subject: New portion of improvements for Dual-Pivot Quicksort In-Reply-To: References: <4C20A97C.2050601@mail.ru> <4C20B766.3010202@gmail.com> <4C20B978.1040607@mail.ru> <4C33C101.1010005@oracle.com> Message-ID: I actually looked into this in some detail and the reason for the difference in C1 is two fold. First the state of the JVM at array load is slightly different for a[i++] vs. a[i], i++. In the first case the top state has a copy of the original i but the local for i has i+1. In the second there is only i. This increases the register pressure since we C1 currently keeps all the locals live in the JVM state for the possible exception for the range check. C1 doesn't always need to keep those values live and there is a workspace where where we are more aggressive about killing unneeded locals in the states used for exceptions. Those changes are probably (hopefully) coming to hs19. Unfortunately there's another reason for this specific example that we force both i and i + 1 to be live simultaneously. C1 doesn't do any cross block scheduling so values which are computed in one block but only used in a later one are evaluated in their original bytecode order relative to other bytecodes which could cause exceptions. This again means we evaluated i + 1 earlier than we absolutely have to since i + 1 is live out of the block into a phi. This is relatively easy to fix by replacing the pin_for_linear_scan logic with an explicit walk of the final ValueStack to evaluate anything which is live out but not yet evaluated. That way values which are live out but unused within the block are evaluated last. This gives you code that's exactly the same for both variants. So that's the long explanation. My recommendation is to continue to write the code in a natural way. tom On Jul 6, 2010, at 6:42 PM, Osvaldo Doederlein wrote: > The ironic thing is that these operators were originally introduced in the C language, at least according to well-known folklore, as an optimization - taking advantage of inc/dec instructions from the PDP arch, in the old times when (I suppose) compilers wouldn't do even basic strength-reduction optimizations like x + 1 => inc x. But this works well for pre-inc/dec, but post-increment and post-decrement have a more complex semantics that requires inducing an extra temporary if the compiler is not smart enough. > > My personal coding style, since my days of C, enforces pre- instead of post- operators; I will always write ++i, never i++, when both choices have the same effect. This is exactly because it's the post- operators that have confusing and error-prone semantics, as soon as the inc/dec operation is used as RHS of a bigger expression (or used a parameter etc.), and not as an isolated statement. I will use post- operators only when I really need its semantics to make my code a little extra terse. And now we discover another gotcha of post- operators: potentially less efficient code generation. It's worth noticing this, because I the post- operators seem to be the preferred style for most people, they can even be found in many Java style guidelines... I wonder why. > > Perhaps it's just the name of the C++ language that has taught a generation to like this wrong style? In that case, the blame goes to Stroustrup, he should have named it "++C" instead. That would get extra nerd points too ;-) > > A+ > Osvaldo > > 2010/7/6 David Holmes > I asked someone to take a look at this and it seems that the problem is that a[less++] requires introduction of a temporary to store the pre-incremented index value which in turn increases register pressure and can lead to a register spill. This seems to not only be architecture dependent but even variable on the same architecture (as observed below). > > As Osvaldo noted C1 does not attempt to decide whether the increment can be reordered with the access and so allow removal of the temporary. You'd need the compiler folk (C1/C2) to comment on whether or not it would be reasonable/possible/practical for C1 to do that - so I've cc'ed them (though I'm not a member of their list so it may be a little while before it gets pushed through to them.) > > David Holmes > > Vladimir Iaroslavski said the following on 06/22/10 23:24: > > both computers with Intel processor: > > Pentium, Intel, 4 CPU, 3.2 GHz, 2 Gb RAM > Pentium, Intel, 4 CPU, 2.8 GHz, 2 Gb RAM > > Osvaldo Pinali Doederlein wrote: > Hi Vladimir, > > Hello, > > I tried with the latest JDK, build 98 and see different behaviour > on two computers: 7570 / 8318 and 8560 / 8590, but sorting method > works slower with a[less++] instruction on both computers: > > Is the first computer (with larger performance diff) an AMD by any chance? It's odd that just the a[less++] would make the code so much slower. Perhaps the worst compiled code has additional costs in some CPUs, e.g. spoiling branch prediction for the bounds checking guards. > > Anyway the change is risk-free (including performance) and the advantage is important at least in some CPUs, so go ahead (FWIW wrt my opinion...). I just wish that C1 would be fixed to not need this kind of hacking - as I categorize this as a hack, not even as a "normal" low-level Java code optimization - because there are certainly millions of uses of the idiom "array[index++/--]" in JavaSE APIs and elsewhere. But I'm not familiar with the C1 source so I don't know if this is some low hanging fruit that could be addressed quickly (any HotSpot engineers there to comment?). > > A+ > Osvaldo > > first second > a[less] = ak; less++; / (a[less++] = ak; > > random: 16371 / 16696 14018 / 14326 > ascendant: 2706 / 2762 2884 / 2897 > descendant: 2994 / 3108 3170 / 3258 > organ pipes: 7073 / 7296 6939 / 7090 > stagger(2): 7765 / 8069 7531 / 7731 > period(1,2): 653 / 743 719 / 753 > random(1..4): 2152 / 2234 1567 / 1591 > > If I change Test class and populate the array with descendant > values, I still see difference in times: 4793 / 5718 > see updated attached Test class. > > Also I'm attaching the latest version of DualPivotQuicksort > with minor format changes. If you don't have comments, I'll > ask to to integrate the code at the end of this week. > > Thank you, > Vladimir > > Osvaldo Doederlein wrote: > Hi Vladimir, > > 2010/6/19 Vladimir Iaroslavski > > > Hello Osvaldo, > > I've prepared simple test which scans an array and does assignments > for each element, > see attached Test class: > > a[k] = a[less]; > a[less++] = 0; // or a[less] = 0; less++; > > The result of running "java -client Test" is: > > a[less], less++; Time: 6998 > a[less++]; Time: 8416 > > It is much more than 1%. Is it bug in JVM? Note that under server VM > > The amount of diff surely depends on the benchmark; your bench should "zoom" the problem by not having much other work polluting the measurement. But in my own test with b98 (32-bit), Q6600 CPU, I've got 5065/5079, so the diff is < 1%. The excessive disadvantage you report may be something bad in your older b84. > > Anyway I investigated the JIT-compiled code, details in the end (I've split the benchmark in two classes just to make the comparison simpler). The problem with "a[less++]" is that "less++" will first increment "less", _then_ it will use the old value (not-incremented) to index "a". C1 generates code that is equivalent to: > > int less_incremented = less + 1; > a[less] = 0; > less = less_incremented; > > ...which is a 1-to-1 translation of the IR coming off the bytecode. C1 is not smart enough to see that the increment can be reordered after the indexing, maybe because there's a data dependency as the indexing uses "less"; but due to the semantics of postfix "++" this dependency is for the before-increment value, so the reordering would be safe. Maybe that's just some simple missing heuristics that could be easily added? > > there is no difference between "a[less++]" and "a[less], less++". > > C2 generates completely different code,with 16X unrolling - this is the inner loop: > > 0x026a6e40: pxor %xmm0,%xmm0 ;*aload_0 > ; - Test1::sort1 at 9 (line 23) > 0x026a6e44: movq %xmm0,0xc(%ecx,%esi,4) > 0x026a6e4a: movq %xmm0,0x14(%ecx,%esi,4) > 0x026a6e50: movq %xmm0,0x1c(%ecx,%esi,4) > 0x026a6e56: movq %xmm0,0x24(%ecx,%esi,4) > 0x026a6e5c: movq %xmm0,0x2c(%ecx,%esi,4) > 0x026a6e62: movq %xmm0,0x34(%ecx,%esi,4) > 0x026a6e68: movq %xmm0,0x3c(%ecx,%esi,4) > 0x026a6e6e: movq %xmm0,0x44(%ecx,%esi,4) ;*iastore > ; - Test1::sort1 at 21 (line 24) > 0x026a6e74: add $0x10,%esi ;*iinc > ; - Test1::sort1 at 22 (line 22) > 0x026a6e77: cmp %ebp,%esi > 0x026a6e79: jl 0x026a6e44 > > There is some extra slow-path code to fill the remaining 1...15 elements if the loop length is not multiple of 16, and that's all. C2 detects the redundancy between the "k" and "less" vars, and kills the also-redundant "a[k] = a[less]" assignment so the net result is a simple zero-fill of the array. Maybe a different benchmark without these redundancies would make easier to see that C2 doesn't have a problem with the postfix "++", but if it had, I think it wouldn't reach the excellent result above. > > A+ > Osvaldo > > > I'm using JDK 7 on Windows XP: > > java version "1.7.0-ea" > Java(TM) SE Runtime Environment (build 1.7.0-ea-b84) > Java HotSpot(TM) Client VM (build 17.0-b09, mixed mode, sharing) > > Thanks, > Vladimir > > > > This is the C1 code for sort2()'s loop: > > 0x0251c1dc: cmp 0x8(%ecx),%esi ; implicit exception: dispatches to 0x0251c21e > ;; 30 branch [AE] [RangeCheckStub: 0x454c640] [bci:13] > 0x0251c1df: jae 0x0251c24a > 0x0251c1e5: mov 0xc(%ecx,%esi,4),%ebx ;*iaload: %ebx = a[less]; > ; - Test2::sort2 at 13 (line 23) > 0x0251c1e9: cmp 0x8(%ecx),%edi > ;; 36 branch [AE] [RangeCheckStub: 0x454c7e0] [bci:14] > 0x0251c1ec: jae 0x0251c263 > 0x0251c1f2: mov %ebx,0xc(%ecx,%edi,4) ;*iastore: a[k] = %ebx; > ; - Test2::sort2 at 14 (line 23) > > (sort1/sort2 start to differ here) > > 0x0251c1f6: cmp 0x8(%ecx),%esi > ;; 42 branch [AE] [RangeCheckStub: 0x454c980] [bci:18] > 0x0251c1f9: jae 0x0251c27c > 0x0251c1ff: movl $0x0,0xc(%ecx,%esi,4) ;*iastore: a[less] = 0; > ; - Test2::sort2 at 18 (line 24) > 0x0251c207: inc %esi ; ++less; > 0x0251c208: inc %edi ; OopMap{ecx=Oop off=73} > ;*goto: for k++ > ; - Test2::sort2 at 25 (line 22) > 0x0251c209: test %eax,0x1a0100 ;*goto > ; - Test2::sort2 at 25 (line 22) > ; {poll} > ;; block B1 [4, 6] > > 0x0251c20f: cmp %edx,%edi > ;; 22 branch [LT] [B2] > 0x0251c211: jl 0x0251c1dc ;*if_icmpge: for k < right > ; - Test2::sort2 at 6 (line 22) > > The code looks OK; C1 doesn't do much optimization - no unrolling, bounds check elimination - but it's otherwise just about the code you would expect for a simple JITting. > Now, C1 code for sort1()'s loop: > > 0x024bc21c: cmp 0x8(%ecx),%esi ; implicit exception: dispatches to 0x024bc262 > ;; 30 branch [AE] [RangeCheckStub: 0x44ee3b0] [bci:13] > 0x024bc21f: jae 0x024bc28e > 0x024bc225: mov 0xc(%ecx,%esi,4),%ebx ;*iaload: %ebx = a[less]; > ; - Test1::sort1 at 13 (line 23) > 0x024bc229: cmp 0x8(%ecx),%edi > ;; 36 branch [AE] [RangeCheckStub: 0x44ee550] [bci:14] > 0x024bc22c: jae 0x024bc2a7 > 0x024bc232: mov %ebx,0xc(%ecx,%edi,4) ;*iastore: a[k] = %ebx; > ; - Test1::sort1 at 14 (line 23) > > (sort1/sort2 start to differ here) > > 0x024bc236: mov %esi,%ebx ; Crap! C1 temps 'less' into %ebx > 0x024bc238: inc %ebx ; ++less; (for the temp "less from future") > > 0x024bc239: cmp 0x8(%ecx),%esi ; %esi is still the "old less".... > ;; 46 branch [AE] [RangeCheckStub: 0x44ee7b8] [bci:21] > 0x024bc23c: jae 0x024bc2c0 > 0x024bc242: movl $0x0,0xc(%ecx,%esi,4) ;*iastore: a[less++] = 0; > ; - Test1::sort1 at 21 (line 24) > 0x024bc24a: inc %edi ; OopMap{ecx=Oop off=75} > ;*goto: for k++ > ; - Test1::sort1 at 25 (line 22) > 0x024bc24b: test %eax,0x1a0100 ; {poll} > 0x024bc251: mov %ebx,%esi ;*goto > ; - Test1::sort1 at 25 (line 22): for... > ;; block B1 [4, 6] > > 0x024bc253: cmp %edx,%edi > ;; 22 branch [LT] [B2] > 0x024bc255: jl 0x024bc21c ;*if_icmpge > ; - Test1::sort1 at 6 (line 22): for... > From christian.thalinger at oracle.com Wed Jul 7 09:43:00 2010 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 07 Jul 2010 18:43:00 +0200 Subject: Request for reviews (XXL): 6961697: move nmethod constants section before instruction section Message-ID: <1278520980.17142.3.camel@macbook> http://cr.openjdk.java.net/~twisti/6961697/webrev.01/ 6961697: move nmethod constants section before instruction section Summary: This is a preparation for 6961690. Reviewed-by: To better support PC-relative addressing of nmethod constant table entries on SPARC, the constants section should be moved before the instruction section. This is a preparation for 6961690. The changes are rather big because of some method renamings that were necessary since the old naming would have been confusing: CodeBlob::instruction_* -> CodeBlob::code_* nmethod::code_* -> nmethod::insts_* CodeBlob::code_* methods refer to memory that belongs to the code section (consts, insts, and stubs that is). nmethod methods are named as the corresponding section (consts_*, insts_*, stub_*). There are a couple of XXX comments in the changes where it isn't clear if e.g. an instruction_begin() call really means the beginning of the instructions or actually the beginning of the code section. Please examine these changes carefully! Testing: DaCapo, JPRT I also did some ad-hoc benchmarking to see if there is a regression: intelsdv03, linux-i486, C2: ============================================================================ logs.baseline/ Benchmark Samples Mean Stdev Geomean Weight specjbb2005 1 4617.76 ============================================================================ logs.6961697/ Benchmark Samples Mean Stdev %Diff P Significant specjbb2005 1 4636.10 0.40 ============================================================================ intelsdv03, linux-amd64, C2, -UseCompressedOops: ============================================================================ logs.baseline/ Benchmark Samples Mean Stdev Geomean Weight specjbb2005 1 132830.27 ============================================================================ logs.6961697/ Benchmark Samples Mean Stdev %Diff P Significant specjbb2005 1 135457.54 1.98 ============================================================================ terminus, solaris-sparc, C2: ============================================================================ logs.baseline/ Benchmark Samples Mean Stdev Geomean Weight specjbb2005 1 42813.38 ============================================================================ logs.6961697/ Benchmark Samples Mean Stdev %Diff P Significant specjbb2005 1 43100.68 0.67 ============================================================================ terminus, solaris-sparcv9, C2, -UseCompressedOops: ============================================================================ logs.baseline/ Benchmark Samples Mean Stdev Geomean Weight specjbb2005 1 34427.36 ============================================================================ logs.6961697/ Benchmark Samples Mean Stdev %Diff P Significant specjbb2005 1 34359.02 -0.20 ============================================================================ From vladimir.kozlov at oracle.com Wed Jul 7 16:56:50 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 07 Jul 2010 16:56:50 -0700 Subject: Request for reviews (XXL): 6961697: move nmethod constants section before instruction section In-Reply-To: <1278520980.17142.3.camel@macbook> References: <1278520980.17142.3.camel@macbook> Message-ID: <4C351442.1090907@oracle.com> Christian, Renaming itself is fine but I don't like putting constants at the beginning. Originally nmethod::code_begin() and CodeBlob::instruction_begin() both point to the first instruction. Now CodeBlob::code_begin() points to the constants section and nmethod::insts_begin() to the first instruction. As result it is very confusing what to use nmethod::insts_begin() or nmethod::code_begin() in some cases. I spent few hours looking on these changes and found few other case (for example, disassembler) in addition to your XXX where I am not sure what to use. And there are no checks/validation that correct method is used. Also for stubs it is silently assumed that there are no constants. Could you explain why for sparc you need the constants section before the instructions section? May be we could use other approach. Thanks, Vladimir Christian Thalinger wrote: > http://cr.openjdk.java.net/~twisti/6961697/webrev.01/ > > 6961697: move nmethod constants section before instruction section > Summary: This is a preparation for 6961690. > Reviewed-by: > > To better support PC-relative addressing of nmethod constant table > entries on SPARC, the constants section should be moved before the > instruction section. This is a preparation for 6961690. > > The changes are rather big because of some method renamings that were > necessary since the old naming would have been confusing: > > CodeBlob::instruction_* -> CodeBlob::code_* > nmethod::code_* -> nmethod::insts_* > > CodeBlob::code_* methods refer to memory that belongs to the code > section (consts, insts, and stubs that is). nmethod methods are named > as the corresponding section (consts_*, insts_*, stub_*). > > There are a couple of XXX comments in the changes where it isn't clear > if e.g. an instruction_begin() call really means the beginning of the > instructions or actually the beginning of the code section. Please > examine these changes carefully! > > Testing: DaCapo, JPRT > From tom.rodriguez at oracle.com Wed Jul 7 20:45:24 2010 From: tom.rodriguez at oracle.com (tom.rodriguez at oracle.com) Date: Thu, 08 Jul 2010 03:45:24 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6 new changesets Message-ID: <20100708034541.3E43E4781D@hg.openjdk.java.net> Changeset: 726b40449bd2 Author: zgu Date: 2010-06-22 09:46 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/726b40449bd2 6939019: Source code adjustments for parfait compilation of hotspot Summary: Minor source code adjustments for parfait compilation, since it uses different compiler vs. JDK Reviewed-by: never, kamg ! src/os/solaris/vm/osThread_solaris.hpp ! src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp Changeset: 3e351982aac7 Author: zgu Date: 2010-06-22 10:03 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/3e351982aac7 Merge Changeset: 1a11430e0326 Author: jcoomes Date: 2010-06-24 15:38 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/1a11430e0326 6888573: class data sharing does not always disable large pages Reviewed-by: phh ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/runtime/arguments.cpp Changeset: c5f1ea9e15e8 Author: coleenp Date: 2010-06-28 12:03 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/c5f1ea9e15e8 Merge ! src/share/vm/runtime/arguments.cpp Changeset: a00567c82f02 Author: coleenp Date: 2010-06-30 11:52 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/a00567c82f02 Merge ! src/share/vm/runtime/arguments.cpp Changeset: a693e51ac197 Author: never Date: 2010-07-07 12:40 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/a693e51ac197 Merge From christian.thalinger at oracle.com Thu Jul 8 01:00:28 2010 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 08 Jul 2010 10:00:28 +0200 Subject: Request for reviews (XXL): 6961697: move nmethod constants section before instruction section In-Reply-To: <4C351442.1090907@oracle.com> References: <1278520980.17142.3.camel@macbook> <4C351442.1090907@oracle.com> Message-ID: <1278576028.19588.13.camel@macbook> On Wed, 2010-07-07 at 16:56 -0700, Vladimir Kozlov wrote: > Christian, > > Renaming itself is fine but I don't like putting constants at the > beginning. > > Originally nmethod::code_begin() and CodeBlob::instruction_begin() > both point to the first instruction. Now CodeBlob::code_begin() points > to the constants section and nmethod::insts_begin() to the first > instruction. As result it is very confusing what to use > nmethod::insts_begin() or > nmethod::code_begin() in some cases. I spent few hours looking on > these changes and found few other case (for example, disassembler) in > addition to your XXX where I am not sure what to use. And there are no > checks/validation that correct method is used. Also for stubs it is > silently assumed that > there are no constants. I agree. But the main problem here is that there was no distinction of the code section begin and the instructions begin before, so changing that now is very difficult. The stubs constant section problem is really annoying. The only solution I can think of is to explicitly add consts and insts sections to the CodeBlob. Maybe even have all section "accessor" methods in CodeBlob (code_*, consts_*, insts_*, stub_*). Then we just have to get the usage of code_* and insts_* correct and we're set once and for all. > > Could you explain why for sparc you need the constants section before > the instructions section? May be we could use other approach. Because we want to use rdpc to get the base address of the constant table. And to keep the offsets small enough the rdpc has to be close to the actual constant table (without using extra instructions to adjust the table base). Having the table after the code and the rdpc instruction at the beginning of the method will probably make in many cases the offsets too big. -- Christian From christian.thalinger at oracle.com Thu Jul 8 02:44:58 2010 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 08 Jul 2010 11:44:58 +0200 Subject: Review Request: Shark In-Reply-To: <20100622144841.GD3420@redhat.com> References: <20100611141655.GI3674@redhat.com> <1277195726.27950.40.camel@macbook> <20100622132939.GC3420@redhat.com> <1277216100.27950.46.camel@macbook> <20100622144841.GD3420@redhat.com> Message-ID: <1278582298.19588.22.camel@macbook> On Tue, 2010-06-22 at 15:48 +0100, Gary Benson wrote: > > > > hotspot/src/share/vm/includeDB_shark: > > > > > > > > Still has the old Sun copyright header. > > > > > > Ah, good catch. I fixed this in: > > > http://cr.openjdk.java.net/~gbenson/shark-hotspot-01/ > > > > I guess you mean: http://cr.openjdk.java.net/~gbenson/shark-hotspot-02/ > > Yes :) Can someone else from our team have a look on this one too? -- Christian From christian.thalinger at oracle.com Thu Jul 8 10:06:31 2010 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 08 Jul 2010 19:06:31 +0200 Subject: Request for reviews (XXL): 6961697: move nmethod constants section before instruction section In-Reply-To: <1278576028.19588.13.camel@macbook> References: <1278520980.17142.3.camel@macbook> <4C351442.1090907@oracle.com> <1278576028.19588.13.camel@macbook> Message-ID: <1278608791.1475.125.camel@macbook> I just talked to Tom and I will come up with a completely different webrev. -- Christian From vladimir.kozlov at oracle.com Thu Jul 8 10:20:58 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 08 Jul 2010 10:20:58 -0700 Subject: Request for reviews (XXL): 6961697: move nmethod constants section before instruction section In-Reply-To: <1278576028.19588.13.camel@macbook> References: <1278520980.17142.3.camel@macbook> <4C351442.1090907@oracle.com> <1278576028.19588.13.camel@macbook> Message-ID: <4C3608FA.2040406@oracle.com> Christian Thalinger wrote: >> there are no constants. > > I agree. But the main problem here is that there was no distinction of > the code section begin and the instructions begin before, so changing > that now is very difficult. > > The stubs constant section problem is really annoying. The only > solution I can think of is to explicitly add consts and insts sections > to the CodeBlob. Maybe even have all section "accessor" methods in > CodeBlob (code_*, consts_*, insts_*, stub_*). Then we just have to get > the usage of code_* and insts_* correct and we're set once and for all. Yes, I think it is only solution here. You still can treat insts and stub as one code section. We only need the offset to instructions. > >> Could you explain why for sparc you need the constants section before >> the instructions section? May be we could use other approach. > > Because we want to use rdpc to get the base address of the constant > table. And to keep the offsets small enough the rdpc has to be close to > the actual constant table (without using extra instructions to adjust > the table base). Having the table after the code and the rdpc > instruction at the beginning of the method will probably make in many > cases the offsets too big. I assume you want to initialize register with base value at the beginning of compiled code. But you have to deal with large offset (>4k) anyway for methods with a lot constants. Note: with compressed oops only 2 instructions are used to construct const narrow oop. Which leaves only polling and card table addresses to optimize. And we trade constant construction with load which may not give improvement. Did you do an experiment to find how much performance improvement it will buy us? I think we need to proceed with this huge changes only if we have benefits from it. Right? Thanks, Vladimir > > -- Christian > From tom.rodriguez at oracle.com Thu Jul 8 12:10:47 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 8 Jul 2010 12:10:47 -0700 Subject: Request for reviews (XXL): 6961697: move nmethod constants section before instruction section In-Reply-To: <4C3608FA.2040406@oracle.com> References: <1278520980.17142.3.camel@macbook> <4C351442.1090907@oracle.com> <1278576028.19588.13.camel@macbook> <4C3608FA.2040406@oracle.com> Message-ID: > I assume you want to initialize register with base value at the beginning of compiled code. But you have to deal with large offset (>4k) anyway for methods with a lot constants. It's not so much about the size of the offsets. The problem is that we need to know the distance between the constant and it's use. We can presize the constant section easily and the current offset will then tell you how far away the reference is from the constant. If the constant section is after it then we have to do a sizing pass to get that information. > Note: with compressed oops only 2 instructions are used to construct const narrow oop. Which leaves only polling and card table addresses to optimize. And we trade constant construction with load which may not give improvement. Maybe, maybe not. On Niagara class machines I think it would. Compressed oops doesn't work for all configurations either so it will still help large heap configurations. It will also help with existing float and double constant references. > Did you do an experiment to find how much performance improvement it will buy us? I think we need to proceed with this huge changes only if we have benefits from it. Right? Let's see how the new webrev looks. I would be ok with holding back this change until we get the code generation for the constant table working to a point where we can evaluate it the performance effects. tom > > Thanks, > Vladimir > >> -- Christian From christian.thalinger at oracle.com Thu Jul 8 12:18:42 2010 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 08 Jul 2010 21:18:42 +0200 Subject: Request for reviews (XXL): 6961697: move nmethod constants section before instruction section In-Reply-To: References: <1278520980.17142.3.camel@macbook> <4C351442.1090907@oracle.com> <1278576028.19588.13.camel@macbook> <4C3608FA.2040406@oracle.com> Message-ID: <1278616722.1475.134.camel@macbook> On Thu, 2010-07-08 at 12:10 -0700, Tom Rodriguez wrote: > > Did you do an experiment to find how much performance improvement it > will buy us? I think we need to proceed with this huge changes only if > we have benefits from it. Right? > > Let's see how the new webrev looks. I would be ok with holding back > this change until we get the code generation for the constant table > working to a point where we can evaluate it the performance effects. I agree on that. When I've finished the new webrev I will merge it with the other workspace and do some performance evaluation. -- Christian From vladimir.kozlov at oracle.com Thu Jul 8 12:40:11 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 08 Jul 2010 12:40:11 -0700 Subject: Request for reviews (XXL): 6961697: move nmethod constants section before instruction section In-Reply-To: References: <1278520980.17142.3.camel@macbook> <4C351442.1090907@oracle.com> <1278576028.19588.13.camel@macbook> <4C3608FA.2040406@oracle.com> Message-ID: <4C36299B.4040101@oracle.com> Tom Rodriguez wrote: >> I assume you want to initialize register with base value at the beginning of compiled code. But you have to deal with large offset (>4k) anyway for methods with a lot constants. > > It's not so much about the size of the offsets. The problem is that we need to know the distance between the constant and it's use. We can presize the constant section easily and the current offset will then tell you how far away the reference is from the constant. If the constant section is after it then we have to do a sizing pass to get that information. Got it, you want to known what instructions needed to construct constant's address/load statically during code generation without additional passes. > >> Note: with compressed oops only 2 instructions are used to construct const narrow oop. Which leaves only polling and card table addresses to optimize. And we trade constant construction with load which may not give improvement. > > Maybe, maybe not. On Niagara class machines I think it would. Compressed oops doesn't work for all configurations either so it will still help large heap configurations. It will also help with existing float and double constant references. Agree, especially for float/doubles. But I would like to see experiment results. Niagara L1 cache is very small per thread. > >> Did you do an experiment to find how much performance improvement it will buy us? I think we need to proceed with this huge changes only if we have benefits from it. Right? > > Let's see how the new webrev looks. I would be ok with holding back this change until we get the code generation for the constant table working to a point where we can evaluate it the performance effects. In general it looks good. I still would like to see separate changes/bugs for renaming and moving constant section at the head. Thanks, Vladimir > > tom > >> Thanks, >> Vladimir >> >>> -- Christian > From vladimir.kozlov at oracle.com Thu Jul 8 16:08:23 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 08 Jul 2010 16:08:23 -0700 Subject: Review Request: Shark In-Reply-To: <1278582298.19588.22.camel@macbook> References: <20100611141655.GI3674@redhat.com> <1277195726.27950.40.camel@macbook> <20100622132939.GC3420@redhat.com> <1277216100.27950.46.camel@macbook> <20100622144841.GD3420@redhat.com> <1278582298.19588.22.camel@macbook> Message-ID: <4C365A67.6070402@oracle.com> Changes in our files looks fine. Vladimir Christian Thalinger wrote: > On Tue, 2010-06-22 at 15:48 +0100, Gary Benson wrote: >>>>> hotspot/src/share/vm/includeDB_shark: >>>>> >>>>> Still has the old Sun copyright header. >>>> Ah, good catch. I fixed this in: >>>> http://cr.openjdk.java.net/~gbenson/shark-hotspot-01/ >>> I guess you mean: http://cr.openjdk.java.net/~gbenson/shark-hotspot-02/ >> Yes :) > > Can someone else from our team have a look on this one too? > > -- Christian > From tom.rodriguez at oracle.com Thu Jul 8 22:20:12 2010 From: tom.rodriguez at oracle.com (tom.rodriguez at oracle.com) Date: Fri, 09 Jul 2010 05:20:12 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6965184: possible races in make_not_entrant_or_zombie Message-ID: <20100709052022.689054785F@hg.openjdk.java.net> Changeset: 2a47bd84841f Author: never Date: 2010-07-08 14:29 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/2a47bd84841f 6965184: possible races in make_not_entrant_or_zombie Reviewed-by: kvn ! agent/src/share/classes/sun/jvm/hotspot/code/NMethod.java - src/os/linux/vm/vtune_linux.cpp - src/os/solaris/vm/vtune_solaris.cpp - src/os/windows/vm/vtune_windows.cpp ! src/share/vm/classfile/classLoader.cpp ! src/share/vm/code/codeBlob.cpp ! src/share/vm/code/codeCache.cpp ! src/share/vm/code/codeCache.hpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/code/nmethod.hpp ! src/share/vm/code/vtableStubs.cpp ! src/share/vm/includeDB_core ! src/share/vm/interpreter/interpreter.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/init.cpp ! src/share/vm/runtime/java.cpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/stubCodeGenerator.cpp ! src/share/vm/runtime/sweeper.cpp ! src/share/vm/runtime/sweeper.hpp ! src/share/vm/runtime/vmStructs.cpp - src/share/vm/runtime/vtune.hpp From john.r.rose at oracle.com Sat Jul 10 22:17:26 2010 From: john.r.rose at oracle.com (John Rose) Date: Sat, 10 Jul 2010 22:17:26 -0700 Subject: Request for review (L): 6964498: JSR 292 invokedynamic sites need local bootstrap methods Message-ID: These JVM changes implement per-call-site bootstrap methods. The JSR 292 EG is (almost certainly) going to change the bootstrap method from a dynamically specified per-class attribute to a statically-specified per-instruction attribute (in the constant pool). This is the implementation. http://cr.openjdk.java.net/~jrose/6964498/webrev/ This JVM continues to run programs with old-style bootstrap methods, under a compatibility switch. These JVM changes will be pushed unilaterally, before corresponding JDK and javac changes. -- John P.S. Here, FYI, are some prototyped JDK and javac changes which work with the JVM webrev. They are almost certain to change, since we don't know yet on how to "spell" bootstrap methods in the Java language. Annotations are a convenient hack, but probably not the right final answer. http://cr.openjdk.java.net/~jrose/6964498/jdk-webrev/ http://cr.openjdk.java.net/~jrose/6964498/lt-webrev/ From christian.thalinger at oracle.com Mon Jul 12 06:13:47 2010 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 12 Jul 2010 15:13:47 +0200 Subject: Request for review (L): 6964498: JSR 292 invokedynamic sites need local bootstrap methods In-Reply-To: References: Message-ID: <1278940427.17376.21.camel@macbook> On Sat, 2010-07-10 at 22:17 -0700, John Rose wrote: > These JVM changes implement per-call-site bootstrap methods. The JSR > 292 EG is (almost certainly) going to change the bootstrap method from > a dynamically specified per-class attribute to a statically-specified > per-instruction attribute (in the constant pool). This is the > implementation. > > http://cr.openjdk.java.net/~jrose/6964498/webrev/ > > This JVM continues to run programs with old-style bootstrap methods, > under a compatibility switch. These JVM changes will be pushed > unilaterally, before corresponding JDK and javac changes. src/share/vm/interpreter/rewriter.cpp: 80 } else { 81 // There is no CP cache entry holding the BSM for these calls. 82 // We will need to look for a class-global BSM, later. 83 assert(AllowTransitionalJSR292, ""); 84 } I know this will go away, but I think we should use a guarantee here instead of an assert. src/share/vm/oops/cpCacheOop.hpp: 188 // For JVM_CONSTANT_InvokeDynamic cache entrues: Typo. Otherwise looks good. -- Christian From tom.rodriguez at oracle.com Mon Jul 12 11:52:55 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Mon, 12 Jul 2010 11:52:55 -0700 Subject: review (XS) for 6968385: malformed xml in sweeper logging Message-ID: <9F040140-4B40-4DD6-896A-EA7078AA477A@oracle.com> http://cr.openjdk.java.net/~never/6968385 6968385: malformed xml in sweeper logging Reviewed-by: The wrong quote was used in some xml output which resulted in parsing errors. Tested with failing test. From john.r.rose at oracle.com Mon Jul 12 12:00:42 2010 From: john.r.rose at oracle.com (John Rose) Date: Mon, 12 Jul 2010 12:00:42 -0700 Subject: Request for review (L): 6964498: JSR 292 invokedynamic sites need local bootstrap methods In-Reply-To: <1278940427.17376.21.camel@macbook> References: <1278940427.17376.21.camel@macbook> Message-ID: <697E0384-AD07-48CB-8872-5E572674452C@oracle.com> Thanks; I'll make the changes. -- John From vladimir.kozlov at oracle.com Mon Jul 12 12:31:53 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 12 Jul 2010 12:31:53 -0700 Subject: review (XS) for 6968385: malformed xml in sweeper logging In-Reply-To: <9F040140-4B40-4DD6-896A-EA7078AA477A@oracle.com> References: <9F040140-4B40-4DD6-896A-EA7078AA477A@oracle.com> Message-ID: <4C3B6DA9.50708@oracle.com> Good. Vladimir Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/6968385 > > 6968385: malformed xml in sweeper logging > Reviewed-by: > > The wrong quote was used in some xml output which resulted in parsing > errors. Tested with failing test. From tom.rodriguez at oracle.com Mon Jul 12 17:32:55 2010 From: tom.rodriguez at oracle.com (tom.rodriguez at oracle.com) Date: Tue, 13 Jul 2010 00:32:55 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6958668: repeated uncommon trapping for new of klass which is being initialized Message-ID: <20100713003302.CE4D24793E@hg.openjdk.java.net> Changeset: 3941674cc7fa Author: never Date: 2010-07-12 10:58 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/3941674cc7fa 6958668: repeated uncommon trapping for new of klass which is being initialized Reviewed-by: kvn, jrose ! src/share/vm/ci/ciInstanceKlass.cpp ! src/share/vm/ci/ciInstanceKlass.hpp ! src/share/vm/opto/doCall.cpp ! src/share/vm/opto/parse.hpp ! src/share/vm/opto/parseHelper.cpp From vladimir.kozlov at oracle.com Tue Jul 13 09:02:49 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 13 Jul 2010 09:02:49 -0700 Subject: Request for reviews (M): 6968368: SIGSEGV in the BCEscapeAnalyzer::copy_dependencies Message-ID: <4C3C8E29.6080206@oracle.com> http://cr.openjdk.java.net/~kvn/6968368/webrev Fixed 6968368: SIGSEGV in the BCEscapeAnalyzer::copy_dependencies Changes for 6966411 moved escape analysis into Optimize() method after ResourceMark so on exit from Optimize() all data allocated in resource area is freed. bcEscapeAnalyzer uses resource area to keep dependency and bytecode analysis data and this data will be lost on exit from Optimize(). The method compilation could be retried (subsume_loads) with the same CI data but bcEscapeAnalyzer dependency and bytecode analysis data are not regenerated and contain garbage. Solution: Use GrowableArray and VectorSet allocated in ciEnv arena. Removed unused _stack field. Failed test, CTW, JPRT, nsk.stress From vladimir.kozlov at oracle.com Tue Jul 13 15:22:10 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 13 Jul 2010 15:22:10 -0700 Subject: Request for reviews (S): 6968646: JVM crashes with SIGFPE during startup Message-ID: <4C3CE712.8070801@oracle.com> http://cr.openjdk.java.net/~kvn/6968646/webrev Fixed 6968646: JVM crashes with SIGFPE during startup Introduced by changes for 6964774 which added cpuid processor topology code. Some cpus have max cpuid >= 11 but do not support processor topology: vendor_id : GenuineIntel cpu family : 6 model : 23 model name : Intel(R) Xeon(R) CPU E5472 @ 3.00GHz stepping : 10 cpu MHz : 2403.000 cpu cores : 4 cpuid level : 13 Solution: Check that cpuid returns valid values for processor topology (not zeros) and use old code if they are invalid. Test on failed machine. From vladimir.kozlov at oracle.com Tue Jul 13 15:53:29 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 13 Jul 2010 15:53:29 -0700 Subject: Request for reviews (M): 6968368: SIGSEGV in the BCEscapeAnalyzer::copy_dependencies In-Reply-To: References: <4C3C8E29.6080206@oracle.com> Message-ID: <4C3CEE69.6080102@oracle.com> Thank you, Tom, for both reviews. Vladimir Tom Rodriguez wrote: > Looks good. > > tom > > On Jul 13, 2010, at 9:02 AM, Vladimir Kozlov wrote: > >> http://cr.openjdk.java.net/~kvn/6968368/webrev >> >> Fixed 6968368: SIGSEGV in the BCEscapeAnalyzer::copy_dependencies >> >> Changes for 6966411 moved escape analysis into Optimize() method >> after ResourceMark so on exit from Optimize() all data allocated >> in resource area is freed. bcEscapeAnalyzer uses resource area >> to keep dependency and bytecode analysis data and this data will >> be lost on exit from Optimize(). The method compilation could be >> retried (subsume_loads) with the same CI data but bcEscapeAnalyzer >> dependency and bytecode analysis data are not regenerated and >> contain garbage. >> >> Solution: >> Use GrowableArray and VectorSet allocated in ciEnv arena. >> Removed unused _stack field. >> >> Failed test, CTW, JPRT, nsk.stress > From tom.rodriguez at oracle.com Tue Jul 13 15:53:51 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 13 Jul 2010 15:53:51 -0700 Subject: Request for reviews (S): 6968646: JVM crashes with SIGFPE during startup In-Reply-To: <4C3CE712.8070801@oracle.com> References: <4C3CE712.8070801@oracle.com> Message-ID: Looks good. tom On Jul 13, 2010, at 3:22 PM, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/6968646/webrev > > Fixed 6968646: JVM crashes with SIGFPE during startup > > Introduced by changes for 6964774 which added cpuid > processor topology code. Some cpus have max cpuid >= 11 > but do not support processor topology: > > vendor_id : GenuineIntel > cpu family : 6 > model : 23 > model name : Intel(R) Xeon(R) CPU E5472 @ 3.00GHz > stepping : 10 > cpu MHz : 2403.000 > cpu cores : 4 > cpuid level : 13 > > > Solution: > Check that cpuid returns valid values for processor > topology (not zeros) and use old code if they are invalid. > > Test on failed machine. From tom.rodriguez at oracle.com Tue Jul 13 15:54:07 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 13 Jul 2010 15:54:07 -0700 Subject: Request for reviews (M): 6968368: SIGSEGV in the BCEscapeAnalyzer::copy_dependencies In-Reply-To: <4C3C8E29.6080206@oracle.com> References: <4C3C8E29.6080206@oracle.com> Message-ID: Looks good. tom On Jul 13, 2010, at 9:02 AM, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/6968368/webrev > > Fixed 6968368: SIGSEGV in the BCEscapeAnalyzer::copy_dependencies > > Changes for 6966411 moved escape analysis into Optimize() method > after ResourceMark so on exit from Optimize() all data allocated > in resource area is freed. bcEscapeAnalyzer uses resource area > to keep dependency and bytecode analysis data and this data will > be lost on exit from Optimize(). The method compilation could be > retried (subsume_loads) with the same CI data but bcEscapeAnalyzer > dependency and bytecode analysis data are not regenerated and > contain garbage. > > Solution: > Use GrowableArray and VectorSet allocated in ciEnv arena. > Removed unused _stack field. > > Failed test, CTW, JPRT, nsk.stress From christian.thalinger at oracle.com Wed Jul 14 00:33:48 2010 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 14 Jul 2010 09:33:48 +0200 Subject: Request for reviews (S): 6968646: JVM crashes with SIGFPE during startup In-Reply-To: <4C3CE712.8070801@oracle.com> References: <4C3CE712.8070801@oracle.com> Message-ID: <1279092828.23674.20.camel@macbook> On Tue, 2010-07-13 at 15:22 -0700, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/6968646/webrev > > Fixed 6968646: JVM crashes with SIGFPE during startup I tried the patch on my failing system and it works. -- Christian From christian.thalinger at oracle.com Wed Jul 14 00:40:32 2010 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 14 Jul 2010 09:40:32 +0200 Subject: Request for reviews (M): 6968368: SIGSEGV in the BCEscapeAnalyzer::copy_dependencies In-Reply-To: <4C3C8E29.6080206@oracle.com> References: <4C3C8E29.6080206@oracle.com> Message-ID: <1279093232.23674.21.camel@macbook> On Tue, 2010-07-13 at 09:02 -0700, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/6968368/webrev > > Fixed 6968368: SIGSEGV in the BCEscapeAnalyzer::copy_dependencies > > Changes for 6966411 moved escape analysis into Optimize() method > after ResourceMark so on exit from Optimize() all data allocated > in resource area is freed. bcEscapeAnalyzer uses resource area > to keep dependency and bytecode analysis data and this data will > be lost on exit from Optimize(). The method compilation could be > retried (subsume_loads) with the same CI data but bcEscapeAnalyzer > dependency and bytecode analysis data are not regenerated and > contain garbage. > > Solution: > Use GrowableArray and VectorSet allocated in ciEnv arena. > Removed unused _stack field. > > Failed test, CTW, JPRT, nsk.stress Looks good. -- Christian From vladimir.kozlov at oracle.com Wed Jul 14 09:44:32 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 14 Jul 2010 09:44:32 -0700 Subject: Request for reviews (M): 6968368: SIGSEGV in the BCEscapeAnalyzer::copy_dependencies In-Reply-To: <1279093232.23674.21.camel@macbook> References: <4C3C8E29.6080206@oracle.com> <1279093232.23674.21.camel@macbook> Message-ID: <4C3DE970.2080000@oracle.com> Thank you, Christian, for reviews Vladimir On 7/14/10 12:40 AM, Christian Thalinger wrote: > On Tue, 2010-07-13 at 09:02 -0700, Vladimir Kozlov wrote: >> http://cr.openjdk.java.net/~kvn/6968368/webrev >> >> Fixed 6968368: SIGSEGV in the BCEscapeAnalyzer::copy_dependencies >> >> Changes for 6966411 moved escape analysis into Optimize() method >> after ResourceMark so on exit from Optimize() all data allocated >> in resource area is freed. bcEscapeAnalyzer uses resource area >> to keep dependency and bytecode analysis data and this data will >> be lost on exit from Optimize(). The method compilation could be >> retried (subsume_loads) with the same CI data but bcEscapeAnalyzer >> dependency and bytecode analysis data are not regenerated and >> contain garbage. >> >> Solution: >> Use GrowableArray and VectorSet allocated in ciEnv arena. >> Removed unused _stack field. >> >> Failed test, CTW, JPRT, nsk.stress > > Looks good. -- Christian > From tom.rodriguez at oracle.com Wed Jul 14 14:17:36 2010 From: tom.rodriguez at oracle.com (tom.rodriguez at oracle.com) Date: Wed, 14 Jul 2010 21:17:36 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6968385: malformed xml in sweeper logging Message-ID: <20100714211744.6F11D479A9@hg.openjdk.java.net> Changeset: 8d5934a77f10 Author: never Date: 2010-07-12 22:27 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/8d5934a77f10 6968385: malformed xml in sweeper logging Reviewed-by: kvn ! src/share/vm/runtime/sweeper.cpp From vladimir.kozlov at oracle.com Wed Jul 14 16:33:18 2010 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Wed, 14 Jul 2010 23:33:18 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6968646: JVM crashes with SIGFPE during startup Message-ID: <20100714233320.EBD0B479B3@hg.openjdk.java.net> Changeset: 079980c86f33 Author: kvn Date: 2010-07-14 14:29 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/079980c86f33 6968646: JVM crashes with SIGFPE during startup Summary: Check that cpuid returns valid values for processor topology (not zeros). Reviewed-by: never, twisti ! src/cpu/x86/vm/vm_version_x86.hpp From vladimir.kozlov at oracle.com Wed Jul 14 19:19:00 2010 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Thu, 15 Jul 2010 02:19:00 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6968368: SIGSEGV in the BCEscapeAnalyzer::copy_dependencies Message-ID: <20100715021909.ECED1479BA@hg.openjdk.java.net> Changeset: 8099e71601df Author: kvn Date: 2010-07-14 14:47 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/8099e71601df 6968368: SIGSEGV in the BCEscapeAnalyzer::copy_dependencies Summary: Use GrowableArray and VectorSet allocated in ciEnv arena. Reviewed-by: never, twisti ! src/share/vm/ci/bcEscapeAnalyzer.cpp ! src/share/vm/ci/bcEscapeAnalyzer.hpp ! src/share/vm/ci/ciMethod.cpp ! src/share/vm/ci/ciMethod.hpp ! src/share/vm/includeDB_compiler2 ! src/share/vm/includeDB_core From tom.rodriguez at oracle.com Thu Jul 15 08:37:25 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 15 Jul 2010 08:37:25 -0700 Subject: review (XS) for 6968336: VM crash guarantee(!nm->is_zombie()) failed: cannot lock a zombie method Message-ID: <691BEA97-7382-4BC2-A571-E0FABCFB8B1D@oracle.com> http://cr.openjdk.java.net/~never/6968336 6968336: VM crash guarantee(!nm->is_zombie()) failed: cannot lock a zombie method Reviewed-by: The fix for 6965671 iterates over the code cache and processes nmethods for which is_alive is true. It includes an nmethodLocker to protect the nmethod but it's illegal to lock zombie nmethods. The nmethodLocker should be inside the is_alive test instead of outside to guard against this case. There was also a ShouldNotReachHere that I added during testing that I should have removed before putback. Tested with the jvmti tests under ute. From christian.thalinger at oracle.com Thu Jul 15 08:52:14 2010 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 15 Jul 2010 17:52:14 +0200 Subject: review (XS) for 6968336: VM crash guarantee(!nm->is_zombie()) failed: cannot lock a zombie method In-Reply-To: <691BEA97-7382-4BC2-A571-E0FABCFB8B1D@oracle.com> References: <691BEA97-7382-4BC2-A571-E0FABCFB8B1D@oracle.com> Message-ID: <1279209134.23674.567.camel@macbook> On Thu, 2010-07-15 at 08:37 -0700, Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/6968336 > > 6968336: VM crash guarantee(!nm->is_zombie()) failed: cannot lock a zombie method > Reviewed-by: > > The fix for 6965671 iterates over the code cache and processes > nmethods for which is_alive is true. It includes an nmethodLocker to > protect the nmethod but it's illegal to lock zombie nmethods. The > nmethodLocker should be inside the is_alive test instead of outside to > guard against this case. There was also a ShouldNotReachHere that I > added during testing that I should have removed before putback. > Tested with the jvmti tests under ute. Looks good. -- Christian From vladimir.kozlov at oracle.com Thu Jul 15 09:31:23 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 15 Jul 2010 09:31:23 -0700 Subject: review (XS) for 6968336: VM crash guarantee(!nm->is_zombie()) failed: cannot lock a zombie method In-Reply-To: <691BEA97-7382-4BC2-A571-E0FABCFB8B1D@oracle.com> References: <691BEA97-7382-4BC2-A571-E0FABCFB8B1D@oracle.com> Message-ID: <4C3F37DB.5000300@oracle.com> Good. Vladimir Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/6968336 > > 6968336: VM crash guarantee(!nm->is_zombie()) failed: cannot lock a zombie method > Reviewed-by: > > The fix for 6965671 iterates over the code cache and processes > nmethods for which is_alive is true. It includes an nmethodLocker to > protect the nmethod but it's illegal to lock zombie nmethods. The > nmethodLocker should be inside the is_alive test instead of outside to > guard against this case. There was also a ShouldNotReachHere that I > added during testing that I should have removed before putback. > Tested with the jvmti tests under ute. From tom.rodriguez at oracle.com Thu Jul 15 12:49:57 2010 From: tom.rodriguez at oracle.com (tom.rodriguez at oracle.com) Date: Thu, 15 Jul 2010 19:49:57 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6968336: VM crash guarantee(!nm->is_zombie()) failed: cannot lock a zombie method Message-ID: <20100715195000.BECAB479EB@hg.openjdk.java.net> Changeset: a528509c992b Author: never Date: 2010-07-15 08:54 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/a528509c992b 6968336: VM crash guarantee(!nm->is_zombie()) failed: cannot lock a zombie method Reviewed-by: twisti ! src/share/vm/prims/jvmtiCodeBlobEvents.cpp From john.r.rose at oracle.com Thu Jul 15 14:53:28 2010 From: john.r.rose at oracle.com (John Rose) Date: Thu, 15 Jul 2010 14:53:28 -0700 Subject: Request for review (M): 6969574: invokedynamic call sites deoptimize instead of executing Message-ID: http://cr.openjdk.java.net/~jrose/6969574/ The compilation of invokedynamic needs several small fixes to enable the expected code generation. An initial breakage in ciTypeFlow was causing the compiler to deoptimize on dynamic call sites. Fixing this exposed a couple of other issues. Summary of fixes: 1. Add missing case for byte_no classification. (cpCacheOop.hpp) 2. Rewrite misleading comment about byte_no. (cpCacheOop.cpp) 3. Pull "signature invoker" for an indy instruction from the correct CP cache field (f1). (ciEnv.cpp) 4. Clarify tests for is_method_handle_adapter vs. is_method_handle_invoke, and assert disjointness. (methodOop.cpp, ciMethod.cpp) 5. Correct format assertion on ldc. (methodHandleWalk.cpp) The original problem (fixed by step 1) was a broken "is linked" test in ciTypeFlow which always caused a bail-out to the interpreter. This made benchmark results somewhat... suboptimal. Hat tip to Eric Bodden, who reported this last month. http://mail.openjdk.java.net/pipermail/mlvm-dev/2010-June/001767.html -- John From vladimir.kozlov at oracle.com Thu Jul 15 15:01:04 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 15 Jul 2010 15:01:04 -0700 Subject: Request for review (M): 6969574: invokedynamic call sites deoptimize instead of executing In-Reply-To: References: Message-ID: <4C3F8520.6000100@oracle.com> Looks good. Vladimir John Rose wrote: > http://cr.openjdk.java.net/~jrose/6969574/ > > The compilation of invokedynamic needs several small fixes to enable the expected code generation. > > An initial breakage in ciTypeFlow was causing the compiler to deoptimize on dynamic call sites. Fixing this exposed a couple of other issues. > > Summary of fixes: > > 1. Add missing case for byte_no classification. (cpCacheOop.hpp) > > 2. Rewrite misleading comment about byte_no. (cpCacheOop.cpp) > > 3. Pull "signature invoker" for an indy instruction from the correct CP cache field (f1). (ciEnv.cpp) > > 4. Clarify tests for is_method_handle_adapter vs. is_method_handle_invoke, and assert disjointness. > (methodOop.cpp, ciMethod.cpp) > > 5. Correct format assertion on ldc. (methodHandleWalk.cpp) > > The original problem (fixed by step 1) was a broken "is linked" test in ciTypeFlow which always caused a bail-out to the interpreter. > > This made benchmark results somewhat... suboptimal. > > Hat tip to Eric Bodden, who reported this last month. > http://mail.openjdk.java.net/pipermail/mlvm-dev/2010-June/001767.html > > -- John From john.r.rose at oracle.com Thu Jul 15 15:13:28 2010 From: john.r.rose at oracle.com (John Rose) Date: Thu, 15 Jul 2010 15:13:28 -0700 Subject: Request for review (M): 6969574: invokedynamic call sites deoptimize instead of executing In-Reply-To: <4C3F8520.6000100@oracle.com> References: <4C3F8520.6000100@oracle.com> Message-ID: Thanks! -- John On Jul 15, 2010, at 3:01 PM, Vladimir Kozlov wrote: > Looks good. From john.r.rose at oracle.com Thu Jul 15 20:36:50 2010 From: john.r.rose at oracle.com (John Rose) Date: Thu, 15 Jul 2010 20:36:50 -0700 Subject: review request (M): 6912064: type profiles need to be more thorough for dynamic language support Message-ID: I got a pre-review for 6912064 in January. These changes still work well; I just used them successfully with a performance tuning experiment. There was a corner case bug which required an additional 'stopped()' check in graphKit. Here's the update: http://cr.openjdk.java.net/~jrose/6912064/webrev.02/ The four lines in this file starting "// Profile disagrees with this path." are new: http://cr.openjdk.java.net/~jrose/6912064/webrev.02/src/share/vm/opto/graphKit.cpp.udiff.html That is the only difference from January. Any further comments on this change set? -- John FTR, here is the previous communication. (Yes, it's been a while.) From: John Rose Date: January 26, 2010 7:14:13 PM PST To: Vladimir Kozlov Cc: Igor Veresov , hotspot-compiler-dev compiler Subject: Re: for pre-review (M): 6912064: type profiles need to be more thorough for dynamic language support On Jan 26, 2010, at 6:59 PM, Vladimir Kozlov wrote: > Then why you generate the klass check with uncommon trap for instanceof > for cases when profiling shows that it will fail? For code like this: if (x instanceof String) doString((String) x); else if (x instanceof Number) doNumber((Number) x); If the 'x' is always an Integer, I want to fold all the tests up from the first instanceof, not the second. The profile will show when 'x' is of a monomorphic type. That is more interesting than whether the first check happens to go true or false. -- John From john.r.rose at oracle.com Thu Jul 15 22:24:17 2010 From: john.r.rose at oracle.com (John Rose) Date: Thu, 15 Jul 2010 22:24:17 -0700 Subject: Request for review (M): 6969574: invokedynamic call sites deoptimize instead of executing In-Reply-To: <4C3F8520.6000100@oracle.com> References: <4C3F8520.6000100@oracle.com> Message-ID: I made a slight change: Unloaded CI methods should never be classified as special internal "method_handle_invokes". See changes near "is_loaded" calls here: http://cr.openjdk.java.net/~jrose/6969574/webrev.01/src/share/vm/ci/ciMethod.cpp.udiff.html When C1 was using the changed code, the call from ciMethod::is_method_handle_invoke to check_if_loaded was throwing asserts. (Hat tip to Stephen Bannasch on mlvm-dev for smoking this bug out almost immediately!) -- John On Jul 15, 2010, at 3:01 PM, Vladimir Kozlov wrote: > Looks good. > > Vladimir > > John Rose wrote: >> http://cr.openjdk.java.net/~jrose/6969574/ >> The compilation of invokedynamic needs several small fixes to enable the expected code generation. >> An initial breakage in ciTypeFlow was causing the compiler to deoptimize on dynamic call sites. Fixing this exposed a couple of other issues. >> Summary of fixes: >> 1. Add missing case for byte_no classification. (cpCacheOop.hpp) >> 2. Rewrite misleading comment about byte_no. (cpCacheOop.cpp) >> 3. Pull "signature invoker" for an indy instruction from the correct CP cache field (f1). (ciEnv.cpp) >> 4. Clarify tests for is_method_handle_adapter vs. is_method_handle_invoke, and assert disjointness. >> (methodOop.cpp, ciMethod.cpp) >> 5. Correct format assertion on ldc. (methodHandleWalk.cpp) >> The original problem (fixed by step 1) was a broken "is linked" test in ciTypeFlow which always caused a bail-out to the interpreter. >> This made benchmark results somewhat... suboptimal. >> Hat tip to Eric Bodden, who reported this last month. >> http://mail.openjdk.java.net/pipermail/mlvm-dev/2010-June/001767.html >> -- John From john.r.rose at oracle.com Fri Jul 16 01:18:49 2010 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Fri, 16 Jul 2010 08:18:49 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6964498: JSR 292 invokedynamic sites need local bootstrap methods Message-ID: <20100716081853.7B82E47A0A@hg.openjdk.java.net> Changeset: 083fde3b838e Author: jrose Date: 2010-07-15 18:40 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/083fde3b838e 6964498: JSR 292 invokedynamic sites need local bootstrap methods Summary: Add JVM_CONSTANT_InvokeDynamic records to constant pool to determine per-instruction BSMs. Reviewed-by: twisti ! agent/src/share/classes/sun/jvm/hotspot/oops/ConstantPool.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/ClassConstants.java ! agent/src/share/classes/sun/jvm/hotspot/tools/jcore/ClassWriter.java ! agent/src/share/classes/sun/jvm/hotspot/ui/classbrowser/HTMLGenerator.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/ConstantTag.java ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/classfile/verifier.cpp ! src/share/vm/interpreter/bytecodeTracer.cpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/interpreter/linkResolver.hpp ! src/share/vm/interpreter/rewriter.cpp ! src/share/vm/interpreter/rewriter.hpp ! src/share/vm/oops/constantPoolKlass.cpp ! src/share/vm/oops/constantPoolOop.cpp ! src/share/vm/oops/constantPoolOop.hpp ! src/share/vm/oops/cpCacheOop.cpp ! src/share/vm/oops/cpCacheOop.hpp ! src/share/vm/prims/jvm.h ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/utilities/constantTag.cpp ! src/share/vm/utilities/constantTag.hpp From john.coomes at oracle.com Fri Jul 16 01:54:21 2010 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 16 Jul 2010 08:54:21 +0000 Subject: hg: jdk7/hotspot-comp: Added tag jdk7-b100 for changeset b218a53ec7d3 Message-ID: <20100716085421.7CFE447A13@hg.openjdk.java.net> Changeset: 4193eaf5f1b8 Author: mikejwre Date: 2010-07-09 19:18 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/rev/4193eaf5f1b8 Added tag jdk7-b100 for changeset b218a53ec7d3 ! .hgtags From john.coomes at oracle.com Fri Jul 16 01:54:25 2010 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 16 Jul 2010 08:54:25 +0000 Subject: hg: jdk7/hotspot-comp/corba: Added tag jdk7-b100 for changeset a56d734a1e97 Message-ID: <20100716085428.BFE5F47A14@hg.openjdk.java.net> Changeset: 86a239832646 Author: mikejwre Date: 2010-07-09 19:18 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/corba/rev/86a239832646 Added tag jdk7-b100 for changeset a56d734a1e97 ! .hgtags From john.coomes at oracle.com Fri Jul 16 02:00:52 2010 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 16 Jul 2010 09:00:52 +0000 Subject: hg: jdk7/hotspot-comp/jaxp: Added tag jdk7-b100 for changeset d524be5ef62e Message-ID: <20100716090052.4CCAB47A15@hg.openjdk.java.net> Changeset: 17f62a566a20 Author: mikejwre Date: 2010-07-09 19:18 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxp/rev/17f62a566a20 Added tag jdk7-b100 for changeset d524be5ef62e ! .hgtags From john.coomes at oracle.com Fri Jul 16 02:00:56 2010 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 16 Jul 2010 09:00:56 +0000 Subject: hg: jdk7/hotspot-comp/jaxws: Added tag jdk7-b100 for changeset bd26d0ce0c3c Message-ID: <20100716090056.B4DC047A16@hg.openjdk.java.net> Changeset: b55ce2744900 Author: mikejwre Date: 2010-07-09 19:18 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxws/rev/b55ce2744900 Added tag jdk7-b100 for changeset bd26d0ce0c3c ! .hgtags From john.coomes at oracle.com Fri Jul 16 02:01:07 2010 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 16 Jul 2010 09:01:07 +0000 Subject: hg: jdk7/hotspot-comp/jdk: 3 new changesets Message-ID: <20100716090208.D04A247A17@hg.openjdk.java.net> Changeset: 820b4e843d51 Author: ohair Date: 2010-07-07 10:21 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/820b4e843d51 6967036: Need to fix links with // in Javadoc comments Reviewed-by: mchung ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/Base64.java ! src/share/classes/com/sun/security/auth/LdapPrincipal.java ! src/share/classes/com/sun/security/sasl/CramMD5Client.java ! src/share/classes/com/sun/security/sasl/CramMD5Server.java ! src/share/classes/com/sun/security/sasl/ExternalClient.java ! src/share/classes/com/sun/security/sasl/gsskerb/GssKrb5Client.java ! src/share/classes/com/sun/security/sasl/gsskerb/GssKrb5Server.java ! src/share/classes/java/net/URI.java ! src/share/classes/java/nio/charset/package.html ! src/share/classes/javax/management/remote/JMXServiceURL.java ! src/share/classes/javax/naming/ldap/LdapName.java ! src/share/classes/javax/naming/ldap/Rdn.java ! src/share/classes/javax/net/ssl/SSLContext.java ! src/share/classes/javax/print/DocFlavor.java ! src/share/classes/sun/awt/image/PNGImageDecoder.java Changeset: 93c4e6d14010 Author: mikejwre Date: 2010-07-09 19:18 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/93c4e6d14010 Added tag jdk7-b100 for changeset 820b4e843d51 ! .hgtags Changeset: d58354a69011 Author: bpatel Date: 2010-07-14 15:42 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/d58354a69011 6955341: Oracle rebranding changes for man pages Reviewed-by: darcy ! src/linux/doc/man/appletviewer.1 ! src/linux/doc/man/apt.1 ! src/linux/doc/man/extcheck.1 ! src/linux/doc/man/idlj.1 ! src/linux/doc/man/ja/appletviewer.1 ! src/linux/doc/man/ja/apt.1 ! src/linux/doc/man/ja/extcheck.1 ! src/linux/doc/man/ja/idlj.1 ! src/linux/doc/man/ja/jar.1 ! src/linux/doc/man/ja/jarsigner.1 ! src/linux/doc/man/ja/java.1 ! src/linux/doc/man/ja/javac.1 ! src/linux/doc/man/ja/javadoc.1 ! src/linux/doc/man/ja/javah.1 ! src/linux/doc/man/ja/javap.1 ! src/linux/doc/man/ja/javaws.1 ! src/linux/doc/man/ja/jconsole.1 ! src/linux/doc/man/ja/jdb.1 ! src/linux/doc/man/ja/jhat.1 ! src/linux/doc/man/ja/jinfo.1 ! src/linux/doc/man/ja/jmap.1 ! src/linux/doc/man/ja/jps.1 ! src/linux/doc/man/ja/jrunscript.1 ! src/linux/doc/man/ja/jsadebugd.1 ! src/linux/doc/man/ja/jstack.1 ! src/linux/doc/man/ja/jstat.1 ! src/linux/doc/man/ja/jstatd.1 ! src/linux/doc/man/ja/keytool.1 - src/linux/doc/man/ja/kinit.1 - src/linux/doc/man/ja/klist.1 - src/linux/doc/man/ja/ktab.1 ! src/linux/doc/man/ja/native2ascii.1 ! src/linux/doc/man/ja/orbd.1 ! src/linux/doc/man/ja/pack200.1 ! src/linux/doc/man/ja/policytool.1 ! src/linux/doc/man/ja/rmic.1 ! src/linux/doc/man/ja/rmid.1 ! src/linux/doc/man/ja/rmiregistry.1 ! src/linux/doc/man/ja/schemagen.1 ! src/linux/doc/man/ja/serialver.1 ! src/linux/doc/man/ja/servertool.1 ! src/linux/doc/man/ja/tnameserv.1 ! src/linux/doc/man/ja/unpack200.1 ! src/linux/doc/man/ja/wsgen.1 ! src/linux/doc/man/ja/wsimport.1 ! src/linux/doc/man/ja/xjc.1 ! src/linux/doc/man/jar.1 ! src/linux/doc/man/jarsigner.1 ! src/linux/doc/man/java.1 ! src/linux/doc/man/javac.1 ! src/linux/doc/man/javadoc.1 ! src/linux/doc/man/javah.1 ! src/linux/doc/man/javap.1 ! src/linux/doc/man/javaws.1 ! src/linux/doc/man/jconsole.1 ! src/linux/doc/man/jdb.1 ! src/linux/doc/man/jhat.1 ! src/linux/doc/man/jinfo.1 ! src/linux/doc/man/jmap.1 ! src/linux/doc/man/jps.1 ! src/linux/doc/man/jrunscript.1 ! src/linux/doc/man/jsadebugd.1 ! src/linux/doc/man/jstack.1 ! src/linux/doc/man/jstat.1 ! src/linux/doc/man/jstatd.1 ! src/linux/doc/man/keytool.1 ! src/linux/doc/man/native2ascii.1 ! src/linux/doc/man/orbd.1 ! src/linux/doc/man/pack200.1 ! src/linux/doc/man/policytool.1 ! src/linux/doc/man/rmic.1 ! src/linux/doc/man/rmid.1 ! src/linux/doc/man/rmiregistry.1 ! src/linux/doc/man/schemagen.1 ! src/linux/doc/man/serialver.1 ! src/linux/doc/man/servertool.1 ! src/linux/doc/man/tnameserv.1 ! src/linux/doc/man/unpack200.1 ! src/linux/doc/man/wsgen.1 ! src/linux/doc/man/wsimport.1 ! src/linux/doc/man/xjc.1 ! src/solaris/doc/sun/man/man1/appletviewer.1 ! src/solaris/doc/sun/man/man1/apt.1 ! src/solaris/doc/sun/man/man1/extcheck.1 ! src/solaris/doc/sun/man/man1/idlj.1 ! src/solaris/doc/sun/man/man1/ja/appletviewer.1 ! src/solaris/doc/sun/man/man1/ja/apt.1 ! src/solaris/doc/sun/man/man1/ja/extcheck.1 ! src/solaris/doc/sun/man/man1/ja/idlj.1 ! src/solaris/doc/sun/man/man1/ja/jar.1 ! src/solaris/doc/sun/man/man1/ja/jarsigner.1 ! src/solaris/doc/sun/man/man1/ja/java.1 ! src/solaris/doc/sun/man/man1/ja/javac.1 ! src/solaris/doc/sun/man/man1/ja/javadoc.1 ! src/solaris/doc/sun/man/man1/ja/javah.1 ! src/solaris/doc/sun/man/man1/ja/javap.1 ! src/solaris/doc/sun/man/man1/ja/javaws.1 ! src/solaris/doc/sun/man/man1/ja/jconsole.1 ! src/solaris/doc/sun/man/man1/ja/jdb.1 ! src/solaris/doc/sun/man/man1/ja/jhat.1 ! src/solaris/doc/sun/man/man1/ja/jinfo.1 ! src/solaris/doc/sun/man/man1/ja/jmap.1 ! src/solaris/doc/sun/man/man1/ja/jps.1 ! src/solaris/doc/sun/man/man1/ja/jrunscript.1 ! src/solaris/doc/sun/man/man1/ja/jsadebugd.1 ! src/solaris/doc/sun/man/man1/ja/jstack.1 ! src/solaris/doc/sun/man/man1/ja/jstat.1 ! src/solaris/doc/sun/man/man1/ja/jstatd.1 ! src/solaris/doc/sun/man/man1/ja/keytool.1 ! src/solaris/doc/sun/man/man1/ja/native2ascii.1 ! src/solaris/doc/sun/man/man1/ja/orbd.1 ! src/solaris/doc/sun/man/man1/ja/pack200.1 ! src/solaris/doc/sun/man/man1/ja/policytool.1 ! src/solaris/doc/sun/man/man1/ja/rmic.1 ! src/solaris/doc/sun/man/man1/ja/rmid.1 ! src/solaris/doc/sun/man/man1/ja/rmiregistry.1 ! src/solaris/doc/sun/man/man1/ja/schemagen.1 ! src/solaris/doc/sun/man/man1/ja/serialver.1 ! src/solaris/doc/sun/man/man1/ja/servertool.1 ! src/solaris/doc/sun/man/man1/ja/tnameserv.1 ! src/solaris/doc/sun/man/man1/ja/unpack200.1 ! src/solaris/doc/sun/man/man1/ja/wsgen.1 ! src/solaris/doc/sun/man/man1/ja/wsimport.1 ! src/solaris/doc/sun/man/man1/ja/xjc.1 ! src/solaris/doc/sun/man/man1/jar.1 ! src/solaris/doc/sun/man/man1/jarsigner.1 ! src/solaris/doc/sun/man/man1/java.1 ! src/solaris/doc/sun/man/man1/javac.1 ! src/solaris/doc/sun/man/man1/javadoc.1 ! src/solaris/doc/sun/man/man1/javah.1 ! src/solaris/doc/sun/man/man1/javap.1 ! src/solaris/doc/sun/man/man1/javaws.1 ! src/solaris/doc/sun/man/man1/jconsole.1 ! src/solaris/doc/sun/man/man1/jdb.1 ! src/solaris/doc/sun/man/man1/jhat.1 ! src/solaris/doc/sun/man/man1/jinfo.1 ! src/solaris/doc/sun/man/man1/jmap.1 ! src/solaris/doc/sun/man/man1/jps.1 ! src/solaris/doc/sun/man/man1/jrunscript.1 ! src/solaris/doc/sun/man/man1/jsadebugd.1 ! src/solaris/doc/sun/man/man1/jstack.1 ! src/solaris/doc/sun/man/man1/jstat.1 ! src/solaris/doc/sun/man/man1/jstatd.1 ! src/solaris/doc/sun/man/man1/keytool.1 ! src/solaris/doc/sun/man/man1/native2ascii.1 ! src/solaris/doc/sun/man/man1/orbd.1 ! src/solaris/doc/sun/man/man1/pack200.1 ! src/solaris/doc/sun/man/man1/policytool.1 ! src/solaris/doc/sun/man/man1/rmic.1 ! src/solaris/doc/sun/man/man1/rmid.1 ! src/solaris/doc/sun/man/man1/rmiregistry.1 ! src/solaris/doc/sun/man/man1/schemagen.1 ! src/solaris/doc/sun/man/man1/serialver.1 ! src/solaris/doc/sun/man/man1/servertool.1 ! src/solaris/doc/sun/man/man1/tnameserv.1 ! src/solaris/doc/sun/man/man1/unpack200.1 ! src/solaris/doc/sun/man/man1/wsgen.1 ! src/solaris/doc/sun/man/man1/wsimport.1 ! src/solaris/doc/sun/man/man1/xjc.1 From john.coomes at oracle.com Fri Jul 16 02:07:10 2010 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 16 Jul 2010 09:07:10 +0000 Subject: hg: jdk7/hotspot-comp/langtools: Added tag jdk7-b100 for changeset d1d7595fa824 Message-ID: <20100716090716.CA60147A18@hg.openjdk.java.net> Changeset: 20a8fe72ee7b Author: mikejwre Date: 2010-07-09 19:18 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/20a8fe72ee7b Added tag jdk7-b100 for changeset d1d7595fa824 ! .hgtags From vladimir.kozlov at oracle.com Fri Jul 16 08:32:25 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 16 Jul 2010 08:32:25 -0700 Subject: Request for review (M): 6969574: invokedynamic call sites deoptimize instead of executing In-Reply-To: References: <4C3F8520.6000100@oracle.com> Message-ID: <4C407B89.6020703@oracle.com> OK. Vladimir On 7/15/10 10:24 PM, John Rose wrote: > I made a slight change: Unloaded CI methods should never be classified as special internal "method_handle_invokes". > > See changes near "is_loaded" calls here: > http://cr.openjdk.java.net/~jrose/6969574/webrev.01/src/share/vm/ci/ciMethod.cpp.udiff.html > > When C1 was using the changed code, the call from ciMethod::is_method_handle_invoke to check_if_loaded was throwing asserts. > > (Hat tip to Stephen Bannasch on mlvm-dev for smoking this bug out almost immediately!) > > -- John > > On Jul 15, 2010, at 3:01 PM, Vladimir Kozlov wrote: > >> Looks good. >> >> Vladimir >> >> John Rose wrote: >>> http://cr.openjdk.java.net/~jrose/6969574/ >>> The compilation of invokedynamic needs several small fixes to enable the expected code generation. >>> An initial breakage in ciTypeFlow was causing the compiler to deoptimize on dynamic call sites. Fixing this exposed a couple of other issues. >>> Summary of fixes: >>> 1. Add missing case for byte_no classification. (cpCacheOop.hpp) >>> 2. Rewrite misleading comment about byte_no. (cpCacheOop.cpp) >>> 3. Pull "signature invoker" for an indy instruction from the correct CP cache field (f1). (ciEnv.cpp) >>> 4. Clarify tests for is_method_handle_adapter vs. is_method_handle_invoke, and assert disjointness. >>> (methodOop.cpp, ciMethod.cpp) >>> 5. Correct format assertion on ldc. (methodHandleWalk.cpp) >>> The original problem (fixed by step 1) was a broken "is linked" test in ciTypeFlow which always caused a bail-out to the interpreter. >>> This made benchmark results somewhat... suboptimal. >>> Hat tip to Eric Bodden, who reported this last month. >>> http://mail.openjdk.java.net/pipermail/mlvm-dev/2010-June/001767.html >>> -- John > From vladimir.kozlov at oracle.com Fri Jul 16 09:58:05 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 16 Jul 2010 09:58:05 -0700 Subject: review request (M): 6912064: type profiles need to be more thorough for dynamic language support In-Reply-To: References: Message-ID: <4C408F9D.8010006@oracle.com> Actually it was not last mail, I replied: Vladimir Kozlov wrote: > I see, I missed that for instanceof case you just compare object's klass > with profiled klass and don't check that it is subtype of require_klass > (which is NULL for this case). Fine. About last changes. Why you not do 'stopped()' check after that call?: 2668 cast_obj = maybe_cast_profiled_receiver(not_null_obj, data, tk->klass()); Vladimir John Rose wrote: > I got a pre-review for 6912064 in January. These changes still work well; I just used them successfully with a performance tuning experiment. > > There was a corner case bug which required an additional 'stopped()' check in graphKit. Here's the update: > http://cr.openjdk.java.net/~jrose/6912064/webrev.02/ > > The four lines in this file starting "// Profile disagrees with this path." are new: > http://cr.openjdk.java.net/~jrose/6912064/webrev.02/src/share/vm/opto/graphKit.cpp.udiff.html > > That is the only difference from January. > > Any further comments on this change set? > > -- John > > FTR, here is the previous communication. (Yes, it's been a while.) > > From: John Rose > Date: January 26, 2010 7:14:13 PM PST > To: Vladimir Kozlov > Cc: Igor Veresov , hotspot-compiler-dev compiler > Subject: Re: for pre-review (M): 6912064: type profiles need to be more thorough for dynamic language support > > On Jan 26, 2010, at 6:59 PM, Vladimir Kozlov wrote: > >> Then why you generate the klass check with uncommon trap for instanceof >> for cases when profiling shows that it will fail? > > For code like this: > > if (x instanceof String) > doString((String) x); > else if (x instanceof Number) > doNumber((Number) x); > > If the 'x' is always an Integer, I want to fold all the tests up from the first instanceof, not the second. > > The profile will show when 'x' is of a monomorphic type. That is more interesting than whether the first check happens to go true or false. > > -- John > > From john.r.rose at oracle.com Fri Jul 16 11:56:36 2010 From: john.r.rose at oracle.com (John Rose) Date: Fri, 16 Jul 2010 11:56:36 -0700 Subject: review request (M): 6912064: type profiles need to be more thorough for dynamic language support In-Reply-To: <4C408F9D.8010006@oracle.com> References: <4C408F9D.8010006@oracle.com> Message-ID: <05989C3B-12EA-4608-B8EC-2BD91BA6D340@oracle.com> On Jul 16, 2010, at 9:58 AM, Vladimir Kozlov wrote: > About last changes. Why you not do 'stopped()' check after that call?: > > 2668 cast_obj = maybe_cast_profiled_receiver(not_null_obj, data, tk->klass()); Because the code (in gen_checkcast) works correctly in the case of dead control after the profile cast. When the obj_path control is dead, the null path might still be live, and the region/phi collect the right results in any case. Should I add a comment? (It's not the only way in which the two routines fail to be parallel, BTW.) Or, the other way to fix it might be to have load_object_klass and gen_subtype_check DTRT with dead control, and remove the explicit check in gen_instanceof. I took the path of least resistance. -- John From vladimir.kozlov at oracle.com Fri Jul 16 11:56:48 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 16 Jul 2010 11:56:48 -0700 Subject: review request (M): 6912064: type profiles need to be more thorough for dynamic language support In-Reply-To: <05989C3B-12EA-4608-B8EC-2BD91BA6D340@oracle.com> References: <4C408F9D.8010006@oracle.com> <05989C3B-12EA-4608-B8EC-2BD91BA6D340@oracle.com> Message-ID: <4C40AB70.2050201@oracle.com> OK. Vladimir John Rose wrote: > On Jul 16, 2010, at 9:58 AM, Vladimir Kozlov wrote: > >> About last changes. Why you not do 'stopped()' check after that call?: >> >> 2668 cast_obj = maybe_cast_profiled_receiver(not_null_obj, data, tk->klass()); > > Because the code (in gen_checkcast) works correctly in the case of dead control after the profile cast. When the obj_path control is dead, the null path might still be live, and the region/phi collect the right results in any case. > > Should I add a comment? (It's not the only way in which the two routines fail to be parallel, BTW.) > > Or, the other way to fix it might be to have load_object_klass and gen_subtype_check DTRT with dead control, and remove the explicit check in gen_instanceof. I took the path of least resistance. > > -- John > From tom.rodriguez at oracle.com Fri Jul 16 12:31:58 2010 From: tom.rodriguez at oracle.com (tom.rodriguez at oracle.com) Date: Fri, 16 Jul 2010 19:31:58 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 8 new changesets Message-ID: <20100716193213.6E04147A3C@hg.openjdk.java.net> Changeset: b2a00dd3117c Author: jcoomes Date: 2010-07-01 21:40 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/b2a00dd3117c 6957084: simplify TaskQueue overflow handling Reviewed-by: ysr, jmasa ! src/share/vm/gc_implementation/includeDB_gc_parallelScavenge ! src/share/vm/gc_implementation/parallelScavenge/psCompactionManager.cpp ! src/share/vm/gc_implementation/parallelScavenge/psCompactionManager.hpp ! src/share/vm/gc_implementation/parallelScavenge/psCompactionManager.inline.hpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.hpp ! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.cpp ! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.hpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp ! src/share/vm/utilities/taskqueue.cpp ! src/share/vm/utilities/taskqueue.hpp Changeset: 9ee05c8ab82f Author: ysr Date: 2010-07-12 12:53 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/9ee05c8ab82f Merge Changeset: bfc89697cccb Author: acorn Date: 2010-07-02 17:23 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/bfc89697cccb 6964164: MonitorInUseLists leak of contended objects Summary: fix MonitorInUseLists memory leak and MonitorBound now works Reviewed-by: chrisphi, dice ! src/share/vm/runtime/synchronizer.cpp ! src/share/vm/runtime/synchronizer.hpp ! src/share/vm/runtime/thread.hpp Changeset: 5087ecc10458 Author: acorn Date: 2010-07-07 14:12 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/5087ecc10458 Merge Changeset: 0e7d2a08b605 Author: mchung Date: 2010-07-07 15:35 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/0e7d2a08b605 6967423: Hotspot support for modules image Summary: Add hotspot support for modules image Reviewed-by: acorn ! make/linux/makefiles/sa.make ! make/solaris/makefiles/sa.make ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/share/vm/runtime/os.cpp Changeset: 1e7ec26380bd Author: apangin Date: 2010-07-14 17:52 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/1e7ec26380bd Merge Changeset: 61fdaf88f57f Author: never Date: 2010-07-15 13:48 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/61fdaf88f57f Merge - src/os/linux/vm/vtune_linux.cpp - src/os/solaris/vm/vtune_solaris.cpp - src/os/windows/vm/vtune_windows.cpp - src/share/vm/runtime/vtune.hpp Changeset: 01b172b8cd7c Author: never Date: 2010-07-16 08:29 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/01b172b8cd7c Merge From suncg03 at gmail.com Fri Jul 16 18:22:28 2010 From: suncg03 at gmail.com (ChenGuang Sun) Date: Fri, 16 Jul 2010 21:22:28 -0400 Subject: A tiny bug in jdk7-b87 Message-ID: Hi, I guess there is a tiny bug in MethodMatcher::match(symbolHandle candidate, symbolHandle match, Mode match_mode) Instead of: case Substring: return strstr(candidate_string, match_string) != NULL; I think it should be: case Substring: return strstr(match_string, candidate_string) != NULL; I'm not sure whether it has been fixed in later versions. Thanks, Chenguang From suncg03 at gmail.com Fri Jul 16 18:28:42 2010 From: suncg03 at gmail.com (ChenGuang Sun) Date: Fri, 16 Jul 2010 21:28:42 -0400 Subject: A tiny bug in jdk7-b87 In-Reply-To: References: Message-ID: Hi, Forget it. I'm sorry I misunderstood the meaning of the code. There is no bug there. Thanks, Chenguang On Fri, Jul 16, 2010 at 9:22 PM, ChenGuang Sun wrote: > Hi, > > ? I guess there is a tiny bug in MethodMatcher::match(symbolHandle > candidate, symbolHandle match, Mode match_mode) > > ? Instead of: > > ? ? ?case Substring: > ? ? ? ?return strstr(candidate_string, match_string) != NULL; > > ? I think it should be: > > ? ? ?case Substring: > ? ? ? ?return strstr(match_string, candidate_string) != NULL; > > ? I'm not sure whether it has been fixed in later versions. > > Thanks, > Chenguang > From john.r.rose at oracle.com Fri Jul 16 23:25:59 2010 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Sat, 17 Jul 2010 06:25:59 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6969574: invokedynamic call sites deoptimize instead of executing Message-ID: <20100717062609.DB5C947A68@hg.openjdk.java.net> Changeset: e0ba4e04c839 Author: jrose Date: 2010-07-16 18:14 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/e0ba4e04c839 6969574: invokedynamic call sites deoptimize instead of executing Reviewed-by: kvn ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/ci/ciMethod.cpp ! src/share/vm/oops/cpCacheOop.cpp ! src/share/vm/oops/cpCacheOop.hpp ! src/share/vm/oops/methodOop.cpp ! src/share/vm/prims/methodHandleWalk.cpp From christian.thalinger at oracle.com Wed Jul 21 02:23:52 2010 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 21 Jul 2010 11:23:52 +0200 Subject: # assert(!n->pinned() || n->is_SafePointScalarObject()) failed: only SafePointScalarObject pinned node is expected here Message-ID: <1279704233.16815.32.camel@macbook> http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/diff/523ded093c31/src/share/vm/opto/gcm.cpp Can you explain to me why the assert in PhaseCFG::replace_block_proj_ctrl checks for: !n->pinned() || n->is_SafePointScalarObject() I want to pin my new MachConstantBaseNode (which represents the base of the constant table) but I hit this assert. -- Christian From tom.rodriguez at oracle.com Wed Jul 21 11:14:27 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 21 Jul 2010 11:14:27 -0700 Subject: review (XS) for 6970566: runThese fails with SIGSEGV Message-ID: <3DD9EB60-8925-46FB-BACF-75A06236E1EE@oracle.com> http://cr.openjdk.java.net/~never/6970566 6970566: runThese fails with SIGSEGV Reviewed-by: In the fix for 6965184 I added some code to track the number of adapters in the code cache by calling CodeCache::commit after the AdapterBlob was created. The code was missing a null check in case the allocation failed and that would lead to crashes if the code cache filled up. Instead of adding a null check I moved it into the AdapterBlob constructor to mirror other calls to commit. I also deleted a dead constructor. From vladimir.kozlov at oracle.com Wed Jul 21 19:04:42 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 21 Jul 2010 19:04:42 -0700 Subject: review (XS) for 6970566: runThese fails with SIGSEGV In-Reply-To: <3DD9EB60-8925-46FB-BACF-75A06236E1EE@oracle.com> References: <3DD9EB60-8925-46FB-BACF-75A06236E1EE@oracle.com> Message-ID: <4C47A73A.8090906@oracle.com> Tom, You did not remove CodeCache::commit() from AdapterBlob::create(). Vladimir Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/6970566 > > 6970566: runThese fails with SIGSEGV > Reviewed-by: > > In the fix for 6965184 I added some code to track the number of > adapters in the code cache by calling CodeCache::commit after the > AdapterBlob was created. The code was missing a null check in case > the allocation failed and that would lead to crashes if the code cache > filled up. Instead of adding a null check I moved it into the > AdapterBlob constructor to mirror other calls to commit. I also > deleted a dead constructor. From vladimir.kozlov at oracle.com Wed Jul 21 19:24:29 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 21 Jul 2010 19:24:29 -0700 Subject: # assert(!n->pinned() || n->is_SafePointScalarObject()) failed: only SafePointScalarObject pinned node is expected here In-Reply-To: <1279704233.16815.32.camel@macbook> References: <1279704233.16815.32.camel@macbook> Message-ID: <4C47ABDD.4050303@oracle.com> Here what I said during this code review: "I looked which nodes are pinned and all of them are CFG nodes except Phi and SafePointScalarObject. The block projection control edge of CFG nodes will be replaced with new Region nodes during PhaseCFG::build_cfg() before GCM. And Phi node can not have block projection control - only Region. Which leaves only SafePointScalarObject node we need to patch. I can add additional assert to verify this:" Christian, why you need to pin it and why you need control edge for it (what dependancy it has with control graph)? Vladimir Christian Thalinger wrote: > http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/diff/523ded093c31/src/share/vm/opto/gcm.cpp > > Can you explain to me why the assert in > PhaseCFG::replace_block_proj_ctrl checks for: > > !n->pinned() || n->is_SafePointScalarObject() > > I want to pin my new MachConstantBaseNode (which represents the base of > the constant table) but I hit this assert. > > -- Christian > From christian.thalinger at oracle.com Thu Jul 22 08:17:46 2010 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 22 Jul 2010 17:17:46 +0200 Subject: # assert(!n->pinned() || n->is_SafePointScalarObject()) failed: only SafePointScalarObject pinned node is expected here In-Reply-To: <4C47ABDD.4050303@oracle.com> References: <1279704233.16815.32.camel@macbook> <4C47ABDD.4050303@oracle.com> Message-ID: <1279811866.7736.8.camel@macbook> On Wed, 2010-07-21 at 19:24 -0700, Vladimir Kozlov wrote: > Here what I said during this code review: > > "I looked which nodes are pinned and all of them are CFG nodes > except Phi and SafePointScalarObject. > The block projection control edge of CFG nodes will be replaced > with new Region nodes during PhaseCFG::build_cfg() before GCM. > And Phi node can not have block projection control - only Region. > Which leaves only SafePointScalarObject node we need to patch. > > I can add additional assert to verify this:" > > Christian, why you need to pin it and why you need control edge for it > (what dependancy it has with control graph)? MachConstantBaseNode is the node that represents the constant table base address and so should be at the beginning of the method. The control is C->root() and I thought it would be a good idea to pin it to this control. -- Christian From vladimir.kozlov at oracle.com Thu Jul 22 11:45:44 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 22 Jul 2010 11:45:44 -0700 Subject: # assert(!n->pinned() || n->is_SafePointScalarObject()) failed: only SafePointScalarObject pinned node is expected here In-Reply-To: <1279811866.7736.8.camel@macbook> References: <1279704233.16815.32.camel@macbook> <4C47ABDD.4050303@oracle.com> <1279811866.7736.8.camel@macbook> Message-ID: <4C4891D8.3080003@oracle.com> Christian Thalinger wrote: > On Wed, 2010-07-21 at 19:24 -0700, Vladimir Kozlov wrote: >> Christian, why you need to pin it and why you need control edge for it >> (what dependancy it has with control graph)? > > MachConstantBaseNode is the node that represents the constant table base > address and so should be at the beginning of the method. The control is > C->root() and I thought it would be a good idea to pin it to this > control. No, it is bad idea. If you place this node far away from usage you will introduce spillings for register which hold the value. From what I understand this node should behave as loadConP_poll node. Vladimir > > -- Christian > From tom.rodriguez at oracle.com Thu Jul 22 13:41:43 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 22 Jul 2010 13:41:43 -0700 Subject: review (XS) for 6970566: runThese fails with SIGSEGV In-Reply-To: <4C47A73A.8090906@oracle.com> References: <3DD9EB60-8925-46FB-BACF-75A06236E1EE@oracle.com> <4C47A73A.8090906@oracle.com> Message-ID: <973BAE4F-0394-486B-92FF-F00A632F6F85@oracle.com> Duh. I started the change elsewhere and moved to a different workspace but left that out. Thanks for catching this. I was able to reproduce the original crash so I couldn't easily test it. I've updated the webrev. tom On Jul 21, 2010, at 7:04 PM, Vladimir Kozlov wrote: > Tom, > > You did not remove CodeCache::commit() from AdapterBlob::create(). > > Vladimir > > Tom Rodriguez wrote: >> http://cr.openjdk.java.net/~never/6970566 >> 6970566: runThese fails with SIGSEGV >> Reviewed-by: >> In the fix for 6965184 I added some code to track the number of >> adapters in the code cache by calling CodeCache::commit after the >> AdapterBlob was created. The code was missing a null check in case >> the allocation failed and that would lead to crashes if the code cache >> filled up. Instead of adding a null check I moved it into the >> AdapterBlob constructor to mirror other calls to commit. I also >> deleted a dead constructor. From vladimir.kozlov at oracle.com Thu Jul 22 13:49:59 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 22 Jul 2010 13:49:59 -0700 Subject: review (XS) for 6970566: runThese fails with SIGSEGV In-Reply-To: <973BAE4F-0394-486B-92FF-F00A632F6F85@oracle.com> References: <3DD9EB60-8925-46FB-BACF-75A06236E1EE@oracle.com> <4C47A73A.8090906@oracle.com> <973BAE4F-0394-486B-92FF-F00A632F6F85@oracle.com> Message-ID: <4C48AEF7.4000701@oracle.com> Looks good. Vladimir Tom Rodriguez wrote: > Duh. I started the change elsewhere and moved to a different workspace but left that out. Thanks for catching this. I was able to reproduce the original crash so I couldn't easily test it. I've updated the webrev. > > tom > > On Jul 21, 2010, at 7:04 PM, Vladimir Kozlov wrote: > >> Tom, >> >> You did not remove CodeCache::commit() from AdapterBlob::create(). >> >> Vladimir >> >> Tom Rodriguez wrote: >>> http://cr.openjdk.java.net/~never/6970566 >>> 6970566: runThese fails with SIGSEGV >>> Reviewed-by: >>> In the fix for 6965184 I added some code to track the number of >>> adapters in the code cache by calling CodeCache::commit after the >>> AdapterBlob was created. The code was missing a null check in case >>> the allocation failed and that would lead to crashes if the code cache >>> filled up. Instead of adding a null check I moved it into the >>> AdapterBlob constructor to mirror other calls to commit. I also >>> deleted a dead constructor. > From john.coomes at oracle.com Thu Jul 22 21:13:32 2010 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 23 Jul 2010 04:13:32 +0000 Subject: hg: jdk7/hotspot-comp: 4 new changesets Message-ID: <20100723041332.4468447BBF@hg.openjdk.java.net> Changeset: 055626b50d2d Author: mikejwre Date: 2010-07-15 20:11 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/rev/055626b50d2d Added tag jdk7-b101 for changeset 4193eaf5f1b8 ! .hgtags Changeset: a191e79df156 Author: lana Date: 2010-06-29 10:48 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/rev/a191e79df156 Merge Changeset: 9cda7c220c08 Author: lana Date: 2010-07-12 19:35 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/rev/9cda7c220c08 Merge Changeset: a136a51f5113 Author: lana Date: 2010-07-20 22:17 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/rev/a136a51f5113 Merge From john.coomes at oracle.com Thu Jul 22 21:13:38 2010 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 23 Jul 2010 04:13:38 +0000 Subject: hg: jdk7/hotspot-comp/corba: 4 new changesets Message-ID: <20100723041343.47A4847BC0@hg.openjdk.java.net> Changeset: d130544adab3 Author: mikejwre Date: 2010-07-15 20:11 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/corba/rev/d130544adab3 Added tag jdk7-b101 for changeset 86a239832646 ! .hgtags Changeset: 03fd3d78e344 Author: lana Date: 2010-06-29 10:48 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/corba/rev/03fd3d78e344 Merge Changeset: 98da66f47273 Author: lana Date: 2010-07-12 19:35 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/corba/rev/98da66f47273 Merge Changeset: 78561a957790 Author: lana Date: 2010-07-20 22:17 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/corba/rev/78561a957790 Merge From john.coomes at oracle.com Thu Jul 22 21:17:43 2010 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 23 Jul 2010 04:17:43 +0000 Subject: hg: jdk7/hotspot-comp/jaxp: 5 new changesets Message-ID: <20100723041743.D7F9E47BC1@hg.openjdk.java.net> Changeset: c9bd73f6d584 Author: mikejwre Date: 2010-07-15 20:11 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxp/rev/c9bd73f6d584 Added tag jdk7-b101 for changeset 17f62a566a20 ! .hgtags Changeset: 34ed99f84832 Author: ohair Date: 2010-06-24 08:34 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxp/rev/34ed99f84832 6963941: Correct download link for source drop bundle Reviewed-by: darcy ! jaxp.properties Changeset: e46c304486c0 Author: lana Date: 2010-06-29 10:49 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxp/rev/e46c304486c0 Merge Changeset: 70c8a34e2eb6 Author: lana Date: 2010-07-12 19:37 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxp/rev/70c8a34e2eb6 Merge Changeset: 15573625af97 Author: lana Date: 2010-07-20 22:17 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxp/rev/15573625af97 Merge From john.coomes at oracle.com Thu Jul 22 21:17:49 2010 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 23 Jul 2010 04:17:49 +0000 Subject: hg: jdk7/hotspot-comp/jaxws: 4 new changesets Message-ID: <20100723041750.18D4E47BC2@hg.openjdk.java.net> Changeset: d1525c38428a Author: mikejwre Date: 2010-07-15 20:11 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxws/rev/d1525c38428a Added tag jdk7-b101 for changeset b55ce2744900 ! .hgtags Changeset: 2dd6394ddec2 Author: lana Date: 2010-06-29 10:49 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxws/rev/2dd6394ddec2 Merge Changeset: 2b7a1ec9562e Author: lana Date: 2010-07-12 19:37 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxws/rev/2b7a1ec9562e Merge Changeset: d8580443d181 Author: lana Date: 2010-07-20 22:17 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxws/rev/d8580443d181 Merge From john.coomes at oracle.com Thu Jul 22 21:19:49 2010 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 23 Jul 2010 04:19:49 +0000 Subject: hg: jdk7/hotspot-comp/jdk: 76 new changesets Message-ID: <20100723043215.A0AE547BC4@hg.openjdk.java.net> Changeset: 6c4450bbad6d Author: mikejwre Date: 2010-07-15 20:11 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/6c4450bbad6d Added tag jdk7-b101 for changeset d58354a69011 ! .hgtags Changeset: c801686d91f4 Author: prr Date: 2010-06-29 09:48 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/c801686d91f4 6943487: NPE in makeMultiCharsetString while printing on linux Reviewed-by: igor, jgodinez ! src/share/classes/sun/awt/PlatformFont.java ! src/share/classes/sun/java2d/HeadlessGraphicsEnvironment.java Changeset: 4da6837dd085 Author: lana Date: 2010-06-30 15:09 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/4da6837dd085 Merge Changeset: ab55cb957830 Author: igor Date: 2010-07-06 18:23 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/ab55cb957830 6967050: JDK build issues with cygwin/vc2010 Reviewed-by: prr, ohair ! make/common/shared/Defs-windows.gmk ! make/mkdemo/Makefile Changeset: e03065fc64e7 Author: igor Date: 2010-07-12 13:16 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/e03065fc64e7 6959998: Return of SurfaceData_InitOps point not checked in all cases (parfait found these) Reviewed-by: prr Contributed-by: ohair ! src/share/native/sun/awt/image/BufImgSurfaceData.c ! src/solaris/native/sun/java2d/opengl/GLXSurfaceData.c ! src/solaris/native/sun/java2d/x11/X11SurfaceData.c ! src/windows/native/sun/java2d/opengl/WGLSurfaceData.c ! src/windows/native/sun/java2d/windows/GDIWindowSurfaceData.cpp Changeset: 2ad69cb576b4 Author: igor Date: 2010-07-12 15:11 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/2ad69cb576b4 6968373: FontUtilities static initializer throws AccessControlException Reviewed-by: prr ! src/share/classes/sun/font/FontUtilities.java ! test/java/awt/FontClass/FontPrivilege.java Changeset: 4a639bcd3361 Author: lana Date: 2010-07-12 19:32 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/4a639bcd3361 Merge Changeset: f5145c7119c2 Author: yan Date: 2010-06-24 11:50 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/f5145c7119c2 6957166: With XAWT, set arguments properly creating a MouseWheelEvent. Summary: swap some parameters to allow bigger values for click count. Reviewed-by: dav ! src/solaris/classes/sun/awt/X11/XWindow.java Changeset: bccf2a4ee318 Author: art Date: 2010-07-06 17:59 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/bccf2a4ee318 6424157: java.awt.EventQueue push/pop might cause threading issues Reviewed-by: ant, dcherepanov ! src/share/classes/java/awt/EventDispatchThread.java ! src/share/classes/java/awt/EventQueue.java ! src/share/classes/sun/awt/SunToolkit.java ! test/java/awt/EventDispatchThread/HandleExceptionOnEDT/HandleExceptionOnEDT.java ! test/java/awt/EventDispatchThread/LoopRobustness/LoopRobustness.java + test/java/awt/EventDispatchThread/PreserveDispathThread/PreserveDispatchThread.java ! test/java/awt/EventQueue/PushPopDeadlock2/PushPopTest.java Changeset: 21b17c64df74 Author: dcherepanov Date: 2010-07-06 18:23 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/21b17c64df74 6966643: GTK FileDialog hangs when user manually closes it Reviewed-by: art ! src/solaris/native/sun/awt/sun_awt_X11_GtkFileDialogPeer.c Changeset: 9950dc616615 Author: dcherepanov Date: 2010-07-07 14:20 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/9950dc616615 6959174: Need to introduce sun.awt.disableGtkFileDialogs system property Reviewed-by: art, anthony ! src/share/classes/sun/awt/SunToolkit.java ! src/solaris/classes/sun/awt/X11/XToolkit.java Changeset: 48aa2a1edd2b Author: lana Date: 2010-07-08 11:28 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/48aa2a1edd2b Merge Changeset: 2d8f060dd1c5 Author: lana Date: 2010-07-12 19:33 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/2d8f060dd1c5 Merge Changeset: 69ddf06e616a Author: malenkov Date: 2010-06-22 12:06 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/69ddf06e616a 6707234: Method returned by Introspector.internalFindMethod not necessarily most specific Reviewed-by: peterz ! src/share/classes/com/sun/beans/finder/MethodFinder.java ! src/share/classes/java/beans/EventSetDescriptor.java ! src/share/classes/java/beans/IndexedPropertyDescriptor.java ! src/share/classes/java/beans/Introspector.java ! src/share/classes/java/beans/MethodDescriptor.java ! src/share/classes/java/beans/PropertyDescriptor.java + test/java/beans/Introspector/Test6707234.java Changeset: 5af3b0430bbe Author: peterz Date: 2010-06-22 14:36 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/5af3b0430bbe 6959260: javax/swing/JLabel/6501991/bug6501991.java failed on build 1.7.0-ea-b96 Reviewed-by: rupashka ! src/share/classes/sun/swing/SwingUtilities2.java ! test/ProblemList.txt ! test/com/sun/java/swing/plaf/gtk/Test6635110.java Changeset: dea63f6dda7a Author: alexp Date: 2010-06-22 19:38 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/dea63f6dda7a 6777378: NullPointerException in XPDefaultRenderer.paint() Reviewed-by: rupashka ! src/share/classes/javax/swing/plaf/basic/BasicTableHeaderUI.java + test/javax/swing/JTable/6777378/bug6777378.java Changeset: a05e047c5b98 Author: alexp Date: 2010-06-22 20:36 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/a05e047c5b98 6684401: JTree isExpanded should not call itself recursively Reviewed-by: rupashka ! src/share/classes/javax/swing/JTree.java Changeset: f1bafc4f249d Author: peterz Date: 2010-06-29 14:42 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/f1bafc4f249d 6963870: NPE in CompoundBorder.getInsets() Reviewed-by: alexp Contributed-by: jon.vanalten at redhat.com ! src/share/classes/com/sun/java/swing/plaf/gtk/GTKPainter.java + test/com/sun/java/swing/plaf/gtk/Test6963870.java Changeset: c0e785f055a7 Author: lana Date: 2010-06-30 19:05 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/c0e785f055a7 Merge ! test/ProblemList.txt Changeset: d062afbe2107 Author: malenkov Date: 2010-07-01 18:09 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/d062afbe2107 4129681: Cannot get a title border to display its label as disabled Reviewed-by: alexp, rupashka ! src/share/classes/javax/swing/border/TitledBorder.java + test/javax/swing/border/Test4129681.html + test/javax/swing/border/Test4129681.java + test/javax/swing/border/Test4760089.html + test/javax/swing/border/Test4760089.java Changeset: 46306a419ba3 Author: malenkov Date: 2010-07-01 18:47 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/46306a419ba3 6959266: test javax/swing/JInternalFrame/6725409/bug6725409.java should be modified Reviewed-by: alexp ! test/javax/swing/JInternalFrame/6725409/bug6725409.java Changeset: e94a94d176f9 Author: alexp Date: 2010-07-02 19:28 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/e94a94d176f9 6711682: JCheckBox in JTable: checkbox doesn't alaways respond to the first mouse click Reviewed-by: rupashka ! src/share/classes/javax/swing/plaf/basic/BasicButtonListener.java + test/javax/swing/AbstractButton/6711682/bug6711682.java Changeset: 46d5aef470a3 Author: alexp Date: 2010-07-02 19:34 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/46d5aef470a3 6937415: Some components return undocumented default values under Nimbus LaF Reviewed-by: peterz ! src/share/classes/javax/swing/JSplitPane.java ! src/share/classes/javax/swing/JTable.java ! src/share/classes/javax/swing/plaf/nimbus/skin.laf Changeset: e12c92d2dc11 Author: rupashka Date: 2010-07-08 19:09 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/e12c92d2dc11 6520101: FileChooser will cause OutOfMemory when application will run long time Reviewed-by: peterz ! src/share/classes/com/sun/java/swing/plaf/motif/MotifFileChooserUI.java + test/javax/swing/JFileChooser/6520101/bug6520101.java Changeset: d0bcc9aa5a7a Author: malenkov Date: 2010-07-09 19:42 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/d0bcc9aa5a7a 6894597: test/closed/javax/swing/JPopupMenu/6495920/bug6495920.java fails Reviewed-by: alexp, peterz + test/javax/swing/JPopupMenu/6495920/bug6495920.java Changeset: 3dc686ecb4cd Author: malenkov Date: 2010-07-09 22:07 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/3dc686ecb4cd 6963811: Deadlock-prone locking changes in Introspector Reviewed-by: peterz, rupashka ! src/share/classes/com/sun/beans/finder/InstanceFinder.java ! src/share/classes/com/sun/beans/finder/PersistenceDelegateFinder.java ! src/share/classes/com/sun/beans/finder/PropertyEditorFinder.java ! src/share/classes/java/beans/Encoder.java ! src/share/classes/java/beans/Introspector.java ! src/share/classes/java/beans/PropertyEditorManager.java + test/java/beans/Introspector/Test6963811.java + test/java/beans/PropertyEditor/Test6963811.java + test/java/beans/XMLEncoder/Test6963811.java Changeset: a93a7ed5018c Author: lana Date: 2010-07-12 19:35 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/a93a7ed5018c Merge Changeset: dd98b0b747ec Author: ohair Date: 2010-06-22 10:54 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/dd98b0b747ec 6931871: Rebranding of javadoc generation in makefiles 6951293: control docs target does not work on windows Reviewed-by: jjg + make/common/shared/Defs-javadoc.gmk ! make/docs/Makefile Changeset: d7fdaee81c14 Author: sherman Date: 2010-06-22 14:04 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/d7fdaee81c14 6963156: TEST_BUG: Several tests under sun/nio/cs failed Summary: Updated the test cases and removed them from ProblemList.txt Reviewed-by: alanb ! test/ProblemList.txt ! test/sun/nio/cs/FindDecoderBugs.java ! test/sun/nio/cs/TestX11CNS.java Changeset: 6fe3b86f4720 Author: sherman Date: 2010-06-22 14:22 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/6fe3b86f4720 Merge Changeset: 4e76be6e9fe1 Author: dcubed Date: 2010-06-22 10:54 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/4e76be6e9fe1 6942989: 2/2 Memory leak of java.lang.ref.WeakReference objects Summary: Use ReferenceQueues to manage WeakReferences in LogManager and Logger. Reviewed-by: dholmes, alanb, emcmanus, tonyp Contributed-by: jeremymanson at google.com ! src/share/classes/java/util/logging/LogManager.java ! src/share/classes/java/util/logging/Logger.java + test/java/util/logging/AnonLoggerWeakRefLeak.java + test/java/util/logging/AnonLoggerWeakRefLeak.sh + test/java/util/logging/LoggerWeakRefLeak.java + test/java/util/logging/LoggerWeakRefLeak.sh Changeset: 600ef8b4a211 Author: dcubed Date: 2010-06-22 16:18 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/600ef8b4a211 Merge Changeset: 25fe5c3bf7b7 Author: ohair Date: 2010-06-22 17:07 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/25fe5c3bf7b7 6939022: Source code adjustments for parfait compilation Reviewed-by: jjg ! src/solaris/demo/jni/Poller/Poller.c Changeset: 848e69fcf2f3 Author: ohair Date: 2010-06-22 17:26 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/848e69fcf2f3 6933622: Duplicate class files in rt.jar and charsets.jar 6895003: JarReorder is not excluding a requested file. Reviewed-by: jjg ! make/common/Release.gmk ! make/tools/src/build/tools/jarreorder/JarReorder.java ! test/ProblemList.txt Changeset: 3c745249065f Author: ohair Date: 2010-06-22 19:18 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/3c745249065f Merge Changeset: 887e525597f8 Author: dsamersoff Date: 2010-06-23 17:25 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/887e525597f8 6931566: NetworkInterface is not working when interface name is more than 15 characters long Summary: Separate Linux and Solaris code, use lifreq under Solaris Reviewed-by: chegar ! src/solaris/native/java/net/NetworkInterface.c Changeset: eb84b89ef3ff Author: alanb Date: 2010-06-23 20:19 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/eb84b89ef3ff 6963027: TEST_BUG: channels and buffer tests need to run in samevm mode Reviewed-by: ohair, sherman, chegar ! test/Makefile ! test/ProblemList.txt ! test/java/nio/BufferPoolMXBean/Basic.java ! test/java/nio/MappedByteBuffer/Basic.java ! test/java/nio/MappedByteBuffer/Force.java ! test/java/nio/MappedByteBuffer/ZeroMap.java ! test/java/nio/channels/AsynchronousChannelGroup/GroupOfOne.java ! test/java/nio/channels/AsynchronousChannelGroup/Identity.java ! test/java/nio/channels/AsynchronousDatagramChannel/Basic.java ! test/java/nio/channels/AsynchronousFileChannel/Basic.java ! test/java/nio/channels/AsynchronousFileChannel/Lock.java ! test/java/nio/channels/AsynchronousFileChannel/LotsOfWrites.java ! test/java/nio/channels/AsynchronousSocketChannel/Basic.java ! test/java/nio/channels/Channels/Basic2.java ! test/java/nio/channels/Channels/Write.java ! test/java/nio/channels/DatagramChannel/AdaptDatagramSocket.java ! test/java/nio/channels/DatagramChannel/EmptyBuffer.java ! test/java/nio/channels/DatagramChannel/ReceiveISA.java ! test/java/nio/channels/DatagramChannel/SelectWhenRefused.java ! test/java/nio/channels/FileChannel/Args.java ! test/java/nio/channels/FileChannel/ClosedChannelTransfer.java ! test/java/nio/channels/FileChannel/ExpandingMap.java ! test/java/nio/channels/FileChannel/Lock.java ! test/java/nio/channels/FileChannel/MapOverEnd.java ! test/java/nio/channels/FileChannel/MapReadOnly.java ! test/java/nio/channels/FileChannel/MapTest.java ! test/java/nio/channels/FileChannel/Mode.java ! test/java/nio/channels/FileChannel/Position.java ! test/java/nio/channels/FileChannel/Pread.java ! test/java/nio/channels/FileChannel/Pwrite.java ! test/java/nio/channels/FileChannel/Read.java ! test/java/nio/channels/FileChannel/ReadFull.java ! test/java/nio/channels/FileChannel/ReadToLimit.java ! test/java/nio/channels/FileChannel/ReleaseOnCloseDeadlock.java ! test/java/nio/channels/FileChannel/ScatteringRead.java ! test/java/nio/channels/FileChannel/Size.java ! test/java/nio/channels/FileChannel/Transfer.java ! test/java/nio/channels/FileChannel/TransferToChannel.java ! test/java/nio/channels/FileChannel/TransferToNonWritable.java ! test/java/nio/channels/FileChannel/Transfers.java ! test/java/nio/channels/FileChannel/TryLock.java ! test/java/nio/channels/FileChannel/Write.java ! test/java/nio/channels/Pipe/NonBlocking.java ! test/java/nio/channels/Pipe/SelectPipe.java ! test/java/nio/channels/SelectionKey/AtomicAttachTest.java ! test/java/nio/channels/Selector/BasicAccept.java ! test/java/nio/channels/Selector/BasicConnect.java ! test/java/nio/channels/Selector/CheckLocking.java ! test/java/nio/channels/Selector/CloseInvalidatesKeys.java ! test/java/nio/channels/Selector/CloseWhenKeyIdle.java ! test/java/nio/channels/Selector/Connect.java ! test/java/nio/channels/Selector/ConnectWrite.java ! test/java/nio/channels/Selector/HelperSlowToDie.java ! test/java/nio/channels/Selector/KeysReady.java ! test/java/nio/channels/Selector/LotsOfChannels.java ! test/java/nio/channels/Selector/RegAfterPreClose.java ! test/java/nio/channels/Selector/SelectAndCancel.java ! test/java/nio/channels/Selector/SelectorLimit.java ! test/java/nio/channels/Selector/SelectorTest.java ! test/java/nio/channels/Selector/WakeupNow.java ! test/java/nio/channels/Selector/WakeupOverflow.java ! test/java/nio/channels/Selector/WakeupSpeed.java - test/java/nio/channels/ServerSocketChannel/AcceptAddress.java ! test/java/nio/channels/SocketChannel/AdaptSocket.java ! test/java/nio/channels/SocketChannel/Bind.java ! test/java/nio/channels/SocketChannel/Close.java ! test/java/nio/channels/SocketChannel/CloseRegisteredChannel.java ! test/java/nio/channels/SocketChannel/CloseTimeoutChannel.java ! test/java/nio/channels/SocketChannel/IsConnectable.java ! test/java/nio/channels/SocketChannel/LocalAddress.java ! test/java/nio/channels/SocketChannel/SocketInheritance.java ! test/java/nio/channels/SocketChannel/Trivial.java ! test/java/nio/channels/SocketChannel/UnboundSocketTests.java ! test/java/nio/channels/etc/Shadow.java ! test/java/nio/channels/spi/SelectorProvider/inheritedChannel/ClosedStreams.java ! test/sun/nio/ch/Basic.java ! test/sun/nio/ch/TempBuffer.java ! test/sun/nio/cs/ReadZero.java ! test/sun/nio/cs/Test4206507.java ! test/sun/nio/cs/TestStringCoding.java Changeset: 55aa27b8bb98 Author: alanb Date: 2010-06-23 21:22 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/55aa27b8bb98 Merge Changeset: c4d60bcce958 Author: darcy Date: 2010-06-23 17:03 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/c4d60bcce958 6911258: Project Coin: Add essential API support for Automatic Resource Management (ARM) blocks 6911261: Project Coin: Retrofit Automatic Resource Management (ARM) support onto platform APIs 6962571: Infinite loop in printing out Throwable stack traces with circular references Reviewed-by: darcy, alanb Contributed-by: jjb at google.com ! make/java/java/FILES_java.gmk ! src/share/classes/java/io/Closeable.java + src/share/classes/java/lang/AutoCloseable.java ! src/share/classes/java/lang/Throwable.java ! src/share/classes/java/nio/channels/FileLock.java ! src/share/classes/javax/imageio/stream/ImageInputStream.java + test/java/lang/Throwable/SuppressedExceptions.java Changeset: 706e2d1fc378 Author: weijun Date: 2010-06-24 14:26 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/706e2d1fc378 6958026: Problem with PKCS12 keystore Reviewed-by: mullan ! src/share/classes/sun/security/pkcs12/PKCS12KeyStore.java + test/sun/security/pkcs12/PKCS12SameKeyId.java Changeset: 1da7dfca3e20 Author: weijun Date: 2010-06-24 14:26 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/1da7dfca3e20 6844907: krb5 etype order should be from strong to weak Reviewed-by: valeriep ! src/share/classes/sun/security/krb5/Credentials.java ! src/share/classes/sun/security/krb5/internal/crypto/EType.java ! src/share/classes/sun/security/krb5/internal/ktab/KeyTab.java + test/sun/security/krb5/etype/ETypeOrder.java ! test/sun/security/krb5/ktab/HighestKvno.java Changeset: 9c0f542c8b37 Author: weijun Date: 2010-06-24 14:26 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/9c0f542c8b37 6946669: SSL/Krb5 should not call EncryptedData.reset(data, false) Reviewed-by: xuelei ! src/share/classes/sun/security/krb5/EncryptedData.java ! src/share/classes/sun/security/krb5/KrbApRep.java ! src/share/classes/sun/security/krb5/KrbApReq.java ! src/share/classes/sun/security/krb5/KrbAsRep.java ! src/share/classes/sun/security/krb5/KrbCred.java ! src/share/classes/sun/security/krb5/KrbPriv.java ! src/share/classes/sun/security/krb5/KrbTgsRep.java ! src/share/classes/sun/security/ssl/krb5/KerberosClientKeyExchangeImpl.java ! src/share/classes/sun/security/ssl/krb5/KerberosPreMasterSecret.java ! test/sun/security/krb5/auto/SSL.java Changeset: 2e9ef9a80d82 Author: ohair Date: 2010-06-25 08:44 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/2e9ef9a80d82 6964311: Build regression due to rt.jar contents change Summary: The fix for 6933622 regressed control builds, this is a workaround fix, filed 6964313 to find the right answer to why it happened and how to fix it correctly. Reviewed-by: alanb, darcy ! make/common/Release.gmk Changeset: 6bf403a14da4 Author: alanb Date: 2010-06-25 18:31 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/6bf403a14da4 6963828: TEST_BUG: java/nio/channels/FileTransfer.java takes too long (win) Reviewed-by: chegar ! test/java/nio/channels/FileChannel/Transfer.java Changeset: 0995c5a2dc6d Author: alanb Date: 2010-06-25 18:34 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/0995c5a2dc6d Merge Changeset: 6d274503d1b7 Author: chegar Date: 2010-06-28 14:55 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/6d274503d1b7 6954525: Testcase failure java/net/Authenticator/B4769350.java Reviewed-by: michaelm, weijun ! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java ! test/java/net/Authenticator/B4769350.java Changeset: a89f8c292a5b Author: chegar Date: 2010-06-28 15:06 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/a89f8c292a5b Merge Changeset: 7c3da1f0e17c Author: chegar Date: 2010-06-28 20:52 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/7c3da1f0e17c 6961029: java/net/BindException/Test.java should not use wildcard address Reviewed-by: michaelm, alanb ! test/ProblemList.txt ! test/java/net/BindException/Test.java ! test/java/net/ipv6tests/Tests.java Changeset: a9e0a6fb6057 Author: ksrini Date: 2010-06-28 18:25 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/a9e0a6fb6057 6856415: Enabling java security manager will make programe thrown wrong exception ( main method not found ) Reviewed-by: darcy ! src/share/classes/sun/launcher/LauncherHelper.java + test/tools/launcher/VerifyExceptions.java Changeset: 5c5fe62d990d Author: alanb Date: 2010-06-29 17:11 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/5c5fe62d990d 6213702: (so) non-blocking sockets with TCP urgent disabled get still selected for read ops (win) Reviewed-by: michaelm, chegar ! src/windows/classes/sun/nio/ch/WindowsSelectorImpl.java ! src/windows/native/sun/nio/ch/WindowsSelectorImpl.c + test/java/nio/channels/Selector/OutOfBand.java Changeset: b318df97820f Author: lana Date: 2010-06-29 10:50 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/b318df97820f Merge Changeset: 4436a3e97a9b Author: martin Date: 2010-06-30 16:11 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/4436a3e97a9b 6934268: Better implementation of Character.isValidCodePoint Summary: Use the cleverest possible bit-twiddling micro-optimizations Reviewed-by: sherman Contributed-by: Ulf Zibis ! src/share/classes/java/lang/Character.java Changeset: 1776791f4fb9 Author: martin Date: 2010-06-30 16:11 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/1776791f4fb9 6934265: Add public method Character.isBmpCodePoint Summary: Move isBmpCodePoint from sun.nio.cs.Surrogate to Character Reviewed-by: sherman Contributed-by: Ulf Zibis ! src/share/classes/java/lang/AbstractStringBuilder.java ! src/share/classes/java/lang/Character.java ! src/share/classes/java/lang/String.java ! src/share/classes/sun/io/CharToByteDBCS_ASCII.java ! src/share/classes/sun/io/CharToByteDBCS_EBCDIC.java ! src/share/classes/sun/nio/cs/Surrogate.java ! src/share/classes/sun/nio/cs/UTF_32Coder.java ! src/share/classes/sun/nio/cs/UTF_8.java ! src/share/classes/sun/nio/cs/ext/EUC_TW.java ! src/share/classes/sun/nio/cs/ext/GB18030.java ! src/share/classes/sun/nio/cs/ext/IBM33722.java ! src/share/classes/sun/nio/cs/ext/IBM964.java ! test/java/nio/charset/coders/BashStreams.java - test/java/nio/charset/coders/Surrogate.java ! test/java/nio/charset/coders/Surrogates.java Changeset: 5503dbb2e6cc Author: martin Date: 2010-06-30 16:11 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/5503dbb2e6cc 6937112: String.lastIndexOf confused by unpaired trailing surrogate Summary: Rewrite lastIndexOf for performance and correctness Reviewed-by: sherman Contributed-by: Reviewed by Ulf Zibis ! src/share/classes/java/lang/String.java ! test/java/lang/String/Supplementary.java ! test/java/lang/StringBuffer/Supplementary.java ! test/java/lang/StringBuilder/Supplementary.java Changeset: 5e9daa8fd04a Author: martin Date: 2010-06-30 16:11 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/5e9daa8fd04a 6940381: Wording improvements for String.indexOf, String.lastIndexOf Summary: Make wording of javadoc clearer and more consistent Reviewed-by: sherman ! src/share/classes/java/lang/String.java Changeset: 0d2bff3b2ca6 Author: martin Date: 2010-06-30 16:11 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/0d2bff3b2ca6 6963749: Minor improvements to Character.UnicodeBlock Summary: Fix surrogate area docs; make source more readable Reviewed-by: okutsu, sherman Contributed-by: Ulf Zibis ! src/share/classes/java/lang/Character.java Changeset: 4f1b4e3c6d1b Author: martin Date: 2010-06-30 16:11 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/4f1b4e3c6d1b 6934270: Remove javac warnings from Character.java Summary: Use generics and conform to coding style Reviewed-by: sherman Contributed-by: Ulf Zibis ! src/share/classes/java/lang/Character.java Changeset: 98186c162c1e Author: martin Date: 2010-06-30 16:11 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/98186c162c1e 6933322: Add methods highSurrogate(), lowSurrogate() to class Character Summary: Add public variants of methods Surrogate.high, Surrogate.low Reviewed-by: okutsu, sherman Contributed-by: Ulf Zibis ! src/share/classes/java/lang/Character.java ! src/share/classes/java/lang/String.java ! src/share/classes/sun/nio/cs/Surrogate.java ! src/share/classes/sun/nio/cs/UTF_32Coder.java ! src/share/classes/sun/nio/cs/UTF_8.java ! src/share/classes/sun/nio/cs/UnicodeEncoder.java ! src/share/classes/sun/nio/cs/ext/EUC_TW.java ! test/java/nio/charset/coders/BashStreams.java Changeset: 838a21b99591 Author: martin Date: 2010-06-30 16:11 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/838a21b99591 6934271: Better handling of longer utf-8 sequences Summary: Various cleanups, including clever bit-twiddling Reviewed-by: sherman ! src/share/classes/sun/nio/cs/UTF_8.java Changeset: 9c80da212eaf Author: martin Date: 2010-06-30 16:11 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/9c80da212eaf 6935172: Optimize bit-twiddling in Bits.java Summary: Transformations to reduce size of bytecode Reviewed-by: sherman Contributed-by: Based on an idea by Ulf Zibis ! src/share/classes/java/io/Bits.java Changeset: ce0ba8da0bd1 Author: martin Date: 2010-06-30 16:11 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/ce0ba8da0bd1 6940258: (bf) Use intrinsified reverseBytes operation; elide no-op constructs Reviewed-by: alanb, sherman Contributed-by: Ulf Zibis ! src/share/classes/java/nio/Bits.java Changeset: a5a34c696d62 Author: alanb Date: 2010-07-01 16:28 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/a5a34c696d62 6947216: Even more Dual-pivot quicksort improvements Reviewed-by: jjb Contributed-by: vladimir.yaroslavskiy at sun.com ! src/share/classes/java/util/DualPivotQuicksort.java ! test/java/util/Arrays/Sorting.java Changeset: 9bffc32b645d Author: mullan Date: 2010-07-01 15:20 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/9bffc32b645d 6782979: Add JNLPAppletLauncher (6618105) to blacklist Reviewed-by: ohair ! make/java/security/Makefile Changeset: c0d2a097eb99 Author: mullan Date: 2010-07-01 15:30 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/c0d2a097eb99 Merge Changeset: 425960cef714 Author: darcy Date: 2010-07-06 18:58 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/425960cef714 6963723: Project Coin: Retrofit more JDK classes for ARM Reviewed-by: alanb, malenkov, prr, amenkov ! src/share/classes/java/beans/XMLDecoder.java ! src/share/classes/java/beans/XMLEncoder.java ! src/share/classes/java/io/ObjectInput.java ! src/share/classes/java/io/ObjectOutput.java ! src/share/classes/java/util/Scanner.java ! src/share/classes/javax/sound/midi/MidiDevice.java ! src/share/classes/javax/sound/midi/Receiver.java ! src/share/classes/javax/sound/midi/Transmitter.java ! src/share/classes/javax/sound/sampled/Line.java Changeset: d6f8ffc3c54a Author: ohair Date: 2010-07-07 10:17 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/d6f8ffc3c54a 6954517: Testcase failure tools/launcher/UnicodeTest.sh Reviewed-by: ksrini ! test/tools/launcher/UnicodeTest.sh Changeset: f13e94562d84 Author: ksrini Date: 2010-07-09 09:54 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/f13e94562d84 6930056: (launcher) Need to remove or build as part of test these liblibrary.so files Reviewed-by: ohair, darcy - test/tools/launcher/Makefile.SolarisRunpath - test/tools/launcher/lib/i386/lib32/lib32/liblibrary.so - test/tools/launcher/lib/i386/lib32/liblibrary.so - test/tools/launcher/lib/sparc/lib32/lib32/liblibrary.so - test/tools/launcher/lib/sparc/lib32/liblibrary.so - test/tools/launcher/lib/sparc/lib64/lib64/liblibrary.so - test/tools/launcher/lib/sparc/lib64/liblibrary.so Changeset: da8526047e5f Author: martin Date: 2010-07-09 18:55 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/da8526047e5f 6967533: Epoch bug: ExceptionInInitializerError on systems with uninitialized clock Summary: Remove (hopefully!) unnecessary check of currentTimeMillis Reviewed-by: dholmes Contributed-by: Jon VanAlten ! src/share/classes/java/lang/System.java Changeset: a7f8f269f741 Author: chegar Date: 2010-07-12 18:13 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/a7f8f269f741 6967937: Scope id no longer being set after 6931566 Reviewed-by: alanb, dsamersoff ! src/solaris/native/java/net/NetworkInterface.c ! test/java/net/Inet6Address/B6214234.java Changeset: 1371a2d5f3a8 Author: chegar Date: 2010-07-12 18:16 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/1371a2d5f3a8 6967684: httpserver using a non thread-safe SimpleDateFormat Reviewed-by: michaelm ! src/share/classes/sun/net/httpserver/ExchangeImpl.java Changeset: bb0b32ffefe9 Author: chegar Date: 2010-07-12 18:18 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/bb0b32ffefe9 6966846: Incorrect assertion in java.net.Inet6Address.readObject Reviewed-by: michaelm ! src/share/classes/java/net/Inet6Address.java Changeset: d3fa95d0710c Author: ksrini Date: 2010-07-09 11:04 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/d3fa95d0710c 6921472: RFE: java launcher code needs clean up Summary: This changeset also contains fixes for 6405284, 6753938 and 6922500 Reviewed-by: darcy ! src/share/bin/emessages.h ! src/share/bin/java.c ! src/share/bin/java.h ! src/share/bin/jli_util.c ! src/share/bin/jli_util.h ! src/solaris/bin/java_md.c ! src/windows/bin/java_md.c ! test/tools/launcher/Arrrghs.java Changeset: ddf825161d2d Author: dcubed Date: 2010-07-12 14:19 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/ddf825161d2d 6968401: 3/3 disable tests added by 6942989 until 6964018 is fixed Summary: Disable AnonLoggerWeakRefLeak.sh and LoggerWeakRefLeak.sh Reviewed-by: ohair ! test/java/util/logging/AnonLoggerWeakRefLeak.sh ! test/java/util/logging/LoggerWeakRefLeak.sh Changeset: 4e365ef6576d Author: dcubed Date: 2010-07-12 15:52 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/4e365ef6576d Merge Changeset: c5a436f053aa Author: lana Date: 2010-07-12 19:42 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/c5a436f053aa Merge ! test/ProblemList.txt - test/java/nio/channels/ServerSocketChannel/AcceptAddress.java - test/java/nio/charset/coders/Surrogate.java - test/tools/launcher/Makefile.SolarisRunpath - test/tools/launcher/lib/i386/lib32/lib32/liblibrary.so - test/tools/launcher/lib/i386/lib32/liblibrary.so - test/tools/launcher/lib/sparc/lib32/lib32/liblibrary.so - test/tools/launcher/lib/sparc/lib32/liblibrary.so - test/tools/launcher/lib/sparc/lib64/lib64/liblibrary.so - test/tools/launcher/lib/sparc/lib64/liblibrary.so Changeset: 13029a61b16b Author: lana Date: 2010-07-20 22:21 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/13029a61b16b Merge - test/java/nio/channels/ServerSocketChannel/AcceptAddress.java - test/java/nio/charset/coders/Surrogate.java - test/tools/launcher/Makefile.SolarisRunpath - test/tools/launcher/lib/i386/lib32/lib32/liblibrary.so - test/tools/launcher/lib/i386/lib32/liblibrary.so - test/tools/launcher/lib/sparc/lib32/lib32/liblibrary.so - test/tools/launcher/lib/sparc/lib32/liblibrary.so - test/tools/launcher/lib/sparc/lib64/lib64/liblibrary.so - test/tools/launcher/lib/sparc/lib64/liblibrary.so From john.coomes at oracle.com Thu Jul 22 21:45:16 2010 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 23 Jul 2010 04:45:16 +0000 Subject: hg: jdk7/hotspot-comp/langtools: 8 new changesets Message-ID: <20100723044534.451F047BC5@hg.openjdk.java.net> Changeset: f87f1f3e23e1 Author: mikejwre Date: 2010-07-15 20:11 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/f87f1f3e23e1 Added tag jdk7-b101 for changeset 20a8fe72ee7b ! .hgtags Changeset: be5cafeb318d Author: darcy Date: 2010-06-23 16:51 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/be5cafeb318d 6911258: Project Coin: Add essential API support for Automatic Resource Management (ARM) blocks Reviewed-by: darcy, alanb Contributed-by: jjb at google.com ! src/share/classes/javax/lang/model/element/ElementKind.java Changeset: d8a15fda7e3a Author: jjg Date: 2010-06-24 10:34 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/d8a15fda7e3a 6917288: Unnamed nested class is not generated Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/comp/Lower.java + test/tools/javac/6917288/GraphicalInstaller.java + test/tools/javac/6917288/GraphicalInstallerTest.java + test/tools/javac/6917288/T6917288.java Changeset: 6386f0fd6205 Author: lana Date: 2010-06-29 12:06 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/6386f0fd6205 Merge ! src/share/classes/com/sun/tools/javac/code/Flags.java ! src/share/classes/com/sun/tools/javac/code/Source.java ! src/share/classes/com/sun/tools/javac/code/Symtab.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java ! src/share/classes/com/sun/tools/javac/jvm/Gen.java ! src/share/classes/com/sun/tools/javac/main/Main.java ! src/share/classes/com/sun/tools/javac/util/Names.java Changeset: d2b7ecf33b35 Author: jjg Date: 2010-06-30 18:06 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/d2b7ecf33b35 6964768: need test program to validate javac resource bundles Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/code/Kinds.java ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/share/classes/com/sun/tools/javac/parser/Scanner.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties + test/tools/javac/diags/CheckResourceKeys.java ! test/tools/javac/literals/BadUnderscoreLiterals.6.out Changeset: 064468702a8d Author: jjg Date: 2010-07-12 16:37 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/064468702a8d 6968497: localized text appears in raw diagnostic Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/comp/Check.java ! test/tools/javac/generics/6946618/T6946618c.java ! test/tools/javac/generics/6946618/T6946618c.out Changeset: eaab979c8b36 Author: lana Date: 2010-07-12 19:43 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/eaab979c8b36 Merge Changeset: ff9c0a0bf7ed Author: lana Date: 2010-07-20 22:22 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/ff9c0a0bf7ed Merge From tom.rodriguez at oracle.com Fri Jul 23 05:32:41 2010 From: tom.rodriguez at oracle.com (tom.rodriguez at oracle.com) Date: Fri, 23 Jul 2010 12:32:41 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6970566: runThese fails with SIGSEGV Message-ID: <20100723123250.BF9FB47BE3@hg.openjdk.java.net> Changeset: 7139e81efd2d Author: never Date: 2010-07-22 15:29 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/7139e81efd2d 6970566: runThese fails with SIGSEGV Reviewed-by: kvn ! src/share/vm/code/codeBlob.cpp ! src/share/vm/code/codeBlob.hpp From vladimir.kozlov at oracle.com Fri Jul 23 09:51:49 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 23 Jul 2010 09:51:49 -0700 Subject: Request for reviews (XS): 6969569: assert(is_static() && is_constant()) failed: illegal call to constant_value() Message-ID: <4C49C8A5.602@oracle.com> The evaluation and suggested fix were done by John. http://cr.openjdk.java.net/~kvn/6969569/webrev Fixed 6969569: assert(is_static() && is_constant()) failed: illegal call to constant_value() All callers of ciField::constant_value must be guarded by both is_constant and is_static. For non-static fields, the correct accessor is ciField::constant_value_of. PhaseMacroExpand::scalar_replacement() and ciField::print() have a missing is_static guard. Solution: Add missing is_static guard. Tested with failed case and JPRT. From christian.thalinger at oracle.com Fri Jul 23 10:05:47 2010 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 23 Jul 2010 19:05:47 +0200 Subject: Request for reviews (XS): 6969569: assert(is_static() && is_constant()) failed: illegal call to constant_value() In-Reply-To: <4C49C8A5.602@oracle.com> References: <4C49C8A5.602@oracle.com> Message-ID: <1279904747.15688.146.camel@macbook> On Fri, 2010-07-23 at 09:51 -0700, Vladimir Kozlov wrote: > The evaluation and suggested fix were done by John. > > http://cr.openjdk.java.net/~kvn/6969569/webrev > > Fixed 6969569: assert(is_static() && is_constant()) failed: illegal call to constant_value() > > All callers of ciField::constant_value must be guarded by > both is_constant and is_static. For non-static fields, > the correct accessor is ciField::constant_value_of. > > PhaseMacroExpand::scalar_replacement() and ciField::print() > have a missing is_static guard. > > Solution: > Add missing is_static guard. > > Tested with failed case and JPRT. I wrote parts of this code. Looks good. -- Christian From vladimir.kozlov at oracle.com Fri Jul 23 10:05:02 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 23 Jul 2010 10:05:02 -0700 Subject: Request for reviews (XS): 6969569: assert(is_static() && is_constant()) failed: illegal call to constant_value() In-Reply-To: <1279904747.15688.146.camel@macbook> References: <4C49C8A5.602@oracle.com> <1279904747.15688.146.camel@macbook> Message-ID: <4C49CBBE.9020301@oracle.com> Thank you, Christian Vladimir Christian Thalinger wrote: > On Fri, 2010-07-23 at 09:51 -0700, Vladimir Kozlov wrote: >> The evaluation and suggested fix were done by John. >> >> http://cr.openjdk.java.net/~kvn/6969569/webrev >> >> Fixed 6969569: assert(is_static() && is_constant()) failed: illegal call to constant_value() >> >> All callers of ciField::constant_value must be guarded by >> both is_constant and is_static. For non-static fields, >> the correct accessor is ciField::constant_value_of. >> >> PhaseMacroExpand::scalar_replacement() and ciField::print() >> have a missing is_static guard. >> >> Solution: >> Add missing is_static guard. >> >> Tested with failed case and JPRT. > > I wrote parts of this code. Looks good. -- Christian > From tom.rodriguez at oracle.com Fri Jul 23 10:19:37 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Fri, 23 Jul 2010 10:19:37 -0700 Subject: Request for reviews (XS): 6969569: assert(is_static() && is_constant()) failed: illegal call to constant_value() In-Reply-To: <4C49C8A5.602@oracle.com> References: <4C49C8A5.602@oracle.com> Message-ID: <7F90CE69-FC20-4543-AE85-2DA84C439833@oracle.com> Looks good. tom On Jul 23, 2010, at 9:51 AM, Vladimir Kozlov wrote: > The evaluation and suggested fix were done by John. > > http://cr.openjdk.java.net/~kvn/6969569/webrev > > Fixed 6969569: assert(is_static() && is_constant()) failed: illegal call to constant_value() > > All callers of ciField::constant_value must be guarded by > both is_constant and is_static. For non-static fields, > the correct accessor is ciField::constant_value_of. > > PhaseMacroExpand::scalar_replacement() and ciField::print() > have a missing is_static guard. > > Solution: > Add missing is_static guard. > > Tested with failed case and JPRT. From vladimir.kozlov at oracle.com Fri Jul 23 10:21:56 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 23 Jul 2010 10:21:56 -0700 Subject: Request for reviews (XS): 6969569: assert(is_static() && is_constant()) failed: illegal call to constant_value() In-Reply-To: <7F90CE69-FC20-4543-AE85-2DA84C439833@oracle.com> References: <4C49C8A5.602@oracle.com> <7F90CE69-FC20-4543-AE85-2DA84C439833@oracle.com> Message-ID: <4C49CFB4.40909@oracle.com> Thank you, Tom Vladimir Tom Rodriguez wrote: > Looks good. > > tom > > On Jul 23, 2010, at 9:51 AM, Vladimir Kozlov wrote: > >> The evaluation and suggested fix were done by John. >> >> http://cr.openjdk.java.net/~kvn/6969569/webrev >> >> Fixed 6969569: assert(is_static() && is_constant()) failed: illegal call to constant_value() >> >> All callers of ciField::constant_value must be guarded by >> both is_constant and is_static. For non-static fields, >> the correct accessor is ciField::constant_value_of. >> >> PhaseMacroExpand::scalar_replacement() and ciField::print() >> have a missing is_static guard. >> >> Solution: >> Add missing is_static guard. >> >> Tested with failed case and JPRT. > From vladimir.kozlov at oracle.com Fri Jul 23 12:22:53 2010 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Fri, 23 Jul 2010 19:22:53 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6969569: assert(is_static() && is_constant()) failed: illegal call to constant_value() Message-ID: <20100723192255.9758D47BFD@hg.openjdk.java.net> Changeset: e5dfb3ccb88b Author: kvn Date: 2010-07-23 10:07 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/e5dfb3ccb88b 6969569: assert(is_static() && is_constant()) failed: illegal call to constant_value() Summary: Add missing is_static guard. Reviewed-by: twisti ! src/share/vm/ci/ciField.cpp ! src/share/vm/opto/macro.cpp From tom.rodriguez at oracle.com Mon Jul 26 18:16:25 2010 From: tom.rodriguez at oracle.com (tom.rodriguez at oracle.com) Date: Tue, 27 Jul 2010 01:16:25 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 35 new changesets Message-ID: <20100727011724.6FD0347CB1@hg.openjdk.java.net> Changeset: f56e28f22410 Author: trims Date: 2010-06-03 18:18 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/f56e28f22410 6958458: Bump the HS19 build number to 03 Summary: Update the HS19 build number to 03 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 49242b3df6cd Author: mikejwre Date: 2010-06-03 13:30 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/49242b3df6cd Added tag jdk7-b96 for changeset 573e8ea5fd68 ! .hgtags Changeset: 5f42499e57ad Author: trims Date: 2010-06-04 11:43 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/5f42499e57ad Added tag hs19-b02 for changeset 573e8ea5fd68 ! .hgtags Changeset: b0e7cd862748 Author: mikejwre Date: 2010-06-10 13:58 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/b0e7cd862748 Added tag jdk7-b97 for changeset 5f42499e57ad ! .hgtags Changeset: 70191885f707 Author: prr Date: 2010-06-16 09:42 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/70191885f707 6961079: Build JDK7 for 64 bit Windows using free Windows 7.1 SDK 64 bit compilers Reviewed-by: ohair, jcoomes ! make/windows/makefiles/defs.make Changeset: 8a045b3f5c13 Author: mikejwre Date: 2010-06-16 15:48 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/8a045b3f5c13 Merge Changeset: 695c43156a9a Author: mikejwre Date: 2010-06-17 16:27 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/695c43156a9a Added tag jdk7-b98 for changeset 8a045b3f5c13 ! .hgtags Changeset: c69846936352 Author: trims Date: 2010-06-17 23:59 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/c69846936352 Merge Changeset: e848dd13e1b6 Author: trims Date: 2010-06-18 00:09 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/e848dd13e1b6 Merge Changeset: 606df121c181 Author: trims Date: 2010-06-04 11:54 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/606df121c181 Merge Changeset: 6a236384a379 Author: trims Date: 2010-06-18 00:19 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/6a236384a379 Merge Changeset: b34c75c0b6b8 Author: mikejwre Date: 2010-06-24 20:03 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/b34c75c0b6b8 Added tag jdk7-b99 for changeset 6a236384a379 ! .hgtags Changeset: e13a5c0ed5e2 Author: prr Date: 2010-06-29 16:33 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/e13a5c0ed5e2 6964882: 32 bit JDK does not build on 64 bit Windows platforms Reviewed-by: ohair, valeriep ! make/windows/makefiles/defs.make Changeset: ad1977f08c4d Author: mikejwre Date: 2010-06-30 18:57 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/ad1977f08c4d Merge Changeset: 871d2aa321f7 Author: trims Date: 2010-07-02 01:36 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/871d2aa321f7 Merge Changeset: 7cc68a696c62 Author: trims Date: 2010-07-02 01:37 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/7cc68a696c62 6966252: Bump the HS19 build number to 04 Summary: Update the HS19 build number to 04 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 56cc7e01da2f Author: trims Date: 2010-07-09 00:31 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/56cc7e01da2f Added tag hs19-b03 for changeset ad1977f08c4d ! .hgtags Changeset: 1dbaff4aa23a Author: trims Date: 2010-07-09 00:32 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/1dbaff4aa23a Merge Changeset: cf647374e044 Author: trims Date: 2010-07-09 00:35 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/cf647374e044 Merge Changeset: 6c3a919105b6 Author: mikejwre Date: 2010-07-09 19:18 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/6c3a919105b6 Added tag jdk7-b100 for changeset ad1977f08c4d ! .hgtags Changeset: a2b581345549 Author: trims Date: 2010-07-15 19:51 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/a2b581345549 Merge ! .hgtags Changeset: e55900b5c1b8 Author: trims Date: 2010-07-15 19:52 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/e55900b5c1b8 Merge - src/os/linux/vm/vtune_linux.cpp - src/os/solaris/vm/vtune_solaris.cpp - src/os/windows/vm/vtune_windows.cpp - src/share/vm/runtime/vtune.hpp Changeset: 75b254ea860e Author: mikejwre Date: 2010-07-15 20:11 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/75b254ea860e Added tag jdk7-b101 for changeset 6c3a919105b6 ! .hgtags Changeset: c5cadf1a0771 Author: trims Date: 2010-07-20 18:13 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/c5cadf1a0771 Merge ! .hgtags Changeset: e7ec8cd4dd8a Author: tonyp Date: 2010-06-28 14:13 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/e7ec8cd4dd8a 6962569: assembler_sparc.cpp:1969: assert(false) failed: error Summary: array_overlap_test() fails when the address range crosses the MSB boundary. Thanks to Tom and Vladimir for their help on this one. Reviewed-by: kvn, never, iveresov ! src/cpu/sparc/vm/stubGenerator_sparc.cpp Changeset: 4e5661ba9d98 Author: tonyp Date: 2010-06-28 14:13 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/4e5661ba9d98 6944166: G1: explicit GCs are not always handled correctly Summary: G1 was not handling explicit GCs correctly in many ways. It does now. See the CR for the list of improvements contained in this changeset. Reviewed-by: iveresov, ysr, johnc ! src/share/vm/gc_implementation/concurrentMarkSweep/vmCMSOperations.cpp ! src/share/vm/gc_implementation/g1/concurrentMarkThread.cpp ! 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/vm_operations_g1.cpp ! src/share/vm/gc_implementation/g1/vm_operations_g1.hpp ! src/share/vm/gc_implementation/includeDB_gc_g1 ! src/share/vm/gc_implementation/shared/vmGCOperations.hpp ! src/share/vm/gc_interface/gcCause.cpp ! src/share/vm/runtime/mutexLocker.cpp Changeset: 1a1ce2076047 Author: ysr Date: 2010-07-16 10:09 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/1a1ce2076047 Merge Changeset: ad7e433e2730 Author: ysr Date: 2010-07-20 16:09 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/ad7e433e2730 Merge - src/os/linux/vm/vtune_linux.cpp - src/os/solaris/vm/vtune_solaris.cpp - src/os/windows/vm/vtune_windows.cpp - src/share/vm/runtime/vtune.hpp Changeset: 131ed9a23d48 Author: ysr Date: 2010-07-21 09:57 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/131ed9a23d48 Merge Changeset: 5063ce716349 Author: never Date: 2010-07-23 10:21 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/5063ce716349 Merge Changeset: a93a9eda13f7 Author: jcoomes Date: 2010-07-16 21:33 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/a93a9eda13f7 6962947: shared TaskQueue statistics Reviewed-by: tonyp, ysr ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.hpp ! src/share/vm/gc_implementation/parNew/parOopClosures.hpp ! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.cpp ! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.hpp ! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.inline.hpp ! src/share/vm/gc_implementation/parallelScavenge/psTasks.cpp ! src/share/vm/utilities/globalDefinitions.hpp ! src/share/vm/utilities/taskqueue.cpp ! src/share/vm/utilities/taskqueue.hpp Changeset: 5cbac8938c4c Author: johnc Date: 2010-07-19 11:06 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/5cbac8938c4c 6956639: G1: assert(cached_ptr != card_ptr) failed: shouldn't be, concurrentG1Refine.cpp:307 Summary: During concurrent refinment, filter cards in young regions after it has been determined that the region has been allocated from and the young type of the region has been set. Reviewed-by: iveresov, tonyp, jcoomes ! src/share/vm/gc_implementation/g1/concurrentG1Refine.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp Changeset: 4f1fffe08c63 Author: ysr Date: 2010-07-21 12:45 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/4f1fffe08c63 Merge Changeset: 1890dc9151da Author: ysr Date: 2010-07-23 14:31 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/1890dc9151da Merge Changeset: 99ceb0e99c9e Author: never Date: 2010-07-26 15:58 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/99ceb0e99c9e Merge From vladimir.kozlov at oracle.com Thu Jul 29 15:54:44 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 29 Jul 2010 15:54:44 -0700 Subject: Request for reviews (S): 6973308: Missing zero length check before repne scas in check_klass_subtype_slow_path() Message-ID: <4C5206B4.8070308@oracle.com> http://cr.openjdk.java.net/~kvn/6973308/webrev Fixed 6973308: Missing zero length check before repne scas in check_klass_subtype_slow_path() Z flag value will not be set by repne_scan(); if RCX == 0 since 'repne' instruction does not change flags (only scas instruction which is repeated sets flags). Setting Z = 1 before repne_scan() in check_klass_subtype_slow_path() will cause exception java.lang.IncompatibleClassChangeError: // pointer were to sneak in here. Note that we have already loaded the // Klass::super_check_offset from the super_klass in the fast path, // so if there is a null in that register, we are already in the afterlife. + push(rax); + xorq(rax,rax); // Set Z = 1 + pop(rax); repne_scanl(); % java -Xmx128M -jar GCBasher.jar -time:300 Exception in thread "main" java.lang.IncompatibleClassChangeError at java.lang.StringCoding$StringDecoder.decode(StringCoding.java:153) Solution: Instead of checking RCX for zero set Z = 0 (not equal) before 'repne' to indicate that class was not found when RCX == 0. Also fixed printed free stack size in hs_err files. Added ability to abort VM only on the exception with specific message. Tested with failed case. From vladimir.kozlov at oracle.com Thu Jul 29 16:39:30 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 29 Jul 2010 16:39:30 -0700 Subject: Request for reviews (S): 6973308: Missing zero length check before repne scas in check_klass_subtype_slow_path() In-Reply-To: <4C5206B4.8070308@oracle.com> References: <4C5206B4.8070308@oracle.com> Message-ID: <4C521132.60907@oracle.com> I updated webrev with additional changes in assembler_x86.cpp to verify r12_heapbase even in zero based case. These changes exposed this bug. Thanks, Vladimir Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/6973308/webrev > > Fixed 6973308: Missing zero length check before repne scas in > check_klass_subtype_slow_path() > > Z flag value will not be set by repne_scan(); if RCX == 0 since > 'repne' instruction does not change flags (only scas instruction > which is repeated sets flags). > > Setting Z = 1 before repne_scan() in check_klass_subtype_slow_path() > will cause exception java.lang.IncompatibleClassChangeError: > > // pointer were to sneak in here. Note that we have already loaded > the > // Klass::super_check_offset from the super_klass in the fast path, > // so if there is a null in that register, we are already in the > afterlife. > + push(rax); > + xorq(rax,rax); // Set Z = 1 > + pop(rax); > repne_scanl(); > > % java -Xmx128M -jar GCBasher.jar -time:300 > Exception in thread "main" java.lang.IncompatibleClassChangeError > at > java.lang.StringCoding$StringDecoder.decode(StringCoding.java:153) > > Solution: > Instead of checking RCX for zero set Z = 0 (not equal) before 'repne' > to indicate that class was not found when RCX == 0. > > Also fixed printed free stack size in hs_err files. > Added ability to abort VM only on the exception with specific message. > > Tested with failed case. From tom.rodriguez at oracle.com Thu Jul 29 18:18:03 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 29 Jul 2010 18:18:03 -0700 Subject: Request for reviews (S): 6973308: Missing zero length check before repne scas in check_klass_subtype_slow_path() In-Reply-To: <4C521132.60907@oracle.com> References: <4C5206B4.8070308@oracle.com> <4C521132.60907@oracle.com> Message-ID: Looks good. tom On Jul 29, 2010, at 4:39 PM, Vladimir Kozlov wrote: > I updated webrev with additional changes in assembler_x86.cpp > to verify r12_heapbase even in zero based case. > These changes exposed this bug. > > Thanks, > Vladimir > > Vladimir Kozlov wrote: >> http://cr.openjdk.java.net/~kvn/6973308/webrev >> Fixed 6973308: Missing zero length check before repne scas in check_klass_subtype_slow_path() >> Z flag value will not be set by repne_scan(); if RCX == 0 since >> 'repne' instruction does not change flags (only scas instruction >> which is repeated sets flags). >> Setting Z = 1 before repne_scan() in check_klass_subtype_slow_path() >> will cause exception java.lang.IncompatibleClassChangeError: >> // pointer were to sneak in here. Note that we have already loaded the >> // Klass::super_check_offset from the super_klass in the fast path, >> // so if there is a null in that register, we are already in the afterlife. >> + push(rax); >> + xorq(rax,rax); // Set Z = 1 >> + pop(rax); >> repne_scanl(); >> % java -Xmx128M -jar GCBasher.jar -time:300 >> Exception in thread "main" java.lang.IncompatibleClassChangeError >> at java.lang.StringCoding$StringDecoder.decode(StringCoding.java:153) >> Solution: >> Instead of checking RCX for zero set Z = 0 (not equal) before 'repne' >> to indicate that class was not found when RCX == 0. >> Also fixed printed free stack size in hs_err files. >> Added ability to abort VM only on the exception with specific message. >> Tested with failed case. From vladimir.kozlov at oracle.com Thu Jul 29 18:40:28 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 29 Jul 2010 18:40:28 -0700 Subject: Request for reviews (S): 6973308: Missing zero length check before repne scas in check_klass_subtype_slow_path() In-Reply-To: References: <4C5206B4.8070308@oracle.com> <4C521132.60907@oracle.com> Message-ID: <4C522D8C.1080502@oracle.com> Thank you, Tom Vladimir On 7/29/10 6:18 PM, Tom Rodriguez wrote: > Looks good. > > tom > > On Jul 29, 2010, at 4:39 PM, Vladimir Kozlov wrote: > >> I updated webrev with additional changes in assembler_x86.cpp >> to verify r12_heapbase even in zero based case. >> These changes exposed this bug. >> >> Thanks, >> Vladimir >> >> Vladimir Kozlov wrote: >>> http://cr.openjdk.java.net/~kvn/6973308/webrev >>> Fixed 6973308: Missing zero length check before repne scas in check_klass_subtype_slow_path() >>> Z flag value will not be set by repne_scan(); if RCX == 0 since >>> 'repne' instruction does not change flags (only scas instruction >>> which is repeated sets flags). >>> Setting Z = 1 before repne_scan() in check_klass_subtype_slow_path() >>> will cause exception java.lang.IncompatibleClassChangeError: >>> // pointer were to sneak in here. Note that we have already loaded the >>> // Klass::super_check_offset from the super_klass in the fast path, >>> // so if there is a null in that register, we are already in the afterlife. >>> + push(rax); >>> + xorq(rax,rax); // Set Z = 1 >>> + pop(rax); >>> repne_scanl(); >>> % java -Xmx128M -jar GCBasher.jar -time:300 >>> Exception in thread "main" java.lang.IncompatibleClassChangeError >>> at java.lang.StringCoding$StringDecoder.decode(StringCoding.java:153) >>> Solution: >>> Instead of checking RCX for zero set Z = 0 (not equal) before 'repne' >>> to indicate that class was not found when RCX == 0. >>> Also fixed printed free stack size in hs_err files. >>> Added ability to abort VM only on the exception with specific message. >>> Tested with failed case. > From vladimir.kozlov at oracle.com Fri Jul 30 12:30:47 2010 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Fri, 30 Jul 2010 19:30:47 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6973308: Missing zero length check before repne scas in check_klass_subtype_slow_path() Message-ID: <20100730193049.16F4347DCF@hg.openjdk.java.net> Changeset: 66c5dadb4d61 Author: kvn Date: 2010-07-30 10:21 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/66c5dadb4d61 6973308: Missing zero length check before repne scas in check_klass_subtype_slow_path() Summary: set Z = 0 (not equal) before repne_scan() to indicate that class was not found when RCX == 0. Reviewed-by: never, phh ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/utilities/exceptions.cpp ! src/share/vm/utilities/exceptions.hpp ! src/share/vm/utilities/vmError.cpp