From christian.thalinger at oracle.com Wed Nov 2 02:05:13 2011 From: christian.thalinger at oracle.com (christian.thalinger at oracle.com) Date: Wed, 02 Nov 2011 09:05:13 +0000 Subject: hg: hsx/hotspot-main/jdk: 7085860: JSR 292: implement CallSite.setTargetNormal and setTargetVolatile as native methods Message-ID: <20111102090542.0ADB3471FA@hg.openjdk.java.net> Changeset: 2a147f854257 Author: twisti Date: 2011-11-02 02:03 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/2a147f854257 7085860: JSR 292: implement CallSite.setTargetNormal and setTargetVolatile as native methods Reviewed-by: jrose, never ! src/share/classes/java/lang/invoke/CallSite.java ! src/share/classes/java/lang/invoke/MethodHandleNatives.java + test/java/lang/invoke/CallSiteTest.java From mark.reinhold at oracle.com Wed Nov 2 09:42:43 2011 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Wed, 02 Nov 2011 09:42:43 -0700 Subject: JEP 122: Remove the Permanent Generation Message-ID: <20111102164243.21E762E56@eggemoggin.niobe.net> Posted: http://openjdk.java.net/jeps/122 - Mark From david.holmes at oracle.com Wed Nov 2 18:59:03 2011 From: david.holmes at oracle.com (David Holmes) Date: Thu, 03 Nov 2011 11:59:03 +1000 Subject: CFV: New HSX Committers Message-ID: <4EB1F567.7090004@oracle.com> I hereby nominate the following people to HSX Committer: Poonam Bajaj Vladimir Danushevsky Bertrand Delsart Zhengyu Gu Robert Ottenhag Frederic Parain Christian T?rnqvist Bob Vandette Kevin Walls Roland Westrelin Jesper Wilhelmsson All of these Hotspot developers met the census criteria [0] to be Committers for the JDK 6, 7, 7 Update, and 8 Projects. During the census review period, however, it was not noticed that they had not been granted the Committer role in the HSX Project, which is now the sole route for all incoming Hotspot changes prior to their integration into one or more of the JDK Projects. Votes are due by 12:01AM Australia EST, Friday November 18, 2011. Only current HSX Committers [1] are eligible to vote on this nomination. For Lazy Consensus voting instructions, see [2]. David Holmes [0] http://openjdk.java.net/census#colophon [1] http://openjdk.java.net/census/#hsx [2] http://openjdk.java.net/projects/#committer-vote From daniel.daugherty at oracle.com Wed Nov 2 20:04:32 2011 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 02 Nov 2011 21:04:32 -0600 Subject: CFV: New HSX Committers In-Reply-To: <4EB1F567.7090004@oracle.com> References: <4EB1F567.7090004@oracle.com> Message-ID: <4EB204C0.5020503@oracle.com> Yes for all. Dan On 11/2/11 7:59 PM, David Holmes wrote: > I hereby nominate the following people to HSX Committer: > > Poonam Bajaj > Vladimir Danushevsky > Bertrand Delsart > Zhengyu Gu > Robert Ottenhag > Frederic Parain > Christian T?rnqvist > Bob Vandette > Kevin Walls > Roland Westrelin > Jesper Wilhelmsson > > All of these Hotspot developers met the census criteria [0] to be > Committers for the JDK 6, 7, 7 Update, and 8 Projects. During the > census review period, however, it was not noticed that they had not > been granted the Committer role in the HSX Project, which is now the > sole route for all incoming Hotspot changes prior to their integration > into one or more of the JDK Projects. > > Votes are due by 12:01AM Australia EST, Friday November 18, 2011. > > Only current HSX Committers [1] are eligible to vote on this nomination. > > For Lazy Consensus voting instructions, see [2]. > > David Holmes > > [0] http://openjdk.java.net/census#colophon > [1] http://openjdk.java.net/census/#hsx > [2] http://openjdk.java.net/projects/#committer-vote From vladimir.kozlov at oracle.com Wed Nov 2 20:16:43 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 02 Nov 2011 20:16:43 -0700 Subject: CFV: New HSX Committers In-Reply-To: <4EB1F567.7090004@oracle.com> References: <4EB1F567.7090004@oracle.com> Message-ID: <4EB2079B.6050103@oracle.com> Vote: yes Vladimir David Holmes wrote: > I hereby nominate the following people to HSX Committer: > > Poonam Bajaj > Vladimir Danushevsky > Bertrand Delsart > Zhengyu Gu > Robert Ottenhag > Frederic Parain > Christian T?rnqvist > Bob Vandette > Kevin Walls > Roland Westrelin > Jesper Wilhelmsson > > All of these Hotspot developers met the census criteria [0] to be > Committers for the JDK 6, 7, 7 Update, and 8 Projects. During the > census review period, however, it was not noticed that they had not been > granted the Committer role in the HSX Project, which is now the sole > route for all incoming Hotspot changes prior to their integration into > one or more of the JDK Projects. > > Votes are due by 12:01AM Australia EST, Friday November 18, 2011. > > Only current HSX Committers [1] are eligible to vote on this nomination. > > For Lazy Consensus voting instructions, see [2]. > > David Holmes > > [0] http://openjdk.java.net/census#colophon > [1] http://openjdk.java.net/census/#hsx > [2] http://openjdk.java.net/projects/#committer-vote From john.r.rose at oracle.com Wed Nov 2 21:26:30 2011 From: john.r.rose at oracle.com (John Rose) Date: Wed, 2 Nov 2011 21:26:30 -0700 Subject: CFV: New HSX Committers In-Reply-To: <4EB1F567.7090004@oracle.com> References: <4EB1F567.7090004@oracle.com> Message-ID: <738AF370-0161-4660-AB84-5AC502E28352@oracle.com> Vote: yes From y.s.ramakrishna at oracle.com Wed Nov 2 22:39:14 2011 From: y.s.ramakrishna at oracle.com (=?utf-8?B?WS4gUy4gUmFtYWtyaXNobmEgKFBob25lKQ==?=) Date: Wed, 02 Nov 2011 22:39:14 -0700 Subject: =?utf-8?B?UmU6IENGVjogTmV3IEhTWCBDb21taXR0ZXJz?= Message-ID: <201111030539.pA35d0u4026437@acsmt356.oracle.com> Vote: yes __ Y. Srinivas Ramakrishna (ysr) Sent from my Verizon Wireless Phone ----- Reply message ----- From: "David Holmes" Date: Wed, Nov 2, 2011 18:59 Subject: CFV: New HSX Committers To: "hotspot-dev developers" I hereby nominate the following people to HSX Committer: Poonam Bajaj Vladimir Danushevsky Bertrand Delsart Zhengyu Gu Robert Ottenhag Frederic Parain Christian T?rnqvist Bob Vandette Kevin Walls Roland Westrelin Jesper Wilhelmsson All of these Hotspot developers met the census criteria [0] to be Committers for the JDK 6, 7, 7 Update, and 8 Projects. During the census review period, however, it was not noticed that they had not been granted the Committer role in the HSX Project, which is now the sole route for all incoming Hotspot changes prior to their integration into one or more of the JDK Projects. Votes are due by 12:01AM Australia EST, Friday November 18, 2011. Only current HSX Committers [1] are eligible to vote on this nomination. For Lazy Consensus voting instructions, see [2]. David Holmes [0] http://openjdk.java.net/census#colophon [1] http://openjdk.java.net/census/#hsx [2] http://openjdk.java.net/projects/#committer-vote -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20111102/a5ae8766/attachment.html From Dmitry.Samersoff at oracle.com Wed Nov 2 23:13:33 2011 From: Dmitry.Samersoff at oracle.com (Dmitry Samersoff) Date: Thu, 03 Nov 2011 10:13:33 +0400 Subject: CFV: New HSX Committers In-Reply-To: <4EB1F567.7090004@oracle.com> References: <4EB1F567.7090004@oracle.com> Message-ID: <4EB2310D.1000805@oracle.com> Vote: yes On 2011-11-03 05:59, David Holmes wrote: > I hereby nominate the following people to HSX Committer: > > Poonam Bajaj > Vladimir Danushevsky > Bertrand Delsart > Zhengyu Gu > Robert Ottenhag > Frederic Parain > Christian T?rnqvist > Bob Vandette > Kevin Walls > Roland Westrelin > Jesper Wilhelmsson > > All of these Hotspot developers met the census criteria [0] to be > Committers for the JDK 6, 7, 7 Update, and 8 Projects. During the > census review period, however, it was not noticed that they had not been > granted the Committer role in the HSX Project, which is now the sole > route for all incoming Hotspot changes prior to their integration into > one or more of the JDK Projects. > > Votes are due by 12:01AM Australia EST, Friday November 18, 2011. > > Only current HSX Committers [1] are eligible to vote on this nomination. > > For Lazy Consensus voting instructions, see [2]. > > David Holmes > > [0] http://openjdk.java.net/census#colophon > [1] http://openjdk.java.net/census/#hsx > [2] http://openjdk.java.net/projects/#committer-vote -- Dmitry Samersoff Java Hotspot development team, SPB04 * There will come soft rains ... From christian.thalinger at oracle.com Thu Nov 3 02:01:34 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 3 Nov 2011 10:01:34 +0100 Subject: CFV: New HSX Committers In-Reply-To: <4EB1F567.7090004@oracle.com> References: <4EB1F567.7090004@oracle.com> Message-ID: <66DBAD41-C957-494D-8898-15CB855C9226@oracle.com> Vote: yes On Nov 3, 2011, at 2:59 AM, David Holmes wrote: > I hereby nominate the following people to HSX Committer: > > Poonam Bajaj > Vladimir Danushevsky > Bertrand Delsart > Zhengyu Gu > Robert Ottenhag > Frederic Parain > Christian T?rnqvist > Bob Vandette > Kevin Walls > Roland Westrelin > Jesper Wilhelmsson > > All of these Hotspot developers met the census criteria [0] to be Committers for the JDK 6, 7, 7 Update, and 8 Projects. During the census review period, however, it was not noticed that they had not been granted the Committer role in the HSX Project, which is now the sole route for all incoming Hotspot changes prior to their integration into one or more of the JDK Projects. > > Votes are due by 12:01AM Australia EST, Friday November 18, 2011. > > Only current HSX Committers [1] are eligible to vote on this nomination. > > For Lazy Consensus voting instructions, see [2]. > > David Holmes > > [0] http://openjdk.java.net/census#colophon > [1] http://openjdk.java.net/census/#hsx > [2] http://openjdk.java.net/projects/#committer-vote From keith.mcguigan at oracle.com Thu Nov 3 03:09:35 2011 From: keith.mcguigan at oracle.com (Keith McGuigan) Date: Thu, 3 Nov 2011 06:09:35 -0400 Subject: CFV: New HSX Committers In-Reply-To: <4EB1F567.7090004@oracle.com> References: <4EB1F567.7090004@oracle.com> Message-ID: Vote: yes On Nov 2, 2011, at 9:59 PM, David Holmes wrote: > I hereby nominate the following people to HSX Committer: > > Poonam Bajaj > Vladimir Danushevsky > Bertrand Delsart > Zhengyu Gu > Robert Ottenhag > Frederic Parain > Christian T?rnqvist > Bob Vandette > Kevin Walls > Roland Westrelin > Jesper Wilhelmsson > > All of these Hotspot developers met the census criteria [0] to be Committers for the JDK 6, 7, 7 Update, and 8 Projects. During the census review period, however, it was not noticed that they had not been granted the Committer role in the HSX Project, which is now the sole route for all incoming Hotspot changes prior to their integration into one or more of the JDK Projects. > > Votes are due by 12:01AM Australia EST, Friday November 18, 2011. > > Only current HSX Committers [1] are eligible to vote on this nomination. > > For Lazy Consensus voting instructions, see [2]. > > David Holmes > > [0] http://openjdk.java.net/census#colophon > [1] http://openjdk.java.net/census/#hsx > [2] http://openjdk.java.net/projects/#committer-vote From karen.kinnear at oracle.com Thu Nov 3 03:22:06 2011 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Thu, 3 Nov 2011 06:22:06 -0400 Subject: CFV: New HSX Committers In-Reply-To: <4EB1F567.7090004@oracle.com> References: <4EB1F567.7090004@oracle.com> Message-ID: <9A174085-9ECF-4111-950E-63BFB3870D0C@oracle.com> Yes to all. thanks, Karen On Nov 2, 2011, at 9:59 PM, David Holmes wrote: > I hereby nominate the following people to HSX Committer: > > Poonam Bajaj > Vladimir Danushevsky > Bertrand Delsart > Zhengyu Gu > Robert Ottenhag > Frederic Parain > Christian T?rnqvist > Bob Vandette > Kevin Walls > Roland Westrelin > Jesper Wilhelmsson > > All of these Hotspot developers met the census criteria [0] to be Committers for the JDK 6, 7, 7 Update, and 8 Projects. During the census review period, however, it was not noticed that they had not been granted the Committer role in the HSX Project, which is now the sole route for all incoming Hotspot changes prior to their integration into one or more of the JDK Projects. > > Votes are due by 12:01AM Australia EST, Friday November 18, 2011. > > Only current HSX Committers [1] are eligible to vote on this nomination. > > For Lazy Consensus voting instructions, see [2]. > > David Holmes > > [0] http://openjdk.java.net/census#colophon > [1] http://openjdk.java.net/census/#hsx > [2] http://openjdk.java.net/projects/#committer-vote From coleen.phillimore at oracle.com Thu Nov 3 04:15:43 2011 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 03 Nov 2011 07:15:43 -0400 Subject: CFV: New HSX Committers In-Reply-To: <4EB1F567.7090004@oracle.com> References: <4EB1F567.7090004@oracle.com> Message-ID: <4EB277DF.3090403@oracle.com> Vote: yes On 11/2/2011 9:59 PM, David Holmes wrote: > I hereby nominate the following people to HSX Committer: > > Poonam Bajaj > Vladimir Danushevsky > Bertrand Delsart > Zhengyu Gu > Robert Ottenhag > Frederic Parain > Christian T?rnqvist > Bob Vandette > Kevin Walls > Roland Westrelin > Jesper Wilhelmsson > > All of these Hotspot developers met the census criteria [0] to be > Committers for the JDK 6, 7, 7 Update, and 8 Projects. During the > census review period, however, it was not noticed that they had not > been granted the Committer role in the HSX Project, which is now the > sole route for all incoming Hotspot changes prior to their integration > into one or more of the JDK Projects. > > Votes are due by 12:01AM Australia EST, Friday November 18, 2011. > > Only current HSX Committers [1] are eligible to vote on this nomination. > > For Lazy Consensus voting instructions, see [2]. > > David Holmes > > [0] http://openjdk.java.net/census#colophon > [1] http://openjdk.java.net/census/#hsx > [2] http://openjdk.java.net/projects/#committer-vote From tom.rodriguez at oracle.com Thu Nov 3 07:58:40 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 3 Nov 2011 07:58:40 -0700 Subject: CFV: New HSX Committers In-Reply-To: <4EB1F567.7090004@oracle.com> References: <4EB1F567.7090004@oracle.com> Message-ID: Vote: yes On Nov 2, 2011, at 6:59 PM, David Holmes wrote: > I hereby nominate the following people to HSX Committer: > > Poonam Bajaj > Vladimir Danushevsky > Bertrand Delsart > Zhengyu Gu > Robert Ottenhag > Frederic Parain > Christian T?rnqvist > Bob Vandette > Kevin Walls > Roland Westrelin > Jesper Wilhelmsson > > All of these Hotspot developers met the census criteria [0] to be Committers for the JDK 6, 7, 7 Update, and 8 Projects. During the census review period, however, it was not noticed that they had not been granted the Committer role in the HSX Project, which is now the sole route for all incoming Hotspot changes prior to their integration into one or more of the JDK Projects. > > Votes are due by 12:01AM Australia EST, Friday November 18, 2011. > > Only current HSX Committers [1] are eligible to vote on this nomination. > > For Lazy Consensus voting instructions, see [2]. > > David Holmes > > [0] http://openjdk.java.net/census#colophon > [1] http://openjdk.java.net/census/#hsx > [2] http://openjdk.java.net/projects/#committer-vote From tony.printezis at oracle.com Thu Nov 3 08:50:03 2011 From: tony.printezis at oracle.com (Tony Printezis) Date: Thu, 03 Nov 2011 11:50:03 -0400 Subject: CFV: New HSX Committers In-Reply-To: <4EB1F567.7090004@oracle.com> References: <4EB1F567.7090004@oracle.com> Message-ID: <4EB2B82B.3040300@oracle.com> (of course) Yes to all. Tony On 11/02/2011 09:59 PM, David Holmes wrote: > I hereby nominate the following people to HSX Committer: > > Poonam Bajaj > Vladimir Danushevsky > Bertrand Delsart > Zhengyu Gu > Robert Ottenhag > Frederic Parain > Christian T?rnqvist > Bob Vandette > Kevin Walls > Roland Westrelin > Jesper Wilhelmsson > > All of these Hotspot developers met the census criteria [0] to be > Committers for the JDK 6, 7, 7 Update, and 8 Projects. During the > census review period, however, it was not noticed that they had not > been granted the Committer role in the HSX Project, which is now the > sole route for all incoming Hotspot changes prior to their integration > into one or more of the JDK Projects. > > Votes are due by 12:01AM Australia EST, Friday November 18, 2011. > > Only current HSX Committers [1] are eligible to vote on this nomination. > > For Lazy Consensus voting instructions, see [2]. > > David Holmes > > [0] http://openjdk.java.net/census#colophon > [1] http://openjdk.java.net/census/#hsx > [2] http://openjdk.java.net/projects/#committer-vote From paul.hohensee at oracle.com Thu Nov 3 10:44:21 2011 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Thu, 03 Nov 2011 13:44:21 -0400 Subject: CFV: New HSX Committers In-Reply-To: <4EB1F567.7090004@oracle.com> References: <4EB1F567.7090004@oracle.com> Message-ID: <4EB2D2F5.6030101@oracle.com> Vote: Yes For all Paul On 11/2/11 9:59 PM, David Holmes wrote: > I hereby nominate the following people to HSX Committer: > > Poonam Bajaj > Vladimir Danushevsky > Bertrand Delsart > Zhengyu Gu > Robert Ottenhag > Frederic Parain > Christian T?rnqvist > Bob Vandette > Kevin Walls > Roland Westrelin > Jesper Wilhelmsson > > All of these Hotspot developers met the census criteria [0] to be > Committers for the JDK 6, 7, 7 Update, and 8 Projects. During the > census review period, however, it was not noticed that they had not > been granted the Committer role in the HSX Project, which is now the > sole route for all incoming Hotspot changes prior to their integration > into one or more of the JDK Projects. > > Votes are due by 12:01AM Australia EST, Friday November 18, 2011. > > Only current HSX Committers [1] are eligible to vote on this nomination. > > For Lazy Consensus voting instructions, see [2]. > > David Holmes > > [0] http://openjdk.java.net/census#colophon > [1] http://openjdk.java.net/census/#hsx > [2] http://openjdk.java.net/projects/#committer-vote From John.Coomes at oracle.com Thu Nov 3 10:49:39 2011 From: John.Coomes at oracle.com (John Coomes) Date: Thu, 3 Nov 2011 10:49:39 -0700 Subject: CFV: New HSX Committers In-Reply-To: <4EB204C0.5020503@oracle.com> References: <4EB1F567.7090004@oracle.com> <4EB204C0.5020503@oracle.com> Message-ID: <20146.54323.44502.360569@oracle.com> Daniel D. Daugherty (daniel.daugherty at oracle.com) wrote: > Yes for all. Just FYI that David may not count your votes. The response is supposed to be in a specific format, which David referenced (see below). Following the format would certainly make tallying the votes easier; we don't to make this process any more tedious. -John > > ... > > For Lazy Consensus voting instructions, see [2]. > > > > David Holmes > > > > [0] http://openjdk.java.net/census#colophon > > [1] http://openjdk.java.net/census/#hsx > > [2] http://openjdk.java.net/projects/#committer-vote From John.Coomes at oracle.com Thu Nov 3 10:51:40 2011 From: John.Coomes at oracle.com (John Coomes) Date: Thu, 3 Nov 2011 10:51:40 -0700 Subject: CFV: New HSX Committers In-Reply-To: <4EB1F567.7090004@oracle.com> References: <4EB1F567.7090004@oracle.com> Message-ID: <20146.54444.433918.367248@oracle.com> Vote: yes -John From daniel.daugherty at oracle.com Thu Nov 3 11:02:59 2011 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 03 Nov 2011 12:02:59 -0600 Subject: CFV: New HSX Committers In-Reply-To: <4EB1F567.7090004@oracle.com> References: <4EB1F567.7090004@oracle.com> Message-ID: <4EB2D753.2080608@oracle.com> Vote: yes for all (I used the wrong format previously) Dan On 11/2/11 7:59 PM, David Holmes wrote: > I hereby nominate the following people to HSX Committer: > > Poonam Bajaj > Vladimir Danushevsky > Bertrand Delsart > Zhengyu Gu > Robert Ottenhag > Frederic Parain > Christian T?rnqvist > Bob Vandette > Kevin Walls > Roland Westrelin > Jesper Wilhelmsson > > All of these Hotspot developers met the census criteria [0] to be > Committers for the JDK 6, 7, 7 Update, and 8 Projects. During the > census review period, however, it was not noticed that they had not > been granted the Committer role in the HSX Project, which is now the > sole route for all incoming Hotspot changes prior to their integration > into one or more of the JDK Projects. > > Votes are due by 12:01AM Australia EST, Friday November 18, 2011. > > Only current HSX Committers [1] are eligible to vote on this nomination. > > For Lazy Consensus voting instructions, see [2]. > > David Holmes > > [0] http://openjdk.java.net/census#colophon > [1] http://openjdk.java.net/census/#hsx > [2] http://openjdk.java.net/projects/#committer-vote > From tony.printezis at oracle.com Thu Nov 3 11:07:35 2011 From: tony.printezis at oracle.com (Tony Printezis) Date: Thu, 03 Nov 2011 14:07:35 -0400 Subject: CFV: New HSX Committers In-Reply-To: <4EB2B82B.3040300@oracle.com> References: <4EB1F567.7090004@oracle.com> <4EB2B82B.3040300@oracle.com> Message-ID: <4EB2D867.4090300@oracle.com> Vote: yes (second try) On 11/03/2011 11:50 AM, Tony Printezis wrote: > (of course) Yes to all. > > Tony > > On 11/02/2011 09:59 PM, David Holmes wrote: >> I hereby nominate the following people to HSX Committer: >> >> Poonam Bajaj >> Vladimir Danushevsky >> Bertrand Delsart >> Zhengyu Gu >> Robert Ottenhag >> Frederic Parain >> Christian T?rnqvist >> Bob Vandette >> Kevin Walls >> Roland Westrelin >> Jesper Wilhelmsson >> >> All of these Hotspot developers met the census criteria [0] to be >> Committers for the JDK 6, 7, 7 Update, and 8 Projects. During the >> census review period, however, it was not noticed that they had not >> been granted the Committer role in the HSX Project, which is now the >> sole route for all incoming Hotspot changes prior to their >> integration into one or more of the JDK Projects. >> >> Votes are due by 12:01AM Australia EST, Friday November 18, 2011. >> >> Only current HSX Committers [1] are eligible to vote on this nomination. >> >> For Lazy Consensus voting instructions, see [2]. >> >> David Holmes >> >> [0] http://openjdk.java.net/census#colophon >> [1] http://openjdk.java.net/census/#hsx >> [2] http://openjdk.java.net/projects/#committer-vote From igor.veresov at oracle.com Thu Nov 3 12:32:13 2011 From: igor.veresov at oracle.com (Igor Veresov) Date: Thu, 3 Nov 2011 09:32:13 -1000 Subject: CFV: New HSX Committers In-Reply-To: <4EB1F567.7090004@oracle.com> References: <4EB1F567.7090004@oracle.com> Message-ID: Vote: yes igor On Wednesday, November 2, 2011 at 3:59 PM, David Holmes wrote: > I hereby nominate the following people to HSX Committer: > > Poonam Bajaj > Vladimir Danushevsky > Bertrand Delsart > Zhengyu Gu > Robert Ottenhag > Frederic Parain > Christian T?rnqvist > Bob Vandette > Kevin Walls > Roland Westrelin > Jesper Wilhelmsson > > All of these Hotspot developers met the census criteria [0] to be > Committers for the JDK 6, 7, 7 Update, and 8 Projects. During the > census review period, however, it was not noticed that they had not been > granted the Committer role in the HSX Project, which is now the sole > route for all incoming Hotspot changes prior to their integration into > one or more of the JDK Projects. > > Votes are due by 12:01AM Australia EST, Friday November 18, 2011. > > Only current HSX Committers [1] are eligible to vote on this nomination. > > For Lazy Consensus voting instructions, see [2]. > > David Holmes > > [0] http://openjdk.java.net/census#colophon > [1] http://openjdk.java.net/census/#hsx > [2] http://openjdk.java.net/projects/#committer-vote From bengt.rutisson at oracle.com Thu Nov 3 23:48:12 2011 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Fri, 04 Nov 2011 07:48:12 +0100 Subject: CFV: New HSX Committers In-Reply-To: <4EB1F567.7090004@oracle.com> References: <4EB1F567.7090004@oracle.com> Message-ID: <4EB38AAC.3070001@oracle.com> Vote: yes Bengt On 2011-11-03 02:59, David Holmes wrote: > I hereby nominate the following people to HSX Committer: > > Poonam Bajaj > Vladimir Danushevsky > Bertrand Delsart > Zhengyu Gu > Robert Ottenhag > Frederic Parain > Christian T?rnqvist > Bob Vandette > Kevin Walls > Roland Westrelin > Jesper Wilhelmsson > > All of these Hotspot developers met the census criteria [0] to be > Committers for the JDK 6, 7, 7 Update, and 8 Projects. During the > census review period, however, it was not noticed that they had not > been granted the Committer role in the HSX Project, which is now the > sole route for all incoming Hotspot changes prior to their integration > into one or more of the JDK Projects. > > Votes are due by 12:01AM Australia EST, Friday November 18, 2011. > > Only current HSX Committers [1] are eligible to vote on this nomination. > > For Lazy Consensus voting instructions, see [2]. > > David Holmes > > [0] http://openjdk.java.net/census#colophon > [1] http://openjdk.java.net/census/#hsx > [2] http://openjdk.java.net/projects/#committer-vote From david.holmes at oracle.com Fri Nov 4 01:05:12 2011 From: david.holmes at oracle.com (david.holmes at oracle.com) Date: Fri, 04 Nov 2011 08:05:12 +0000 Subject: hg: hsx/hotspot-main/hotspot: 3 new changesets Message-ID: <20111104080523.666BF47239@hg.openjdk.java.net> Changeset: d5c4c73aa855 Author: dholmes Date: 2011-10-27 18:04 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/d5c4c73aa855 7104173: sun/tools tests fail with debug build after 7012206 Summary: Disable PrintVMOptions in embedded debug builds so tests are unaffected by extra output Reviewed-by: twisti, coleenp, phh, fparain, dsamersoff ! src/share/vm/runtime/globals.hpp Changeset: 6da94c5a6746 Author: dholmes Date: 2011-10-30 18:40 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/6da94c5a6746 Merge Changeset: 95009f678859 Author: brutisso Date: 2011-11-01 13:44 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/95009f678859 7106766: Move the precompiled header from the src/share/vm directory Summary: Moved precompiled.hpp to src/share/vm/precompiled Reviewed-by: coleenp, dholmes Contributed-by: rbackman ! make/bsd/makefiles/buildtree.make ! make/bsd/makefiles/gcc.make ! make/linux/makefiles/buildtree.make ! make/linux/makefiles/gcc.make ! make/solaris/makefiles/buildtree.make ! make/solaris/makefiles/gcc.make ! make/windows/makefiles/vm.make - src/share/vm/precompiled.hpp + src/share/vm/precompiled/precompiled.hpp From mlists at juma.me.uk Fri Nov 4 01:54:30 2011 From: mlists at juma.me.uk (Ismael Juma) Date: Fri, 4 Nov 2011 08:54:30 +0000 (UTC) Subject: JEP 122: Remove the Permanent Generation References: <20111102164243.21E762E56@eggemoggin.niobe.net> Message-ID: writes: > Posted: http://openjdk.java.net/jeps/122 Excellent. Since this effort has been going on for a while and parts of it have already been integrated, is there some information on what still has to be done? Best, Ismael From jon.masamitsu at oracle.com Fri Nov 4 07:49:56 2011 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Fri, 04 Nov 2011 07:49:56 -0700 Subject: JEP 122: Remove the Permanent Generation In-Reply-To: References: <20111102164243.21E762E56@eggemoggin.niobe.net> Message-ID: <4EB3FB94.5020706@oracle.com> Ismael, Are you asking about parts of the project that will be visible to a Java application? For example, some objects have already been moved out of the permanent generation into the Java heap so some increase (generally small but application dependent) in the Java heap usage was seen. Or are your asking about changes that are only visible internally to hotspot? For example, not all the garbage collectors are working yet, there's still compiler (JIT) work that has to be completed, we need to better manage the native memory used for the class metadata (we expect that using malloc and free will lead to too much fragmentation in the Cheap), Class Data Sharing still needs to be fixed and the list goes on. Jon On 11/4/2011 1:54 AM, Ismael Juma wrote: > writes: >> Posted: http://openjdk.java.net/jeps/122 > Excellent. Since this effort has been going on for a while and parts of it have > already been integrated, is there some information on what still has to be done? > > Best, > Ismael > From zhengyu.gu at oracle.com Fri Nov 4 07:51:29 2011 From: zhengyu.gu at oracle.com (Zhengyu Gu) Date: Fri, 04 Nov 2011 10:51:29 -0400 Subject: Code review request: 7071311 Decoder enhancement In-Reply-To: <4EA18EA5.1070603@oracle.com> References: <4E9F01EB.6050901@oracle.com> <4EA18EA5.1070603@oracle.com> Message-ID: <4EB3FBF1.6060608@oracle.com> Hi, Based on the feedbacks from Coleen, this update separated decoder implementation from the decoder wrapper. Please review. Webrev: http://cr.openjdk.java.net/~zgu/7071311/webrev.02/ Thanks, -Zhengyu On 10/21/2011 11:24 AM, Zhengyu Gu wrote: > Minor updates based on current feedback. > > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7067266 > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7071311 > > Webrev: http://cr.openjdk.java.net/~zgu/7071311/webrev.01/ > > > Thanks, > > -Zhengyu > > > > On 10/19/2011 12:59 PM, Zhengyu Gu wrote: >> Hi, >> >> This is a refactoring and enhancement of current decoder. The primary >> goal is to make it thread-safe, so it can be used by other than just >> error handler. It also addressed CR 7067266 >> (http://monaco.sfbay.sun.com/detail.jsf?cr=7067266). >> >> CR 7071311: http://monaco.sfbay.sun.com/detail.jsf?cr=7071311 >> Webrev: http://cr.openjdk.java.net/~zgu/7071311/webrev.00/ >> >> The changes have been tested on Win32, Linux 32 and Solaris. >> >> Thanks, >> >> -Zhengyu From rasbold at google.com Fri Nov 4 08:05:47 2011 From: rasbold at google.com (Chuck Rasbold) Date: Fri, 4 Nov 2011 08:05:47 -0700 Subject: CFV: New HSX Committers In-Reply-To: <4EB1F567.7090004@oracle.com> References: <4EB1F567.7090004@oracle.com> Message-ID: Vote: yes On Wed, Nov 2, 2011 at 6:59 PM, David Holmes wrote: > I hereby nominate the following people to HSX Committer: > > Poonam Bajaj > Vladimir Danushevsky > Bertrand Delsart > Zhengyu Gu > Robert Ottenhag > Frederic Parain > Christian T?rnqvist > Bob Vandette > Kevin Walls > Roland Westrelin > Jesper Wilhelmsson > > All of these Hotspot developers met the census criteria [0] to be > Committers for the JDK 6, 7, 7 Update, and 8 Projects. During the census > review period, however, it was not noticed that they had not been granted > the Committer role in the HSX Project, which is now the sole route for all > incoming Hotspot changes prior to their integration into one or more of the > JDK Projects. > > Votes are due by 12:01AM Australia EST, Friday November 18, 2011. > > Only current HSX Committers [1] are eligible to vote on this nomination. > > For Lazy Consensus voting instructions, see [2]. > > David Holmes > > [0] http://openjdk.java.net/**census#colophon > [1] http://openjdk.java.net/**census/#hsx > [2] http://openjdk.java.net/**projects/#committer-vote > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20111104/b2dfb2d0/attachment.html From jon.masamitsu at oracle.com Fri Nov 4 10:39:40 2011 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Fri, 04 Nov 2011 10:39:40 -0700 Subject: CFV: New HSX Committers In-Reply-To: <4EB1F567.7090004@oracle.com> References: <4EB1F567.7090004@oracle.com> Message-ID: <4EB4235C.5070202@oracle.com> Vote: yes On 11/2/2011 6:59 PM, David Holmes wrote: > I hereby nominate the following people to HSX Committer: > > Poonam Bajaj > Vladimir Danushevsky > Bertrand Delsart > Zhengyu Gu > Robert Ottenhag > Frederic Parain > Christian T?rnqvist > Bob Vandette > Kevin Walls > Roland Westrelin > Jesper Wilhelmsson > > All of these Hotspot developers met the census criteria [0] to be > Committers for the JDK 6, 7, 7 Update, and 8 Projects. During the > census review period, however, it was not noticed that they had not > been granted the Committer role in the HSX Project, which is now the > sole route for all incoming Hotspot changes prior to their integration > into one or more of the JDK Projects. > > Votes are due by 12:01AM Australia EST, Friday November 18, 2011. > > Only current HSX Committers [1] are eligible to vote on this nomination. > > For Lazy Consensus voting instructions, see [2]. > > David Holmes > > [0] http://openjdk.java.net/census#colophon > [1] http://openjdk.java.net/census/#hsx > [2] http://openjdk.java.net/projects/#committer-vote From paul.hohensee at oracle.com Fri Nov 4 10:50:55 2011 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Fri, 04 Nov 2011 13:50:55 -0400 Subject: CFV: New HSX Committers In-Reply-To: <4EB1F567.7090004@oracle.com> References: <4EB1F567.7090004@oracle.com> Message-ID: <4EB425FF.8070707@oracle.com> Vote: yes On 11/2/11 9:59 PM, David Holmes wrote: > I hereby nominate the following people to HSX Committer: > > Poonam Bajaj > Vladimir Danushevsky > Bertrand Delsart > Zhengyu Gu > Robert Ottenhag > Frederic Parain > Christian T?rnqvist > Bob Vandette > Kevin Walls > Roland Westrelin > Jesper Wilhelmsson > > All of these Hotspot developers met the census criteria [0] to be > Committers for the JDK 6, 7, 7 Update, and 8 Projects. During the > census review period, however, it was not noticed that they had not > been granted the Committer role in the HSX Project, which is now the > sole route for all incoming Hotspot changes prior to their integration > into one or more of the JDK Projects. > > Votes are due by 12:01AM Australia EST, Friday November 18, 2011. > > Only current HSX Committers [1] are eligible to vote on this nomination. > > For Lazy Consensus voting instructions, see [2]. > > David Holmes > > [0] http://openjdk.java.net/census#colophon > [1] http://openjdk.java.net/census/#hsx > [2] http://openjdk.java.net/projects/#committer-vote > From dean.long at oracle.com Fri Nov 4 12:01:09 2011 From: dean.long at oracle.com (dean.long at oracle.com) Date: Fri, 4 Nov 2011 12:01:09 -0700 (PDT) Subject: Auto Reply: hotspot-dev Digest, Vol 55, Issue 5 Message-ID: <47c8c6a8-2dab-4d66-ae43-fd53cb904a16@default> This is an auto-replied message. I am out of the office right now. From john.coomes at oracle.com Fri Nov 4 15:59:22 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 04 Nov 2011 22:59:22 +0000 Subject: hg: hsx/hsx23/hotspot: 7 new changesets Message-ID: <20111104225938.124E947248@hg.openjdk.java.net> Changeset: ddb34559f9a7 Author: katleman Date: 2011-11-03 10:32 -0700 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/ddb34559f9a7 Added tag jdk8-b12 for changeset 1d3900713a67 ! .hgtags Changeset: 5c8c7bef6403 Author: jcoomes Date: 2011-10-28 18:30 -0700 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/5c8c7bef6403 7106092: Bump the hs23 build number to 05 Reviewed-by: johnc Contributed-by: alejandro.murillo at oracle.com ! make/hotspot_version Changeset: d5c4c73aa855 Author: dholmes Date: 2011-10-27 18:04 -0400 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/d5c4c73aa855 7104173: sun/tools tests fail with debug build after 7012206 Summary: Disable PrintVMOptions in embedded debug builds so tests are unaffected by extra output Reviewed-by: twisti, coleenp, phh, fparain, dsamersoff ! src/share/vm/runtime/globals.hpp Changeset: 6da94c5a6746 Author: dholmes Date: 2011-10-30 18:40 -0700 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/6da94c5a6746 Merge Changeset: 95009f678859 Author: brutisso Date: 2011-11-01 13:44 +0100 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/95009f678859 7106766: Move the precompiled header from the src/share/vm directory Summary: Moved precompiled.hpp to src/share/vm/precompiled Reviewed-by: coleenp, dholmes Contributed-by: rbackman ! make/bsd/makefiles/buildtree.make ! make/bsd/makefiles/gcc.make ! make/linux/makefiles/buildtree.make ! make/linux/makefiles/gcc.make ! make/solaris/makefiles/buildtree.make ! make/solaris/makefiles/gcc.make ! make/windows/makefiles/vm.make - src/share/vm/precompiled.hpp + src/share/vm/precompiled/precompiled.hpp Changeset: 3e609627e780 Author: jcoomes Date: 2011-11-04 12:40 -0700 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/3e609627e780 Merge - src/share/vm/precompiled.hpp Changeset: b92ca8e229d2 Author: jcoomes Date: 2011-11-04 12:43 -0700 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/b92ca8e229d2 Added tag hs23-b05 for changeset 3e609627e780 ! .hgtags From john.coomes at oracle.com Fri Nov 4 21:27:27 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Sat, 05 Nov 2011 04:27:27 +0000 Subject: hg: hsx/hotspot-main/hotspot: 4 new changesets Message-ID: <20111105042737.DA88E4724C@hg.openjdk.java.net> Changeset: ddb34559f9a7 Author: katleman Date: 2011-11-03 10:32 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/ddb34559f9a7 Added tag jdk8-b12 for changeset 1d3900713a67 ! .hgtags Changeset: 3e609627e780 Author: jcoomes Date: 2011-11-04 12:40 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/3e609627e780 Merge - src/share/vm/precompiled.hpp Changeset: b92ca8e229d2 Author: jcoomes Date: 2011-11-04 12:43 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/b92ca8e229d2 Added tag hs23-b05 for changeset 3e609627e780 ! .hgtags Changeset: 869804b759e7 Author: jcoomes Date: 2011-11-04 14:06 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/869804b759e7 7108553: Bump the hs23 build number to 06 Reviewed-by: johnc Contributed-by: alejandro.murillo at oracle.com ! make/hotspot_version From mlists at juma.me.uk Sun Nov 6 13:50:36 2011 From: mlists at juma.me.uk (Ismael Juma) Date: Sun, 6 Nov 2011 21:50:36 +0000 (UTC) Subject: JEP 122: Remove the Permanent Generation References: <20111102164243.21E762E56@eggemoggin.niobe.net> <4EB3FB94.5020706@oracle.com> Message-ID: Hi Jon, Jon Masamitsu writes: > Or are your asking about changes that are only visible > internally to hotspot? For example, not all the > garbage collectors are working yet, there's still > compiler (JIT) work that has to be completed, > we need to better manage the native memory > used for the class metadata (we expect that using > malloc and free will lead to too much fragmentation > in the Cheap), Class Data Sharing still needs to > be fixed and the list goes on. This is indeed what I was asking. The bit about the Java heap is also good to know (and confirms what I was expecting). Thanks! Best, Ismael From ahughes at redhat.com Sun Nov 6 16:35:00 2011 From: ahughes at redhat.com (Dr Andrew John Hughes) Date: Mon, 7 Nov 2011 00:35:00 +0000 Subject: HotSpot development trees In-Reply-To: <4EABA885.2060700@netdemons.com> References: <20111026224959.GK594@rivendell.redhat.com> <4EA8C35F.3010208@oracle.com> <4EA976E3.3000704@oracle.com> <4EA9F94F.3030707@netdemons.com> <4EAA1AEA.2060505@oracle.com> <4EABA885.2060700@netdemons.com> Message-ID: <20111107003500.GG25917@rivendell.middle-earth.co.uk> On 00:17 Sat 29 Oct , Erik Trimble wrote: > On 10/27/2011 11:58 PM, Krystal Mok wrote: > > Hi all, > > > > HS21 introduced quite a few behavioral changes that OpenJDK 6 users > > might not be expecting. One of them would be the progress of PermGen > > removal, which affects some tuning. It might still be pretty much > > compatible, but no one has been testing for JDK6/HS21 compatibility, > > right? > > > > From what we can see from the outside, recent JDK 6 releases from > > Oracle are staying on HotSpot 20.x, with some bug fixes applied. > > > > My question is: > > Are there any plans from Oracle/OpenJDK to release further updates to > > OpenJDK 6, with the bug fixes applied to HotSpot Express 20's master > > repo? Or, could there be a list of recommended list of bug > > fixes/patches that should be backported to HS20? > > > > We're stuck on JDK 6 now, with no plans to move to JDK 7 in the near > > future, our work would have to base on HS20. So backporting bugfixes > > to HS20 is kind of like "scratching my own itch". If there's anything > > outside contributors can do about this, I'm more than willing to help. > > > > Regards, > > Kris Mok > > > > Software Engineer > > Taobao (http://www.taobao.com) > > > > I admit I'm not as intimately aware of what's going on in the JVM as I > once was, but I see no real reason why HS21 or better shouldn't work > under OpenJDK 6, *provided* that during the backport process, certain > features are either permanently disabled, or just turned off by default. > Any idea what these features are? I'll look at providing hs22 as an IcedTea option as a first step. -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: Digital signature Url : http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20111107/12800d28/attachment.bin From christian.thalinger at oracle.com Mon Nov 7 01:59:27 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 7 Nov 2011 10:59:27 +0100 Subject: Request for review (XS): 7109063: JSR 292: fix for 7085860 is incomplete Message-ID: http://cr.openjdk.java.net/~twisti/7109063/ 7109063: JSR 292: fix for 7085860 is incomplete Reviewed-by: 7085860 missed to remove two unused methods in MethodHandleImpl which use the methods which were removed from MethodHandleNatives. src/share/classes/java/lang/invoke/MethodHandleImpl.java From Alan.Bateman at oracle.com Mon Nov 7 02:33:31 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 07 Nov 2011 10:33:31 +0000 Subject: Request for review (XS): 7109063: JSR 292: fix for 7085860 is incomplete In-Reply-To: References: Message-ID: <4EB7B3FB.7010308@oracle.com> On 07/11/2011 09:59, Christian Thalinger wrote: > http://cr.openjdk.java.net/~twisti/7109063/ > > 7109063: JSR 292: fix for 7085860 is incomplete > Reviewed-by: > > 7085860 missed to remove two unused methods in MethodHandleImpl which > use the methods which were removed from MethodHandleNatives. > > src/share/classes/java/lang/invoke/MethodHandleImpl.java > I know you're anxious to get this in so I looked at the webrev and it looks fine to me. -Alan. From christian.thalinger at oracle.com Mon Nov 7 02:39:30 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 7 Nov 2011 11:39:30 +0100 Subject: Request for review (XS): 7109063: JSR 292: fix for 7085860 is incomplete In-Reply-To: <4EB7B3FB.7010308@oracle.com> References: <4EB7B3FB.7010308@oracle.com> Message-ID: Thank you, Alan. -- Chris On Nov 7, 2011, at 11:33 AM, Alan Bateman wrote: > On 07/11/2011 09:59, Christian Thalinger wrote: >> http://cr.openjdk.java.net/~twisti/7109063/ >> >> 7109063: JSR 292: fix for 7085860 is incomplete >> Reviewed-by: >> >> 7085860 missed to remove two unused methods in MethodHandleImpl which >> use the methods which were removed from MethodHandleNatives. >> >> src/share/classes/java/lang/invoke/MethodHandleImpl.java >> > I know you're anxious to get this in so I looked at the webrev and it looks fine to me. > > -Alan. From christian.thalinger at oracle.com Mon Nov 7 07:20:07 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 7 Nov 2011 16:20:07 +0100 Subject: Request for review (XS): 7109063: JSR 292: fix for 7085860 is incomplete In-Reply-To: References: <4EB7B3FB.7010308@oracle.com> Message-ID: <2F563764-DD95-4587-B50B-43EDD1200A20@oracle.com> When trying to push that thing via JPRT I noticed that the test case is also broken (junit is not provided so it does not compile). Sigh. I fixed the test too and updated the webrev. -- Chris On Nov 7, 2011, at 11:39 AM, Christian Thalinger wrote: > Thank you, Alan. -- Chris > > On Nov 7, 2011, at 11:33 AM, Alan Bateman wrote: > >> On 07/11/2011 09:59, Christian Thalinger wrote: >>> http://cr.openjdk.java.net/~twisti/7109063/ >>> >>> 7109063: JSR 292: fix for 7085860 is incomplete >>> Reviewed-by: >>> >>> 7085860 missed to remove two unused methods in MethodHandleImpl which >>> use the methods which were removed from MethodHandleNatives. >>> >>> src/share/classes/java/lang/invoke/MethodHandleImpl.java >>> >> I know you're anxious to get this in so I looked at the webrev and it looks fine to me. >> >> -Alan. > From Alan.Bateman at oracle.com Mon Nov 7 07:41:43 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 07 Nov 2011 15:41:43 +0000 Subject: Request for review (XS): 7109063: JSR 292: fix for 7085860 is incomplete In-Reply-To: <2F563764-DD95-4587-B50B-43EDD1200A20@oracle.com> References: <4EB7B3FB.7010308@oracle.com> <2F563764-DD95-4587-B50B-43EDD1200A20@oracle.com> Message-ID: <4EB7FC37.6030101@oracle.com> On 07/11/2011 15:20, Christian Thalinger wrote: > When trying to push that thing via JPRT I noticed that the test case is also broken (junit is not provided so it does not compile). Sigh. I fixed the test too and updated the webrev. > > -- Chris > Several of the JSR-292 tests use JUnit so I'm curious how they compile if junit.jar is not installed. -Alan. From christian.thalinger at oracle.com Mon Nov 7 07:45:31 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 7 Nov 2011 16:45:31 +0100 Subject: Request for review (XS): 7109063: JSR 292: fix for 7085860 is incomplete In-Reply-To: <4EB7FC37.6030101@oracle.com> References: <4EB7B3FB.7010308@oracle.com> <2F563764-DD95-4587-B50B-43EDD1200A20@oracle.com> <4EB7FC37.6030101@oracle.com> Message-ID: <162796C2-69AF-4238-BAEE-529D5DC5A10B@oracle.com> On Nov 7, 2011, at 4:41 PM, Alan Bateman wrote: > On 07/11/2011 15:20, Christian Thalinger wrote: >> When trying to push that thing via JPRT I noticed that the test case is also broken (junit is not provided so it does not compile). Sigh. I fixed the test too and updated the webrev. >> >> -- Chris >> > Several of the JSR-292 tests use JUnit so I'm curious how they compile if junit.jar is not installed. I'm wondering myself. The other tests' usage of JUnit made me use it in my test too. Anyway, I only use assertEquals which is easy to add to the test itself and then it's self-contained. -- Chris > > -Alan. > From Alan.Bateman at oracle.com Mon Nov 7 08:17:27 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 07 Nov 2011 16:17:27 +0000 Subject: Request for review (XS): 7109063: JSR 292: fix for 7085860 is incomplete In-Reply-To: <162796C2-69AF-4238-BAEE-529D5DC5A10B@oracle.com> References: <4EB7B3FB.7010308@oracle.com> <2F563764-DD95-4587-B50B-43EDD1200A20@oracle.com> <4EB7FC37.6030101@oracle.com> <162796C2-69AF-4238-BAEE-529D5DC5A10B@oracle.com> Message-ID: <4EB80497.7070508@oracle.com> On 07/11/2011 15:45, Christian Thalinger wrote: > > I'm wondering myself. The other tests' usage of JUnit made me use it in my test too. Anyway, I only use assertEquals which is easy to add to the test itself and then it's self-contained. > > -- Chris > Christian and I chatted offline about this with Jon Gibbons and the issue is that this test isn't compiled as a JUnit test because it doesn't specify @run junit. There's a second test (InvokeDynamicPrintArgs.java) with the same issue but that test is excluded from test runs because it's on the problem list (jdk/test/ProblemList.txt). -Alan. From john.pampuch at oracle.com Mon Nov 7 10:20:05 2011 From: john.pampuch at oracle.com (John Pampuch) Date: Mon, 07 Nov 2011 10:20:05 -0800 Subject: HotSpot development trees In-Reply-To: <20111107003500.GG25917@rivendell.middle-earth.co.uk> References: <20111026224959.GK594@rivendell.redhat.com> <4EA8C35F.3010208@oracle.com> <4EA976E3.3000704@oracle.com> <4EA9F94F.3030707@netdemons.com> <4EAA1AEA.2060505@oracle.com> <4EABA885.2060700@netdemons.com> <20111107003500.GG25917@rivendell.middle-earth.co.uk> Message-ID: <4EB82155.3080002@oracle.com> An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20111107/3ae2fac1/attachment.html From david.holmes at oracle.com Mon Nov 7 14:16:33 2011 From: david.holmes at oracle.com (David Holmes) Date: Tue, 08 Nov 2011 08:16:33 +1000 Subject: Request for review (XS): 7109063: JSR 292: fix for 7085860 is incomplete In-Reply-To: References: Message-ID: <4EB858C1.7030808@oracle.com> On 7/11/2011 7:59 PM, Christian Thalinger wrote: > http://cr.openjdk.java.net/~twisti/7109063/ > > 7109063: JSR 292: fix for 7085860 is incomplete > Reviewed-by: > > 7085860 missed to remove two unused methods in MethodHandleImpl which > use the methods which were removed from MethodHandleNatives. > > src/share/classes/java/lang/invoke/MethodHandleImpl.java Does this change imply that we have an unbuildable repo somewhere - if so which one? If it's hotspot-main/jdk that's good :) David From christian.thalinger at oracle.com Tue Nov 8 00:40:54 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 8 Nov 2011 09:40:54 +0100 Subject: Request for review (XS): 7109063: JSR 292: fix for 7085860 is incomplete In-Reply-To: <4EB858C1.7030808@oracle.com> References: <4EB858C1.7030808@oracle.com> Message-ID: <2177B226-7F97-44D3-8E2A-E9FA9ABC71B2@oracle.com> On Nov 7, 2011, at 11:16 PM, David Holmes wrote: > On 7/11/2011 7:59 PM, Christian Thalinger wrote: >> http://cr.openjdk.java.net/~twisti/7109063/ >> >> 7109063: JSR 292: fix for 7085860 is incomplete >> Reviewed-by: >> >> 7085860 missed to remove two unused methods in MethodHandleImpl which >> use the methods which were removed from MethodHandleNatives. >> >> src/share/classes/java/lang/invoke/MethodHandleImpl.java > > Does this change imply that we have an unbuildable repo somewhere - if so which one? If it's hotspot-main/jdk that's good :) Yes, that one. John Coomes didn't integrate it into jdk8 so it's contained. -- Chris > > David > From christian.thalinger at oracle.com Tue Nov 8 02:22:57 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 8 Nov 2011 11:22:57 +0100 Subject: Request for review (XS): 7109063: JSR 292: fix for 7085860 is incomplete In-Reply-To: <4EB80497.7070508@oracle.com> References: <4EB7B3FB.7010308@oracle.com> <2F563764-DD95-4587-B50B-43EDD1200A20@oracle.com> <4EB7FC37.6030101@oracle.com> <162796C2-69AF-4238-BAEE-529D5DC5A10B@oracle.com> <4EB80497.7070508@oracle.com> Message-ID: <8E440C0D-6961-44CC-B63D-D4A00C038740@oracle.com> On Nov 7, 2011, at 5:17 PM, Alan Bateman wrote: > On 07/11/2011 15:45, Christian Thalinger wrote: >> >> I'm wondering myself. The other tests' usage of JUnit made me use it in my test too. Anyway, I only use assertEquals which is easy to add to the test itself and then it's self-contained. >> >> -- Chris >> > Christian and I chatted offline about this with Jon Gibbons and the issue is that this test isn't compiled as a JUnit test because it doesn't specify @run junit. There's a second test (InvokeDynamicPrintArgs.java) with the same issue but that test is excluded from test runs because it's on the problem list (jdk/test/ProblemList.txt). I fixed InvokeDynamicPrintArgs.java and removed the exclude from ProblemList.txt. Also I did a quick JPRT run of the jdk_lang tests and that looks good. The updated webrev is here: http://cr.openjdk.java.net/~twisti/7109063/ -- Chris > > -Alan. From Alan.Bateman at oracle.com Tue Nov 8 02:44:12 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 08 Nov 2011 10:44:12 +0000 Subject: Request for review (XS): 7109063: JSR 292: fix for 7085860 is incomplete In-Reply-To: <8E440C0D-6961-44CC-B63D-D4A00C038740@oracle.com> References: <4EB7B3FB.7010308@oracle.com> <2F563764-DD95-4587-B50B-43EDD1200A20@oracle.com> <4EB7FC37.6030101@oracle.com> <162796C2-69AF-4238-BAEE-529D5DC5A10B@oracle.com> <4EB80497.7070508@oracle.com> <8E440C0D-6961-44CC-B63D-D4A00C038740@oracle.com> Message-ID: <4EB907FC.7030200@oracle.com> On 08/11/2011 10:22, Christian Thalinger wrote: > : > I fixed InvokeDynamicPrintArgs.java and removed the exclude from ProblemList.txt. Also I did a quick JPRT run of the jdk_lang tests and that looks good. The updated webrev is here: > > http://cr.openjdk.java.net/~twisti/7109063/ > > -- Chris > Looks fine to me, and good to have InvokeDynamicPrintArgs.java removed from the exclude list. -Alan. From christian.thalinger at oracle.com Tue Nov 8 03:02:36 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 8 Nov 2011 12:02:36 +0100 Subject: Request for review (XS): 7109063: JSR 292: fix for 7085860 is incomplete In-Reply-To: <4EB907FC.7030200@oracle.com> References: <4EB7B3FB.7010308@oracle.com> <2F563764-DD95-4587-B50B-43EDD1200A20@oracle.com> <4EB7FC37.6030101@oracle.com> <162796C2-69AF-4238-BAEE-529D5DC5A10B@oracle.com> <4EB80497.7070508@oracle.com> <8E440C0D-6961-44CC-B63D-D4A00C038740@oracle.com> <4EB907FC.7030200@oracle.com> Message-ID: <574DEBE6-270E-4F82-9B43-CCC56BD48DBC@oracle.com> On Nov 8, 2011, at 11:44 AM, Alan Bateman wrote: > On 08/11/2011 10:22, Christian Thalinger wrote: >> : >> I fixed InvokeDynamicPrintArgs.java and removed the exclude from ProblemList.txt. Also I did a quick JPRT run of the jdk_lang tests and that looks good. The updated webrev is here: >> >> http://cr.openjdk.java.net/~twisti/7109063/ >> >> -- Chris >> > Looks fine to me, and good to have InvokeDynamicPrintArgs.java removed from the exclude list. Thank you, Alan. -- Chris > > -Alan. From john.coomes at oracle.com Tue Nov 8 15:42:36 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Tue, 08 Nov 2011 23:42:36 +0000 Subject: hg: hsx/hsx22/hotspot: 2 new changesets Message-ID: <20111108234240.3FF6D4729F@hg.openjdk.java.net> Changeset: c8abdaa56b47 Author: jcoomes Date: 2011-11-08 11:48 -0800 URL: http://hg.openjdk.java.net/hsx/hsx22/hotspot/rev/c8abdaa56b47 7108550: Bump the hs22 build number to 09 Reviewed-by: johnc Contributed-by: alejandro.murillo at oracle.com ! make/hotspot_version Changeset: 12a4ef429155 Author: jcoomes Date: 2011-11-08 11:48 -0800 URL: http://hg.openjdk.java.net/hsx/hsx22/hotspot/rev/12a4ef429155 Added tag hs22-b09 for changeset c8abdaa56b47 ! .hgtags From christian.thalinger at oracle.com Wed Nov 9 00:47:11 2011 From: christian.thalinger at oracle.com (christian.thalinger at oracle.com) Date: Wed, 09 Nov 2011 08:47:11 +0000 Subject: hg: hsx/hotspot-main/jdk: 7109063: JSR 292: fix for 7085860 is incomplete Message-ID: <20111109084752.0CC4A472A6@hg.openjdk.java.net> Changeset: 5c34ed65176e Author: twisti Date: 2011-11-09 00:46 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/5c34ed65176e 7109063: JSR 292: fix for 7085860 is incomplete Reviewed-by: iveresov, alanb, jrose ! src/share/classes/java/lang/invoke/MethodHandleImpl.java ! test/ProblemList.txt ! test/java/lang/invoke/CallSiteTest.java ! test/java/lang/invoke/InvokeDynamicPrintArgs.java From david.holmes at oracle.com Wed Nov 9 20:50:07 2011 From: david.holmes at oracle.com (David Holmes) Date: Thu, 10 Nov 2011 14:50:07 +1000 Subject: XS RFR: 7108264 - Fix for 7104173 is insufficient Message-ID: <4EBB57FF.3000901@oracle.com> The original fix (7104173) was discussed here: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2011-October/002510.html That fix missed the fact that non-embedded builds would still fail these tests. The new solution simply disables PrintVMOptions by default, in all cases. webrev: http://cr.openjdk.java.net/~dholmes/7108264/webrev/ This has been run through our internal test suites to ensure no unforeseen regressions. Thanks, David From rednaxelafx at gmail.com Wed Nov 9 23:54:52 2011 From: rednaxelafx at gmail.com (Krystal Mok) Date: Thu, 10 Nov 2011 15:54:52 +0800 Subject: RFE: Add compressed oops to VM info string Message-ID: Hi all, I'd like to propose to add "compressed oops" to the VM info string, so that people using "java -version" can get a better understanding of the ergonomics of the VM. I've posted a patch [1], against hsx20's master. The files modified are still pretty much the same on hotspot-main's master. With the patch applied, "java -version" may show: OpenJDK 64-Bit Server VM (build 20.0-b11-internal, mixed mode, compressed oops) and what used to work still works: OpenJDK Client VM (build 20.0-b11-internal, mixed mode, sharing) P.S. Alibaba (Taobao)'s OCA is submitted already, still waiting for approval from Oracle. Regards, Kris Mok Software Engineer, Taobao (http://www.taobao.com) [1]: https://gist.github.com/1354299 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20111110/430a955f/attachment.html From Dmitry.Samersoff at oracle.com Thu Nov 10 00:32:18 2011 From: Dmitry.Samersoff at oracle.com (Dmitry Samersoff) Date: Thu, 10 Nov 2011 12:32:18 +0400 Subject: XS RFR: 7108264 - Fix for 7104173 is insufficient In-Reply-To: <4EBB57FF.3000901@oracle.com> References: <4EBB57FF.3000901@oracle.com> Message-ID: <4EBB8C12.90805@oracle.com> David, Looks good for me! Thank you for taking care of it. -Dmitry On 2011-11-10 08:50, David Holmes wrote: > The original fix (7104173) was discussed here: > > http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2011-October/002510.html > > > That fix missed the fact that non-embedded builds would still fail these > tests. The new solution simply disables PrintVMOptions by default, in > all cases. > > webrev: http://cr.openjdk.java.net/~dholmes/7108264/webrev/ > > This has been run through our internal test suites to ensure no > unforeseen regressions. > > Thanks, > David -- Dmitry Samersoff Java Hotspot development team, SPB04 * There will come soft rains ... From christian.thalinger at oracle.com Thu Nov 10 01:08:58 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 10 Nov 2011 10:08:58 +0100 Subject: XS RFR: 7108264 - Fix for 7104173 is insufficient In-Reply-To: <4EBB57FF.3000901@oracle.com> References: <4EBB57FF.3000901@oracle.com> Message-ID: <0EA2A838-EF75-4F9D-8692-09ACDC30CFD7@oracle.com> Looks good. -- Chris On Nov 10, 2011, at 5:50 AM, David Holmes wrote: > The original fix (7104173) was discussed here: > > http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2011-October/002510.html > > That fix missed the fact that non-embedded builds would still fail these tests. The new solution simply disables PrintVMOptions by default, in all cases. > > webrev: http://cr.openjdk.java.net/~dholmes/7108264/webrev/ > > This has been run through our internal test suites to ensure no unforeseen regressions. > > Thanks, > David From volker.simonis at gmail.com Thu Nov 10 03:16:32 2011 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 10 Nov 2011 12:16:32 +0100 Subject: RFE: Add compressed oops to VM info string In-Reply-To: References: Message-ID: Hi Kris, first I want to say that I like and support your enhancement request. However once we do this, if would suggest printing other information as well. Particularly the fact if we're using tiered compilation comes to my mind here. I would therefore suggest to use a less verbose "compressed oops" string and also print the concrete compressed oops mode that's actually used (unscaled, zerobased, heapbased). This information may be particularly usefull because it may change depending on the users heap setting and the current system memory situation. So finally, we could use something like: OpenJDK 64-Bit Server VM (build 20.0-b11-internal, mixed mode, tiered, compr-oops=unscaled) For such a version string, it would be probably better to construct the string on the fly, otherwise the 'info_strs' struct you are currently using may become too big. What are your opinions? Regards, Volker On Thu, Nov 10, 2011 at 8:54 AM, Krystal Mok wrote: > Hi all, > I'd like to propose to add "compressed oops" to the VM info string, so that > people using "java -version" can get a better understanding of the > ergonomics of the VM. > I've posted a patch [1], against hsx20's master. The files modified are > still pretty much the same on hotspot-main's master. > With the patch applied, "java -version" may show: > OpenJDK 64-Bit Server VM (build 20.0-b11-internal, mixed mode, compressed > oops) > and what used to work still works: > OpenJDK Client VM (build 20.0-b11-internal, mixed mode, sharing) > P.S. Alibaba (Taobao)'s OCA is submitted already, still waiting for approval > from Oracle. > Regards, > Kris Mok > Software Engineer, Taobao (http://www.taobao.com) > [1]:?https://gist.github.com/1354299 From david.holmes at oracle.com Thu Nov 10 03:19:35 2011 From: david.holmes at oracle.com (David Holmes) Date: Thu, 10 Nov 2011 21:19:35 +1000 Subject: RFE: Add compressed oops to VM info string In-Reply-To: References: Message-ID: <4EBBB347.1080103@oracle.com> Hi Kris, On 10/11/2011 5:54 PM, Krystal Mok wrote: > Hi all, > > I'd like to propose to add "compressed oops" to the VM info string, so > that people using "java -version" can get a better understanding of the > ergonomics of the VM. You could make the same argument for showing what GC was selected, and probably a number of other settings. Why should compressed oops be special here? You can use -XX:+PrintFlagsFinal to see all the settings. David ----- > I've posted a patch [1], against hsx20's master. The files modified are > still pretty much the same on hotspot-main's master. > > With the patch applied, "java -version" may show: > OpenJDK 64-Bit Server VM (build 20.0-b11-internal, mixed mode, > compressed oops) > and what used to work still works: > OpenJDK Client VM (build 20.0-b11-internal, mixed mode, sharing) > > P.S. Alibaba (Taobao)'s OCA is submitted already, still waiting for > approval from Oracle. > > Regards, > Kris Mok > Software Engineer, Taobao (http://www.taobao.com) > > [1]: https://gist.github.com/1354299 From david.holmes at oracle.com Thu Nov 10 03:31:49 2011 From: david.holmes at oracle.com (David Holmes) Date: Thu, 10 Nov 2011 21:31:49 +1000 Subject: RFE: Add compressed oops to VM info string In-Reply-To: References: Message-ID: <4EBBB625.7040000@oracle.com> Volker, On 10/11/2011 9:16 PM, Volker Simonis wrote: > first I want to say that I like and support your enhancement request. > > However once we do this, if would suggest printing other information as well. > Particularly the fact if we're using tiered compilation comes to my mind here. AFAIK tiered replaces "mixed-mode". The possible values are: - interpreted - Xcomp - mixed-mode - tiered David ----- > I would therefore suggest to use a less verbose "compressed oops" > string and also > print the concrete compressed oops mode that's actually used > (unscaled, zerobased, heapbased). > This information may be particularly usefull because it may change > depending on the users heap setting > and the current system memory situation. > > So finally, we could use something like: > > OpenJDK 64-Bit Server VM (build 20.0-b11-internal, mixed mode, tiered, > compr-oops=unscaled) > > For such a version string, it would be probably better to construct > the string on the fly, otherwise > the 'info_strs' struct you are currently using may become too big. > > What are your opinions? > > Regards, > Volker > > > On Thu, Nov 10, 2011 at 8:54 AM, Krystal Mok wrote: >> Hi all, >> I'd like to propose to add "compressed oops" to the VM info string, so that >> people using "java -version" can get a better understanding of the >> ergonomics of the VM. >> I've posted a patch [1], against hsx20's master. The files modified are >> still pretty much the same on hotspot-main's master. >> With the patch applied, "java -version" may show: >> OpenJDK 64-Bit Server VM (build 20.0-b11-internal, mixed mode, compressed >> oops) >> and what used to work still works: >> OpenJDK Client VM (build 20.0-b11-internal, mixed mode, sharing) >> P.S. Alibaba (Taobao)'s OCA is submitted already, still waiting for approval >> from Oracle. >> Regards, >> Kris Mok >> Software Engineer, Taobao (http://www.taobao.com) >> [1]: https://gist.github.com/1354299 From christian.thalinger at oracle.com Thu Nov 10 03:37:16 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 10 Nov 2011 12:37:16 +0100 Subject: RFE: Add compressed oops to VM info string In-Reply-To: <4EBBB625.7040000@oracle.com> References: <4EBBB625.7040000@oracle.com> Message-ID: On Nov 10, 2011, at 12:31 PM, David Holmes wrote: > Volker, > > On 10/11/2011 9:16 PM, Volker Simonis wrote: >> first I want to say that I like and support your enhancement request. >> >> However once we do this, if would suggest printing other information as well. >> Particularly the fact if we're using tiered compilation comes to my mind here. > > AFAIK tiered replaces "mixed-mode". The possible values are: > - interpreted > - Xcomp > - mixed-mode > - tiered No, that's not correct: $ java -XX:+TieredCompilation -version VM option '+TieredCompilation' java version "1.8.0-ea" Java(TM) SE Runtime Environment (build 1.8.0-ea-b12) Java HotSpot(TM) Server VM (build 23.0-b03-internal-fastdebug, mixed mode) -- Chris > > David > ----- > >> I would therefore suggest to use a less verbose "compressed oops" >> string and also >> print the concrete compressed oops mode that's actually used >> (unscaled, zerobased, heapbased). >> This information may be particularly usefull because it may change >> depending on the users heap setting >> and the current system memory situation. >> >> So finally, we could use something like: >> >> OpenJDK 64-Bit Server VM (build 20.0-b11-internal, mixed mode, tiered, >> compr-oops=unscaled) >> >> For such a version string, it would be probably better to construct >> the string on the fly, otherwise >> the 'info_strs' struct you are currently using may become too big. >> >> What are your opinions? >> >> Regards, >> Volker >> >> >> On Thu, Nov 10, 2011 at 8:54 AM, Krystal Mok wrote: >>> Hi all, >>> I'd like to propose to add "compressed oops" to the VM info string, so that >>> people using "java -version" can get a better understanding of the >>> ergonomics of the VM. >>> I've posted a patch [1], against hsx20's master. The files modified are >>> still pretty much the same on hotspot-main's master. >>> With the patch applied, "java -version" may show: >>> OpenJDK 64-Bit Server VM (build 20.0-b11-internal, mixed mode, compressed >>> oops) >>> and what used to work still works: >>> OpenJDK Client VM (build 20.0-b11-internal, mixed mode, sharing) >>> P.S. Alibaba (Taobao)'s OCA is submitted already, still waiting for approval >>> from Oracle. >>> Regards, >>> Kris Mok >>> Software Engineer, Taobao (http://www.taobao.com) >>> [1]: https://gist.github.com/1354299 From christian.thalinger at oracle.com Thu Nov 10 03:38:05 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 10 Nov 2011 12:38:05 +0100 Subject: RFE: Add compressed oops to VM info string In-Reply-To: <4EBBB347.1080103@oracle.com> References: <4EBBB347.1080103@oracle.com> Message-ID: <786F3DCE-8FA4-4F2C-9C95-9FE0489D5D75@oracle.com> On Nov 10, 2011, at 12:19 PM, David Holmes wrote: > Hi Kris, > > On 10/11/2011 5:54 PM, Krystal Mok wrote: >> Hi all, >> >> I'd like to propose to add "compressed oops" to the VM info string, so >> that people using "java -version" can get a better understanding of the >> ergonomics of the VM. > > You could make the same argument for showing what GC was selected ...and that would be very helpful. -- Chris > , and probably a number of other settings. Why should compressed oops be special here? You can use -XX:+PrintFlagsFinal to see all the settings. > > David > ----- > >> I've posted a patch [1], against hsx20's master. The files modified are >> still pretty much the same on hotspot-main's master. >> >> With the patch applied, "java -version" may show: >> OpenJDK 64-Bit Server VM (build 20.0-b11-internal, mixed mode, >> compressed oops) >> and what used to work still works: >> OpenJDK Client VM (build 20.0-b11-internal, mixed mode, sharing) >> >> P.S. Alibaba (Taobao)'s OCA is submitted already, still waiting for >> approval from Oracle. >> >> Regards, >> Kris Mok >> Software Engineer, Taobao (http://www.taobao.com) >> >> [1]: https://gist.github.com/1354299 From christian.thalinger at oracle.com Thu Nov 10 03:44:01 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 10 Nov 2011 12:44:01 +0100 Subject: RFE: Add compressed oops to VM info string In-Reply-To: References: Message-ID: On Nov 10, 2011, at 12:16 PM, Volker Simonis wrote: > Hi Kris, > > first I want to say that I like and support your enhancement request. > > However once we do this, if would suggest printing other information as well. > Particularly the fact if we're using tiered compilation comes to my mind here. > > I would therefore suggest to use a less verbose "compressed oops" > string and also > print the concrete compressed oops mode that's actually used > (unscaled, zerobased, heapbased). > This information may be particularly usefull because it may change > depending on the users heap setting > and the current system memory situation. > > So finally, we could use something like: > > OpenJDK 64-Bit Server VM (build 20.0-b11-internal, mixed mode, tiered, > compr-oops=unscaled) Honestly I don't know what it takes to change that string since it's a public known option. But my personal opinion is: print the most important runtime settings like JIT mode, GC used, compressed oops mode. Something along these lines: Java HotSpot(TM) Server VM (build 23.0-b03, mixed mode, tiered, serial gc, zerobased coops) Just my two cents... -- Chris > > For such a version string, it would be probably better to construct > the string on the fly, otherwise > the 'info_strs' struct you are currently using may become too big. > > What are your opinions? > > Regards, > Volker > > > On Thu, Nov 10, 2011 at 8:54 AM, Krystal Mok wrote: >> Hi all, >> I'd like to propose to add "compressed oops" to the VM info string, so that >> people using "java -version" can get a better understanding of the >> ergonomics of the VM. >> I've posted a patch [1], against hsx20's master. The files modified are >> still pretty much the same on hotspot-main's master. >> With the patch applied, "java -version" may show: >> OpenJDK 64-Bit Server VM (build 20.0-b11-internal, mixed mode, compressed >> oops) >> and what used to work still works: >> OpenJDK Client VM (build 20.0-b11-internal, mixed mode, sharing) >> P.S. Alibaba (Taobao)'s OCA is submitted already, still waiting for approval >> from Oracle. >> Regards, >> Kris Mok >> Software Engineer, Taobao (http://www.taobao.com) >> [1]: https://gist.github.com/1354299 From david.holmes at oracle.com Thu Nov 10 03:59:22 2011 From: david.holmes at oracle.com (David Holmes) Date: Thu, 10 Nov 2011 21:59:22 +1000 Subject: RFE: Add compressed oops to VM info string In-Reply-To: References: <4EBBB625.7040000@oracle.com> Message-ID: <4EBBBC9A.80205@oracle.com> On 10/11/2011 9:37 PM, Christian Thalinger wrote: > On Nov 10, 2011, at 12:31 PM, David Holmes wrote: >> On 10/11/2011 9:16 PM, Volker Simonis wrote: >>> first I want to say that I like and support your enhancement request. >>> >>> However once we do this, if would suggest printing other information as well. >>> Particularly the fact if we're using tiered compilation comes to my mind here. >> >> AFAIK tiered replaces "mixed-mode". The possible values are: >> - interpreted >> - Xcomp >> - mixed-mode >> - tiered > > No, that's not correct: Thanks Chris - my apologies as I was mis-remembering something. That something was that a long time ago if the VM was built as Tiered then it reported "Tiered" rather than "Server" or "Client" in the version string. (See 6575876) David ----- > $ java -XX:+TieredCompilation -version > VM option '+TieredCompilation' > java version "1.8.0-ea" > Java(TM) SE Runtime Environment (build 1.8.0-ea-b12) > Java HotSpot(TM) Server VM (build 23.0-b03-internal-fastdebug, mixed mode) > > -- Chris > >> >> David >> ----- >> >>> I would therefore suggest to use a less verbose "compressed oops" >>> string and also >>> print the concrete compressed oops mode that's actually used >>> (unscaled, zerobased, heapbased). >>> This information may be particularly usefull because it may change >>> depending on the users heap setting >>> and the current system memory situation. >>> >>> So finally, we could use something like: >>> >>> OpenJDK 64-Bit Server VM (build 20.0-b11-internal, mixed mode, tiered, >>> compr-oops=unscaled) >>> >>> For such a version string, it would be probably better to construct >>> the string on the fly, otherwise >>> the 'info_strs' struct you are currently using may become too big. >>> >>> What are your opinions? >>> >>> Regards, >>> Volker >>> >>> >>> On Thu, Nov 10, 2011 at 8:54 AM, Krystal Mok wrote: >>>> Hi all, >>>> I'd like to propose to add "compressed oops" to the VM info string, so that >>>> people using "java -version" can get a better understanding of the >>>> ergonomics of the VM. >>>> I've posted a patch [1], against hsx20's master. The files modified are >>>> still pretty much the same on hotspot-main's master. >>>> With the patch applied, "java -version" may show: >>>> OpenJDK 64-Bit Server VM (build 20.0-b11-internal, mixed mode, compressed >>>> oops) >>>> and what used to work still works: >>>> OpenJDK Client VM (build 20.0-b11-internal, mixed mode, sharing) >>>> P.S. Alibaba (Taobao)'s OCA is submitted already, still waiting for approval >>>> from Oracle. >>>> Regards, >>>> Kris Mok >>>> Software Engineer, Taobao (http://www.taobao.com) >>>> [1]: https://gist.github.com/1354299 > From david.holmes at oracle.com Thu Nov 10 04:01:03 2011 From: david.holmes at oracle.com (David Holmes) Date: Thu, 10 Nov 2011 22:01:03 +1000 Subject: XS RFR: 7108264 - Fix for 7104173 is insufficient In-Reply-To: <0EA2A838-EF75-4F9D-8692-09ACDC30CFD7@oracle.com> References: <4EBB57FF.3000901@oracle.com> <0EA2A838-EF75-4F9D-8692-09ACDC30CFD7@oracle.com> Message-ID: <4EBBBCFF.2010107@oracle.com> Thanks Chris and Dmitry. Fix has been submitted. David On 10/11/2011 7:08 PM, Christian Thalinger wrote: > Looks good. -- Chris > > On Nov 10, 2011, at 5:50 AM, David Holmes wrote: > >> The original fix (7104173) was discussed here: >> >> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2011-October/002510.html >> >> That fix missed the fact that non-embedded builds would still fail these tests. The new solution simply disables PrintVMOptions by default, in all cases. >> >> webrev: http://cr.openjdk.java.net/~dholmes/7108264/webrev/ >> >> This has been run through our internal test suites to ensure no unforeseen regressions. >> >> Thanks, >> David > From fweimer at bfk.de Thu Nov 10 04:23:17 2011 From: fweimer at bfk.de (Florian Weimer) Date: Thu, 10 Nov 2011 12:23:17 +0000 Subject: Reduce cap on maximum heap size? Message-ID: <8239dwp3nu.fsf@mid.bfk.de> It seems that in OpenJDK 7, there isn't a useful limit on the automatically configured maximum heap size. With 48 GB on a Linux system (amd64), the default choice is 12 GB, which means that scaled compressed oops which have a performance impact are used, as far as I understand it. Would it make sense to cap the maximum heap size around 1.5 GB instead? -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra?e 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From tony.printezis at oracle.com Thu Nov 10 04:52:42 2011 From: tony.printezis at oracle.com (Tony Printezis) Date: Thu, 10 Nov 2011 07:52:42 -0500 Subject: Reduce cap on maximum heap size? In-Reply-To: <8239dwp3nu.fsf@mid.bfk.de> References: <8239dwp3nu.fsf@mid.bfk.de> Message-ID: <4EBBC91A.7050402@oracle.com> Florian, compressed oops should have similar performance to the 32-bit JVM in most situations (you lose some given that the JVM still uses 64-bit references, you gain some given that 64-bit architectures typically have more registers available to the JIT compiler). With regards to capping the default heap size: this is a policy for which whatever we do we just cannot please everyone. I'm sure there will be lots of people on this list that in fact will tell us NOT to cap it (or increase it to take up most of the machine's physical memory). So, if you'd like a smaller heap size (or the 32-bit JVM) please use the appropriate parameters when you launch the JVM. Regards, Tony On 11/10/2011 07:23 AM, Florian Weimer wrote: > It seems that in OpenJDK 7, there isn't a useful limit on the > automatically configured maximum heap size. With 48 GB on a Linux > system (amd64), the default choice is 12 GB, which means that scaled > compressed oops which have a performance impact are used, as far as I > understand it. > > Would it make sense to cap the maximum heap size around 1.5 GB instead? > From volker.simonis at gmail.com Thu Nov 10 05:18:50 2011 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 10 Nov 2011 14:18:50 +0100 Subject: RFE: Add compressed oops to VM info string In-Reply-To: References: Message-ID: +1 from me On Thu, Nov 10, 2011 at 12:44 PM, Christian Thalinger wrote: > > On Nov 10, 2011, at 12:16 PM, Volker Simonis wrote: > >> Hi Kris, >> >> first I want to say that I like and support your enhancement request. >> >> However once we do this, if would suggest printing other information as well. >> Particularly the fact if we're using tiered compilation comes to my mind here. >> >> I would therefore suggest to use a less verbose "compressed oops" >> string and also >> print the concrete compressed oops mode that's ?actually used >> (unscaled, zerobased, heapbased). >> This information may be particularly usefull because it may change >> depending on the users heap setting >> and ?the current system memory situation. >> >> So finally, we could use something like: >> >> OpenJDK 64-Bit Server VM (build 20.0-b11-internal, mixed mode, tiered, >> compr-oops=unscaled) > > Honestly I don't know what it takes to change that string since it's a public known option. ?But my personal opinion is: ?print the most important runtime settings like JIT mode, GC used, compressed oops mode. ?Something along these lines: > > Java HotSpot(TM) Server VM (build 23.0-b03, mixed mode, tiered, serial gc, zerobased coops) > > Just my two cents... > > -- Chris > >> >> For such a version string, it would be probably better to construct >> the string on the fly, otherwise >> the 'info_strs' struct you are currently using may become too big. >> >> What are your opinions? >> >> Regards, >> Volker >> >> >> On Thu, Nov 10, 2011 at 8:54 AM, Krystal Mok wrote: >>> Hi all, >>> I'd like to propose to add "compressed oops" to the VM info string, so that >>> people using "java -version" can get a better understanding of the >>> ergonomics of the VM. >>> I've posted a patch [1], against hsx20's master. The files modified are >>> still pretty much the same on hotspot-main's master. >>> With the patch applied, "java -version" may show: >>> OpenJDK 64-Bit Server VM (build 20.0-b11-internal, mixed mode, compressed >>> oops) >>> and what used to work still works: >>> OpenJDK Client VM (build 20.0-b11-internal, mixed mode, sharing) >>> P.S. Alibaba (Taobao)'s OCA is submitted already, still waiting for approval >>> from Oracle. >>> Regards, >>> Kris Mok >>> Software Engineer, Taobao (http://www.taobao.com) >>> [1]: https://gist.github.com/1354299 > > From fweimer at bfk.de Thu Nov 10 05:50:21 2011 From: fweimer at bfk.de (Florian Weimer) Date: Thu, 10 Nov 2011 13:50:21 +0000 Subject: Reduce cap on maximum heap size? In-Reply-To: <4EBBC91A.7050402@oracle.com> (Tony Printezis's message of "Thu, 10 Nov 2011 07:52:42 -0500") References: <8239dwp3nu.fsf@mid.bfk.de> <4EBBC91A.7050402@oracle.com> Message-ID: <82vcqsnl2a.fsf@mid.bfk.de> * Tony Printezis: > compressed oops should have similar performance to the 32-bit JVM in > most situations (you lose some given that the JVM still uses 64-bit > references, you gain some given that 64-bit architectures typically > have more registers available to the JIT compiler). There used to be several variants of compressed oops: zero-based unscaled, zero-based scaled, and offseted and scaled, depending on where the heap segment is located in the process address space. The zero-based unscaled encoding does not need an address decoding step and should therefore be faster. However, that is only possible if the heap fits within the lowest 4 GB, which is never the case for a 12 GB heap. For example, one of our tools runs like this (median on five runs, including startup time): -Xmx1g 4194ms (6184ms user+system) default 4428ms (6620ms user+system) -Xmx40g 4351ms (6232ms user+system) (The old generation is never collected, even with the 1GB heap.) I understand that there is a difficult trade-off, but increasing the default heap size to scaled compressed oops seems to have its costs. -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra?e 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From coleen.phillimore at oracle.com Thu Nov 10 06:56:47 2011 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 10 Nov 2011 09:56:47 -0500 Subject: XS RFR: 7108264 - Fix for 7104173 is insufficient In-Reply-To: <0EA2A838-EF75-4F9D-8692-09ACDC30CFD7@oracle.com> References: <4EBB57FF.3000901@oracle.com> <0EA2A838-EF75-4F9D-8692-09ACDC30CFD7@oracle.com> Message-ID: <4EBBE62F.1090103@oracle.com> Looks good to me too. Thanks for the extra effort in verifying that it doesn't break any of the SQE testing. Coleen On 11/10/2011 4:08 AM, Christian Thalinger wrote: > Looks good. -- Chris > > On Nov 10, 2011, at 5:50 AM, David Holmes wrote: > >> The original fix (7104173) was discussed here: >> >> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2011-October/002510.html >> >> That fix missed the fact that non-embedded builds would still fail these tests. The new solution simply disables PrintVMOptions by default, in all cases. >> >> webrev: http://cr.openjdk.java.net/~dholmes/7108264/webrev/ >> >> This has been run through our internal test suites to ensure no unforeseen regressions. >> >> Thanks, >> David From paul.hohensee at oracle.com Thu Nov 10 07:27:40 2011 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Thu, 10 Nov 2011 10:27:40 -0500 Subject: XS RFR: 7108264 - Fix for 7104173 is insufficient In-Reply-To: <4EBBE62F.1090103@oracle.com> References: <4EBB57FF.3000901@oracle.com> <0EA2A838-EF75-4F9D-8692-09ACDC30CFD7@oracle.com> <4EBBE62F.1090103@oracle.com> Message-ID: <4EBBED6C.106@oracle.com> Ok. Paul On 11/10/11 9:56 AM, Coleen Phillimore wrote: > Looks good to me too. Thanks for the extra effort in verifying that > it doesn't break any of the SQE testing. > Coleen > > On 11/10/2011 4:08 AM, Christian Thalinger wrote: >> Looks good. -- Chris >> >> On Nov 10, 2011, at 5:50 AM, David Holmes wrote: >> >>> The original fix (7104173) was discussed here: >>> >>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2011-October/002510.html >>> >>> >>> That fix missed the fact that non-embedded builds would still fail >>> these tests. The new solution simply disables PrintVMOptions by >>> default, in all cases. >>> >>> webrev: http://cr.openjdk.java.net/~dholmes/7108264/webrev/ >>> >>> This has been run through our internal test suites to ensure no >>> unforeseen regressions. >>> >>> Thanks, >>> David From coleen.phillimore at oracle.com Thu Nov 10 07:38:00 2011 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 10 Nov 2011 10:38:00 -0500 Subject: RFE: Add compressed oops to VM info string In-Reply-To: References: Message-ID: <4EBBEFD8.1040802@oracle.com> This > Java HotSpot(TM) Server VM (build 23.0-b03, mixed mode, tiered, serial gc, zerobased coops) "zerobased coops" looks awkward to me. If the requirement is that you know whether compressed oops is on or off, simply printing "compressed oops" meets that. If you want to know more about the compressed oops mode, you can use the option PrintCompressedOopsMode (not PrintFlagsFinal, which oddly doesn't mention compressed oops). Since adding "compressed oops" to the version string in the error handler was thought important enough for error diagnosis, I think adding it to the version string is an good improvement. I actually thought that's what I'd done in the first place, so I like this change. The code in vm_version is an improvement as well. thanks, Coleen On 11/10/2011 8:18 AM, Volker Simonis wrote: > +1 from me > > On Thu, Nov 10, 2011 at 12:44 PM, Christian Thalinger > wrote: >> On Nov 10, 2011, at 12:16 PM, Volker Simonis wrote: >> >>> Hi Kris, >>> >>> first I want to say that I like and support your enhancement request. >>> >>> However once we do this, if would suggest printing other information as well. >>> Particularly the fact if we're using tiered compilation comes to my mind here. >>> >>> I would therefore suggest to use a less verbose "compressed oops" >>> string and also >>> print the concrete compressed oops mode that's actually used >>> (unscaled, zerobased, heapbased). >>> This information may be particularly usefull because it may change >>> depending on the users heap setting >>> and the current system memory situation. >>> >>> So finally, we could use something like: >>> >>> OpenJDK 64-Bit Server VM (build 20.0-b11-internal, mixed mode, tiered, >>> compr-oops=unscaled) >> Honestly I don't know what it takes to change that string since it's a public known option. But my personal opinion is: print the most important runtime settings like JIT mode, GC used, compressed oops mode. Something along these lines: >> >> Java HotSpot(TM) Server VM (build 23.0-b03, mixed mode, tiered, serial gc, zerobased coops) >> >> Just my two cents... >> >> -- Chris >> >>> For such a version string, it would be probably better to construct >>> the string on the fly, otherwise >>> the 'info_strs' struct you are currently using may become too big. >>> >>> What are your opinions? >>> >>> Regards, >>> Volker >>> >>> >>> On Thu, Nov 10, 2011 at 8:54 AM, Krystal Mok wrote: >>>> Hi all, >>>> I'd like to propose to add "compressed oops" to the VM info string, so that >>>> people using "java -version" can get a better understanding of the >>>> ergonomics of the VM. >>>> I've posted a patch [1], against hsx20's master. The files modified are >>>> still pretty much the same on hotspot-main's master. >>>> With the patch applied, "java -version" may show: >>>> OpenJDK 64-Bit Server VM (build 20.0-b11-internal, mixed mode, compressed >>>> oops) >>>> and what used to work still works: >>>> OpenJDK Client VM (build 20.0-b11-internal, mixed mode, sharing) >>>> P.S. Alibaba (Taobao)'s OCA is submitted already, still waiting for approval >>>> from Oracle. >>>> Regards, >>>> Kris Mok >>>> Software Engineer, Taobao (http://www.taobao.com) >>>> [1]: https://gist.github.com/1354299 >> From joe.darcy at oracle.com Thu Nov 10 07:41:33 2011 From: joe.darcy at oracle.com (Joe Darcy) Date: Thu, 10 Nov 2011 07:41:33 -0800 Subject: RFE: Add compressed oops to VM info string In-Reply-To: <4EBBB347.1080103@oracle.com> References: <4EBBB347.1080103@oracle.com> Message-ID: <4EBBF0AD.7030106@oracle.com> Hello, On 11/10/2011 3:19 AM, David Holmes wrote: > Hi Kris, > > On 10/11/2011 5:54 PM, Krystal Mok wrote: >> Hi all, >> >> I'd like to propose to add "compressed oops" to the VM info string, so >> that people using "java -version" can get a better understanding of the >> ergonomics of the VM. > > You could make the same argument for showing what GC was selected, and > probably a number of other settings. Why should compressed oops be > special here? You can use -XX:+PrintFlagsFinal to see all the settings. To me anyway, compressed oops status don't rise to the level of information that should be printed out by default by java -version. Without pretty detailed knowledge of the particulars of the optimization, it is not clear what the various settings mean. This would be good information to make available under another flag though. -Joe From fweimer at bfk.de Thu Nov 10 07:43:24 2011 From: fweimer at bfk.de (Florian Weimer) Date: Thu, 10 Nov 2011 15:43:24 +0000 Subject: RFE: Add compressed oops to VM info string In-Reply-To: <4EBBEFD8.1040802@oracle.com> (Coleen Phillimore's message of "Thu, 10 Nov 2011 10:38:00 -0500") References: <4EBBEFD8.1040802@oracle.com> Message-ID: <82d3d0nftv.fsf@mid.bfk.de> * Coleen Phillimore: > This >> Java HotSpot(TM) Server VM (build 23.0-b03, mixed mode, tiered, serial gc, zerobased coops) > "zerobased coops" looks awkward to me. If the requirement is that > you know whether compressed oops is on or off, simply printing > "compressed oops" meets that. If you want to know more about the > compressed oops mode, you can use the option PrintCompressedOopsMode > (not PrintFlagsFinal, which oddly doesn't mention compressed oops). This option is guarded by -XX:+UnlockDiagnosticVMOptions (for my future reference 8-). -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra?e 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From paul.hohensee at oracle.com Thu Nov 10 08:01:18 2011 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Thu, 10 Nov 2011 11:01:18 -0500 Subject: RFE: Add compressed oops to VM info string In-Reply-To: References: Message-ID: <4EBBF54E.1060104@oracle.com> I don't think the version string is the place for dumping ergo decision results, rather I agree with David Holmes and Joe that PrintFlagsFinal, PrintCommandLineFlags, or some other switch should be used. We shouldn't have "mixed mode", etc. in the string either, but given that they're there we're kinda stuck with them. The reason we have "Server" and "Client" (and "Embedded, btw) is to distinguish builds that are statically different. Tiered got folded into Server awhile ago, which is why it's no longer mentioned in the version string. Changing the version string is a non-trivial thing to do: it has to go through an approval process because it's a supported public interface. There are, e.g., quite a few version string parsers out there that wouldn't take kindly to change. Paul On 11/10/11 8:18 AM, Volker Simonis wrote: > +1 from me > > On Thu, Nov 10, 2011 at 12:44 PM, Christian Thalinger > wrote: >> On Nov 10, 2011, at 12:16 PM, Volker Simonis wrote: >> >>> Hi Kris, >>> >>> first I want to say that I like and support your enhancement request. >>> >>> However once we do this, if would suggest printing other information as well. >>> Particularly the fact if we're using tiered compilation comes to my mind here. >>> >>> I would therefore suggest to use a less verbose "compressed oops" >>> string and also >>> print the concrete compressed oops mode that's actually used >>> (unscaled, zerobased, heapbased). >>> This information may be particularly usefull because it may change >>> depending on the users heap setting >>> and the current system memory situation. >>> >>> So finally, we could use something like: >>> >>> OpenJDK 64-Bit Server VM (build 20.0-b11-internal, mixed mode, tiered, >>> compr-oops=unscaled) >> Honestly I don't know what it takes to change that string since it's a public known option. But my personal opinion is: print the most important runtime settings like JIT mode, GC used, compressed oops mode. Something along these lines: >> >> Java HotSpot(TM) Server VM (build 23.0-b03, mixed mode, tiered, serial gc, zerobased coops) >> >> Just my two cents... >> >> -- Chris >> >>> For such a version string, it would be probably better to construct >>> the string on the fly, otherwise >>> the 'info_strs' struct you are currently using may become too big. >>> >>> What are your opinions? >>> >>> Regards, >>> Volker >>> >>> >>> On Thu, Nov 10, 2011 at 8:54 AM, Krystal Mok wrote: >>>> Hi all, >>>> I'd like to propose to add "compressed oops" to the VM info string, so that >>>> people using "java -version" can get a better understanding of the >>>> ergonomics of the VM. >>>> I've posted a patch [1], against hsx20's master. The files modified are >>>> still pretty much the same on hotspot-main's master. >>>> With the patch applied, "java -version" may show: >>>> OpenJDK 64-Bit Server VM (build 20.0-b11-internal, mixed mode, compressed >>>> oops) >>>> and what used to work still works: >>>> OpenJDK Client VM (build 20.0-b11-internal, mixed mode, sharing) >>>> P.S. Alibaba (Taobao)'s OCA is submitted already, still waiting for approval >>>> from Oracle. >>>> Regards, >>>> Kris Mok >>>> Software Engineer, Taobao (http://www.taobao.com) >>>> [1]: https://gist.github.com/1354299 >> From coleen.phillimore at oracle.com Thu Nov 10 08:33:51 2011 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 10 Nov 2011 11:33:51 -0500 Subject: RFE: Add compressed oops to VM info string In-Reply-To: <4EBBF54E.1060104@oracle.com> References: <4EBBF54E.1060104@oracle.com> Message-ID: <4EBBFCEF.1080402@oracle.com> On 11/10/2011 11:01 AM, Paul Hohensee wrote: > I don't think the version string is the place for dumping ergo > decision results, > rather I agree with David Holmes and Joe that PrintFlagsFinal, > PrintCommandLineFlags, > or some other switch should be used. We shouldn't have "mixed mode", > etc. in the > string either, but given that they're there we're kinda stuck with them. PrintCommandLineFlags (which should be something like PrintErgoFlags imho) is okay for printing ergonomics decisions, except it doesn't say which mode compressed oops is because that's not a flag. PrintFlagsFinal doesn't mention compressed oops at all. > > The reason we have "Server" and "Client" (and "Embedded, btw) is to > distinguish > builds that are statically different. Tiered got folded into Server > awhile ago, which > is why it's no longer mentioned in the version string. > > Changing the version string is a non-trivial thing to do: it has to go > through > an approval process because it's a supported public interface. There > are, e.g., > quite a few version string parsers out there that wouldn't take kindly > to change. In this case, I won't argue for the change. Thanks, Coleen > > Paul > > On 11/10/11 8:18 AM, Volker Simonis wrote: >> +1 from me >> >> On Thu, Nov 10, 2011 at 12:44 PM, Christian Thalinger >> wrote: >>> On Nov 10, 2011, at 12:16 PM, Volker Simonis wrote: >>> >>>> Hi Kris, >>>> >>>> first I want to say that I like and support your enhancement request. >>>> >>>> However once we do this, if would suggest printing other >>>> information as well. >>>> Particularly the fact if we're using tiered compilation comes to my >>>> mind here. >>>> >>>> I would therefore suggest to use a less verbose "compressed oops" >>>> string and also >>>> print the concrete compressed oops mode that's actually used >>>> (unscaled, zerobased, heapbased). >>>> This information may be particularly usefull because it may change >>>> depending on the users heap setting >>>> and the current system memory situation. >>>> >>>> So finally, we could use something like: >>>> >>>> OpenJDK 64-Bit Server VM (build 20.0-b11-internal, mixed mode, tiered, >>>> compr-oops=unscaled) >>> Honestly I don't know what it takes to change that string since it's >>> a public known option. But my personal opinion is: print the most >>> important runtime settings like JIT mode, GC used, compressed oops >>> mode. Something along these lines: >>> >>> Java HotSpot(TM) Server VM (build 23.0-b03, mixed mode, tiered, >>> serial gc, zerobased coops) >>> >>> Just my two cents... >>> >>> -- Chris >>> >>>> For such a version string, it would be probably better to construct >>>> the string on the fly, otherwise >>>> the 'info_strs' struct you are currently using may become too big. >>>> >>>> What are your opinions? >>>> >>>> Regards, >>>> Volker >>>> >>>> >>>> On Thu, Nov 10, 2011 at 8:54 AM, Krystal >>>> Mok wrote: >>>>> Hi all, >>>>> I'd like to propose to add "compressed oops" to the VM info >>>>> string, so that >>>>> people using "java -version" can get a better understanding of the >>>>> ergonomics of the VM. >>>>> I've posted a patch [1], against hsx20's master. The files >>>>> modified are >>>>> still pretty much the same on hotspot-main's master. >>>>> With the patch applied, "java -version" may show: >>>>> OpenJDK 64-Bit Server VM (build 20.0-b11-internal, mixed mode, >>>>> compressed >>>>> oops) >>>>> and what used to work still works: >>>>> OpenJDK Client VM (build 20.0-b11-internal, mixed mode, sharing) >>>>> P.S. Alibaba (Taobao)'s OCA is submitted already, still waiting >>>>> for approval >>>>> from Oracle. >>>>> Regards, >>>>> Kris Mok >>>>> Software Engineer, Taobao (http://www.taobao.com) >>>>> [1]: https://gist.github.com/1354299 >>> From kelly.ohair at oracle.com Thu Nov 10 08:43:51 2011 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Thu, 10 Nov 2011 11:43:51 -0500 Subject: RFE: Add compressed oops to VM info string In-Reply-To: <4EBBF54E.1060104@oracle.com> References: <4EBBF54E.1060104@oracle.com> Message-ID: On Nov 10, 2011, at 11:01 AM, Paul Hohensee wrote: > Changing the version string is a non-trivial thing to do: it has to go through > an approval process because it's a supported public interface. There are, e.g., > quite a few version string parsers out there that wouldn't take kindly to change. > > Paul Yup. Nasty version creatures out there, take a sharp knife with you. ;^) -kto -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20111110/ebc13fe5/attachment.html From mandy.chung at oracle.com Thu Nov 10 10:02:43 2011 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 10 Nov 2011 10:02:43 -0800 Subject: RFE: Add compressed oops to VM info string In-Reply-To: <4EBBF54E.1060104@oracle.com> References: <4EBBF54E.1060104@oracle.com> Message-ID: <4EBC11C3.1000705@oracle.com> FWIW. Kumar added an internal option -XshowSettings to the launcher in JDK 7 to print various VM and java settings. This could be a potential place to include "compressed oops" and other VM ergonomic setting in. It takes an optional suboption "all, vm, properties, locale". $ java -XshowSettings:vm VM settings: Stack Size: 320.00K Max. Heap Size (Estimated): 910.00M Ergonomics Machine Class: server Using VM: Java HotSpot(TM) Server VM [snip..] java -XshowSettings -version doesn't print the additional information. I haven't spent time looking into the reason why. Mandy On 11/10/11 08:01, Paul Hohensee wrote: > I don't think the version string is the place for dumping ergo > decision results, > rather I agree with David Holmes and Joe that PrintFlagsFinal, > PrintCommandLineFlags, > or some other switch should be used. We shouldn't have "mixed mode", > etc. in the > string either, but given that they're there we're kinda stuck with them. > > The reason we have "Server" and "Client" (and "Embedded, btw) is to > distinguish > builds that are statically different. Tiered got folded into Server > awhile ago, which > is why it's no longer mentioned in the version string. > > Changing the version string is a non-trivial thing to do: it has to go > through > an approval process because it's a supported public interface. There > are, e.g., > quite a few version string parsers out there that wouldn't take kindly > to change. > > Paul > > On 11/10/11 8:18 AM, Volker Simonis wrote: >> +1 from me >> >> On Thu, Nov 10, 2011 at 12:44 PM, Christian Thalinger >> wrote: >>> On Nov 10, 2011, at 12:16 PM, Volker Simonis wrote: >>> >>>> Hi Kris, >>>> >>>> first I want to say that I like and support your enhancement request. >>>> >>>> However once we do this, if would suggest printing other >>>> information as well. >>>> Particularly the fact if we're using tiered compilation comes to my >>>> mind here. >>>> >>>> I would therefore suggest to use a less verbose "compressed oops" >>>> string and also >>>> print the concrete compressed oops mode that's actually used >>>> (unscaled, zerobased, heapbased). >>>> This information may be particularly usefull because it may change >>>> depending on the users heap setting >>>> and the current system memory situation. >>>> >>>> So finally, we could use something like: >>>> >>>> OpenJDK 64-Bit Server VM (build 20.0-b11-internal, mixed mode, tiered, >>>> compr-oops=unscaled) >>> Honestly I don't know what it takes to change that string since it's >>> a public known option. But my personal opinion is: print the most >>> important runtime settings like JIT mode, GC used, compressed oops >>> mode. Something along these lines: >>> >>> Java HotSpot(TM) Server VM (build 23.0-b03, mixed mode, tiered, >>> serial gc, zerobased coops) >>> >>> Just my two cents... >>> >>> -- Chris >>> >>>> For such a version string, it would be probably better to construct >>>> the string on the fly, otherwise >>>> the 'info_strs' struct you are currently using may become too big. >>>> >>>> What are your opinions? >>>> >>>> Regards, >>>> Volker >>>> >>>> >>>> On Thu, Nov 10, 2011 at 8:54 AM, Krystal >>>> Mok wrote: >>>>> Hi all, >>>>> I'd like to propose to add "compressed oops" to the VM info >>>>> string, so that >>>>> people using "java -version" can get a better understanding of the >>>>> ergonomics of the VM. >>>>> I've posted a patch [1], against hsx20's master. The files >>>>> modified are >>>>> still pretty much the same on hotspot-main's master. >>>>> With the patch applied, "java -version" may show: >>>>> OpenJDK 64-Bit Server VM (build 20.0-b11-internal, mixed mode, >>>>> compressed >>>>> oops) >>>>> and what used to work still works: >>>>> OpenJDK Client VM (build 20.0-b11-internal, mixed mode, sharing) >>>>> P.S. Alibaba (Taobao)'s OCA is submitted already, still waiting >>>>> for approval >>>>> from Oracle. >>>>> Regards, >>>>> Kris Mok >>>>> Software Engineer, Taobao (http://www.taobao.com) >>>>> [1]: https://gist.github.com/1354299 >>> From christian.thalinger at oracle.com Thu Nov 10 10:07:26 2011 From: christian.thalinger at oracle.com (christian.thalinger at oracle.com) Date: Thu, 10 Nov 2011 18:07:26 +0000 Subject: hg: hsx/hotspot-main/hotspot: 27 new changesets Message-ID: <20111110180822.DEBAE472F3@hg.openjdk.java.net> Changeset: 5bda8dae4e14 Author: never Date: 2011-10-23 20:23 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/5bda8dae4e14 7103784: enable some flags by default Reviewed-by: kvn ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp Changeset: 754110e02bd5 Author: never Date: 2011-10-23 12:31 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/754110e02bd5 7103380: assertion failure with -XX:+PrintNativeNMethods Reviewed-by: kvn, iveresov ! src/share/vm/asm/codeBuffer.cpp Changeset: 42783d1414b2 Author: never Date: 2011-10-23 23:57 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/42783d1414b2 Merge - make/templates/bsd-header Changeset: b20d64f83668 Author: twisti Date: 2011-10-24 07:53 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/b20d64f83668 7090904: JSR 292: JRuby junit test crashes in PSScavengeRootsClosure::do_oop Reviewed-by: kvn, never, jrose ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp ! src/share/vm/interpreter/bytecodeTracer.cpp ! src/share/vm/runtime/deoptimization.cpp ! src/share/vm/runtime/frame.cpp ! src/share/vm/runtime/frame.hpp ! src/share/vm/runtime/thread.cpp Changeset: 12d38ffcba2a Author: twisti Date: 2011-10-25 00:55 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/12d38ffcba2a 7094138: JSR 292: JRuby junit test fails in CallSite.setTargetNormal: obj->is_oop() failed: sanity check Reviewed-by: iveresov, never ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/prims/unsafe.cpp Changeset: 2ec638646e86 Author: twisti Date: 2011-10-25 04:07 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/2ec638646e86 7101642: JSR 292: SIGSEGV in java.lang.invoke.MethodHandleImpl$FieldAccessor.getFieldI(Ljava/lang/Object;)I Reviewed-by: kvn, iveresov ! src/share/vm/runtime/sharedRuntime.cpp Changeset: a6eef545f1a2 Author: never Date: 2011-10-25 08:17 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/a6eef545f1a2 7103224: collision between __LEAF define in interfaceSupport.hpp and /usr/include/sys/cdefs.h with gcc Reviewed-by: never Contributed-by: Omair Majid ! src/share/vm/opto/addnode.cpp ! src/share/vm/prims/jniCheck.cpp ! src/share/vm/prims/jvmtiEnter.xsl ! src/share/vm/prims/jvmtiEnv.cpp ! src/share/vm/prims/jvmtiExport.cpp ! src/share/vm/runtime/interfaceSupport.hpp Changeset: e69a66a1457b Author: kvn Date: 2011-10-25 12:51 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/e69a66a1457b 7059039: EA: don't change non-escaping state of NULL pointer Summary: NULL pointers do not escape but escape state propagation may change it leading to worser results. Reviewed-by: never ! src/share/vm/opto/escape.cpp Changeset: d8cb48376797 Author: kvn Date: 2011-10-26 06:08 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/d8cb48376797 7097546: Optimize use of CMOVE instructions Summary: Avoid CMove in a loop if possible. May generate CMove if it could be moved outside a loop. Reviewed-by: never ! src/cpu/sparc/vm/sparc.ad ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/opto/loopopts.cpp ! src/share/vm/opto/matcher.hpp Changeset: cec1757a0134 Author: twisti Date: 2011-10-27 04:43 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/cec1757a0134 7102657: JSR 292: C1 deoptimizes unlinked invokedynamic call sites infinitely Reviewed-by: never, bdelsart ! src/cpu/sparc/vm/c1_CodeStubs_sparc.cpp ! src/cpu/sparc/vm/c1_Runtime1_sparc.cpp ! src/cpu/x86/vm/c1_CodeStubs_x86.cpp ! src/cpu/x86/vm/c1_Runtime1_x86.cpp ! src/share/vm/c1/c1_Runtime1.cpp ! src/share/vm/c1/c1_Runtime1.hpp ! src/share/vm/opto/runtime.cpp Changeset: e0658a9b3f87 Author: kvn Date: 2011-10-27 09:39 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/e0658a9b3f87 7105364: JDK8 b10 hotspot: src/share/vm/ci/ciMethodHandle.cpp Error: Use "." or "->" Summary: Define ciMethodHandle::print_chain_impl() and ciMethodHandle::print_chain() bodies only in debug builds. Reviewed-by: never, twisti ! src/share/vm/ci/ciMethodHandle.cpp ! src/share/vm/ci/ciMethodHandle.hpp Changeset: 34535d2cb362 Author: iveresov Date: 2011-10-27 14:40 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/34535d2cb362 7104177: Tiered: -XX:+PrintCanonicalization doesn't work with -XX:+TieredCompilation Summary: Initialize printable_bci of instruction when passed to Canonicalizer Reviewed-by: kvn, never ! src/share/vm/c1/c1_Canonicalizer.hpp Changeset: f350490a45fd Author: kvn Date: 2011-10-27 18:20 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/f350490a45fd 7105611: Set::print() is broken Summary: Reimplemented class VSetI_ to restore Set::print(). Reviewed-by: never ! src/share/vm/libadt/vectset.cpp ! src/share/vm/libadt/vectset.hpp Changeset: eba044a722a4 Author: never Date: 2011-10-28 14:44 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/eba044a722a4 7103261: crash with jittester on sparc Reviewed-by: iveresov, kvn ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp + test/compiler/7103261/Test7103261.java Changeset: e3b0dcc327b9 Author: twisti Date: 2011-10-31 03:06 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/e3b0dcc327b9 7104561: UseRDPCForConstantTableBase doesn't work after shorten branches changes Reviewed-by: never, kvn ! src/cpu/sparc/vm/vm_version_sparc.cpp ! src/share/vm/opto/machnode.cpp Changeset: 71699e9d8673 Author: kvn Date: 2011-10-31 15:52 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/71699e9d8673 7106907: 64 bit VM fails test compiler/6865265/StackOverflowBug.java Summary: Use -Xss224k instead of -Xss128k. Reviewed-by: never ! test/compiler/6865265/StackOverflowBug.java Changeset: e342a5110bed Author: twisti Date: 2011-11-03 01:43 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/e342a5110bed 7106774: JSR 292: nightly test inlineMHTarget fails with wrong result Reviewed-by: kvn ! src/share/vm/interpreter/bytecode.hpp ! src/share/vm/runtime/deoptimization.cpp Changeset: 448691f285a5 Author: twisti Date: 2011-11-03 04:12 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/448691f285a5 7106944: assert(_pc == *pc_addr) failed may be too strong Reviewed-by: kvn, never ! src/cpu/x86/vm/frame_x86.cpp Changeset: 1feb272af3a7 Author: never Date: 2011-11-04 13:55 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/1feb272af3a7 6636110: unaligned stackpointer leads to crash during deoptimization Reviewed-by: never, kvn Contributed-by: Andreas Schoesser ! src/cpu/x86/vm/sharedRuntime_x86_64.cpp Changeset: 59e515ee9354 Author: kvn Date: 2011-11-07 14:33 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/59e515ee9354 7059047: EA: can't find initializing store with several CheckCastPP Summary: Split adjust_escape_state() method into two methods to find initializing stores. Reviewed-by: never ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/escape.hpp Changeset: 44ce519bc3d1 Author: never Date: 2011-11-08 10:31 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/44ce519bc3d1 7104960: JSR 292: +VerifyMethodHandles in product JVM can overflow buffer Reviewed-by: kvn, jrose, twisti ! src/cpu/sparc/vm/assembler_sparc.inline.hpp ! src/cpu/sparc/vm/methodHandles_sparc.cpp ! src/cpu/sparc/vm/methodHandles_sparc.hpp ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/cpu/x86/vm/methodHandles_x86.hpp ! src/share/vm/asm/codeBuffer.cpp ! src/share/vm/asm/codeBuffer.hpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/runtime/globals.hpp Changeset: c9a03402fe56 Author: never Date: 2011-11-08 17:29 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/c9a03402fe56 7105305: assert check_method_context proper context Reviewed-by: jrose, kvn ! src/share/vm/code/dependencies.cpp ! src/share/vm/oops/constantPoolKlass.cpp Changeset: e3e363b2bf19 Author: never Date: 2011-11-08 20:42 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/e3e363b2bf19 7108242: jinfo -permstat shouldn't report interned strings as part of perm Reviewed-by: kvn, twisti ! agent/src/share/classes/sun/jvm/hotspot/tools/HeapSummary.java ! agent/src/share/classes/sun/jvm/hotspot/tools/PermStat.java Changeset: 83d0b5cd1438 Author: twisti Date: 2011-11-09 00:42 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/83d0b5cd1438 7087727: JSR 292: C2 crash if ScavengeRootsInCode=2 when "static final" MethodHandle constants are in use Reviewed-by: jrose, kvn, never ! src/share/vm/opto/callGenerator.cpp Changeset: 7e0e43cf86d6 Author: kvn Date: 2011-11-09 06:14 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/7e0e43cf86d6 7109887: java/util/Arrays/CopyMethods.java fails with -XX:+DeoptimizeALot Summary: zero array when compiled code is deoptimized. Reviewed-by: never, twisti ! src/share/vm/opto/runtime.cpp ! src/share/vm/opto/runtime.hpp Changeset: 670a74b863fc Author: kvn Date: 2011-11-09 07:25 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/670a74b863fc 7107042: assert(no_dead_loop) failed: dead loop detected Summary: Use dead nodes elimination code in PhaseIdealLoop before executing EA. Reviewed-by: never, twisti ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/loopnode.cpp ! src/share/vm/opto/loopnode.hpp ! src/share/vm/opto/loopopts.cpp ! src/share/vm/opto/matcher.cpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/phaseX.cpp ! src/share/vm/runtime/globals.hpp Changeset: 78bef05801ca Author: twisti Date: 2011-11-10 04:46 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/78bef05801ca Merge - src/share/vm/precompiled.hpp ! src/share/vm/runtime/globals.hpp From david.holmes at oracle.com Thu Nov 10 13:31:24 2011 From: david.holmes at oracle.com (David Holmes) Date: Fri, 11 Nov 2011 07:31:24 +1000 Subject: RFE: Add compressed oops to VM info string In-Reply-To: <4EBC11C3.1000705@oracle.com> References: <4EBBF54E.1060104@oracle.com> <4EBC11C3.1000705@oracle.com> Message-ID: <4EBC42AC.6030106@oracle.com> In case I didn't mention it earlier there is also -Xinternalversion which might be extended this way. But personally I think printing the flags is the way to go, and if the desired flags are not printed then that is a RFE for the print-flags options. David On 11/11/2011 4:02 AM, Mandy Chung wrote: > FWIW. Kumar added an internal option -XshowSettings to the launcher in > JDK 7 to print various VM and java settings. This could be a potential > place to include "compressed oops" and other VM ergonomic setting in. It > takes an optional suboption "all, vm, properties, locale". > > $ java -XshowSettings:vm > > VM settings: > Stack Size: 320.00K > Max. Heap Size (Estimated): 910.00M > Ergonomics Machine Class: server > Using VM: Java HotSpot(TM) Server VM > > [snip..] > > java -XshowSettings -version doesn't print the additional information. I > haven't spent time looking into the reason why. > > Mandy > > On 11/10/11 08:01, Paul Hohensee wrote: >> I don't think the version string is the place for dumping ergo >> decision results, >> rather I agree with David Holmes and Joe that PrintFlagsFinal, >> PrintCommandLineFlags, >> or some other switch should be used. We shouldn't have "mixed mode", >> etc. in the >> string either, but given that they're there we're kinda stuck with them. >> >> The reason we have "Server" and "Client" (and "Embedded, btw) is to >> distinguish >> builds that are statically different. Tiered got folded into Server >> awhile ago, which >> is why it's no longer mentioned in the version string. >> >> Changing the version string is a non-trivial thing to do: it has to go >> through >> an approval process because it's a supported public interface. There >> are, e.g., >> quite a few version string parsers out there that wouldn't take kindly >> to change. >> >> Paul >> >> On 11/10/11 8:18 AM, Volker Simonis wrote: >>> +1 from me >>> >>> On Thu, Nov 10, 2011 at 12:44 PM, Christian Thalinger >>> wrote: >>>> On Nov 10, 2011, at 12:16 PM, Volker Simonis wrote: >>>> >>>>> Hi Kris, >>>>> >>>>> first I want to say that I like and support your enhancement request. >>>>> >>>>> However once we do this, if would suggest printing other >>>>> information as well. >>>>> Particularly the fact if we're using tiered compilation comes to my >>>>> mind here. >>>>> >>>>> I would therefore suggest to use a less verbose "compressed oops" >>>>> string and also >>>>> print the concrete compressed oops mode that's actually used >>>>> (unscaled, zerobased, heapbased). >>>>> This information may be particularly usefull because it may change >>>>> depending on the users heap setting >>>>> and the current system memory situation. >>>>> >>>>> So finally, we could use something like: >>>>> >>>>> OpenJDK 64-Bit Server VM (build 20.0-b11-internal, mixed mode, tiered, >>>>> compr-oops=unscaled) >>>> Honestly I don't know what it takes to change that string since it's >>>> a public known option. But my personal opinion is: print the most >>>> important runtime settings like JIT mode, GC used, compressed oops >>>> mode. Something along these lines: >>>> >>>> Java HotSpot(TM) Server VM (build 23.0-b03, mixed mode, tiered, >>>> serial gc, zerobased coops) >>>> >>>> Just my two cents... >>>> >>>> -- Chris >>>> >>>>> For such a version string, it would be probably better to construct >>>>> the string on the fly, otherwise >>>>> the 'info_strs' struct you are currently using may become too big. >>>>> >>>>> What are your opinions? >>>>> >>>>> Regards, >>>>> Volker >>>>> >>>>> >>>>> On Thu, Nov 10, 2011 at 8:54 AM, Krystal Mok >>>>> wrote: >>>>>> Hi all, >>>>>> I'd like to propose to add "compressed oops" to the VM info >>>>>> string, so that >>>>>> people using "java -version" can get a better understanding of the >>>>>> ergonomics of the VM. >>>>>> I've posted a patch [1], against hsx20's master. The files >>>>>> modified are >>>>>> still pretty much the same on hotspot-main's master. >>>>>> With the patch applied, "java -version" may show: >>>>>> OpenJDK 64-Bit Server VM (build 20.0-b11-internal, mixed mode, >>>>>> compressed >>>>>> oops) >>>>>> and what used to work still works: >>>>>> OpenJDK Client VM (build 20.0-b11-internal, mixed mode, sharing) >>>>>> P.S. Alibaba (Taobao)'s OCA is submitted already, still waiting >>>>>> for approval >>>>>> from Oracle. >>>>>> Regards, >>>>>> Kris Mok >>>>>> Software Engineer, Taobao (http://www.taobao.com) >>>>>> [1]: https://gist.github.com/1354299 >>>> > From tony.printezis at oracle.com Fri Nov 11 08:57:16 2011 From: tony.printezis at oracle.com (Tony Printezis) Date: Fri, 11 Nov 2011 11:57:16 -0500 Subject: Reduce cap on maximum heap size? In-Reply-To: <82vcqsnl2a.fsf@mid.bfk.de> References: <8239dwp3nu.fsf@mid.bfk.de> <4EBBC91A.7050402@oracle.com> <82vcqsnl2a.fsf@mid.bfk.de> Message-ID: <4EBD53EC.8060805@oracle.com> Florian, Sure, but you can still get zero-based (scaled) coops for heaps larger than 4G; we just have to shift every reference. I'd be surprised if the difference between scaled and unscaled zero-based coops is big and/or noticeable (I don't have perf data handy, someone else might want to share some). Regarding the larger default heap size, I'm sure we increased it because we got lots of complaints like "I have 32G of RAM, why do you only use 5%-10% of it?". And for a lot of users with large data sets not getting an OOM is more important than the JVM running a tiny bit faster by default. As I said, folks have difference requirements and there is no policy with a clear win here. Regards, Tony On 11/10/2011 8:50 AM, Florian Weimer wrote: > * Tony Printezis: > >> compressed oops should have similar performance to the 32-bit JVM in >> most situations (you lose some given that the JVM still uses 64-bit >> references, you gain some given that 64-bit architectures typically >> have more registers available to the JIT compiler). > There used to be several variants of compressed oops: zero-based > unscaled, zero-based scaled, and offseted and scaled, depending on where > the heap segment is located in the process address space. The > zero-based unscaled encoding does not need an address decoding step and > should therefore be faster. However, that is only possible if the heap > fits within the lowest 4 GB, which is never the case for a 12 GB heap. > > For example, one of our tools runs like this (median on five runs, > including startup time): > > -Xmx1g 4194ms (6184ms user+system) > default 4428ms (6620ms user+system) > -Xmx40g 4351ms (6232ms user+system) > > (The old generation is never collected, even with the 1GB heap.) > > I understand that there is a difficult trade-off, but increasing the > default heap size to scaled compressed oops seems to have its costs. > From paul.hohensee at oracle.com Fri Nov 11 09:26:56 2011 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Fri, 11 Nov 2011 12:26:56 -0500 Subject: Reduce cap on maximum heap size? In-Reply-To: <4EBD53EC.8060805@oracle.com> References: <8239dwp3nu.fsf@mid.bfk.de> <4EBBC91A.7050402@oracle.com> <82vcqsnl2a.fsf@mid.bfk.de> <4EBD53EC.8060805@oracle.com> Message-ID: <4EBD5AE0.9030502@oracle.com> The current 64-bit default heap size policy is "1/4 of physical memory up to 32gb", which allows for the maximum heap size using compressed pointers of whatever description (in order of efficiency, zero-based unscaled: < 4gb, zero-based scaled with 8-byte object alignment: 4 to ~26gb and non-zero-based scaled with 8-byte object alignment: > ~26gb). Hotspot automatically uses the most efficient version base on -Xmx. You can also increase object alignment in order to get bigger zero-based scaled compressed pointers using -XX:ObjectAlignmentInBytes=, where is a power of 2. == 16 will give you zero based scaled with up to ~56gb heap, etc. On Intel, there's essentially no penalty for using zero-based, scaled or unscaled, because scaling with an 8-byte alignment costs only an extra index byte in a typical address mode. The extra registers in 64-bit mode make 64-bit zero-based faster than 32-bit in all the benchmarks we run. Non-zero-based scaled burns a register to hold the heap base, so runs slightly slower than zero-based. Paul On 11/11/11 11:57 AM, Tony Printezis wrote: > Florian, > > Sure, but you can still get zero-based (scaled) coops for heaps larger > than 4G; we just have to shift every reference. I'd be surprised if > the difference between scaled and unscaled zero-based coops is big > and/or noticeable (I don't have perf data handy, someone else might > want to share some). > > Regarding the larger default heap size, I'm sure we increased it > because we got lots of complaints like "I have 32G of RAM, why do you > only use 5%-10% of it?". And for a lot of users with large data sets > not getting an OOM is more important than the JVM running a tiny bit > faster by default. As I said, folks have difference requirements and > there is no policy with a clear win here. > > Regards, > > Tony > > On 11/10/2011 8:50 AM, Florian Weimer wrote: >> * Tony Printezis: >> >>> compressed oops should have similar performance to the 32-bit JVM in >>> most situations (you lose some given that the JVM still uses 64-bit >>> references, you gain some given that 64-bit architectures typically >>> have more registers available to the JIT compiler). >> There used to be several variants of compressed oops: zero-based >> unscaled, zero-based scaled, and offseted and scaled, depending on where >> the heap segment is located in the process address space. The >> zero-based unscaled encoding does not need an address decoding step and >> should therefore be faster. However, that is only possible if the heap >> fits within the lowest 4 GB, which is never the case for a 12 GB heap. >> >> For example, one of our tools runs like this (median on five runs, >> including startup time): >> >> -Xmx1g 4194ms (6184ms user+system) >> default 4428ms (6620ms user+system) >> -Xmx40g 4351ms (6232ms user+system) >> >> (The old generation is never collected, even with the 1GB heap.) >> >> I understand that there is a difficult trade-off, but increasing the >> default heap size to scaled compressed oops seems to have its costs. >> From ysr1729 at gmail.com Fri Nov 11 15:53:06 2011 From: ysr1729 at gmail.com (Srinivas Ramakrishna) Date: Fri, 11 Nov 2011 15:53:06 -0800 Subject: RFE: Add compressed oops to VM info string In-Reply-To: <4EBC42AC.6030106@oracle.com> References: <4EBBF54E.1060104@oracle.com> <4EBC11C3.1000705@oracle.com> <4EBC42AC.6030106@oracle.com> Message-ID: +1 to David's (and others') suggestion:- I agree that +PrintFlagsFinal makes this less subjective and more uniform. -- ramki On Thu, Nov 10, 2011 at 1:31 PM, David Holmes wrote: > In case I didn't mention it earlier there is also -Xinternalversion which > might be extended this way. > > But personally I think printing the flags is the way to go, and if the > desired flags are not printed then that is a RFE for the print-flags > options. > > David > > > On 11/11/2011 4:02 AM, Mandy Chung wrote: > >> FWIW. Kumar added an internal option -XshowSettings to the launcher in >> JDK 7 to print various VM and java settings. This could be a potential >> place to include "compressed oops" and other VM ergonomic setting in. It >> takes an optional suboption "all, vm, properties, locale". >> >> $ java -XshowSettings:vm >> >> VM settings: >> Stack Size: 320.00K >> Max. Heap Size (Estimated): 910.00M >> Ergonomics Machine Class: server >> Using VM: Java HotSpot(TM) Server VM >> >> [snip..] >> >> java -XshowSettings -version doesn't print the additional information. I >> haven't spent time looking into the reason why. >> >> Mandy >> >> On 11/10/11 08:01, Paul Hohensee wrote: >> >>> I don't think the version string is the place for dumping ergo >>> decision results, >>> rather I agree with David Holmes and Joe that PrintFlagsFinal, >>> PrintCommandLineFlags, >>> or some other switch should be used. We shouldn't have "mixed mode", >>> etc. in the >>> string either, but given that they're there we're kinda stuck with them. >>> >>> The reason we have "Server" and "Client" (and "Embedded, btw) is to >>> distinguish >>> builds that are statically different. Tiered got folded into Server >>> awhile ago, which >>> is why it's no longer mentioned in the version string. >>> >>> Changing the version string is a non-trivial thing to do: it has to go >>> through >>> an approval process because it's a supported public interface. There >>> are, e.g., >>> quite a few version string parsers out there that wouldn't take kindly >>> to change. >>> >>> Paul >>> >>> On 11/10/11 8:18 AM, Volker Simonis wrote: >>> >>>> +1 from me >>>> >>>> On Thu, Nov 10, 2011 at 12:44 PM, Christian Thalinger >>>> > >>>> wrote: >>>> >>>>> On Nov 10, 2011, at 12:16 PM, Volker Simonis wrote: >>>>> >>>>> Hi Kris, >>>>>> >>>>>> first I want to say that I like and support your enhancement request. >>>>>> >>>>>> However once we do this, if would suggest printing other >>>>>> information as well. >>>>>> Particularly the fact if we're using tiered compilation comes to my >>>>>> mind here. >>>>>> >>>>>> I would therefore suggest to use a less verbose "compressed oops" >>>>>> string and also >>>>>> print the concrete compressed oops mode that's actually used >>>>>> (unscaled, zerobased, heapbased). >>>>>> This information may be particularly usefull because it may change >>>>>> depending on the users heap setting >>>>>> and the current system memory situation. >>>>>> >>>>>> So finally, we could use something like: >>>>>> >>>>>> OpenJDK 64-Bit Server VM (build 20.0-b11-internal, mixed mode, tiered, >>>>>> compr-oops=unscaled) >>>>>> >>>>> Honestly I don't know what it takes to change that string since it's >>>>> a public known option. But my personal opinion is: print the most >>>>> important runtime settings like JIT mode, GC used, compressed oops >>>>> mode. Something along these lines: >>>>> >>>>> Java HotSpot(TM) Server VM (build 23.0-b03, mixed mode, tiered, >>>>> serial gc, zerobased coops) >>>>> >>>>> Just my two cents... >>>>> >>>>> -- Chris >>>>> >>>>> For such a version string, it would be probably better to construct >>>>>> the string on the fly, otherwise >>>>>> the 'info_strs' struct you are currently using may become too big. >>>>>> >>>>>> What are your opinions? >>>>>> >>>>>> Regards, >>>>>> Volker >>>>>> >>>>>> >>>>>> On Thu, Nov 10, 2011 at 8:54 AM, Krystal Mok >>>>>> wrote: >>>>>> >>>>>>> Hi all, >>>>>>> I'd like to propose to add "compressed oops" to the VM info >>>>>>> string, so that >>>>>>> people using "java -version" can get a better understanding of the >>>>>>> ergonomics of the VM. >>>>>>> I've posted a patch [1], against hsx20's master. The files >>>>>>> modified are >>>>>>> still pretty much the same on hotspot-main's master. >>>>>>> With the patch applied, "java -version" may show: >>>>>>> OpenJDK 64-Bit Server VM (build 20.0-b11-internal, mixed mode, >>>>>>> compressed >>>>>>> oops) >>>>>>> and what used to work still works: >>>>>>> OpenJDK Client VM (build 20.0-b11-internal, mixed mode, sharing) >>>>>>> P.S. Alibaba (Taobao)'s OCA is submitted already, still waiting >>>>>>> for approval >>>>>>> from Oracle. >>>>>>> Regards, >>>>>>> Kris Mok >>>>>>> Software Engineer, Taobao (http://www.taobao.com) >>>>>>> [1]: https://gist.github.com/**1354299 >>>>>>> >>>>>> >>>>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20111111/7b42c183/attachment.html From bengt.rutisson at oracle.com Sun Nov 13 06:14:37 2011 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Sun, 13 Nov 2011 15:14:37 +0100 Subject: Request for review (S): 7110152: assert(size_in_words <= (julong)max_jint) failed: no overflow Message-ID: <4EBFD0CD.2000706@oracle.com> Hi all, I already sent this out for review on the GC alias. It started out as a pure GC change, but after some updates it has become a change in src/share/vm/oops/arrayOop.hpp, which deserves a broader alias (thanks David Holmes for pointing this out). So, I am resending this review request to the hotspot-dev alias. http://cr.openjdk.java.net/~brutisso/7110152/webrev.04/ Vladimir and David Holmes have already looked at it. But more comments are of course welcome. The background is that when I pushed this: 7102044: G1: VM crashes with assert(old_end != new_end) failed: don't call this otherwise http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/6fd81579526f I changed arrayOopDesc::max_array_length() to always return max_jint in 64 bit VMs. This was intentional and is correct as far as I can tell. But it turns out that a large part of the GC code passes object sizes around as int and not size_t. Thus, we might overflow the int when we add the object header. My proposed change now reverts back to reducing the maximum array length to be slightly less than max_jint. CR: 7110152 assert(size_in_words <= (julong)max_jint) failed: no overflow http://monaco.sfbay.sun.com/detail.jsf?cr=7110152 Here is a reproducer that triggers the assert before my change but passes after: public class MaxJIntArray { public static void main(String[] args) { final int MAX_JINT = 2147483647; double[] a = new double[MAX_JINT]; System.out.println("Allocated a[" + a.length + "]"); } } Thanks, Bengt From david.holmes at oracle.com Sun Nov 13 17:54:26 2011 From: david.holmes at oracle.com (David Holmes) Date: Mon, 14 Nov 2011 11:54:26 +1000 Subject: Request for review (S): 7110152: assert(size_in_words <= (julong)max_jint) failed: no overflow In-Reply-To: <4EBFD0CD.2000706@oracle.com> References: <4EBFD0CD.2000706@oracle.com> Message-ID: <4EC074D2.6050905@oracle.com> Hi Bengt, On 14/11/2011 12:14 AM, Bengt Rutisson wrote: > I already sent this out for review on the GC alias. It started out as a > pure GC change, but after some updates it has become a change in > src/share/vm/oops/arrayOop.hpp, which deserves a broader alias (thanks > David Holmes for pointing this out). So, I am resending this review > request to the hotspot-dev alias. > > http://cr.openjdk.java.net/~brutisso/7110152/webrev.04/ > > Vladimir and David Holmes have already looked at it. But more comments > are of course welcome. > > The background is that when I pushed this: > 7102044: G1: VM crashes with assert(old_end != new_end) failed: don't > call this otherwise > http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/6fd81579526f > > I changed arrayOopDesc::max_array_length() to always return max_jint in > 64 bit VMs. This was intentional and is correct as far as I can tell. > But it turns out that a large part of the GC code passes object sizes > around as int and not size_t. Thus, we might overflow the int when we > add the object header. > > My proposed change now reverts back to reducing the maximum array length > to be slightly less than max_jint. Okay, so the original code would only return max_jint for the smaller element types (up to ints on 64-bit, and short/char on 32-bit). And otherwise calculated a size in words that allowed for adding back the header. The previous fix allowed max_jint to be returned for all types but didn't allow for adding back the header - which is now fixed (and only necessary because int is used in some places as you stated). Anyway this fix seems okay to me as long as nothing else in the code tries to pass around an object size in bytes using an int. > CR: > > 7110152 assert(size_in_words <= (julong)max_jint) failed: no overflow > http://monaco.sfbay.sun.com/detail.jsf?cr=7110152 http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7110152 Cheers, David ----- > Here is a reproducer that triggers the assert before my change but > passes after: > > public class MaxJIntArray { > public static void main(String[] args) { > final int MAX_JINT = 2147483647; > double[] a = new double[MAX_JINT]; > System.out.println("Allocated a[" + a.length + "]"); > } > } > > Thanks, > Bengt From rednaxelafx at gmail.com Mon Nov 14 03:22:51 2011 From: rednaxelafx at gmail.com (Krystal Mok) Date: Mon, 14 Nov 2011 19:22:51 +0800 Subject: RFE: Add compressed oops to VM info string In-Reply-To: References: <4EBBF54E.1060104@oracle.com> <4EBC11C3.1000705@oracle.com> <4EBC42AC.6030106@oracle.com> Message-ID: Hi all, (Sorry for replying so late. I was attending a conference last Friday, and didn't have reliable network connection until today.) A thanks to everyone in the discussion. I wasn't sure whether it's appropriate or not to mention other JVM impls on this list, but, just for reference, this is the version string from J9: $ java -version java version "1.6.0" Java(TM) SE Runtime Environment (build pxa6460sr8fp1-20100624_01(SR8 FP1)) IBM J9 VM (build 2.4, JRE 1.6.0 IBM J9 2.4 Linux amd64-64 jvmxa6460sr8ifx-20100609_59383 (JIT enabled, AOT enabled) J9VM - 20100609_059383 JIT - r9_20100401_15339ifx2 GC - 20100308_AA) JCL - 20100624_01 $ java -Xcompressedrefs -version java version "1.6.0" Java(TM) SE Runtime Environment (build pxa6460sr8fp1-20100624_01(SR8 FP1)) IBM J9 VM (build 2.4, JRE 1.6.0 IBM J9 2.4 Linux amd64-64 jvmxa6460sr8ifx-20100609_59383 (JIT enabled, AOT enabled) J9VM - 20100609_059383 JIT - r9_20100401_15339ifx2 GC - 20100308_AA_CMPRSS) JCL - 20100624_01 Notice the GC line; "CMPRSS" shows this VM is using compressed references. It probably makes more sense to show this info with J9 because it's another set of VM binaries when -Xcompressedrefs is given to the launcher. It's much more verbose than HotSpot's version string. Not arguing for this kind of verbose style, it's just that I was looking for an easy way to get people tell me what VM configuration they were using. But yes, the most of you are right, the VM version string is a public interface and shouldn't be changed without a very good reason. @Mandy Thanks for mentioning -XshowSettings. That looks like a good place to add these kind of verbose / internal information. I'll make another patch based on -XshowSettings or -Xinternalversion. @Coleen I've been using PrintCompressedOopsMode to get the compressed oops mode for some time. Too bad once the mode is calculated (and printed), it's thrown away, leaving only the base and shift values. Sometimes it might be useful to keep the mode; one of my extensions to HotSpot actually needed it to check for VM argument consistency, and I had to duplicate PrintCompressedOopsMode code to get it done. @David Printing flags isn't good enough in some scenarios. Take jmap -heap for example. HeapSummary prints out a few flags of interest, but it can be misleading for people who don't know that not all flags are in effect all the time. In [1], MaxNewSize shows "17592186044415 MB", and OldSize shows "5439488 (5.1875MB)". Neither of these values correspond to the actual heap stats; they just act as a hint to let ergonomics make the decision. PrintFlagsFinal won't do any good in this kind of scenario (and PrintCommandLineFlags won't show anything). Regards, Kris Mok [1]: https://gist.github.com/1363195 On Sat, Nov 12, 2011 at 7:53 AM, Srinivas Ramakrishna wrote: > +1 to David's (and others') suggestion:- > > I agree that +PrintFlagsFinal makes this less subjective and more uniform. > > -- ramki > > > On Thu, Nov 10, 2011 at 1:31 PM, David Holmes wrote: > >> In case I didn't mention it earlier there is also -Xinternalversion which >> might be extended this way. >> >> But personally I think printing the flags is the way to go, and if the >> desired flags are not printed then that is a RFE for the print-flags >> options. >> >> David >> >> >> On 11/11/2011 4:02 AM, Mandy Chung wrote: >> >>> FWIW. Kumar added an internal option -XshowSettings to the launcher in >>> JDK 7 to print various VM and java settings. This could be a potential >>> place to include "compressed oops" and other VM ergonomic setting in. It >>> takes an optional suboption "all, vm, properties, locale". >>> >>> $ java -XshowSettings:vm >>> >>> VM settings: >>> Stack Size: 320.00K >>> Max. Heap Size (Estimated): 910.00M >>> Ergonomics Machine Class: server >>> Using VM: Java HotSpot(TM) Server VM >>> >>> [snip..] >>> >>> java -XshowSettings -version doesn't print the additional information. I >>> haven't spent time looking into the reason why. >>> >>> Mandy >>> >>> On 11/10/11 08:01, Paul Hohensee wrote: >>> >>>> I don't think the version string is the place for dumping ergo >>>> decision results, >>>> rather I agree with David Holmes and Joe that PrintFlagsFinal, >>>> PrintCommandLineFlags, >>>> or some other switch should be used. We shouldn't have "mixed mode", >>>> etc. in the >>>> string either, but given that they're there we're kinda stuck with them. >>>> >>>> The reason we have "Server" and "Client" (and "Embedded, btw) is to >>>> distinguish >>>> builds that are statically different. Tiered got folded into Server >>>> awhile ago, which >>>> is why it's no longer mentioned in the version string. >>>> >>>> Changing the version string is a non-trivial thing to do: it has to go >>>> through >>>> an approval process because it's a supported public interface. There >>>> are, e.g., >>>> quite a few version string parsers out there that wouldn't take kindly >>>> to change. >>>> >>>> Paul >>>> >>>> On 11/10/11 8:18 AM, Volker Simonis wrote: >>>> >>>>> +1 from me >>>>> >>>>> On Thu, Nov 10, 2011 at 12:44 PM, Christian Thalinger >>>>> > >>>>> wrote: >>>>> >>>>>> On Nov 10, 2011, at 12:16 PM, Volker Simonis wrote: >>>>>> >>>>>> Hi Kris, >>>>>>> >>>>>>> first I want to say that I like and support your enhancement request. >>>>>>> >>>>>>> However once we do this, if would suggest printing other >>>>>>> information as well. >>>>>>> Particularly the fact if we're using tiered compilation comes to my >>>>>>> mind here. >>>>>>> >>>>>>> I would therefore suggest to use a less verbose "compressed oops" >>>>>>> string and also >>>>>>> print the concrete compressed oops mode that's actually used >>>>>>> (unscaled, zerobased, heapbased). >>>>>>> This information may be particularly usefull because it may change >>>>>>> depending on the users heap setting >>>>>>> and the current system memory situation. >>>>>>> >>>>>>> So finally, we could use something like: >>>>>>> >>>>>>> OpenJDK 64-Bit Server VM (build 20.0-b11-internal, mixed mode, >>>>>>> tiered, >>>>>>> compr-oops=unscaled) >>>>>>> >>>>>> Honestly I don't know what it takes to change that string since it's >>>>>> a public known option. But my personal opinion is: print the most >>>>>> important runtime settings like JIT mode, GC used, compressed oops >>>>>> mode. Something along these lines: >>>>>> >>>>>> Java HotSpot(TM) Server VM (build 23.0-b03, mixed mode, tiered, >>>>>> serial gc, zerobased coops) >>>>>> >>>>>> Just my two cents... >>>>>> >>>>>> -- Chris >>>>>> >>>>>> For such a version string, it would be probably better to construct >>>>>>> the string on the fly, otherwise >>>>>>> the 'info_strs' struct you are currently using may become too big. >>>>>>> >>>>>>> What are your opinions? >>>>>>> >>>>>>> Regards, >>>>>>> Volker >>>>>>> >>>>>>> >>>>>>> On Thu, Nov 10, 2011 at 8:54 AM, Krystal Mok >>>>>>> wrote: >>>>>>> >>>>>>>> Hi all, >>>>>>>> I'd like to propose to add "compressed oops" to the VM info >>>>>>>> string, so that >>>>>>>> people using "java -version" can get a better understanding of the >>>>>>>> ergonomics of the VM. >>>>>>>> I've posted a patch [1], against hsx20's master. The files >>>>>>>> modified are >>>>>>>> still pretty much the same on hotspot-main's master. >>>>>>>> With the patch applied, "java -version" may show: >>>>>>>> OpenJDK 64-Bit Server VM (build 20.0-b11-internal, mixed mode, >>>>>>>> compressed >>>>>>>> oops) >>>>>>>> and what used to work still works: >>>>>>>> OpenJDK Client VM (build 20.0-b11-internal, mixed mode, sharing) >>>>>>>> P.S. Alibaba (Taobao)'s OCA is submitted already, still waiting >>>>>>>> for approval >>>>>>>> from Oracle. >>>>>>>> Regards, >>>>>>>> Kris Mok >>>>>>>> Software Engineer, Taobao (http://www.taobao.com) >>>>>>>> [1]: https://gist.github.com/**1354299 >>>>>>>> >>>>>>> >>>>>> >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20111114/8fbbfc50/attachment.html From david.holmes at oracle.com Mon Nov 14 17:10:25 2011 From: david.holmes at oracle.com (David Holmes) Date: Tue, 15 Nov 2011 11:10:25 +1000 Subject: RFE: Add compressed oops to VM info string In-Reply-To: References: <4EBBF54E.1060104@oracle.com> <4EBC11C3.1000705@oracle.com> <4EBC42AC.6030106@oracle.com> Message-ID: <4EC1BC01.1070401@oracle.com> On 14/11/2011 9:22 PM, Krystal Mok wrote: > @David > Printing flags isn't good enough in some scenarios. > Take jmap -heap for example. HeapSummary prints out a few flags of > interest, but it can be misleading for people who don't know that not > all flags are in effect all the time. > In [1], MaxNewSize shows "17592186044415 MB", and OldSize shows "5439488 > (5.1875MB)". Neither of these values correspond to the actual heap > stats; they just act as a hint to let ergonomics make the decision. > PrintFlagsFinal won't do any good in this kind of scenario (and > PrintCommandLineFlags won't show anything). As I said if the print-flags option isn't showing the compressed-oops flag settings then that should be fixed. Sorry I don't understand the connection to your jmap -heap example. David ----- > Regards, > Kris Mok > > [1]: https://gist.github.com/1363195 > > On Sat, Nov 12, 2011 at 7:53 AM, Srinivas Ramakrishna > wrote: > > +1 to David's (and others') suggestion:- > > I agree that +PrintFlagsFinal makes this less subjective and more > uniform. > > -- ramki > > > On Thu, Nov 10, 2011 at 1:31 PM, David Holmes > > wrote: > > In case I didn't mention it earlier there is also > -Xinternalversion which might be extended this way. > > But personally I think printing the flags is the way to go, and > if the desired flags are not printed then that is a RFE for the > print-flags options. > > David > > > On 11/11/2011 4:02 AM, Mandy Chung wrote: > > FWIW. Kumar added an internal option -XshowSettings to the > launcher in > JDK 7 to print various VM and java settings. This could be a > potential > place to include "compressed oops" and other VM ergonomic > setting in. It > takes an optional suboption "all, vm, properties, locale". > > $ java -XshowSettings:vm > > VM settings: > Stack Size: 320.00K > Max. Heap Size (Estimated): 910.00M > Ergonomics Machine Class: server > Using VM: Java HotSpot(TM) Server VM > > [snip..] > > java -XshowSettings -version doesn't print the additional > information. I > haven't spent time looking into the reason why. > > Mandy > > On 11/10/11 08:01, Paul Hohensee wrote: > > I don't think the version string is the place for > dumping ergo > decision results, > rather I agree with David Holmes and Joe that > PrintFlagsFinal, > PrintCommandLineFlags, > or some other switch should be used. We shouldn't have > "mixed mode", > etc. in the > string either, but given that they're there we're kinda > stuck with them. > > The reason we have "Server" and "Client" (and "Embedded, > btw) is to > distinguish > builds that are statically different. Tiered got folded > into Server > awhile ago, which > is why it's no longer mentioned in the version string. > > Changing the version string is a non-trivial thing to > do: it has to go > through > an approval process because it's a supported public > interface. There > are, e.g., > quite a few version string parsers out there that > wouldn't take kindly > to change. > > Paul > > On 11/10/11 8:18 AM, Volker Simonis wrote: > > +1 from me > > On Thu, Nov 10, 2011 at 12:44 PM, Christian Thalinger > > wrote: > > On Nov 10, 2011, at 12:16 PM, Volker Simonis wrote: > > Hi Kris, > > first I want to say that I like and support > your enhancement request. > > However once we do this, if would suggest > printing other > information as well. > Particularly the fact if we're using tiered > compilation comes to my > mind here. > > I would therefore suggest to use a less > verbose "compressed oops" > string and also > print the concrete compressed oops mode > that's actually used > (unscaled, zerobased, heapbased). > This information may be particularly usefull > because it may change > depending on the users heap setting > and the current system memory situation. > > So finally, we could use something like: > > OpenJDK 64-Bit Server VM (build > 20.0-b11-internal, mixed mode, tiered, > compr-oops=unscaled) > > Honestly I don't know what it takes to change > that string since it's > a public known option. But my personal opinion > is: print the most > important runtime settings like JIT mode, GC > used, compressed oops > mode. Something along these lines: > > Java HotSpot(TM) Server VM (build 23.0-b03, > mixed mode, tiered, > serial gc, zerobased coops) > > Just my two cents... > > -- Chris > > For such a version string, it would be > probably better to construct > the string on the fly, otherwise > the 'info_strs' struct you are currently > using may become too big. > > What are your opinions? > > Regards, > Volker > > > On Thu, Nov 10, 2011 at 8:54 AM, Krystal > Mok > > wrote: > > Hi all, > I'd like to propose to add "compressed > oops" to the VM info > string, so that > people using "java -version" can get a > better understanding of the > ergonomics of the VM. > I've posted a patch [1], against hsx20's > master. The files > modified are > still pretty much the same on > hotspot-main's master. > With the patch applied, "java -version" > may show: > OpenJDK 64-Bit Server VM (build > 20.0-b11-internal, mixed mode, > compressed > oops) > and what used to work still works: > OpenJDK Client VM (build > 20.0-b11-internal, mixed mode, sharing) > P.S. Alibaba (Taobao)'s OCA is submitted > already, still waiting > for approval > from Oracle. > Regards, > Kris Mok > Software Engineer, Taobao > (http://www.taobao.com) > [1]: https://gist.github.com/__1354299 > > > > > > From rednaxelafx at gmail.com Mon Nov 14 17:50:12 2011 From: rednaxelafx at gmail.com (Krystal Mok) Date: Tue, 15 Nov 2011 09:50:12 +0800 Subject: RFE: Add compressed oops to VM info string In-Reply-To: <4EC1BC01.1070401@oracle.com> References: <4EBBF54E.1060104@oracle.com> <4EBC11C3.1000705@oracle.com> <4EBC42AC.6030106@oracle.com> <4EC1BC01.1070401@oracle.com> Message-ID: HI David, The jmap -heap example is also printing some of the VM flags as part of the heap summary. The problem is, the flags printed can be misleading, because some of them can be different than the actual value used by the actual heap, due to the way ergonomics works now. The MaxNewSize and OldSize flags in the example shows exactly that. I've had colleagues asking me why they're getting a young gen of size "17592186044415 MB", and it took a while to explain to them that it's just a hint to ergonomics, and not the actual value used. For people who do know the internals, though, you're right that the flags (+ some of the HSPERFDATA counters for things that are not a flag) already give a lot of clues of what's going on. It's just not so obvious for normals users, and some kind of summary would be nice. Regards, Kris Mok On Tue, Nov 15, 2011 at 9:10 AM, David Holmes wrote: > On 14/11/2011 9:22 PM, Krystal Mok wrote: > >> @David >> Printing flags isn't good enough in some scenarios. >> Take jmap -heap for example. HeapSummary prints out a few flags of >> interest, but it can be misleading for people who don't know that not >> all flags are in effect all the time. >> In [1], MaxNewSize shows "17592186044415 MB", and OldSize shows "5439488 >> (5.1875MB)". Neither of these values correspond to the actual heap >> stats; they just act as a hint to let ergonomics make the decision. >> PrintFlagsFinal won't do any good in this kind of scenario (and >> PrintCommandLineFlags won't show anything). >> > > As I said if the print-flags option isn't showing the compressed-oops flag > settings then that should be fixed. > > Sorry I don't understand the connection to your jmap -heap example. > > David > ----- > > Regards, >> Kris Mok >> >> [1]: https://gist.github.com/**1363195 >> >> On Sat, Nov 12, 2011 at 7:53 AM, Srinivas Ramakrishna > > wrote: >> >> +1 to David's (and others') suggestion:- >> >> I agree that +PrintFlagsFinal makes this less subjective and more >> uniform. >> >> -- ramki >> >> >> On Thu, Nov 10, 2011 at 1:31 PM, David Holmes >> >> >> wrote: >> >> In case I didn't mention it earlier there is also >> -Xinternalversion which might be extended this way. >> >> But personally I think printing the flags is the way to go, and >> if the desired flags are not printed then that is a RFE for the >> print-flags options. >> >> David >> >> >> On 11/11/2011 4:02 AM, Mandy Chung wrote: >> >> FWIW. Kumar added an internal option -XshowSettings to the >> launcher in >> JDK 7 to print various VM and java settings. This could be a >> potential >> place to include "compressed oops" and other VM ergonomic >> setting in. It >> takes an optional suboption "all, vm, properties, locale". >> >> $ java -XshowSettings:vm >> >> VM settings: >> Stack Size: 320.00K >> Max. Heap Size (Estimated): 910.00M >> Ergonomics Machine Class: server >> Using VM: Java HotSpot(TM) Server VM >> >> [snip..] >> >> java -XshowSettings -version doesn't print the additional >> information. I >> haven't spent time looking into the reason why. >> >> Mandy >> >> On 11/10/11 08:01, Paul Hohensee wrote: >> >> I don't think the version string is the place for >> dumping ergo >> decision results, >> rather I agree with David Holmes and Joe that >> PrintFlagsFinal, >> PrintCommandLineFlags, >> or some other switch should be used. We shouldn't have >> "mixed mode", >> etc. in the >> string either, but given that they're there we're kinda >> stuck with them. >> >> The reason we have "Server" and "Client" (and "Embedded, >> btw) is to >> distinguish >> builds that are statically different. Tiered got folded >> into Server >> awhile ago, which >> is why it's no longer mentioned in the version string. >> >> Changing the version string is a non-trivial thing to >> do: it has to go >> through >> an approval process because it's a supported public >> interface. There >> are, e.g., >> quite a few version string parsers out there that >> wouldn't take kindly >> to change. >> >> Paul >> >> On 11/10/11 8:18 AM, Volker Simonis wrote: >> >> +1 from me >> >> On Thu, Nov 10, 2011 at 12:44 PM, Christian Thalinger >> > >> >> >> wrote: >> >> On Nov 10, 2011, at 12:16 PM, Volker Simonis wrote: >> >> Hi Kris, >> >> first I want to say that I like and support >> your enhancement request. >> >> However once we do this, if would suggest >> printing other >> information as well. >> Particularly the fact if we're using tiered >> compilation comes to my >> mind here. >> >> I would therefore suggest to use a less >> verbose "compressed oops" >> string and also >> print the concrete compressed oops mode >> that's actually used >> (unscaled, zerobased, heapbased). >> This information may be particularly usefull >> because it may change >> depending on the users heap setting >> and the current system memory situation. >> >> So finally, we could use something like: >> >> OpenJDK 64-Bit Server VM (build >> 20.0-b11-internal, mixed mode, tiered, >> compr-oops=unscaled) >> >> Honestly I don't know what it takes to change >> that string since it's >> a public known option. But my personal opinion >> is: print the most >> important runtime settings like JIT mode, GC >> used, compressed oops >> mode. Something along these lines: >> >> Java HotSpot(TM) Server VM (build 23.0-b03, >> mixed mode, tiered, >> serial gc, zerobased coops) >> >> Just my two cents... >> >> -- Chris >> >> For such a version string, it would be >> probably better to construct >> the string on the fly, otherwise >> the 'info_strs' struct you are currently >> using may become too big. >> >> What are your opinions? >> >> Regards, >> Volker >> >> >> On Thu, Nov 10, 2011 at 8:54 AM, Krystal >> Mok> **> >> >> wrote: >> >> Hi all, >> I'd like to propose to add "compressed >> oops" to the VM info >> string, so that >> people using "java -version" can get a >> better understanding of the >> ergonomics of the VM. >> I've posted a patch [1], against hsx20's >> master. The files >> modified are >> still pretty much the same on >> hotspot-main's master. >> With the patch applied, "java -version" >> may show: >> OpenJDK 64-Bit Server VM (build >> 20.0-b11-internal, mixed mode, >> compressed >> oops) >> and what used to work still works: >> OpenJDK Client VM (build >> 20.0-b11-internal, mixed mode, sharing) >> P.S. Alibaba (Taobao)'s OCA is submitted >> already, still waiting >> for approval >> from Oracle. >> Regards, >> Kris Mok >> Software Engineer, Taobao >> (http://www.taobao.com) >> [1]: https://gist.github.com/__**1354299 >> >> > >> >> >> >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20111115/6ed59980/attachment-0001.html From david.holmes at oracle.com Mon Nov 14 18:03:02 2011 From: david.holmes at oracle.com (David Holmes) Date: Tue, 15 Nov 2011 12:03:02 +1000 Subject: RFE: Add compressed oops to VM info string In-Reply-To: References: <4EBBF54E.1060104@oracle.com> <4EBC11C3.1000705@oracle.com> <4EBC42AC.6030106@oracle.com> <4EC1BC01.1070401@oracle.com> Message-ID: <4EC1C856.3050607@oracle.com> On 15/11/2011 11:50 AM, Krystal Mok wrote: > HI David, > > The jmap -heap example is also printing some of the VM flags as part of > the heap summary. > > The problem is, the flags printed can be misleading, because some of > them can be different than the actual value used by the actual heap, due > to the way ergonomics works now. The MaxNewSize and OldSize flags in the > example shows exactly that. Okay but I don't see a connection to the original subject. If you print (or use) flags you need to understand what they mean. David ----- > I've had colleagues asking me why they're getting a young gen of size > "17592186044415 MB", and it took a while to explain to them that it's > just a hint to ergonomics, and not the actual value used. > > For people who do know the internals, though, you're right that the > flags (+ some of the HSPERFDATA counters for things that are not a flag) > already give a lot of clues of what's going on. It's just not so obvious > for normals users, and some kind of summary would be nice. > > Regards, > Kris Mok > > On Tue, Nov 15, 2011 at 9:10 AM, David Holmes > wrote: > > On 14/11/2011 9:22 PM, Krystal Mok wrote: > > @David > Printing flags isn't good enough in some scenarios. > Take jmap -heap for example. HeapSummary prints out a few flags of > interest, but it can be misleading for people who don't know > that not > all flags are in effect all the time. > In [1], MaxNewSize shows "17592186044415 MB", and OldSize shows > "5439488 > (5.1875MB)". Neither of these values correspond to the actual heap > stats; they just act as a hint to let ergonomics make the decision. > PrintFlagsFinal won't do any good in this kind of scenario (and > PrintCommandLineFlags won't show anything). > > > As I said if the print-flags option isn't showing the > compressed-oops flag settings then that should be fixed. > > Sorry I don't understand the connection to your jmap -heap example. > > David > ----- > > Regards, > Kris Mok > > [1]: https://gist.github.com/__1363195 > > > On Sat, Nov 12, 2011 at 7:53 AM, Srinivas Ramakrishna > > >> wrote: > > +1 to David's (and others') suggestion:- > > I agree that +PrintFlagsFinal makes this less subjective and > more > uniform. > > -- ramki > > > On Thu, Nov 10, 2011 at 1:31 PM, David Holmes > > >> wrote: > > In case I didn't mention it earlier there is also > -Xinternalversion which might be extended this way. > > But personally I think printing the flags is the way to > go, and > if the desired flags are not printed then that is a RFE > for the > print-flags options. > > David > > > On 11/11/2011 4:02 AM, Mandy Chung wrote: > > FWIW. Kumar added an internal option -XshowSettings > to the > launcher in > JDK 7 to print various VM and java settings. This > could be a > potential > place to include "compressed oops" and other VM > ergonomic > setting in. It > takes an optional suboption "all, vm, properties, > locale". > > $ java -XshowSettings:vm > > VM settings: > Stack Size: 320.00K > Max. Heap Size (Estimated): 910.00M > Ergonomics Machine Class: server > Using VM: Java HotSpot(TM) Server VM > > [snip..] > > java -XshowSettings -version doesn't print the > additional > information. I > haven't spent time looking into the reason why. > > Mandy > > On 11/10/11 08:01, Paul Hohensee wrote: > > I don't think the version string is the place for > dumping ergo > decision results, > rather I agree with David Holmes and Joe that > PrintFlagsFinal, > PrintCommandLineFlags, > or some other switch should be used. We > shouldn't have > "mixed mode", > etc. in the > string either, but given that they're there > we're kinda > stuck with them. > > The reason we have "Server" and "Client" (and > "Embedded, > btw) is to > distinguish > builds that are statically different. Tiered got > folded > into Server > awhile ago, which > is why it's no longer mentioned in the version > string. > > Changing the version string is a non-trivial > thing to > do: it has to go > through > an approval process because it's a supported public > interface. There > are, e.g., > quite a few version string parsers out there that > wouldn't take kindly > to change. > > Paul > > On 11/10/11 8:18 AM, Volker Simonis wrote: > > +1 from me > > On Thu, Nov 10, 2011 at 12:44 PM, Christian > Thalinger > > >> wrote: > > On Nov 10, 2011, at 12:16 PM, Volker > Simonis wrote: > > Hi Kris, > > first I want to say that I like and > support > your enhancement request. > > However once we do this, if would > suggest > printing other > information as well. > Particularly the fact if we're using > tiered > compilation comes to my > mind here. > > I would therefore suggest to use a less > verbose "compressed oops" > string and also > print the concrete compressed oops mode > that's actually used > (unscaled, zerobased, heapbased). > This information may be particularly > usefull > because it may change > depending on the users heap setting > and the current system memory situation. > > So finally, we could use something like: > > OpenJDK 64-Bit Server VM (build > 20.0-b11-internal, mixed mode, tiered, > compr-oops=unscaled) > > Honestly I don't know what it takes to > change > that string since it's > a public known option. But my personal > opinion > is: print the most > important runtime settings like JIT mode, GC > used, compressed oops > mode. Something along these lines: > > Java HotSpot(TM) Server VM (build 23.0-b03, > mixed mode, tiered, > serial gc, zerobased coops) > > Just my two cents... > > -- Chris > > For such a version string, it would be > probably better to construct > the string on the fly, otherwise > the 'info_strs' struct you are currently > using may become too big. > > What are your opinions? > > Regards, > Volker > > > On Thu, Nov 10, 2011 at 8:54 AM, Krystal > Mok > >__> > > wrote: > > Hi all, > I'd like to propose to add > "compressed > oops" to the VM info > string, so that > people using "java -version" can > get a > better understanding of the > ergonomics of the VM. > I've posted a patch [1], against > hsx20's > master. The files > modified are > still pretty much the same on > hotspot-main's master. > With the patch applied, "java > -version" > may show: > OpenJDK 64-Bit Server VM (build > 20.0-b11-internal, mixed mode, > compressed > oops) > and what used to work still works: > OpenJDK Client VM (build > 20.0-b11-internal, mixed mode, > sharing) > P.S. Alibaba (Taobao)'s OCA is > submitted > already, still waiting > for approval > from Oracle. > Regards, > Kris Mok > Software Engineer, Taobao > (http://www.taobao.com) > [1]: > https://gist.github.com/____1354299 > > > > > > > > > From bengt.rutisson at oracle.com Tue Nov 15 23:34:43 2011 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Wed, 16 Nov 2011 08:34:43 +0100 Subject: Request for review (S): 7110152: assert(size_in_words <= (julong)max_jint) failed: no overflow In-Reply-To: <4EC074D2.6050905@oracle.com> References: <4EBFD0CD.2000706@oracle.com> <4EC074D2.6050905@oracle.com> Message-ID: <4EC36793.4010908@oracle.com> Vladimir, David and Tony, Thanks for the reviews! Bengt On 2011-11-14 02:54, David Holmes wrote: > Hi Bengt, > > On 14/11/2011 12:14 AM, Bengt Rutisson wrote: >> I already sent this out for review on the GC alias. It started out as a >> pure GC change, but after some updates it has become a change in >> src/share/vm/oops/arrayOop.hpp, which deserves a broader alias (thanks >> David Holmes for pointing this out). So, I am resending this review >> request to the hotspot-dev alias. >> >> http://cr.openjdk.java.net/~brutisso/7110152/webrev.04/ >> >> Vladimir and David Holmes have already looked at it. But more comments >> are of course welcome. >> >> The background is that when I pushed this: >> 7102044: G1: VM crashes with assert(old_end != new_end) failed: don't >> call this otherwise >> http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/6fd81579526f >> >> I changed arrayOopDesc::max_array_length() to always return max_jint in >> 64 bit VMs. This was intentional and is correct as far as I can tell. >> But it turns out that a large part of the GC code passes object sizes >> around as int and not size_t. Thus, we might overflow the int when we >> add the object header. >> >> My proposed change now reverts back to reducing the maximum array length >> to be slightly less than max_jint. > > Okay, so the original code would only return max_jint for the smaller > element types (up to ints on 64-bit, and short/char on 32-bit). And > otherwise calculated a size in words that allowed for adding back the > header. The previous fix allowed max_jint to be returned for all types > but didn't allow for adding back the header - which is now fixed (and > only necessary because int is used in some places as you stated). > > Anyway this fix seems okay to me as long as nothing else in the code > tries to pass around an object size in bytes using an int. > >> CR: >> >> 7110152 assert(size_in_words <= (julong)max_jint) failed: no overflow >> http://monaco.sfbay.sun.com/detail.jsf?cr=7110152 > > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7110152 > > Cheers, > David > ----- > >> Here is a reproducer that triggers the assert before my change but >> passes after: >> >> public class MaxJIntArray { >> public static void main(String[] args) { >> final int MAX_JINT = 2147483647; >> double[] a = new double[MAX_JINT]; >> System.out.println("Allocated a[" + a.length + "]"); >> } >> } >> >> Thanks, >> Bengt From coleen.phillimore at oracle.com Wed Nov 16 15:26:49 2011 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Wed, 16 Nov 2011 23:26:49 +0000 Subject: hg: hsx/hotspot-main/hotspot: 2 new changesets Message-ID: <20111116232655.0819E47399@hg.openjdk.java.net> Changeset: 3c7d67df8d07 Author: dholmes Date: 2011-11-10 06:23 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/3c7d67df8d07 7108264: Fix for 7104173 is insufficient Summary: Disable PrintVMOptions by default for all builds Reviewed-by: dsamersoff, twisti ! src/share/vm/runtime/globals.hpp Changeset: f9a80a035a4a Author: coleenp Date: 2011-11-15 12:40 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/f9a80a035a4a Merge ! src/share/vm/runtime/globals.hpp From vladimir.kozlov at oracle.com Wed Nov 16 17:43:48 2011 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Thu, 17 Nov 2011 01:43:48 +0000 Subject: hg: hsx/hsx22/hotspot: 7110586: C2 generates incorrect results Message-ID: <20111117014354.38A46473AA@hg.openjdk.java.net> Changeset: 742a2251c87b Author: kvn Date: 2011-11-10 20:17 -0800 URL: http://hg.openjdk.java.net/hsx/hsx22/hotspot/rev/742a2251c87b 7110586: C2 generates incorrect results Summary: Exact limit of empty loop calculated incorrectly. Reviewed-by: iveresov, never ! src/share/vm/opto/loopnode.cpp + test/compiler/7110586/Test7110586.java From sebastian.sickelmann at gmx.de Thu Nov 17 02:19:57 2011 From: sebastian.sickelmann at gmx.de (Sebastian Sickelmann) Date: Thu, 17 Nov 2011 11:19:57 +0100 Subject: Question about instanceKlass::find_field with and without boolean is_static parameter Message-ID: <4EC4DFCD.9080400@gmx.de> Hello, i few days ago i posted a question (maybe to the wrong list(hotspot-runtime-dev), so i now try it here: While evalutation some stuff in hotspot i got to the two instanceKlass::find_field methods. First i thought it could be an easy target for an code-deduplication refactoring. But than i saw that changing "instanceKlass::find_field(Symbol* name, Symbol* sig, fieldDescriptor* fd)" to klassOop instanceKlass::find_field(Symbol* name, Symbol* sig, fieldDescriptor* fd) const { find_field(name,sig,false,fd); } would change behavoir. There main reason that make me stop to refactor it was the difference between a call to instanceKlass::find_field(Symbol* name, Symbol* sig, fieldDescriptor* fd) and a call to instanceKlass::find_field(Symbol* name, Symbol* sig, bool is_static, fieldDescriptor* fd) with is_static = false. It is the part of // 2) search for field recursively in direct superinterfaces if (is_static) { klassOop intf = find_interface_field(name, sig, fd); if (intf != NULL) return intf; } in instanceKlass::find_field(Symbol* name, Symbol* sig, bool is_static, fieldDescriptor* fd) method that make the difference. I searched for the calls to these two methods to understand what's going on here. I found that the three usage of the method with the boolean parameter are needed by jni (GetFieldID and GetStaticFieldID) and the method ciInstanceKlass::get_field_by_name which is only used by PhaseStringOpts::PhaseStringOpts to find the sizeTable instancefield of the Integer Class. The Method without the boolean parameter is used for normal field lookup (JVM spec (5.4.3.2, p.167).) I think that the comment to the jvm spec in the method with the boolean parameter is misleading. This is a special function which is needed to fulfill the requirements of the two jni methods and the special case of the static sizeTable field. I think we can change the sizeTable example to something that uses the other method and does some checking(is field static and declaring class equals to Integer) afterwards. If this is possible i would suggest to rename the method with the boolean parameter to something more special and remove the comment to JVM spec (5.4.3.2, p.167). If i am totally wrong, please let me know. Kind regards Sebastian From sebastian.sickelmann at gmx.de Thu Nov 17 02:26:12 2011 From: sebastian.sickelmann at gmx.de (Sebastian Sickelmann) Date: Thu, 17 Nov 2011 11:26:12 +0100 Subject: Reason for non-const of instanceKlass::method_with_idnum(int idnum) Message-ID: <4EC4E144.9030004@gmx.de> Hello, is there a reason why the method instanceKlass::method_with_idnum(int idnum) does not have a const qualifier? The methods - instanceKlass::methods() - methodOop::idnum() - objectArrayOop::obj_at(int) that are used inside of method_with_idnum are all const and i don't see a change to manipulate the internal state of instanceKlass unintantional through making method_with_idnum constant. Kind regards Sebastian From john.coomes at oracle.com Thu Nov 17 11:20:04 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 17 Nov 2011 19:20:04 +0000 Subject: hg: hsx/hsx22/hotspot: 3 new changesets Message-ID: <20111117192011.CF48D473BA@hg.openjdk.java.net> Changeset: 0544a9618b87 Author: poonam Date: 2011-11-16 16:27 -0800 URL: http://hg.openjdk.java.net/hsx/hsx22/hotspot/rev/0544a9618b87 7110428: Crash during HeapDump operation Reviewed-by: ysr, dholmes ! src/share/vm/services/heapDumper.cpp Changeset: 3ba0bb2e7c8d Author: jcoomes Date: 2011-11-16 17:44 -0800 URL: http://hg.openjdk.java.net/hsx/hsx22/hotspot/rev/3ba0bb2e7c8d 7112766: Bump the hs22 build number to 10 Reviewed-by: johnc Contributed-by: alejandro.murillo at oracle.com ! make/hotspot_version Changeset: c6cd7638991b Author: jcoomes Date: 2011-11-16 17:44 -0800 URL: http://hg.openjdk.java.net/hsx/hsx22/hotspot/rev/c6cd7638991b Added tag hs22-b10 for changeset 3ba0bb2e7c8d ! .hgtags From tony.printezis at oracle.com Thu Nov 17 13:27:11 2011 From: tony.printezis at oracle.com (tony.printezis at oracle.com) Date: Thu, 17 Nov 2011 21:27:11 +0000 Subject: hg: hsx/hotspot-main/hotspot: 10 new changesets Message-ID: <20111117212732.DD2F4473BB@hg.openjdk.java.net> Changeset: 5a5ed80bea5b Author: ysr Date: 2011-10-26 21:07 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/5a5ed80bea5b 7105163: CMS: some mentions of MinChunkSize should be IndexSetStart Summary: Fixed the instances that were missed in the changeset for 7099817. Reviewed-by: stefank ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.hpp Changeset: 59519b7d7b9d Author: tonyp Date: 2011-10-28 13:04 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/59519b7d7b9d Merge Changeset: 6fd81579526f Author: brutisso Date: 2011-10-31 08:01 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/6fd81579526f 7102044: G1: VM crashes with assert(old_end != new_end) failed: don't call this otherwise Summary: arrayOopDesc::max_array_length() should return a value that does not overflow a size_t if it is converted to bytes. Reviewed-by: kvn, dholmes ! make/jprt.properties ! src/share/vm/oops/arrayOop.cpp ! src/share/vm/oops/arrayOop.hpp ! src/share/vm/prims/jni.cpp ! src/share/vm/utilities/quickSort.cpp ! test/Makefile Changeset: ed80554efa25 Author: brutisso Date: 2011-11-02 08:04 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/ed80554efa25 7106751: G1: gc/gctests/nativeGC03 crashes VM with SIGSEGV Summary: _cset_rs_update_cl[] was indexed with values beyond what it is set up to handle. Reviewed-by: ysr, jmasa, johnc ! src/share/vm/gc_implementation/g1/g1RemSet.cpp Changeset: 8aae2050e83e Author: tonyp Date: 2011-11-07 22:11 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/8aae2050e83e 7092309: G1: introduce old region set Summary: Keep track of all the old regions in the heap with a heap region set. Reviewed-by: brutisso, johnc ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1MarkSweep.cpp ! src/share/vm/gc_implementation/g1/heapRegionSet.cpp ! src/share/vm/gc_implementation/g1/heapRegionSet.hpp ! src/share/vm/gc_implementation/g1/heapRegionSets.cpp ! src/share/vm/gc_implementation/g1/heapRegionSets.hpp Changeset: 53074c2c4600 Author: tonyp Date: 2011-11-08 00:41 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/53074c2c4600 7099849: G1: include heap region information in hs_err files Reviewed-by: johnc, brutisso, poonam ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.cpp ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.hpp ! src/share/vm/gc_interface/collectedHeap.hpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/genCollectedHeap.hpp ! src/share/vm/memory/universe.cpp ! src/share/vm/memory/universe.hpp ! src/share/vm/utilities/vmError.cpp Changeset: ab5107bee78c Author: brutisso Date: 2011-11-09 23:21 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/ab5107bee78c 7110190: GCCause::to_string missing case for _adaptive_size_policy Summary: Added case for _adaptive_size_policy Reviewed-by: johnc, ysr ! src/share/vm/gc_interface/gcCause.cpp Changeset: aa4c21b00f7f Author: brutisso Date: 2011-11-15 20:17 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/aa4c21b00f7f 7110152: assert(size_in_words <= (julong)max_jint) failed: no overflow Summary: Reduce what arrayOopDesc::max_array_length() returns to avoid int overflow Reviewed-by: kvn, dholmes, tonyp ! src/share/vm/oops/arrayOop.hpp Changeset: 2ceafe3ceb65 Author: poonam Date: 2011-11-16 16:27 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/2ceafe3ceb65 7110428: Crash during HeapDump operation Reviewed-by: ysr, dholmes ! src/share/vm/services/heapDumper.cpp Changeset: b1754f3fbbd8 Author: tonyp Date: 2011-11-17 13:14 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/b1754f3fbbd8 Merge From david.holmes at oracle.com Thu Nov 17 13:39:01 2011 From: david.holmes at oracle.com (David Holmes) Date: Fri, 18 Nov 2011 07:39:01 +1000 Subject: Result: New HSX Committers Message-ID: <4EC57EF5.5060008@oracle.com> Voting for the following new committers [1] is now closed: Poonam Bajaj Vladimir Danushevsky Bertrand Delsart Zhengyu Gu Robert Ottenhag Frederic Parain Christian T?rnqvist Bob Vandette Kevin Walls Roland Westrelin Jesper Wilhelmsson Yes: 17 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nominations. David Holmes [1] http://mail.openjdk.java.net/pipermail/hotspot-dev/2011-November/004650.html From changren at taobao.com Thu Nov 17 22:39:06 2011 From: changren at taobao.com (changren) Date: Fri, 18 Nov 2011 14:39:06 +0800 Subject: Native wrapper optimization Message-ID: <4EC5FD8A.5060104@taobao.com> Hi, all Attached patch(diff with hsx20) is supposed to speed up native invocation. It rearranges the compiled-to-native wrapper code to straighten branches which improves spatial locality. Micro benchmark(500m consecutive JNI invocations with warm up) shows the stalled CPU cycles caused by instruction fetch due to L1 ICache miss decrease 3.4% on Intel Nehalem microarchitecture and 9.6% on Core microarchitecture. The real execution time of the micro benchmark is also decreased 5-10% respectively which reflects the improvement. Thanks, Joseph ________________________________ This email (including any attachments) is confidential and may be legally privileged. If you received this email in error, please delete it immediately and do not copy it or use it for any purpose or disclose its contents to any other person. Thank you. ??????(????????????)???????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: JNIWrapperOpt.patch Url: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20111118/38c6a0ea/JNIWrapperOpt.patch From christian.thalinger at oracle.com Fri Nov 18 01:09:53 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 18 Nov 2011 10:09:53 +0100 Subject: Native wrapper optimization In-Reply-To: <4EC5FD8A.5060104@taobao.com> References: <4EC5FD8A.5060104@taobao.com> Message-ID: <31E62419-9788-4714-9E12-3A5B43023C30@oracle.com> Looks like a good patch to me. What about 32-bit x86? -- Chris On Nov 18, 2011, at 7:39 AM, changren wrote: > Hi, all > Attached patch(diff with hsx20) is supposed to speed up native > invocation. It rearranges the compiled-to-native wrapper code to > straighten branches which improves spatial locality. Micro > benchmark(500m consecutive JNI invocations with warm up) shows the > stalled CPU cycles caused by instruction fetch due to L1 ICache miss > decrease 3.4% on Intel Nehalem microarchitecture and 9.6% on Core > microarchitecture. The real execution time of the micro benchmark is > also decreased 5-10% respectively which reflects the improvement. > Thanks, > Joseph > > > ________________________________ > > This email (including any attachments) is confidential and may be legally privileged. If you received this email in error, please delete it immediately and do not copy it or use it for any purpose or disclose its contents to any other person. Thank you. > > ??????(????????????)???????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? > From changren at taobao.com Fri Nov 18 03:13:28 2011 From: changren at taobao.com (changren) Date: Fri, 18 Nov 2011 19:13:28 +0800 Subject: Native wrapper optimization In-Reply-To: <31E62419-9788-4714-9E12-3A5B43023C30@oracle.com> References: <4EC5FD8A.5060104@taobao.com> <31E62419-9788-4714-9E12-3A5B43023C30@oracle.com> Message-ID: <4EC63DD8.609@taobao.com> Ok, Kris will help to port to 32bit. Thanks, Joseph ?? 2011-11-18 17:09, Christian Thalinger ????: > Looks like a good patch to me. What about 32-bit x86? > > -- Chris > > On Nov 18, 2011, at 7:39 AM, changren wrote: > >> Hi, all >> Attached patch(diff with hsx20) is supposed to speed up native >> invocation. It rearranges the compiled-to-native wrapper code to >> straighten branches which improves spatial locality. Micro >> benchmark(500m consecutive JNI invocations with warm up) shows the >> stalled CPU cycles caused by instruction fetch due to L1 ICache miss >> decrease 3.4% on Intel Nehalem microarchitecture and 9.6% on Core >> microarchitecture. The real execution time of the micro benchmark is >> also decreased 5-10% respectively which reflects the improvement. >> Thanks, >> Joseph >> >> >> ________________________________ >> >> This email (including any attachments) is confidential and may be legally privileged. If you received this email in error, please delete it immediately and do not copy it or use it for any purpose or disclose its contents to any other person. Thank you. >> >> ??????(????????????)???????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? >> From tom.rodriguez at oracle.com Fri Nov 18 11:24:04 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Fri, 18 Nov 2011 11:24:04 -0800 Subject: Reason for non-const of instanceKlass::method_with_idnum(int idnum) In-Reply-To: <4EC4E144.9030004@gmx.de> References: <4EC4E144.9030004@gmx.de> Message-ID: On Nov 17, 2011, at 2:26 AM, Sebastian Sickelmann wrote: > Hello, > > is there a reason why the method instanceKlass::method_with_idnum(int idnum) does not have a const qualifier? We're not particularly religious about the use of const so no one probably bothered. tom > > The methods > - instanceKlass::methods() > - methodOop::idnum() > - objectArrayOop::obj_at(int) > > that are used inside of method_with_idnum are all const and i don't see a change to manipulate the internal state of instanceKlass unintantional through making method_with_idnum constant. > > Kind regards > Sebastian From john.coomes at oracle.com Fri Nov 18 17:44:10 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Sat, 19 Nov 2011 01:44:10 +0000 Subject: hg: hsx/hsx23/hotspot: 44 new changesets Message-ID: <20111119014540.E7B26473E9@hg.openjdk.java.net> Changeset: 088d09a130ff Author: katleman Date: 2011-11-10 11:46 -0800 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/088d09a130ff Added tag jdk8-b13 for changeset b92ca8e229d2 ! .hgtags Changeset: 883328bfc472 Author: katleman Date: 2011-11-17 10:45 -0800 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/883328bfc472 Added tag jdk8-b14 for changeset 088d09a130ff ! .hgtags Changeset: 869804b759e7 Author: jcoomes Date: 2011-11-04 14:06 -0700 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/869804b759e7 7108553: Bump the hs23 build number to 06 Reviewed-by: johnc Contributed-by: alejandro.murillo at oracle.com ! make/hotspot_version Changeset: 5bda8dae4e14 Author: never Date: 2011-10-23 20:23 -0700 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/5bda8dae4e14 7103784: enable some flags by default Reviewed-by: kvn ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp Changeset: 754110e02bd5 Author: never Date: 2011-10-23 12:31 -0700 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/754110e02bd5 7103380: assertion failure with -XX:+PrintNativeNMethods Reviewed-by: kvn, iveresov ! src/share/vm/asm/codeBuffer.cpp Changeset: 42783d1414b2 Author: never Date: 2011-10-23 23:57 -0700 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/42783d1414b2 Merge - make/templates/bsd-header Changeset: b20d64f83668 Author: twisti Date: 2011-10-24 07:53 -0700 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/b20d64f83668 7090904: JSR 292: JRuby junit test crashes in PSScavengeRootsClosure::do_oop Reviewed-by: kvn, never, jrose ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp ! src/share/vm/interpreter/bytecodeTracer.cpp ! src/share/vm/runtime/deoptimization.cpp ! src/share/vm/runtime/frame.cpp ! src/share/vm/runtime/frame.hpp ! src/share/vm/runtime/thread.cpp Changeset: 12d38ffcba2a Author: twisti Date: 2011-10-25 00:55 -0700 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/12d38ffcba2a 7094138: JSR 292: JRuby junit test fails in CallSite.setTargetNormal: obj->is_oop() failed: sanity check Reviewed-by: iveresov, never ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/prims/unsafe.cpp Changeset: 2ec638646e86 Author: twisti Date: 2011-10-25 04:07 -0700 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/2ec638646e86 7101642: JSR 292: SIGSEGV in java.lang.invoke.MethodHandleImpl$FieldAccessor.getFieldI(Ljava/lang/Object;)I Reviewed-by: kvn, iveresov ! src/share/vm/runtime/sharedRuntime.cpp Changeset: a6eef545f1a2 Author: never Date: 2011-10-25 08:17 -0700 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/a6eef545f1a2 7103224: collision between __LEAF define in interfaceSupport.hpp and /usr/include/sys/cdefs.h with gcc Reviewed-by: never Contributed-by: Omair Majid ! src/share/vm/opto/addnode.cpp ! src/share/vm/prims/jniCheck.cpp ! src/share/vm/prims/jvmtiEnter.xsl ! src/share/vm/prims/jvmtiEnv.cpp ! src/share/vm/prims/jvmtiExport.cpp ! src/share/vm/runtime/interfaceSupport.hpp Changeset: e69a66a1457b Author: kvn Date: 2011-10-25 12:51 -0700 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/e69a66a1457b 7059039: EA: don't change non-escaping state of NULL pointer Summary: NULL pointers do not escape but escape state propagation may change it leading to worser results. Reviewed-by: never ! src/share/vm/opto/escape.cpp Changeset: d8cb48376797 Author: kvn Date: 2011-10-26 06:08 -0700 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/d8cb48376797 7097546: Optimize use of CMOVE instructions Summary: Avoid CMove in a loop if possible. May generate CMove if it could be moved outside a loop. Reviewed-by: never ! src/cpu/sparc/vm/sparc.ad ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/opto/loopopts.cpp ! src/share/vm/opto/matcher.hpp Changeset: cec1757a0134 Author: twisti Date: 2011-10-27 04:43 -0700 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/cec1757a0134 7102657: JSR 292: C1 deoptimizes unlinked invokedynamic call sites infinitely Reviewed-by: never, bdelsart ! src/cpu/sparc/vm/c1_CodeStubs_sparc.cpp ! src/cpu/sparc/vm/c1_Runtime1_sparc.cpp ! src/cpu/x86/vm/c1_CodeStubs_x86.cpp ! src/cpu/x86/vm/c1_Runtime1_x86.cpp ! src/share/vm/c1/c1_Runtime1.cpp ! src/share/vm/c1/c1_Runtime1.hpp ! src/share/vm/opto/runtime.cpp Changeset: e0658a9b3f87 Author: kvn Date: 2011-10-27 09:39 -0700 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/e0658a9b3f87 7105364: JDK8 b10 hotspot: src/share/vm/ci/ciMethodHandle.cpp Error: Use "." or "->" Summary: Define ciMethodHandle::print_chain_impl() and ciMethodHandle::print_chain() bodies only in debug builds. Reviewed-by: never, twisti ! src/share/vm/ci/ciMethodHandle.cpp ! src/share/vm/ci/ciMethodHandle.hpp Changeset: 34535d2cb362 Author: iveresov Date: 2011-10-27 14:40 -0700 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/34535d2cb362 7104177: Tiered: -XX:+PrintCanonicalization doesn't work with -XX:+TieredCompilation Summary: Initialize printable_bci of instruction when passed to Canonicalizer Reviewed-by: kvn, never ! src/share/vm/c1/c1_Canonicalizer.hpp Changeset: f350490a45fd Author: kvn Date: 2011-10-27 18:20 -0700 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/f350490a45fd 7105611: Set::print() is broken Summary: Reimplemented class VSetI_ to restore Set::print(). Reviewed-by: never ! src/share/vm/libadt/vectset.cpp ! src/share/vm/libadt/vectset.hpp Changeset: eba044a722a4 Author: never Date: 2011-10-28 14:44 -0700 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/eba044a722a4 7103261: crash with jittester on sparc Reviewed-by: iveresov, kvn ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp + test/compiler/7103261/Test7103261.java Changeset: e3b0dcc327b9 Author: twisti Date: 2011-10-31 03:06 -0700 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/e3b0dcc327b9 7104561: UseRDPCForConstantTableBase doesn't work after shorten branches changes Reviewed-by: never, kvn ! src/cpu/sparc/vm/vm_version_sparc.cpp ! src/share/vm/opto/machnode.cpp Changeset: 71699e9d8673 Author: kvn Date: 2011-10-31 15:52 -0700 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/71699e9d8673 7106907: 64 bit VM fails test compiler/6865265/StackOverflowBug.java Summary: Use -Xss224k instead of -Xss128k. Reviewed-by: never ! test/compiler/6865265/StackOverflowBug.java Changeset: e342a5110bed Author: twisti Date: 2011-11-03 01:43 -0700 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/e342a5110bed 7106774: JSR 292: nightly test inlineMHTarget fails with wrong result Reviewed-by: kvn ! src/share/vm/interpreter/bytecode.hpp ! src/share/vm/runtime/deoptimization.cpp Changeset: 448691f285a5 Author: twisti Date: 2011-11-03 04:12 -0700 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/448691f285a5 7106944: assert(_pc == *pc_addr) failed may be too strong Reviewed-by: kvn, never ! src/cpu/x86/vm/frame_x86.cpp Changeset: 1feb272af3a7 Author: never Date: 2011-11-04 13:55 -0700 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/1feb272af3a7 6636110: unaligned stackpointer leads to crash during deoptimization Reviewed-by: never, kvn Contributed-by: Andreas Schoesser ! src/cpu/x86/vm/sharedRuntime_x86_64.cpp Changeset: 59e515ee9354 Author: kvn Date: 2011-11-07 14:33 -0800 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/59e515ee9354 7059047: EA: can't find initializing store with several CheckCastPP Summary: Split adjust_escape_state() method into two methods to find initializing stores. Reviewed-by: never ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/escape.hpp Changeset: 44ce519bc3d1 Author: never Date: 2011-11-08 10:31 -0800 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/44ce519bc3d1 7104960: JSR 292: +VerifyMethodHandles in product JVM can overflow buffer Reviewed-by: kvn, jrose, twisti ! src/cpu/sparc/vm/assembler_sparc.inline.hpp ! src/cpu/sparc/vm/methodHandles_sparc.cpp ! src/cpu/sparc/vm/methodHandles_sparc.hpp ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/cpu/x86/vm/methodHandles_x86.hpp ! src/share/vm/asm/codeBuffer.cpp ! src/share/vm/asm/codeBuffer.hpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/runtime/globals.hpp Changeset: c9a03402fe56 Author: never Date: 2011-11-08 17:29 -0800 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/c9a03402fe56 7105305: assert check_method_context proper context Reviewed-by: jrose, kvn ! src/share/vm/code/dependencies.cpp ! src/share/vm/oops/constantPoolKlass.cpp Changeset: e3e363b2bf19 Author: never Date: 2011-11-08 20:42 -0800 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/e3e363b2bf19 7108242: jinfo -permstat shouldn't report interned strings as part of perm Reviewed-by: kvn, twisti ! agent/src/share/classes/sun/jvm/hotspot/tools/HeapSummary.java ! agent/src/share/classes/sun/jvm/hotspot/tools/PermStat.java Changeset: 83d0b5cd1438 Author: twisti Date: 2011-11-09 00:42 -0800 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/83d0b5cd1438 7087727: JSR 292: C2 crash if ScavengeRootsInCode=2 when "static final" MethodHandle constants are in use Reviewed-by: jrose, kvn, never ! src/share/vm/opto/callGenerator.cpp Changeset: 7e0e43cf86d6 Author: kvn Date: 2011-11-09 06:14 -0800 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/7e0e43cf86d6 7109887: java/util/Arrays/CopyMethods.java fails with -XX:+DeoptimizeALot Summary: zero array when compiled code is deoptimized. Reviewed-by: never, twisti ! src/share/vm/opto/runtime.cpp ! src/share/vm/opto/runtime.hpp Changeset: 670a74b863fc Author: kvn Date: 2011-11-09 07:25 -0800 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/670a74b863fc 7107042: assert(no_dead_loop) failed: dead loop detected Summary: Use dead nodes elimination code in PhaseIdealLoop before executing EA. Reviewed-by: never, twisti ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/loopnode.cpp ! src/share/vm/opto/loopnode.hpp ! src/share/vm/opto/loopopts.cpp ! src/share/vm/opto/matcher.cpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/phaseX.cpp ! src/share/vm/runtime/globals.hpp Changeset: 78bef05801ca Author: twisti Date: 2011-11-10 04:46 -0800 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/78bef05801ca Merge - src/share/vm/precompiled.hpp ! src/share/vm/runtime/globals.hpp Changeset: 3c7d67df8d07 Author: dholmes Date: 2011-11-10 06:23 -0500 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/3c7d67df8d07 7108264: Fix for 7104173 is insufficient Summary: Disable PrintVMOptions by default for all builds Reviewed-by: dsamersoff, twisti ! src/share/vm/runtime/globals.hpp Changeset: f9a80a035a4a Author: coleenp Date: 2011-11-15 12:40 -0500 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/f9a80a035a4a Merge ! src/share/vm/runtime/globals.hpp Changeset: 5a5ed80bea5b Author: ysr Date: 2011-10-26 21:07 -0700 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/5a5ed80bea5b 7105163: CMS: some mentions of MinChunkSize should be IndexSetStart Summary: Fixed the instances that were missed in the changeset for 7099817. Reviewed-by: stefank ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.hpp Changeset: 59519b7d7b9d Author: tonyp Date: 2011-10-28 13:04 -0400 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/59519b7d7b9d Merge Changeset: 6fd81579526f Author: brutisso Date: 2011-10-31 08:01 +0100 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/6fd81579526f 7102044: G1: VM crashes with assert(old_end != new_end) failed: don't call this otherwise Summary: arrayOopDesc::max_array_length() should return a value that does not overflow a size_t if it is converted to bytes. Reviewed-by: kvn, dholmes ! make/jprt.properties ! src/share/vm/oops/arrayOop.cpp ! src/share/vm/oops/arrayOop.hpp ! src/share/vm/prims/jni.cpp ! src/share/vm/utilities/quickSort.cpp ! test/Makefile Changeset: ed80554efa25 Author: brutisso Date: 2011-11-02 08:04 +0100 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/ed80554efa25 7106751: G1: gc/gctests/nativeGC03 crashes VM with SIGSEGV Summary: _cset_rs_update_cl[] was indexed with values beyond what it is set up to handle. Reviewed-by: ysr, jmasa, johnc ! src/share/vm/gc_implementation/g1/g1RemSet.cpp Changeset: 8aae2050e83e Author: tonyp Date: 2011-11-07 22:11 -0500 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/8aae2050e83e 7092309: G1: introduce old region set Summary: Keep track of all the old regions in the heap with a heap region set. Reviewed-by: brutisso, johnc ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1MarkSweep.cpp ! src/share/vm/gc_implementation/g1/heapRegionSet.cpp ! src/share/vm/gc_implementation/g1/heapRegionSet.hpp ! src/share/vm/gc_implementation/g1/heapRegionSets.cpp ! src/share/vm/gc_implementation/g1/heapRegionSets.hpp Changeset: 53074c2c4600 Author: tonyp Date: 2011-11-08 00:41 -0500 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/53074c2c4600 7099849: G1: include heap region information in hs_err files Reviewed-by: johnc, brutisso, poonam ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.cpp ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.hpp ! src/share/vm/gc_interface/collectedHeap.hpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/genCollectedHeap.hpp ! src/share/vm/memory/universe.cpp ! src/share/vm/memory/universe.hpp ! src/share/vm/utilities/vmError.cpp Changeset: ab5107bee78c Author: brutisso Date: 2011-11-09 23:21 +0100 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/ab5107bee78c 7110190: GCCause::to_string missing case for _adaptive_size_policy Summary: Added case for _adaptive_size_policy Reviewed-by: johnc, ysr ! src/share/vm/gc_interface/gcCause.cpp Changeset: aa4c21b00f7f Author: brutisso Date: 2011-11-15 20:17 +0100 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/aa4c21b00f7f 7110152: assert(size_in_words <= (julong)max_jint) failed: no overflow Summary: Reduce what arrayOopDesc::max_array_length() returns to avoid int overflow Reviewed-by: kvn, dholmes, tonyp ! src/share/vm/oops/arrayOop.hpp Changeset: 2ceafe3ceb65 Author: poonam Date: 2011-11-16 16:27 -0800 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/2ceafe3ceb65 7110428: Crash during HeapDump operation Reviewed-by: ysr, dholmes ! src/share/vm/services/heapDumper.cpp Changeset: b1754f3fbbd8 Author: tonyp Date: 2011-11-17 13:14 -0500 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/b1754f3fbbd8 Merge Changeset: 6c2a55d4902f Author: jcoomes Date: 2011-11-18 15:15 -0800 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/6c2a55d4902f Merge Changeset: fde2a39ed7f3 Author: jcoomes Date: 2011-11-18 15:15 -0800 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/fde2a39ed7f3 Added tag hs23-b06 for changeset 6c2a55d4902f ! .hgtags From john.coomes at oracle.com Sat Nov 19 00:18:42 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Sat, 19 Nov 2011 08:18:42 +0000 Subject: hg: hsx/hotspot-main: 8 new changesets Message-ID: <20111119081842.E6591473EB@hg.openjdk.java.net> Changeset: 26fb81a1e9ce Author: katleman Date: 2011-11-03 10:32 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/26fb81a1e9ce Added tag jdk8-b12 for changeset 8e2104d565ba ! .hgtags Changeset: 8da26d5c32a7 Author: katleman Date: 2011-11-10 11:45 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/8da26d5c32a7 Added tag jdk8-b13 for changeset 26fb81a1e9ce ! .hgtags Changeset: a62a0f35eb9c Author: asaha Date: 2011-06-27 11:45 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/a62a0f35eb9c Merge Changeset: f9b3e6b2aa2c Author: asaha Date: 2011-06-28 08:38 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/f9b3e6b2aa2c Merge Changeset: ea2ab83ce564 Author: asaha Date: 2011-07-19 11:03 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/ea2ab83ce564 Merge Changeset: 8f525559ae73 Author: asaha Date: 2011-11-07 21:45 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/8f525559ae73 Merge Changeset: 23aa7f2c80a2 Author: lana Date: 2011-11-14 18:16 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/23aa7f2c80a2 Merge Changeset: a4f28069d44a Author: katleman Date: 2011-11-17 10:45 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/a4f28069d44a Added tag jdk8-b14 for changeset 23aa7f2c80a2 ! .hgtags From john.coomes at oracle.com Sat Nov 19 00:18:56 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Sat, 19 Nov 2011 08:18:56 +0000 Subject: hg: hsx/hotspot-main/corba: 9 new changesets Message-ID: <20111119081903.310A5473EC@hg.openjdk.java.net> Changeset: 5b9d9b839d3d Author: katleman Date: 2011-11-03 10:32 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/5b9d9b839d3d Added tag jdk8-b12 for changeset 31d70911b712 ! .hgtags Changeset: 6f601a737e0f Author: katleman Date: 2011-11-10 11:45 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/6f601a737e0f Added tag jdk8-b13 for changeset 5b9d9b839d3d ! .hgtags Changeset: d84682019b5f Author: asaha Date: 2011-06-27 11:45 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/d84682019b5f Merge Changeset: 9c20c1e7cdd9 Author: asaha Date: 2011-06-28 08:38 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/9c20c1e7cdd9 Merge Changeset: cb5aec0570a5 Author: asaha Date: 2011-07-19 11:03 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/cb5aec0570a5 Merge Changeset: 21369018a679 Author: mbankal Date: 2011-08-09 05:39 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/21369018a679 7055902: Oracle Java IIOP Deserialization Type Confusion Remote Code Execution Vulnerability Reviewed-by: coffeys ! src/share/classes/com/sun/corba/se/impl/io/IIOPInputStream.java Changeset: 058c18d237a9 Author: asaha Date: 2011-11-07 21:45 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/058c18d237a9 Merge Changeset: e59c47de1ad8 Author: lana Date: 2011-11-14 18:16 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/e59c47de1ad8 Merge Changeset: 99925e8d1b86 Author: katleman Date: 2011-11-17 10:45 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/99925e8d1b86 Added tag jdk8-b14 for changeset e59c47de1ad8 ! .hgtags From john.coomes at oracle.com Sat Nov 19 00:19:12 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Sat, 19 Nov 2011 08:19:12 +0000 Subject: hg: hsx/hotspot-main/jaxp: 8 new changesets Message-ID: <20111119081912.F3FE5473ED@hg.openjdk.java.net> Changeset: bcc739229f63 Author: katleman Date: 2011-11-03 10:32 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/bcc739229f63 Added tag jdk8-b12 for changeset ca977d167697 ! .hgtags Changeset: e7172d80a8f4 Author: katleman Date: 2011-11-10 11:46 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/e7172d80a8f4 Added tag jdk8-b13 for changeset bcc739229f63 ! .hgtags Changeset: 7adf14d6060c Author: asaha Date: 2011-06-27 11:46 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/7adf14d6060c Merge Changeset: d239aa024b6e Author: asaha Date: 2011-06-28 08:38 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/d239aa024b6e Merge Changeset: eca33f89c823 Author: asaha Date: 2011-07-19 11:03 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/eca33f89c823 Merge Changeset: 0ed9ae36ee2a Author: asaha Date: 2011-11-07 21:47 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/0ed9ae36ee2a Merge Changeset: 9d0c9d638757 Author: lana Date: 2011-11-14 18:16 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/9d0c9d638757 Merge Changeset: 804f666d6d44 Author: katleman Date: 2011-11-17 10:45 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/804f666d6d44 Added tag jdk8-b14 for changeset 9d0c9d638757 ! .hgtags From john.coomes at oracle.com Sat Nov 19 00:19:22 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Sat, 19 Nov 2011 08:19:22 +0000 Subject: hg: hsx/hotspot-main/jaxws: 10 new changesets Message-ID: <20111119081922.C88F5473EE@hg.openjdk.java.net> Changeset: adf2a6b5fde1 Author: katleman Date: 2011-11-03 10:32 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxws/rev/adf2a6b5fde1 Added tag jdk8-b12 for changeset e6eed2ff5d5f ! .hgtags Changeset: f502a343a92e Author: katleman Date: 2011-11-10 11:46 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxws/rev/f502a343a92e Added tag jdk8-b13 for changeset adf2a6b5fde1 ! .hgtags Changeset: 75a652e72489 Author: asaha Date: 2011-06-27 11:46 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxws/rev/75a652e72489 Merge Changeset: b058cae6fd3b Author: asaha Date: 2011-06-28 08:39 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxws/rev/b058cae6fd3b Merge Changeset: 61c046c6895a Author: asaha Date: 2011-07-19 11:03 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxws/rev/61c046c6895a Merge Changeset: 9e82b46cd4fa Author: asaha Date: 2011-07-25 11:38 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxws/rev/9e82b46cd4fa 7046794: Configurable behavior for server-side stacktraces Reviewed-by: ramap ! jaxws.properties Changeset: c78fccb01d4e Author: asaha Date: 2011-11-07 21:48 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxws/rev/c78fccb01d4e Merge Changeset: cae6db74d6af Author: asaha Date: 2011-11-10 13:38 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxws/rev/cae6db74d6af 7110676: Update jaf source download url for jaxws Reviewed-by: ramap ! jaxws.properties Changeset: 54c4bf4b83ec Author: lana Date: 2011-11-14 18:16 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxws/rev/54c4bf4b83ec Merge Changeset: c9ab96ff23d5 Author: katleman Date: 2011-11-17 10:46 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxws/rev/c9ab96ff23d5 Added tag jdk8-b14 for changeset 54c4bf4b83ec ! .hgtags From john.coomes at oracle.com Sat Nov 19 00:21:57 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Sat, 19 Nov 2011 08:21:57 +0000 Subject: hg: hsx/hotspot-main/jdk: 92 new changesets Message-ID: <20111119083707.D642F473EF@hg.openjdk.java.net> Changeset: 7746eb8c610b Author: bae Date: 2011-10-17 15:20 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/7746eb8c610b 6997116: The case automatically failed due to java.lang.ClassCastException. Reviewed-by: jgodinez, prr ! src/windows/classes/sun/java2d/d3d/D3DSurfaceData.java + test/sun/java2d/DirectX/DrawBitmaskToSurfaceTest.java Changeset: a7a001378444 Author: jgodinez Date: 2011-10-24 09:58 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/a7a001378444 6604109: javax.print.PrintServiceLookup.lookupPrintServices fails SOMETIMES for Cups Reviewed-by: bae, prr ! src/solaris/classes/sun/print/UnixPrintServiceLookup.java Changeset: 8f9b0629d088 Author: lana Date: 2011-10-25 21:53 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/8f9b0629d088 Merge Changeset: 2b27e14a4c82 Author: vinnie Date: 2011-10-13 12:00 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/2b27e14a4c82 7099228: Use a PKCS11 config attribute to control encoding of an EC point Reviewed-by: valeriep, mullan ! src/share/classes/sun/security/pkcs11/Config.java ! src/share/classes/sun/security/pkcs11/P11ECKeyFactory.java ! src/share/classes/sun/security/pkcs11/P11Key.java ! src/share/lib/security/sunpkcs11-solaris.cfg ! test/ProblemList.txt Changeset: 01615d3e74ed Author: mullan Date: 2011-10-13 13:50 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/01615d3e74ed 6953295: Move few sun.security.{util, x509, pkcs} classes used by keytool/jarsigner to another package Reviewed-by: mchung ! make/sun/security/other/Makefile - src/share/classes/sun/security/pkcs/EncodingException.java - src/share/classes/sun/security/pkcs/PKCS10.java - src/share/classes/sun/security/pkcs/PKCS10Attribute.java - src/share/classes/sun/security/pkcs/PKCS10Attributes.java + src/share/classes/sun/security/pkcs10/PKCS10.java + src/share/classes/sun/security/pkcs10/PKCS10Attribute.java + src/share/classes/sun/security/pkcs10/PKCS10Attributes.java ! src/share/classes/sun/security/provider/certpath/CertStoreHelper.java ! src/share/classes/sun/security/provider/certpath/URICertStore.java ! src/share/classes/sun/security/provider/certpath/ldap/LDAPCertStore.java ! src/share/classes/sun/security/provider/certpath/ldap/LDAPCertStoreHelper.java + src/share/classes/sun/security/provider/certpath/ssl/SSLServerCertStore.java + src/share/classes/sun/security/provider/certpath/ssl/SSLServerCertStoreHelper.java + src/share/classes/sun/security/tools/CertAndKeyGen.java ! src/share/classes/sun/security/tools/KeyTool.java + src/share/classes/sun/security/tools/PathList.java - src/share/classes/sun/security/util/BigInt.java - src/share/classes/sun/security/util/PathList.java - src/share/classes/sun/security/x509/CertAndKeyGen.java - test/sun/security/util/BigInt/BigIntEqualsHashCode.java Changeset: 04ecbd2bcf5a Author: mullan Date: 2011-10-13 13:53 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/04ecbd2bcf5a Merge Changeset: 6cb07b35acf5 Author: weijun Date: 2011-10-17 17:11 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/6cb07b35acf5 7099399: cannot deal with CRL file larger than 16MB Reviewed-by: xuelei, mullan ! src/share/classes/sun/security/provider/X509Factory.java + test/sun/security/provider/X509Factory/BigCRL.java Changeset: 9bf526cc4046 Author: mullan Date: 2011-10-18 10:12 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/9bf526cc4046 7092897: sun.security.util.Cache should be generified Reviewed-by: xuelei ! src/share/classes/sun/security/pkcs11/KeyCache.java ! src/share/classes/sun/security/provider/X509Factory.java ! src/share/classes/sun/security/provider/certpath/CertStoreHelper.java ! src/share/classes/sun/security/provider/certpath/URICertStore.java ! src/share/classes/sun/security/provider/certpath/X509CertificatePair.java ! src/share/classes/sun/security/provider/certpath/ldap/LDAPCertStore.java ! src/share/classes/sun/security/ssl/SSLSessionContextImpl.java ! src/share/classes/sun/security/util/Cache.java Changeset: f566cd364a90 Author: mullan Date: 2011-10-18 10:15 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/f566cd364a90 Merge ! src/share/classes/sun/security/provider/X509Factory.java Changeset: 8640b7185be1 Author: wetmore Date: 2011-10-18 11:58 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/8640b7185be1 7031830: bad_record_mac failure on TLSv1.2 enabled connection with SSLEngine Reviewed-by: xuelei, weijun, asaha ! src/share/classes/sun/security/ssl/CipherBox.java + test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLEngineImpl/SSLEngineBadBufferArrayAccess.java Changeset: 57eb9136b73b Author: mullan Date: 2011-10-19 10:15 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/57eb9136b73b 7102686: Restructure timestamp code so that jars and modules can more easily share the same code Reviewed-by: mchung ! src/share/classes/sun/security/pkcs/PKCS7.java ! src/share/classes/sun/security/pkcs/SignerInfo.java ! src/share/classes/sun/security/timestamp/HttpTimestamper.java ! src/share/classes/sun/security/timestamp/TSRequest.java ! src/share/classes/sun/security/timestamp/TSResponse.java ! src/share/classes/sun/security/tools/JarSigner.java ! src/share/classes/sun/security/tools/TimestampedSigner.java ! src/share/classes/sun/security/util/Debug.java ! src/share/classes/sun/security/util/SignatureFileVerifier.java Changeset: 15078025eed9 Author: mullan Date: 2011-10-19 10:16 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/15078025eed9 Merge Changeset: c5c91589b126 Author: mduigou Date: 2011-10-19 14:17 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/c5c91589b126 5029031: Add Collections.checkedQueue() Reviewed-by: mduigou Contributed-by: darryl.mocek at oracle.com ! src/share/classes/java/util/Collections.java + test/java/util/Collections/CheckedQueue.java Changeset: 634cd6f050ba Author: chegar Date: 2011-10-20 09:08 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/634cd6f050ba 7102704: test/java/net/DatagramSocket/ChangingAddress.java failing Reviewed-by: chegar Contributed-by: kurchi.subhra.hazra at oracle.com - test/java/net/DatagramSocket/ChangingAddress.java Changeset: 2d89c3f74aa5 Author: michaelm Date: 2011-10-20 09:21 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/2d89c3f74aa5 7102665: Move tests to Problemlist Reviewed-by: chegar, alanb ! test/ProblemList.txt Changeset: 52c2dd336207 Author: michaelm Date: 2011-10-20 09:26 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/52c2dd336207 Merge - test/java/net/DatagramSocket/ChangingAddress.java Changeset: c3da0672a882 Author: ngmr Date: 2011-10-13 12:30 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/c3da0672a882 7100054: (porting) Native code should include fcntl.h and unistd.h rather than sys/fcntl.h and sys/unistd.h Summary: Use POSIX defined includes for unistd.h and fcntl.h Reviewed-by: dholmes, alanb, chegar, ngmr Contributed-by: Charles Lee ! src/solaris/native/sun/nio/fs/genSolarisConstants.c ! src/solaris/native/sun/nio/fs/genUnixConstants.c Changeset: d979afceb792 Author: peytoia Date: 2011-10-21 15:56 +0900 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/d979afceb792 7103108: (tz) Support tzdata2011l Reviewed-by: okutsu ! make/sun/javazic/tzdata/VERSION ! make/sun/javazic/tzdata/asia ! make/sun/javazic/tzdata/australasia ! make/sun/javazic/tzdata/europe ! make/sun/javazic/tzdata/northamerica ! make/sun/javazic/tzdata/southamerica ! make/sun/javazic/tzdata/zone.tab ! src/share/classes/sun/util/resources/TimeZoneNames.java ! src/share/classes/sun/util/resources/TimeZoneNames_de.java ! src/share/classes/sun/util/resources/TimeZoneNames_es.java ! src/share/classes/sun/util/resources/TimeZoneNames_fr.java ! src/share/classes/sun/util/resources/TimeZoneNames_it.java ! src/share/classes/sun/util/resources/TimeZoneNames_ja.java ! src/share/classes/sun/util/resources/TimeZoneNames_ko.java ! src/share/classes/sun/util/resources/TimeZoneNames_pt_BR.java ! src/share/classes/sun/util/resources/TimeZoneNames_sv.java ! src/share/classes/sun/util/resources/TimeZoneNames_zh_CN.java ! src/share/classes/sun/util/resources/TimeZoneNames_zh_TW.java Changeset: db9e246c651e Author: peytoia Date: 2011-10-21 18:01 +0900 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/db9e246c651e 7103405: Correct display names for Pacific/Apia timezone Reviewed-by: okutsu ! src/share/classes/sun/util/resources/TimeZoneNames.java ! src/share/classes/sun/util/resources/TimeZoneNames_de.java ! src/share/classes/sun/util/resources/TimeZoneNames_es.java ! src/share/classes/sun/util/resources/TimeZoneNames_fr.java ! src/share/classes/sun/util/resources/TimeZoneNames_it.java ! src/share/classes/sun/util/resources/TimeZoneNames_ja.java ! src/share/classes/sun/util/resources/TimeZoneNames_ko.java ! src/share/classes/sun/util/resources/TimeZoneNames_pt_BR.java ! src/share/classes/sun/util/resources/TimeZoneNames_sv.java ! src/share/classes/sun/util/resources/TimeZoneNames_zh_CN.java ! src/share/classes/sun/util/resources/TimeZoneNames_zh_TW.java Changeset: 3f391e649ccb Author: chegar Date: 2011-10-24 20:55 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/3f391e649ccb 7104209: Cleanup and remove librmi (native library) Reviewed-by: mduigou, alanb ! make/java/java/mapfile-vers ! make/sun/rmi/rmi/Makefile - make/sun/rmi/rmi/mapfile-vers ! src/share/classes/java/io/ObjectInputStream.java ! src/share/classes/sun/misc/VM.java ! src/share/classes/sun/rmi/server/MarshalInputStream.java ! src/share/native/java/io/ObjectInputStream.c ! src/share/native/sun/misc/VM.c - src/share/native/sun/rmi/server/MarshalInputStream.c Changeset: b375523d6037 Author: chegar Date: 2011-10-24 21:03 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/b375523d6037 7103549: Remove dependencies on libjava and libjvm from security libraries Reviewed-by: vinnie, ohair, alanb, dholmes ! make/com/sun/security/auth/module/Makefile ! make/common/Defs.gmk ! make/common/Library.gmk ! make/sun/security/ec/Makefile ! make/sun/security/jgss/wrapper/Makefile ! make/sun/security/krb5/Makefile ! make/sun/security/mscapi/Makefile ! make/sun/security/pkcs11/Makefile ! make/sun/security/smartcardio/Makefile ! src/share/native/sun/security/pkcs11/wrapper/p11_convert.c ! src/share/native/sun/security/pkcs11/wrapper/p11_digest.c ! src/share/native/sun/security/pkcs11/wrapper/p11_dual.c ! src/share/native/sun/security/pkcs11/wrapper/p11_general.c ! src/share/native/sun/security/pkcs11/wrapper/p11_keymgmt.c ! src/share/native/sun/security/pkcs11/wrapper/p11_mutex.c ! src/share/native/sun/security/pkcs11/wrapper/p11_objmgmt.c ! src/share/native/sun/security/pkcs11/wrapper/p11_sessmgmt.c ! src/share/native/sun/security/pkcs11/wrapper/p11_sign.c ! src/share/native/sun/security/pkcs11/wrapper/p11_util.c ! src/share/native/sun/security/pkcs11/wrapper/pkcs11wrapper.h ! src/solaris/native/sun/security/pkcs11/j2secmod_md.c ! src/solaris/native/sun/security/smartcardio/pcsc_md.c ! src/windows/native/sun/security/pkcs11/j2secmod_md.c Changeset: 72666cd49ac3 Author: alanb Date: 2011-10-25 09:27 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/72666cd49ac3 7104577: Changes for 7104209 cause many RMI tests to fail Reviewed-by: chegar ! src/share/classes/sun/rmi/server/MarshalInputStream.java Changeset: 7814800c64bd Author: lana Date: 2011-10-25 21:54 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/7814800c64bd Merge - make/sun/rmi/rmi/mapfile-vers - src/share/classes/sun/security/pkcs/EncodingException.java - src/share/classes/sun/security/pkcs/PKCS10.java - src/share/classes/sun/security/pkcs/PKCS10Attribute.java - src/share/classes/sun/security/pkcs/PKCS10Attributes.java - src/share/classes/sun/security/util/BigInt.java - src/share/classes/sun/security/util/PathList.java - src/share/classes/sun/security/x509/CertAndKeyGen.java - src/share/native/sun/rmi/server/MarshalInputStream.c - test/java/net/DatagramSocket/ChangingAddress.java - test/sun/security/util/BigInt/BigIntEqualsHashCode.java Changeset: 09fd2067f715 Author: lana Date: 2011-10-28 17:49 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/09fd2067f715 Merge - make/sun/rmi/rmi/mapfile-vers - src/share/classes/sun/security/pkcs/EncodingException.java - src/share/classes/sun/security/pkcs/PKCS10.java - src/share/classes/sun/security/pkcs/PKCS10Attribute.java - src/share/classes/sun/security/pkcs/PKCS10Attributes.java - src/share/classes/sun/security/util/BigInt.java - src/share/classes/sun/security/util/PathList.java - src/share/classes/sun/security/x509/CertAndKeyGen.java - src/share/native/sun/rmi/server/MarshalInputStream.c - test/java/net/DatagramSocket/ChangingAddress.java - test/sun/security/util/BigInt/BigIntEqualsHashCode.java Changeset: d636e737c478 Author: katleman Date: 2011-11-03 10:32 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/d636e737c478 Added tag jdk8-b12 for changeset 09fd2067f715 ! .hgtags Changeset: bfd720647db2 Author: yhuang Date: 2011-10-31 20:14 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/bfd720647db2 7077119: remove past transition dates from CurrencyData.properties file Reviewed-by: naoto ! src/share/classes/java/util/CurrencyData.properties ! test/java/util/Currency/CurrencyTest.java ! test/java/util/Currency/ValidateISO4217.java ! test/java/util/Currency/tablea1.txt Changeset: cfc6fd491b97 Author: yhuang Date: 2011-10-31 21:30 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/cfc6fd491b97 6755060: Collator.compare() does not compare correctly for the Thai locale Reviewed-by: naoto ! src/share/classes/sun/text/resources/CollationData_th.java + test/sun/text/resources/Collator/Bug6755060.java Changeset: 0549410acf26 Author: yhuang Date: 2011-10-31 21:38 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/0549410acf26 Merge Changeset: f3227efde13d Author: yhuang Date: 2011-10-31 21:43 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/f3227efde13d 7101495: In Latvia first day of week is Monday Reviewed-by: naoto, peytoia ! src/share/classes/sun/util/resources/CalendarData_lv.properties ! test/sun/text/resources/LocaleData ! test/sun/text/resources/LocaleDataTest.java Changeset: ab837acc60fb Author: yhuang Date: 2011-10-31 21:45 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/ab837acc60fb Merge Changeset: 631ee738378a Author: mfang Date: 2011-11-03 17:34 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/631ee738378a Merge Changeset: 94e5604022fa Author: ngmr Date: 2011-09-15 19:29 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/94e5604022fa 6988099: jvmti demos missing Publisher (COMPANY resource) in dlls/exes on windows Summary: Add creation/linking of resource data to link step for demos on Windows Reviewed-by: dcubed, zgu, ngmr, ohair Contributed-by: Sean Chou ! make/common/Demo.gmk Changeset: 5791714b9472 Author: ohair Date: 2011-11-04 10:34 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/5791714b9472 Merge Changeset: 4cb2e8679b27 Author: katleman Date: 2011-11-09 13:46 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/4cb2e8679b27 Merge Changeset: 52bd7fc8fcb0 Author: katleman Date: 2011-11-10 11:46 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/52bd7fc8fcb0 Added tag jdk8-b13 for changeset 4cb2e8679b27 ! .hgtags Changeset: 9de1dbf8c9be Author: lana Date: 2011-10-26 17:59 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/9de1dbf8c9be Merge - src/share/classes/java/util/XMLUtils.java - src/share/classes/sun/tools/jar/JarImageSource.java Changeset: 76defa20906a Author: ngmr Date: 2011-09-23 15:18 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/76defa20906a 7105640: Unix printing does not check the result of exec'd lpr/lp command Summary: Add checking, exception for spool process failure Reviewed-by: prr, jgodinez Contributed-by: Neil Richards ! src/share/classes/sun/print/PSPrinterJob.java ! src/solaris/classes/sun/print/UnixPrintJob.java Changeset: 4544585a3cea Author: lana Date: 2011-11-05 14:27 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/4544585a3cea Merge - make/sun/rmi/rmi/mapfile-vers - src/share/classes/sun/security/pkcs/EncodingException.java - src/share/classes/sun/security/pkcs/PKCS10.java - src/share/classes/sun/security/pkcs/PKCS10Attribute.java - src/share/classes/sun/security/pkcs/PKCS10Attributes.java - src/share/classes/sun/security/util/BigInt.java - src/share/classes/sun/security/util/PathList.java - src/share/classes/sun/security/x509/CertAndKeyGen.java - src/share/native/sun/rmi/server/MarshalInputStream.c - test/java/net/DatagramSocket/ChangingAddress.java - test/sun/security/util/BigInt/BigIntEqualsHashCode.java Changeset: aa3f5117c485 Author: rupashka Date: 2011-10-17 15:10 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/aa3f5117c485 7099251: javax.swing.text.html.HTMLDocument.insertAfterStart(null, something) throws NPE Reviewed-by: rupashka Contributed-by: alexandr.scherbatiy at oracle.com ! src/share/classes/javax/swing/text/html/HTMLDocument.java Changeset: 4f74e3fdf86b Author: rupashka Date: 2011-10-17 16:40 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/4f74e3fdf86b 7100004: javax.swing.JTable.setAutoCreateRowSorter(boolean autoCreateRowSorter) should mention default value Reviewed-by: rupashka Contributed-by: alexandr.scherbatiy at oracle.com ! src/share/classes/javax/swing/JTable.java Changeset: f1dbc62c7c6d Author: rupashka Date: 2011-10-17 17:19 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/f1dbc62c7c6d 7077293: javax/swing/JComponent/4337267/bug4337267.java failed on windows 2003 Reviewed-by: rupashka Contributed-by: alexandr.scherbatiy at oracle.com ! src/share/classes/sun/swing/SwingUtilities2.java Changeset: a2f5d7049258 Author: dbuck Date: 2011-10-17 19:06 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/a2f5d7049258 6887286: StackOverflowError at sun.awt.image.ImageWatched$WeakLink.isWatcher Summary: Fixed OffScreenImageSource to call imageComplete() with SINGLEFAMEDONE, not STATICIMAGEDONE. This fixed memory leak (that caused SOFE when we use recursion to iterate over linked list). Reviewed-by: bae ! src/share/classes/sun/awt/image/OffScreenImageSource.java Changeset: 7636a62aba7e Author: anthony Date: 2011-11-01 18:01 +0300 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/7636a62aba7e 7104625: sun.awt.X11.XEvent is creating 600 MB of char[] for no good reason Summary: Wrap logging calls with if(){} statements Reviewed-by: anthony, son Contributed-by: Federico Tello Gentile ! src/solaris/classes/sun/awt/X11/XComponentPeer.java Changeset: ac55f169fadd Author: anthony Date: 2011-11-01 18:03 +0300 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/ac55f169fadd 7105529: XAWT: Optimize getFieldsAsString() methods generated by WrapperGenerator Summary: Replace string concatenation with StringBuilder.append() Reviewed-by: anthony, son Contributed-by: Federico Tello Gentile ! src/solaris/classes/sun/awt/X11/generator/WrapperGenerator.java Changeset: 41610a897379 Author: rupashka Date: 2011-11-02 14:17 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/41610a897379 6624077: Regression test fails: closed/javax/swing/ToolTipManager/6256140/bug6256140.java Reviewed-by: rupashka Contributed-by: alexandr.scherbatiy at oracle.com + test/javax/swing/ToolTipManager/Test6256140.java Changeset: 8068f1584715 Author: mrkam Date: 2011-11-02 17:39 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/8068f1584715 7074853: TransparentRuler demos Readme should mention the correct jar file name Reviewed-by: rupashka ! src/share/demo/jfc/TransparentRuler/README.txt Changeset: 323f6d046cc9 Author: rupashka Date: 2011-11-02 23:53 +0300 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/323f6d046cc9 7049024: DnD fails with JTextArea and JTextField Reviewed-by: rupashka Contributed-by: Sean Chou ! src/share/classes/javax/swing/text/DefaultCaret.java + test/javax/swing/JTextArea/7049024/bug7049024.java Changeset: 7c29751a9331 Author: rupashka Date: 2011-11-03 14:14 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/7c29751a9331 6955919: Intermittent ClassCastException in bug4492274 test Reviewed-by: rupashka Contributed-by: alexandr.scherbatiy at oracle.com + test/javax/swing/JEditorPane/4492274/bug4492274.java + test/javax/swing/JEditorPane/4492274/test.html Changeset: 1c0624d9a2b6 Author: ngmr Date: 2011-10-13 13:02 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/1c0624d9a2b6 7107957: AWT: Native code should include fcntl.h and unistd.h rather than sys/fcntl.h and sys/unistd.h Summary: Use POSIX defined includes for unistd.h and fcntl.h Reviewed-by: anthony, ngmr Contributed-by: Charles Lee ! src/solaris/native/sun/awt/splashscreen/splashscreen_config.h Changeset: adb31ff942ef Author: rupashka Date: 2011-11-07 16:50 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/adb31ff942ef 7080203: JTree.getSelectionPaths() now returns empty array instead of null Reviewed-by: malenkov ! src/share/classes/javax/swing/JTree.java Changeset: d219e0b11327 Author: lana Date: 2011-11-07 10:26 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/d219e0b11327 Merge - make/sun/rmi/rmi/mapfile-vers - src/share/classes/java/util/XMLUtils.java - src/share/classes/sun/security/pkcs/EncodingException.java - src/share/classes/sun/security/pkcs/PKCS10.java - src/share/classes/sun/security/pkcs/PKCS10Attribute.java - src/share/classes/sun/security/pkcs/PKCS10Attributes.java - src/share/classes/sun/security/util/BigInt.java - src/share/classes/sun/security/util/PathList.java - src/share/classes/sun/security/x509/CertAndKeyGen.java - src/share/classes/sun/tools/jar/JarImageSource.java - src/share/native/sun/awt/libpng/pnggccrd.c - src/share/native/sun/awt/libpng/pngvcrd.c - src/share/native/sun/rmi/server/MarshalInputStream.c - test/sun/security/util/BigInt/BigIntEqualsHashCode.java Changeset: f8a3dff76b48 Author: rupashka Date: 2011-11-08 14:36 +0300 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/f8a3dff76b48 7107585: Test incorrect calculate position of object on frame Reviewed-by: rupashka Contributed-by: alexandr.scherbatiy at oracle.com + test/javax/swing/JSlider/6348946/bug6348946.java Changeset: af4fb33fca29 Author: lana Date: 2011-11-08 15:37 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/af4fb33fca29 Merge Changeset: 88a260444e4d Author: chegar Date: 2011-10-26 13:58 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/88a260444e4d 7104650: rawtype warnings in several net, nio and security source files Summary: Also reviewed by Ulf.Zibis at gmx.de Reviewed-by: mcimadamore, alanb, dholmes ! make/sun/net/Makefile ! src/share/classes/java/net/InetAddress.java ! src/share/classes/java/net/ServerSocket.java ! src/share/classes/java/nio/charset/Charset.java ! src/share/classes/java/security/Security.java ! src/share/classes/sun/nio/ch/Util.java Changeset: 0d371f2911a1 Author: peytoia Date: 2011-10-26 22:16 +0900 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/0d371f2911a1 7090046: Lots of invalid link in java.text.BreakIterator comments Reviewed-by: okutsu ! src/share/classes/java/text/BreakIterator.java Changeset: 291b55aa9b1e Author: lana Date: 2011-10-25 10:51 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/291b55aa9b1e Merge - src/share/native/sun/awt/libpng/pnggccrd.c - src/share/native/sun/awt/libpng/pngvcrd.c Changeset: 64faf533b99d Author: lana Date: 2011-10-26 12:29 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/64faf533b99d Merge Changeset: 449113aea001 Author: weijun Date: 2011-10-27 17:23 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/449113aea001 7104161: test/sun/tools/jinfo/Basic.sh fails on Ubuntu Reviewed-by: alanb ! test/sun/tools/jinfo/Basic.sh Changeset: 64ccf18bbad5 Author: coffeys Date: 2011-10-27 10:32 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/64ccf18bbad5 7099658: Properties.loadFromXML fails with ClassCastException Reviewed-by: alanb, mchung ! src/share/classes/sun/util/xml/XMLUtils.java Changeset: 56cc907fc8dc Author: mullan Date: 2011-10-27 10:57 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/56cc907fc8dc 7094155: JSR105 code throws javax.xml.crypto.URIReferenceException when running into Java 7 VM Reviewed-by: xuelei ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/IdResolver.java ! test/javax/xml/crypto/dsig/GenerationTests.java Changeset: 8cd2e3b8127a Author: mullan Date: 2011-10-27 11:01 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/8cd2e3b8127a Merge - make/sun/rmi/rmi/mapfile-vers - src/share/native/sun/awt/libpng/pnggccrd.c - src/share/native/sun/awt/libpng/pngvcrd.c - src/share/native/sun/rmi/server/MarshalInputStream.c Changeset: 6e59c482e9b8 Author: xuelei Date: 2011-10-28 07:18 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/6e59c482e9b8 7105940: Test regression: KeyStore must be from provider SunPKCS11-NSSKeyStore Reviewed-by: weijun ! test/sun/security/pkcs11/fips/CipherTest.java ! test/sun/security/pkcs11/fips/ClientJSSEServerJSSE.java Changeset: bb2b9a8b6e77 Author: alanb Date: 2011-10-30 14:53 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/bb2b9a8b6e77 7103889: (fs) Reduce String concatenation when iterating over directory Reviewed-by: alanb Contributed-by: mike.skells at talk21.com ! src/share/classes/java/nio/file/Files.java ! src/windows/classes/sun/nio/fs/WindowsDirectoryStream.java ! src/windows/classes/sun/nio/fs/WindowsPathParser.java Changeset: 30900a1a9cfc Author: xuelei Date: 2011-10-30 20:07 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/30900a1a9cfc 7106277: Brokenness in the seqNumberOverflow of MAC Reviewed-by: wetmore ! src/share/classes/sun/security/ssl/MAC.java Changeset: 8681362a2f04 Author: wetmore Date: 2011-10-31 11:54 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/8681362a2f04 7105780: Add SSLSocket client/SSLEngine server to templates directory Reviewed-by: xuelei + test/sun/security/ssl/templates/SSLSocketSSLEngineTemplate.java Changeset: b60e88ef5d8d Author: wetmore Date: 2011-10-31 16:23 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/b60e88ef5d8d 7053252: New regression test does not compile on windows-amd64 Reviewed-by: valeriep ! test/ProblemList.txt ! test/sun/security/pkcs11/Provider/Absolute.java Changeset: 5f2838744544 Author: ysr Date: 2011-10-31 17:38 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/5f2838744544 4243978: (ref) Race condition in Reference.enqueue() 4268317: (ref) Reference.isEnqueued() can return true when instance not enqueued Summary: The reference handler now declares, and assumes, that the discovered field, rather than the next field, is (to be) used to link the entries in the pending list, thus allowing a reference object to be safely enqueued even while it is in the pending state. Also added slightly modified regression tests from the two bug reports. Reviewed-by: mchung, alanb, jcoomes ! src/share/classes/java/lang/ref/Reference.java ! src/share/javavm/export/jvm.h ! src/share/native/common/jdk_util.c + test/java/lang/ref/ReferenceEnqueue.java + test/java/lang/ref/ReferenceEnqueuePending.java Changeset: 2f2f56ac8b82 Author: mduigou Date: 2011-11-03 13:26 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/2f2f56ac8b82 4533691: Add Collections.emptySortedSet() Reviewed-by: mduigou, alanb, dholmes Contributed-by: darryl.mocek at oracle.com ! src/share/classes/java/util/Collections.java + test/java/util/Collections/EmptySortedSet.java Changeset: ead9dabe8c75 Author: lana Date: 2011-11-05 00:00 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/ead9dabe8c75 Merge Changeset: 417d91754849 Author: sherman Date: 2011-11-07 13:46 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/417d91754849 7096080: UTF8 update and new CESU-8 charset 7082884: Incorrect UTF8 conversion for sequence ED 31 7082883: Incorrect UTF8 conversion for sequence fc 80 80 8f bf bf Summary: Updated UTF8 and added CESU-8 to following the latest Standard Reviewed-by: alanb ! make/java/nio/FILES_java.gmk + src/share/classes/sun/nio/cs/CESU_8.java ! src/share/classes/sun/nio/cs/UTF_8.java ! src/share/classes/sun/nio/cs/standard-charsets ! test/java/nio/charset/coders/Errors.java ! test/sun/nio/cs/TestStringCoding.java ! test/sun/nio/cs/TestStringCodingUTF8.java ! test/sun/nio/cs/TestUTF8.java Changeset: 0bb498332894 Author: lana Date: 2011-11-08 15:38 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/0bb498332894 Merge Changeset: 51db54a3b953 Author: lana Date: 2011-11-14 18:15 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/51db54a3b953 Merge Changeset: 3b2128c89361 Author: alanb Date: 2011-06-15 14:49 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/3b2128c89361 7000600: InputStream.skip() makes sensitive data accessible to malicious code Reviewed-by: hawtin, chegar ! src/share/classes/java/io/InputStream.java Changeset: 06e0d91548b3 Author: anthony Date: 2011-06-21 20:20 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/06e0d91548b3 7022113: Security icon can be moved behind the window using the com.sun.SecurityWarning.setPosition() method Reviewed-by: art, dcherepanov ! src/windows/native/sun/windows/awt_Window.cpp Changeset: d32b75c73389 Author: alanb Date: 2011-06-27 20:30 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/d32b75c73389 7059259: (process) ProcessBuilder.start permission check should be improved when redirecting output to append Reviewed-by: hawtin ! src/windows/classes/java/lang/ProcessImpl.java Changeset: 446b13a08aca Author: asaha Date: 2011-06-27 12:30 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/446b13a08aca Merge Changeset: 4fdd1a44e846 Author: asaha Date: 2011-06-27 12:35 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/4fdd1a44e846 Merge Changeset: 3e42f7893861 Author: asaha Date: 2011-06-28 08:39 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/3e42f7893861 Merge Changeset: f578448792b9 Author: ksrini Date: 2011-07-15 13:57 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/f578448792b9 7057857: SIGSEGV [libunpack.so] store_Utf8_char(signed char*, unsigned short) in java.util.jar.pack200 Reviewed-by: jrose, asaha, hawtin ! src/share/native/com/sun/java/util/jar/pack/unpack.cpp ! src/share/native/com/sun/java/util/jar/pack/utils.cpp ! src/share/native/com/sun/java/util/jar/pack/utils.h Changeset: 4b20375fe623 Author: asaha Date: 2011-07-19 11:04 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/4b20375fe623 Merge - src/share/classes/sun/misc/JavaxSecurityAuthKerberosAccess.java - test/sun/security/ssl/com/sun/net/ssl/internal/ssl/InputRecord/InterruptedIO.java Changeset: bc9c70e57f62 Author: asaha Date: 2011-07-20 09:01 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/bc9c70e57f62 7032417: Fix for 6981922 does not address multiple VM case Reviewed-by: michaelm ! src/share/classes/sun/net/ResourceManager.java Changeset: a7177942302f Author: asaha Date: 2011-07-20 14:45 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/a7177942302f 7023640: calculation for malloc size in TransformHelper.c could overflow an integer Reviewed-by: flar ! src/share/native/sun/java2d/loops/TransformHelper.c Changeset: 6c76f2a49061 Author: denis Date: 2011-07-22 21:14 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/6c76f2a49061 7019773: AWTKeyStroke.ctor is a mutable static Reviewed-by: art ! src/share/classes/java/awt/AWTKeyStroke.java Changeset: b25558c39ffc Author: smarks Date: 2011-08-30 14:30 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/b25558c39ffc 7077466: fix for RMI DGC Reviewed-by: valeriep ! src/share/classes/sun/rmi/server/UnicastServerRef.java Changeset: efd8035f3d14 Author: smarks Date: 2011-08-30 17:29 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/efd8035f3d14 7083012: fix for RMI Registry Reviewed-by: jdn, valeriep ! src/share/classes/sun/rmi/registry/RegistryImpl.java ! src/share/classes/sun/rmi/server/LoaderHandler.java Changeset: 27bda11f1330 Author: smarks Date: 2011-09-21 15:37 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/27bda11f1330 7092186: adjust package access in rmiregistry Reviewed-by: asaha, coffeys ! src/share/classes/sun/rmi/registry/RegistryImpl.java ! test/sun/tools/jstatd/jstatdExternalRegistry.sh Changeset: 42eb725f739c Author: xuelei Date: 2011-09-29 17:31 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/42eb725f739c 7064341: jsse/runtime security problem Reviewed-by: wetmore ! src/share/classes/javax/net/ssl/SSLEngine.java ! src/share/classes/sun/security/ssl/AppOutputStream.java ! src/share/classes/sun/security/ssl/CipherBox.java ! src/share/classes/sun/security/ssl/CipherSuite.java ! src/share/classes/sun/security/ssl/EngineOutputRecord.java ! src/share/classes/sun/security/ssl/Record.java ! src/share/classes/sun/security/ssl/SSLEngineImpl.java ! src/share/classes/sun/security/ssl/SSLSocketImpl.java ! test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/CheckStatus.java ! test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/LargeBufs.java ! test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/LargePacket.java Changeset: 53a16cf28db3 Author: xuelei Date: 2011-09-30 18:47 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/53a16cf28db3 7096936: issue in jsse/runtime 7096937: TEST: com/sun/net/ssl/internal/ssl/GenSSLConfigs/main.java need modification as a result of TLS fix Reviewed-by: wetmore, jdn, xuelei ! src/share/classes/com/sun/net/ssl/HttpsURLConnection.java ! src/share/classes/javax/net/ssl/HttpsURLConnection.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/GenSSLConfigs/main.java Changeset: 27a8f4fc555a Author: asaha Date: 2011-11-14 11:52 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/27a8f4fc555a Merge ! src/share/classes/java/awt/AWTKeyStroke.java ! src/share/classes/javax/net/ssl/HttpsURLConnection.java ! src/share/classes/sun/security/ssl/CipherBox.java ! src/share/classes/sun/security/ssl/CipherSuite.java ! src/share/classes/sun/security/ssl/SSLEngineImpl.java ! src/share/classes/sun/security/ssl/SSLSocketImpl.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/GenSSLConfigs/main.java ! test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/LargePacket.java ! test/sun/tools/jstatd/jstatdExternalRegistry.sh Changeset: 99632935785e Author: lana Date: 2011-11-14 18:18 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/99632935785e Merge Changeset: 00e2c88e2234 Author: katleman Date: 2011-11-17 10:46 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/00e2c88e2234 Added tag jdk8-b14 for changeset 99632935785e ! .hgtags Changeset: bdb2d63c176c Author: jcoomes Date: 2011-11-18 16:57 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/bdb2d63c176c Merge ! test/ProblemList.txt From john.coomes at oracle.com Sat Nov 19 00:51:28 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Sat, 19 Nov 2011 08:51:28 +0000 Subject: hg: hsx/hotspot-main/langtools: 27 new changesets Message-ID: <20111119085226.D7E27473F0@hg.openjdk.java.net> Changeset: b5d0b8effc85 Author: mcimadamore Date: 2011-10-17 12:54 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/b5d0b8effc85 7097436: Project Coin: duplicate varargs warnings on method annotated with @SafeVarargs Summary: Duplicate aliasing check during subtyping leads to spurious varargs diagnostic Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Types.java + test/tools/javac/varargs/7097436/T7097436.java + test/tools/javac/varargs/7097436/T7097436.out ! test/tools/javac/varargs/warning/Warn5.java Changeset: 3cdfa97e1be9 Author: mcimadamore Date: 2011-10-17 12:57 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/3cdfa97e1be9 7093325: Redundant entry in bytecode exception table Summary: Inlining of finalizers does not update gaps list accordingly Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/jvm/Code.java ! src/share/classes/com/sun/tools/javac/jvm/Gen.java + test/tools/javac/T7093325.java Changeset: 366c233eb838 Author: mcimadamore Date: 2011-10-19 16:56 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/366c233eb838 7102515: javac running very very long and not returning Summary: Verbose resolution diagnostics slow down with operator resolution Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Resolve.java + test/tools/javac/7102515/T7102515.java + test/tools/javac/7102515/T7102515.out Changeset: d2cbb77469ed Author: jjg Date: 2011-10-19 15:29 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/d2cbb77469ed 7101146: Paths should more directly managed by BaseFileManager Reviewed-by: mcimadamore ! 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/nio/JavacPathFileManager.java ! src/share/classes/com/sun/tools/javac/util/BaseFileManager.java Changeset: b4021c520e40 Author: jjh Date: 2011-10-21 14:14 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/b4021c520e40 7098530: tools/javac/javazip/Test.sh can fail on Windows Summary: Fix cygpath command to properly convert path Reviewed-by: jjg ! test/tools/javac/javazip/Test.sh Changeset: d346ab55031b Author: mcimadamore Date: 2011-10-24 13:00 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/d346ab55031b 7096014: Javac tokens should retain state Summary: Refactor javac tokens from enum constants to stateful instances (to keep track of position, comments, etc.) Reviewed-by: jjg ! src/share/classes/com/sun/tools/apt/main/AptJavaCompiler.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/JavaTokenizer.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java + src/share/classes/com/sun/tools/javac/parser/JavadocTokenizer.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/ParserFactory.java ! src/share/classes/com/sun/tools/javac/parser/Scanner.java ! src/share/classes/com/sun/tools/javac/parser/ScannerFactory.java - src/share/classes/com/sun/tools/javac/parser/Token.java + src/share/classes/com/sun/tools/javac/parser/Tokens.java + src/share/classes/com/sun/tools/javac/parser/UnicodeReader.java ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java ! src/share/classes/com/sun/tools/javadoc/JavadocTool.java ! test/tools/javac/api/TestJavacTaskScanner.java + test/tools/javac/depDocComment/DeprecatedDocComment3.java + test/tools/javac/tree/DocCommentToplevelTest.java Changeset: 05814303a056 Author: mcimadamore Date: 2011-10-24 13:00 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/05814303a056 7098660: Write better overload resolution/inference tests Summary: Add overload/inference debug diagnostics - added test harness using annotations to check outcome of overload resolution/inference Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Printer.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 + test/tools/javac/diags/examples/ApplicableMethodFound.java + test/tools/javac/diags/examples/ApplicableMethodFound1.java + test/tools/javac/diags/examples/DeferredMethodInst.java + test/tools/javac/diags/examples/FullInstSig.java + test/tools/javac/diags/examples/NotApplicableMethodFound.java + test/tools/javac/diags/examples/PartialInstSig.java + test/tools/javac/diags/examples/VerboseResolveMulti.java + test/tools/javac/diags/examples/VerboseResolveMulti1.java + test/tools/javac/resolve/Candidate.java + test/tools/javac/resolve/Pos.java + test/tools/javac/resolve/ResolveHarness.java + test/tools/javac/resolve/TraceResolve.java + test/tools/javac/resolve/tests/BoxedReturnTypeInference.java + test/tools/javac/resolve/tests/PrimitiveOverReferenceOverInferred.java + test/tools/javac/resolve/tests/PrimitiveOverReferenceOverVarargs.java + test/tools/javac/resolve/tests/PrimitiveOverReferenceVarargsAmbiguous.java + test/tools/javac/resolve/tests/PrimitiveOverload.java + test/tools/javac/resolve/tests/PrimitiveReturnTypeInference.java + test/tools/javac/resolve/tests/ReferenceOverInferred.java + test/tools/javac/resolve/tests/ReferenceOverVarargs.java + test/tools/javac/resolve/tests/ReferenceOverload.java Changeset: b73a9be0b993 Author: mcimadamore Date: 2011-10-25 15:40 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/b73a9be0b993 7104618: MessageInfo.java is failing after lexer changes Summary: Two langtools regression tests cannot be built due to a bad import statement Reviewed-by: jjg ! test/tools/javac/diags/ArgTypeCompilerFactory.java Changeset: d830d28fc72e Author: jjg Date: 2011-10-25 10:48 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/d830d28fc72e 7104039: refactor/cleanup javac Paths class Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/apt/main/Main.java ! src/share/classes/com/sun/tools/javac/file/JavacFileManager.java + src/share/classes/com/sun/tools/javac/file/Locations.java - src/share/classes/com/sun/tools/javac/file/Paths.java ! src/share/classes/com/sun/tools/javac/nio/JavacPathFileManager.java ! src/share/classes/com/sun/tools/javac/util/BaseFileManager.java ! src/share/classes/com/sun/tools/javadoc/DocletInvoker.java Changeset: a1eaf78ababb Author: jjh Date: 2011-10-25 19:18 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/a1eaf78ababb 7104905: Java SE build fails on call to CreateSymbols Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/file/Locations.java Changeset: 52df2131e294 Author: lana Date: 2011-10-25 21:55 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/52df2131e294 Merge - src/share/classes/com/sun/tools/javac/file/Paths.java - src/share/classes/com/sun/tools/javac/parser/DocCommentScanner.java - src/share/classes/com/sun/tools/javac/parser/Keywords.java - src/share/classes/com/sun/tools/javac/parser/Token.java Changeset: f2d6ed25857d Author: lana Date: 2011-10-28 17:49 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/f2d6ed25857d Merge - src/share/classes/com/sun/tools/javac/file/Paths.java - src/share/classes/com/sun/tools/javac/parser/DocCommentScanner.java - src/share/classes/com/sun/tools/javac/parser/Keywords.java - src/share/classes/com/sun/tools/javac/parser/Token.java Changeset: ae25163501bc Author: katleman Date: 2011-11-03 10:32 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/ae25163501bc Added tag jdk8-b12 for changeset f2d6ed25857d ! .hgtags Changeset: 65444e7998e3 Author: katleman Date: 2011-11-10 11:47 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/65444e7998e3 Added tag jdk8-b13 for changeset ae25163501bc ! .hgtags Changeset: e52159ff8d0c Author: lana Date: 2011-10-25 10:52 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/e52159ff8d0c Merge Changeset: 897b72b2751b Author: lana Date: 2011-10-26 12:28 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/897b72b2751b Merge - src/share/classes/com/sun/tools/javac/file/Paths.java Changeset: 9e2eb4bc49eb Author: jjh Date: 2011-11-01 15:49 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/9e2eb4bc49eb 7101933: langtools jtreg tests do not work with jprt on windows Summary: Fixed langtools/test/Makefile to work on cygwin. Updated jtreg to 4.1 and JCK to JCK8. Reviewed-by: jjg, ohair ! test/Makefile Changeset: 56830d5cb5bb Author: mcimadamore Date: 2011-11-04 12:36 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/56830d5cb5bb 7104201: Refactor DocCommentScanner Summary: Add new Comment helper class to parse contents of comments in source code Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/parser/JavaTokenizer.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/parser/JavadocTokenizer.java ! src/share/classes/com/sun/tools/javac/parser/Tokens.java ! src/share/classes/com/sun/tools/javac/parser/UnicodeReader.java + test/tools/javac/depDocComment/DeprecatedDocComment4.java + test/tools/javac/depDocComment/DeprecatedDocComment4.out Changeset: 11c184155128 Author: lana Date: 2011-11-05 00:02 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/11c184155128 Merge Changeset: ca49d50318dc Author: jjg Date: 2011-11-08 11:51 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/ca49d50318dc 6921494: provide way to print javac tree tag values Reviewed-by: jjg, mcimadamore Contributed-by: vicenterz at yahoo.es ! src/share/classes/com/sun/tools/javac/api/JavacTaskImpl.java ! src/share/classes/com/sun/tools/javac/api/JavacTrees.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/Check.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/jvm/CRTable.java ! src/share/classes/com/sun/tools/javac/jvm/Gen.java ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/share/classes/com/sun/tools/javac/model/JavacElements.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.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/javadoc/ClassDocImpl.java ! src/share/classes/com/sun/tools/javadoc/JavadocTool.java ! test/tools/javac/failover/CheckAttributedTree.java ! test/tools/javac/tree/AbstractTreeScannerTest.java ! test/tools/javac/tree/TreePosTest.java Changeset: b7003a6a530b Author: lana Date: 2011-11-14 18:16 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/b7003a6a530b Merge Changeset: 15ea1c763273 Author: asaha Date: 2011-06-27 12:29 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/15ea1c763273 Merge - src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/inherit.gif Changeset: c79cf0f04be6 Author: asaha Date: 2011-06-28 08:39 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/c79cf0f04be6 Merge Changeset: 34e175c1fabc Author: asaha Date: 2011-07-19 11:05 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/34e175c1fabc Merge Changeset: c4478931e22d Author: asaha Date: 2011-11-07 21:52 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/c4478931e22d Merge Changeset: 58f1325d72b2 Author: lana Date: 2011-11-14 18:18 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/58f1325d72b2 Merge Changeset: 16906df5bffc Author: katleman Date: 2011-11-17 10:46 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/16906df5bffc Added tag jdk8-b14 for changeset 58f1325d72b2 ! .hgtags From sebastian.sickelmann at gmx.de Sat Nov 19 04:10:03 2011 From: sebastian.sickelmann at gmx.de (Sebastian Sickelmann) Date: Sat, 19 Nov 2011 13:10:03 +0100 Subject: Reason for non-const of instanceKlass::method_with_idnum(int idnum) In-Reply-To: References: <4EC4E144.9030004@gmx.de> Message-ID: <4EC79C9B.8030705@gmx.de> Am 18.11.2011 20:24, schrieb Tom Rodriguez: > On Nov 17, 2011, at 2:26 AM, Sebastian Sickelmann wrote: > >> Hello, >> >> is there a reason why the method instanceKlass::method_with_idnum(int idnum) does not have a const qualifier? > We're not particularly religious about the use of const so no one probably bothered. > > tom Thanks for the reply. Ok, than i can change this for my prototype, if i have to change it, without bringing to much hurt to integration-time. >> The methods >> - instanceKlass::methods() >> - methodOop::idnum() >> - objectArrayOop::obj_at(int) >> >> that are used inside of method_with_idnum are all const and i don't see a change to manipulate the internal state of instanceKlass unintantional through making method_with_idnum constant. >> >> Kind regards >> Sebastian From john.coomes at oracle.com Sat Nov 19 05:43:13 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Sat, 19 Nov 2011 13:43:13 +0000 Subject: hg: hsx/hotspot-main/hotspot: 5 new changesets Message-ID: <20111119134330.7531A473F2@hg.openjdk.java.net> Changeset: 088d09a130ff Author: katleman Date: 2011-11-10 11:46 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/088d09a130ff Added tag jdk8-b13 for changeset b92ca8e229d2 ! .hgtags Changeset: 883328bfc472 Author: katleman Date: 2011-11-17 10:45 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/883328bfc472 Added tag jdk8-b14 for changeset 088d09a130ff ! .hgtags Changeset: 6c2a55d4902f Author: jcoomes Date: 2011-11-18 15:15 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/6c2a55d4902f Merge Changeset: fde2a39ed7f3 Author: jcoomes Date: 2011-11-18 15:15 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/fde2a39ed7f3 Added tag hs23-b06 for changeset 6c2a55d4902f ! .hgtags Changeset: da4182086289 Author: jcoomes Date: 2011-11-18 17:39 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/da4182086289 7113503: Bump the hs23 build number to 07 Reviewed-by: johnc Contributed-by: alejandro.murillo at oracle.com ! make/hotspot_version From rednaxelafx at gmail.com Sun Nov 20 17:54:17 2011 From: rednaxelafx at gmail.com (Krystal Mok) Date: Mon, 21 Nov 2011 09:54:17 +0800 Subject: HotSpot development trees In-Reply-To: <4EAAEAC4.8000001@oracle.com> References: <20111026224959.GK594@rivendell.redhat.com> <4EA8C35F.3010208@oracle.com> <4EA976E3.3000704@oracle.com> <4EA9F94F.3030707@netdemons.com> <4EAA1AEA.2060505@oracle.com> <4EAAEAC4.8000001@oracle.com> Message-ID: Hi all, The HotSpot VM 20.0-b12 in OpenJDK 6 build 24 released last week covers what I was concerned about, mainly the back port of bug fixes to loop optimizations. Thanks for the effort! - Kris -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20111121/e872cb5f/attachment.html From rednaxelafx at gmail.com Sun Nov 20 20:53:49 2011 From: rednaxelafx at gmail.com (Krystal Mok) Date: Mon, 21 Nov 2011 12:53:49 +0800 Subject: Native wrapper optimization In-Reply-To: <4EC63DD8.609@taobao.com> References: <4EC5FD8A.5060104@taobao.com> <31E62419-9788-4714-9E12-3A5B43023C30@oracle.com> <4EC63DD8.609@taobao.com> Message-ID: Hi all, (Just in case my company email strips attachment again, I'm replying with my personal email) I've got the patch ported to 32-bit x86. See attachment. Additional comments about the patch: Joseph's original patch moves the IC miss jump out-of-line, but on x64 with compressed oops, that doesn't really save space in the unverified entry point code sequence, due to the 8-byte alignment. Examples in [1]. The version in this mail's attachment uses jump_cc() inline instead of jcc() and a out-of-line jump(). The UEP code generated by both C1 and C2 uses the same pattern. There's a similar pattern in generate_i2c2i_adapters() that could have used jump_cc() to call the ic_miss_stub. But the gains doesn't look significant enough so I didn't modify it. Another note: In x64's version of SharedRuntime::generate_dtrace_nmethod(), the IC check isn't using load_klass(). __ verify_oop(receiver); __ cmpl(ic_reg, Address(receiver, oopDesc::klass_offset_in_bytes())); __ jcc(Assembler::equal, hit); Is this correct, or should it be modified to use load_klass(), too? My take is the latter. load_klass() was introduced in [2], and later, generate_dtrace_nmethod() was introduced in [3]. I think [3] missed the compressed oops changes. Regards, Kris Mok Software Engineer, Taobao (http://www.taobao.com) [1]: https://gist.github.com/1380416#file_notes.md [2]: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/file/ba764ed4b6f2/src/cpu/x86/vm/sharedRuntime_x86_64.cpp [3]: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/file/018d5b58dd4f/src/cpu/x86/vm/sharedRuntime_x86_64.cpp 2011/11/18 changren > Ok, Kris will help to port to 32bit. > Thanks, > Joseph > > ?? 2011-11-18 17:09, Christian Thalinger ????: > > Looks like a good patch to me. What about 32-bit x86? > > > > -- Chris > > > > On Nov 18, 2011, at 7:39 AM, changren wrote: > > > >> Hi, all > >> Attached patch(diff with hsx20) is supposed to speed up native > >> invocation. It rearranges the compiled-to-native wrapper code to > >> straighten branches which improves spatial locality. Micro > >> benchmark(500m consecutive JNI invocations with warm up) shows the > >> stalled CPU cycles caused by instruction fetch due to L1 ICache miss > >> decrease 3.4% on Intel Nehalem microarchitecture and 9.6% on Core > >> microarchitecture. The real execution time of the micro benchmark is > >> also decreased 5-10% respectively which reflects the improvement. > >> Thanks, > >> Joseph > >> > >> > >> ________________________________ > >> > >> This email (including any attachments) is confidential and may be > legally privileged. If you received this email in error, please delete it > immediately and do not copy it or use it for any purpose or disclose its > contents to any other person. Thank you. > >> > >> > ??????(????????????)???????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? > >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20111121/68f7eb42/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: JNI_wrapper_ver2.patch Type: application/octet-stream Size: 7936 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20111121/68f7eb42/JNI_wrapper_ver2.patch From changren at taobao.com Sun Nov 20 21:22:29 2011 From: changren at taobao.com (changren) Date: Mon, 21 Nov 2011 13:22:29 +0800 Subject: Native wrapper optimization In-Reply-To: References: <4EC5FD8A.5060104@taobao.com> <31E62419-9788-4714-9E12-3A5B43023C30@oracle.com> <4EC63DD8.609@taobao.com> Message-ID: <4EC9E015.1030806@taobao.com> Either is ok. Thanks, Joseph ________________________________ This email (including any attachments) is confidential and may be legally privileged. If you received this email in error, please delete it immediately and do not copy it or use it for any purpose or disclose its contents to any other person. Thank you. ??????(????????????)???????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? From christian.thalinger at oracle.com Mon Nov 21 01:41:21 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 21 Nov 2011 10:41:21 +0100 Subject: Native wrapper optimization In-Reply-To: References: <4EC5FD8A.5060104@taobao.com> <31E62419-9788-4714-9E12-3A5B43023C30@oracle.com> <4EC63DD8.609@taobao.com> Message-ID: On Nov 21, 2011, at 5:53 AM, Krystal Mok wrote: > Hi all, > > (Just in case my company email strips attachment again, I'm replying with my personal email) > > I've got the patch ported to 32-bit x86. See attachment. > > Additional comments about the patch: > Joseph's original patch moves the IC miss jump out-of-line, but on x64 with compressed oops, that doesn't really save space in the unverified entry point code sequence, due to the 8-byte alignment. Examples in [1]. > > The version in this mail's attachment uses jump_cc() inline instead of jcc() and a out-of-line jump(). The UEP code generated by both C1 and C2 uses the same pattern. > > There's a similar pattern in generate_i2c2i_adapters() that could have used jump_cc() to call the ic_miss_stub. But the gains doesn't look significant enough so I didn't modify it. Are there any performance regressions with this patch on older x86 architectures? > > > Another note: > In x64's version of SharedRuntime::generate_dtrace_nmethod(), the IC check isn't using load_klass(). > > __ verify_oop(receiver); > __ cmpl(ic_reg, Address(receiver, oopDesc::klass_offset_in_bytes())); > __ jcc(Assembler::equal, hit); > > Is this correct, or should it be modified to use load_klass(), too? My take is the latter. It seems the 32-bit version was copied verbatim to the 64-bit one and looks like a bug to me. -- Chris > > load_klass() was introduced in [2], and later, generate_dtrace_nmethod() was introduced in [3]. I think [3] missed the compressed oops changes. > > Regards, > Kris Mok > Software Engineer, Taobao (http://www.taobao.com) > > [1]: https://gist.github.com/1380416#file_notes.md > [2]: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/file/ba764ed4b6f2/src/cpu/x86/vm/sharedRuntime_x86_64.cpp > [3]: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/file/018d5b58dd4f/src/cpu/x86/vm/sharedRuntime_x86_64.cpp > > 2011/11/18 changren > Ok, Kris will help to port to 32bit. > Thanks, > Joseph > > ?? 2011-11-18 17:09, Christian Thalinger ????: > > Looks like a good patch to me. What about 32-bit x86? > > > > -- Chris > > > > On Nov 18, 2011, at 7:39 AM, changren wrote: > > > >> Hi, all > >> Attached patch(diff with hsx20) is supposed to speed up native > >> invocation. It rearranges the compiled-to-native wrapper code to > >> straighten branches which improves spatial locality. Micro > >> benchmark(500m consecutive JNI invocations with warm up) shows the > >> stalled CPU cycles caused by instruction fetch due to L1 ICache miss > >> decrease 3.4% on Intel Nehalem microarchitecture and 9.6% on Core > >> microarchitecture. The real execution time of the micro benchmark is > >> also decreased 5-10% respectively which reflects the improvement. > >> Thanks, > >> Joseph > >> > >> > >> ________________________________ > >> > >> This email (including any attachments) is confidential and may be legally privileged. If you received this email in error, please delete it immediately and do not copy it or use it for any purpose or disclose its contents to any other person. Thank you. > >> > >> ??????(????????????)???????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? > >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20111121/480d75d8/attachment-0001.html From changren at taobao.com Mon Nov 21 02:26:54 2011 From: changren at taobao.com (changren) Date: Mon, 21 Nov 2011 18:26:54 +0800 Subject: Native wrapper optimization In-Reply-To: References: <4EC5FD8A.5060104@taobao.com> <31E62419-9788-4714-9E12-3A5B43023C30@oracle.com> <4EC63DD8.609@taobao.com> Message-ID: <4ECA276E.3070604@taobao.com> Hi Chris, Are there any performance regressions with this patch on older x86 architectures? Sorry, we don't have older architecture machines to do regression. It seems the 32-bit version was copied verbatim to the 64-bit one and looks like a bug to me. to me too. Regards, Joseph ?? 2011-11-21 17:41, Christian Thalinger ????: On Nov 21, 2011, at 5:53 AM, Krystal Mok wrote: Hi all, (Just in case my company email strips attachment again, I'm replying with my personal email) I've got the patch ported to 32-bit x86. See attachment. Additional comments about the patch: Joseph's original patch moves the IC miss jump out-of-line, but on x64 with compressed oops, that doesn't really save space in the unverified entry point code sequence, due to the 8-byte alignment. Examples in [1]. The version in this mail's attachment uses jump_cc() inline instead of jcc() and a out-of-line jump(). The UEP code generated by both C1 and C2 uses the same pattern. There's a similar pattern in generate_i2c2i_adapters() that could have used jump_cc() to call the ic_miss_stub. But the gains doesn't look significant enough so I didn't modify it. Are there any performance regressions with this patch on older x86 architectures? Another note: In x64's version of SharedRuntime::generate_dtrace_nmethod(), the IC check isn't using load_klass(). __ verify_oop(receiver); __ cmpl(ic_reg, Address(receiver, oopDesc::klass_offset_in_bytes())); __ jcc(Assembler::equal, hit); Is this correct, or should it be modified to use load_klass(), too? My take is the latter. It seems the 32-bit version was copied verbatim to the 64-bit one and looks like a bug to me. -- Chris load_klass() was introduced in [2], and later, generate_dtrace_nmethod() was introduced in [3]. I think [3] missed the compressed oops changes. Regards, Kris Mok Software Engineer, Taobao (http://www.taobao.com) [1]: https://gist.github.com/1380416#file_notes.md [2]: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/file/ba764ed4b6f2/src/cpu/x86/vm/sharedRuntime_x86_64.cpp [3]: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/file/018d5b58dd4f/src/cpu/x86/vm/sharedRuntime_x86_64.cpp 2011/11/18 changren > Ok, Kris will help to port to 32bit. Thanks, Joseph ?? 2011-11-18 17:09, Christian Thalinger ????: > Looks like a good patch to me. What about 32-bit x86? > > -- Chris > > On Nov 18, 2011, at 7:39 AM, changren wrote: > >> Hi, all >> Attached patch(diff with hsx20) is supposed to speed up native >> invocation. It rearranges the compiled-to-native wrapper code to >> straighten branches which improves spatial locality. Micro >> benchmark(500m consecutive JNI invocations with warm up) shows the >> stalled CPU cycles caused by instruction fetch due to L1 ICache miss >> decrease 3.4% on Intel Nehalem microarchitecture and 9.6% on Core >> microarchitecture. The real execution time of the micro benchmark is >> also decreased 5-10% respectively which reflects the improvement. >> Thanks, >> Joseph >> >> >> ________________________________ >> >> This email (including any attachments) is confidential and may be legally privileged. If you received this email in error, please delete it immediately and do not copy it or use it for any purpose or disclose its contents to any other person. Thank you. >> >> ??????(????????????)?????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? ?????????????????? >> ________________________________ This email (including any attachments) is confidential and may be legally privileged. If you received this email in error, please delete it immediately and do not copy it or use it for any purpose or disclose its contents to any other person. Thank you. ??????(????????????)???????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20111121/ffc9c042/attachment.html From coleen.phillimore at oracle.com Mon Nov 21 14:56:42 2011 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Mon, 21 Nov 2011 22:56:42 +0000 Subject: hg: hsx/hotspot-main/hotspot: 4 new changesets Message-ID: <20111121225655.7E26D47415@hg.openjdk.java.net> Changeset: 36b057451829 Author: dholmes Date: 2011-11-16 20:38 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/36b057451829 7110017: is_headless_jre should be updated to reflect the new location of awt toolkit libraries Reviewed-by: dholmes, dsamersoff Contributed-by: Chris Hegarty ! src/os/bsd/vm/os_bsd.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/os_solaris.cpp Changeset: 002cb3fc8256 Author: coleenp Date: 2011-11-18 17:26 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/002cb3fc8256 Merge Changeset: c17bc65648de Author: brutisso Date: 2011-11-21 08:02 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/c17bc65648de 7112308: Fix Visual Studio build for precompiled header Summary: Add the new path to precompiled.hpp in the project make file Reviewed-by: coleenp, dholmes, brutisso Contributed-by: rbackman ! make/windows/makefiles/projectcreator.make Changeset: 1d090cf33da6 Author: coleenp Date: 2011-11-21 10:22 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/1d090cf33da6 Merge From aoqi at loongson.cn Mon Nov 21 18:39:52 2011 From: aoqi at loongson.cn (Ao Qi) Date: Tue, 22 Nov 2011 10:39:52 +0800 Subject: Can c1 be built for 64-bit? Message-ID: Hi, all I try to build a 64-bit c1, however, in hotspot/make/Makefile, I found: ifeq ($(ARCH_DATA_MODEL), 32) $(CD) $(OUTPUTDIR); \ $(MAKE) -f $(ABS_OS_MAKEFILE) \ $(MAKE_ARGS) $(VM_TARGET) else @$(ECHO) "No compiler1 ($(VM_TARGET)) for ARCH_DATA_MODEL=$(ARCH_DATA_MODEL)" endif So I wonder why compiler1 can not be built for a 64-bit version? Thanks, Ao Qi From tom.rodriguez at oracle.com Tue Nov 22 09:08:37 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 22 Nov 2011 09:08:37 -0800 Subject: Can c1 be built for 64-bit? In-Reply-To: References: Message-ID: That's not a supported or tested configuration. C1 does work in 64 bit mode but it's only used as part of the tiered system. tom On Nov 21, 2011, at 6:39 PM, Ao Qi wrote: > Hi, all > I try to build a 64-bit c1, however, in hotspot/make/Makefile, I found: > > ifeq ($(ARCH_DATA_MODEL), 32) > $(CD) $(OUTPUTDIR); \ > $(MAKE) -f $(ABS_OS_MAKEFILE) \ > $(MAKE_ARGS) $(VM_TARGET) > else > @$(ECHO) "No compiler1 ($(VM_TARGET)) for ARCH_DATA_MODEL=$(ARCH_DATA_MODEL)" > endif > > So I wonder why compiler1 can not be built for a 64-bit version? > > Thanks, > Ao Qi From spoole at linux.vnet.ibm.com Wed Nov 23 06:29:49 2011 From: spoole at linux.vnet.ibm.com (Steve Poole) Date: Wed, 23 Nov 2011 14:29:49 +0000 Subject: Improving the documention of the JVM implementation interface Message-ID: <1322058589.13674.7.camel@jazzette> Hi all, I've been talking to Mikael Vidstedt and a few other Oracle luminaries about improving the documentation of the interface between the JVM and the rest of the SDK. We wanted to make that discussion public hence this post. I'll start and Mikael can jump in. What I'm trying to do is simply gain some agreement on what code is JVM implementation specific and what isn't. Then, where this JVM implementation specific code interacts with the SDK, improve the documentation. A few examples to consider... JVM_* entry points in the VM that are there for the class library code to call: these are not part of the public JNI spec - I'd like to get them documented in more detail. These extra entry points can blur the line between the JVM and the class libraries: sometimes making it's difficult to work out if the "real" API is the C entry point or the calling Java class. To put it another way - there is Java code that is intentionally JVM implementation specific. I'd like to get that status documented. Another similar example is where Hotspot code leaks out of the JVM into the class libs and tools. The Late Attach API is a good (or is that bad) example. Sometimes it's difficult to work out if that leakage is intentional or inadvertent. I'd like to get that status documented too. So to recap: what I'd like to do is discover and document the API between the JVM implementation specific code and everything else. Hopefully in the process improving everyone's awareness and getting some common agreement over actual behaviour or design versus intention. This work might discover areas that could benefit from improved interface design and some form of refactoring but that would be for later. Thanks Steve From nils.loodin at oracle.com Wed Nov 23 06:47:44 2011 From: nils.loodin at oracle.com (Nils Loodin) Date: Wed, 23 Nov 2011 15:47:44 +0100 Subject: Request for review: 7069991: Setup make/jprt.properties files for jdk8 Message-ID: <4ECD0790.2010400@oracle.com> The make/jprt.properties files need to be adjusted for use with jprt for jdk8. http://cr.openjdk.java.net/~nloodin/7069991/webrev.00/webrev/ Thanks! /Nils Loodin From keith.mcguigan at oracle.com Wed Nov 23 07:02:54 2011 From: keith.mcguigan at oracle.com (Keith McGuigan) Date: Wed, 23 Nov 2011 10:02:54 -0500 Subject: Request for review: 7069991: Setup make/jprt.properties files for jdk8 In-Reply-To: <4ECD0790.2010400@oracle.com> References: <4ECD0790.2010400@oracle.com> Message-ID: <5AA34F68-75B8-4F10-B740-43F0E3458881@oracle.com> Looks good. When we get another reviewer, I'll shepherd this through for you. -- - Keith On Nov 23, 2011, at 9:47 AM, Nils Loodin wrote: > The make/jprt.properties files need to be adjusted for use with jprt > for jdk8. > http://cr.openjdk.java.net/~nloodin/7069991/webrev.00/webrev/ > > Thanks! > /Nils Loodin > > From kelly.ohair at oracle.com Wed Nov 23 07:17:44 2011 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Wed, 23 Nov 2011 07:17:44 -0800 Subject: Request for review: 7069991: Setup make/jprt.properties files for jdk8 In-Reply-To: <4ECD0790.2010400@oracle.com> References: <4ECD0790.2010400@oracle.com> Message-ID: <6C63AF8C-AB29-4988-9671-AADB2BDF3292@oracle.com> FYI... This locks down the repository to only use jdk8, regardless of what the jprt submit -release NNN option says. If this change only went into jdk8 I think it would be fine, but don't these same hotspot sources get integrated into jdk7? Will someone change this to jdk7 when that happens? Hotspot like Sybil (http://en.wikipedia.org/wiki/Sybil_%28book%29) has many personalities, and that explains why this file is so crazy. %-) I think the idea was that when submitting a hotspot job, you would always use 'jprt submit -release jdkN ...' to tell JPRT and this properties file what the build was for. JPRT does have a default release of jdk7, which I could change to jdk8, but the jdk7 repositories currently rely on that being the default, an unfortunate situation. :^( This release name is JPRT's only way of knowing what build/test dependencies are required for the build. -kto On Nov 23, 2011, at 6:47 AM, Nils Loodin wrote: > The make/jprt.properties files need to be adjusted for use with jprt for jdk8. > http://cr.openjdk.java.net/~nloodin/7069991/webrev.00/webrev/ > > Thanks! > /Nils Loodin > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20111123/fdf2e0c1/attachment.html From keith.mcguigan at oracle.com Wed Nov 23 07:39:16 2011 From: keith.mcguigan at oracle.com (Keith McGuigan) Date: Wed, 23 Nov 2011 10:39:16 -0500 Subject: Request for review: 7069991: Setup make/jprt.properties files for jdk8 In-Reply-To: <6C63AF8C-AB29-4988-9671-AADB2BDF3292@oracle.com> References: <4ECD0790.2010400@oracle.com> <6C63AF8C-AB29-4988-9671-AADB2BDF3292@oracle.com> Message-ID: On Nov 23, 2011, at 10:17 AM, Kelly O'Hair wrote: > FYI... This locks down the repository to only use jdk8, regardless > of what the jprt submit -release NNN option says. > > If this change only went into jdk8 I think it would be fine, but > don't these same hotspot sources get > integrated into jdk7? Will someone change this to jdk7 when that > happens? We can tailor the hsxNN repositories to use jdk7 if that's their expected release vehicle. hsx really ought to be jdk8, though. I didn't realize that this setting overrides the -release value passed on the submit line... How would we go about setting a default that is overrideable? -- - Keith From kelly.ohair at oracle.com Wed Nov 23 07:55:11 2011 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Wed, 23 Nov 2011 07:55:11 -0800 Subject: Request for review: 7069991: Setup make/jprt.properties files for jdk8 In-Reply-To: References: <4ECD0790.2010400@oracle.com> <6C63AF8C-AB29-4988-9671-AADB2BDF3292@oracle.com> Message-ID: <8F65A602-237D-4049-82BE-0C0FCD601D34@oracle.com> On Nov 23, 2011, at 7:39 AM, Keith McGuigan wrote: > > On Nov 23, 2011, at 10:17 AM, Kelly O'Hair wrote: > >> FYI... This locks down the repository to only use jdk8, regardless of what the jprt submit -release NNN option says. >> >> If this change only went into jdk8 I think it would be fine, but don't these same hotspot sources get >> integrated into jdk7? Will someone change this to jdk7 when that happens? > > We can tailor the hsxNN repositories to use jdk7 if that's their expected release vehicle. hsx really ought to be jdk8, though. I didn't realize that this setting overrides the -release value passed on the submit line... How would we go about setting a default that is overrideable? The JPRT default release is jdk7 right now, it is overridable at submit time by using the -release option. At submit time, JPRT sets jprt.submit.release to whatever the -release setting becomes. The repository sets it's own specific release value with the jprt.tools.default.release property. I'm having a hard time envisioning what you would want, making my head hurt. Give me some suggestions or scenarios how you might want this to work... -kto > > -- > - Keith > From keith.mcguigan at oracle.com Wed Nov 23 08:13:16 2011 From: keith.mcguigan at oracle.com (Keith McGuigan) Date: Wed, 23 Nov 2011 11:13:16 -0500 Subject: Request for review: 7069991: Setup make/jprt.properties files for jdk8 In-Reply-To: <8F65A602-237D-4049-82BE-0C0FCD601D34@oracle.com> References: <4ECD0790.2010400@oracle.com> <6C63AF8C-AB29-4988-9671-AADB2BDF3292@oracle.com> <8F65A602-237D-4049-82BE-0C0FCD601D34@oracle.com> Message-ID: On Nov 23, 2011, at 10:55 AM, Kelly O'Hair wrote: > The JPRT default release is jdk7 right now, it is overridable at > submit time by using the -release option. > At submit time, JPRT sets jprt.submit.release to whatever the - > release setting becomes. > > The repository sets it's own specific release value with the > jprt.tools.default.release property. > I'm having a hard time envisioning what you would want, making my > head hurt. > Give me some suggestions or scenarios how you might want this to > work... What *I* want, if it is feasible, is to not to ever have to specify a - release value at all, and let the data in the repository config determine the release to use. However, if for some reason we wanted to override the repo default, we could specify -release when submitting a job. When cutting a branch that would go to a jdk7u release or something like that, the config files would have to be adjusted at that time. (which is what I thought this code was doing). This may not work when a single repo is used for multiple releases, such as jdk7 AND jdk8, but I don't think we have a good solution for that in any case (other than specifying -release every time). -- - Keith From kelly.ohair at oracle.com Wed Nov 23 09:20:27 2011 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Wed, 23 Nov 2011 09:20:27 -0800 Subject: Request for review: 7069991: Setup make/jprt.properties files for jdk8 In-Reply-To: References: <4ECD0790.2010400@oracle.com> <6C63AF8C-AB29-4988-9671-AADB2BDF3292@oracle.com> <8F65A602-237D-4049-82BE-0C0FCD601D34@oracle.com> Message-ID: <2E9143BF-5E24-4FFE-A2D0-9418160F21FD@oracle.com> On Nov 23, 2011, at 8:13 AM, Keith McGuigan wrote: > > On Nov 23, 2011, at 10:55 AM, Kelly O'Hair wrote: >> The JPRT default release is jdk7 right now, it is overridable at submit time by using the -release option. >> At submit time, JPRT sets jprt.submit.release to whatever the -release setting becomes. >> >> The repository sets it's own specific release value with the jprt.tools.default.release property. >> I'm having a hard time envisioning what you would want, making my head hurt. >> Give me some suggestions or scenarios how you might want this to work... > > What *I* want, if it is feasible, is to not to ever have to specify a -release value at all, and let the data in the repository config determine the release to use. However, if for some reason we wanted to override the repo default, we could specify -release when submitting a job. When cutting a branch that would go to a jdk7u release or something like that, the config files would have to be adjusted at that time. (which is what I thought this code was doing). > > This may not work when a single repo is used for multiple releases, such as jdk7 AND jdk8, but I don't think we have a good solution for that in any case (other than specifying -release every time). But when this convoluted hotspot/make/jprt.properties file was created, that was the understanding, that every submit would require a -release option, if you wanted a specific release built. Otherwise, you were at the mercy of what JPRT thought the default release should be, something I wish I never defined in JPRT. :^( So let me see if I can understand the flow here now... * jprt submit starts up * reads the internal properties of JPRT to see what it thinks the default should be * reads the options supplied to find any explicit release asked for (explicit release does override all settings) * sets jprt.submit.release to the release it thinks it is at this point * THEN it reads the hotspot/make/jprt.properties file, which should inspect jprt.submit.release to set the right target lists * If no explicit release was set, it checks for jprt.tools.default.release So the value of jprt.submit.release is either the explicit release specified by the user, or the default JPRT release but you cannot tell the difference.... I think what I should do is only set jprt.submit.release to the explicit release from the command line, and leave it empty when there was none. Then you could do something like: jprt.my.default.release=jdk8 jprt.my.release.=${jprt.my.default.release} jprt.my.release.jdk8=jdk8 jprt.my.release.jdk7=jdk7 jprt.my.release.jdk6=jdk6 jprt.my.release.jdk6perf=jdk6perf jprt.my.release.ejdk6=ejdk6 jprt.tools.default.release=${jprt.my.release.${jprt.submit.release}} Then you would be independent of what JPRT thinks the default should be. (I would delete all references to jdk7b107, jdk7temp, jdk6u10, jdk6u14, jdk6u18, jdk6u20, ejdk7 I don't think you need them, and JPRT doesn't accept many of them anymore.) How does that sound? -kto > > -- > - Keith From keith.mcguigan at oracle.com Wed Nov 23 10:00:27 2011 From: keith.mcguigan at oracle.com (Keith McGuigan) Date: Wed, 23 Nov 2011 13:00:27 -0500 Subject: Request for review: 7069991: Setup make/jprt.properties files for jdk8 In-Reply-To: <2E9143BF-5E24-4FFE-A2D0-9418160F21FD@oracle.com> References: <4ECD0790.2010400@oracle.com> <6C63AF8C-AB29-4988-9671-AADB2BDF3292@oracle.com> <8F65A602-237D-4049-82BE-0C0FCD601D34@oracle.com> <2E9143BF-5E24-4FFE-A2D0-9418160F21FD@oracle.com> Message-ID: <56BD2CFF-71C1-488F-B9C3-5E7D1DA24461@oracle.com> On Nov 23, 2011, at 12:20 PM, Kelly O'Hair wrote: > > So let me see if I can understand the flow here now... > > * jprt submit starts up > * reads the internal properties of JPRT to see what it thinks the > default should be > * reads the options supplied to find any explicit release asked for > (explicit release does override all settings) > * sets jprt.submit.release to the release it thinks it is at this > point > * THEN it reads the hotspot/make/jprt.properties file, which should > inspect jprt.submit.release to set the right target lists > * If no explicit release was set, it checks for > jprt.tools.default.release > > So the value of jprt.submit.release is either the explicit release > specified by the user, or the default JPRT release > but you cannot tell the difference.... I think what I should do is > only set jprt.submit.release to the explicit release > from the command line, and leave it empty when there was none. How about this: (don't care about the actual names, just placeholders for the logic) jprt.default => JPRT system default jprt.repo.default => default release value read out of repo's jprt.properties file jprt.submit.value => value of -release on the submit command line. actual release = jprt.submit.value, if non-NULL, otherwise jprt.repo.default, if non-NULL, otherwise jprt.default ? -- - Keith From david.holmes at oracle.com Wed Nov 23 17:48:14 2011 From: david.holmes at oracle.com (David Holmes) Date: Thu, 24 Nov 2011 11:48:14 +1000 Subject: Request for review: 7069991: Setup make/jprt.properties files for jdk8 In-Reply-To: <56BD2CFF-71C1-488F-B9C3-5E7D1DA24461@oracle.com> References: <4ECD0790.2010400@oracle.com> <6C63AF8C-AB29-4988-9671-AADB2BDF3292@oracle.com> <8F65A602-237D-4049-82BE-0C0FCD601D34@oracle.com> <2E9143BF-5E24-4FFE-A2D0-9418160F21FD@oracle.com> <56BD2CFF-71C1-488F-B9C3-5E7D1DA24461@oracle.com> Message-ID: <4ECDA25E.3080208@oracle.com> Kelly and I have had this discussion just recently because of problems with repos getting hard-wired release values (eg you couldn't submit a 6UX repo using -ejdk6 to build embedded because it had been hard-wired to jdk6!) Logically I want what Keith wants: -release on the submit overrides both the JPRT default and whatever is specified in the jprt.properties file (though I don't really see a need to hard-wire things in the properties file). With such a scheme I see the following: - JPRT defines the default release - this gets updated over time (should be 8 now) - this can be overridden by the submission or the repo - the hsx/hotspot-main/hotspot jprt.properties always accepts whatever release is passed to it from the JPRT system (either default or -release option) as today - the hsx/hsNN/hotspot jprt.properties can hardwire a specific release if they are only applicable to that release - else it remains as for hotspot-main and -release must be used on submission. My suggestion for today is that this change request be rejected, and that JPRT's default release be switched to 8. David ----- On 24/11/2011 4:00 AM, Keith McGuigan wrote: > > On Nov 23, 2011, at 12:20 PM, Kelly O'Hair wrote: >> >> So let me see if I can understand the flow here now... >> >> * jprt submit starts up >> * reads the internal properties of JPRT to see what it thinks the >> default should be >> * reads the options supplied to find any explicit release asked for >> (explicit release does override all settings) >> * sets jprt.submit.release to the release it thinks it is at this point >> * THEN it reads the hotspot/make/jprt.properties file, which should >> inspect jprt.submit.release to set the right target lists >> * If no explicit release was set, it checks for >> jprt.tools.default.release >> >> So the value of jprt.submit.release is either the explicit release >> specified by the user, or the default JPRT release >> but you cannot tell the difference.... I think what I should do is >> only set jprt.submit.release to the explicit release >> from the command line, and leave it empty when there was none. > > How about this: > > (don't care about the actual names, just placeholders for the logic) > > jprt.default => JPRT system default > jprt.repo.default => default release value read out of repo's > jprt.properties file > jprt.submit.value => value of -release on the submit command line. > > actual release = jprt.submit.value, if non-NULL, otherwise > jprt.repo.default, if non-NULL, otherwise jprt.default > > ? > > -- > - Keith > > > > > From rednaxelafx at gmail.com Wed Nov 23 19:26:57 2011 From: rednaxelafx at gmail.com (Krystal Mok) Date: Thu, 24 Nov 2011 11:26:57 +0800 Subject: Improving the documention of the JVM implementation interface In-Reply-To: <1322058589.13674.7.camel@jazzette> References: <1322058589.13674.7.camel@jazzette> Message-ID: Hi Steve, There's been some efforts in this area before. There's an OpenJDK project called "Common VM Interface" [1], ran by Dr Andrew John Hughes. One of the earlier notes can be found at [2]. The aims of this project seems to be in the same direction as what you're looking for. Xi Yang has been working on integrating OpenJDK class libraries into Jikes RVM this year. This work also needed a definition of the VM interface in OpenJDK. He's made quite a lot of progress already, so he might be able to help out with this documentation proposal. I'm cc'ing this mail to him. - Kris [1]: http://openjdk.java.net/projects/cvmi/ [2]: http://mail.openjdk.java.net/pipermail/cvmi-dev/2008-July/000006.html On Wed, Nov 23, 2011 at 10:29 PM, Steve Poole wrote: > Hi all, I've been talking to Mikael Vidstedt and a few other Oracle > luminaries about improving the documentation of the interface between > the JVM and the rest of the SDK. > > We wanted to make that discussion public hence this post. I'll start > and Mikael can jump in. > > What I'm trying to do is simply gain some agreement on what code is JVM > implementation specific and what isn't. Then, where this JVM > implementation specific code interacts with the SDK, improve the > documentation. > > A few examples to consider... > > JVM_* entry points in the VM that are there for the class library code > to call: these are not part of the public JNI spec - I'd like to get > them documented in more detail. > > These extra entry points can blur the line between the JVM and the class > libraries: sometimes making it's difficult to work out if the "real" > API is the C entry point or the calling Java class. To put it another > way - there is Java code that is intentionally JVM implementation > specific. I'd like to get that status documented. > > Another similar example is where Hotspot code leaks out of the JVM into > the class libs and tools. The Late Attach API is a good (or is that > bad) example. Sometimes it's difficult to work out if that leakage is > intentional or inadvertent. I'd like to get that status documented too. > > So to recap: what I'd like to do is discover and document the API > between the JVM implementation specific code and everything else. > Hopefully in the process improving everyone's awareness and getting some > common agreement over actual behaviour or design versus intention. This > work might discover areas that could benefit from improved interface > design and some form of refactoring but that would be for later. > > > Thanks > > Steve > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20111124/669d68cb/attachment.html From manojo10386 at gmail.com Thu Nov 24 08:57:19 2011 From: manojo10386 at gmail.com (Manohar Jonnalagedda) Date: Thu, 24 Nov 2011 17:57:19 +0100 Subject: proper usage of -XX:+PrintIdeal In-Reply-To: References: Message-ID: Hello all, I am new to using the debug features of hotspot (probably posting to the wrong list, as I haven't seen any list targetted to hotspot users), and was interested in checking out the graph of a program that I wrote. The program contains a method 'methodA' which I would like to inspect in terms of optimizations performed. I verified using the PrintCompilation (and PrintAssembly) flag that it was indeed JIT compiled. When I use the PrintIdeal flags, however, my output xml files do not contain any mention of this method. Here is the command I use : $JAVA_HOME/bin/java -verbose:gc -server -d64 -XX:+UseCompressedOops -XX:+DoEscapeAnalysis -XX:PrintIdealGraphLevel=1 -XX:PrintIdealGraphFile="file.xml" -XX:+PrintIdeal $JAVA_OPTS "$@" Would the problem be due to not using the flags properly? Thanks a lot for your help, Manohar -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20111124/d05bf364/attachment.html From rednaxelafx at gmail.com Thu Nov 24 23:23:41 2011 From: rednaxelafx at gmail.com (Krystal Mok) Date: Fri, 25 Nov 2011 15:23:41 +0800 Subject: proper usage of -XX:+PrintIdeal In-Reply-To: References: Message-ID: Hi Manohar, You should probably post this to hotspot-compiler-dev, because these debugging features were meant to be used by compiler developers. What version of HotSpot are you using? And, I assume you are using a fastdebug build, right? Otherwise the PrintIdeal* arguments won't even be accepted at VM start. Your command line arguments looks okay to me. I tried it on a fastdebug build of HotSpot 20.0-b11 and it worked fine. Is it that the file.xml is empty, or is it the particular method that you're after doesn't exist in "file.xml"? For the latter case, did you see a "file1.xml" in the same directory? Does it contain the method you're after? - Kris On Fri, Nov 25, 2011 at 12:57 AM, Manohar Jonnalagedda < manojo10386 at gmail.com> wrote: > Hello all, > > I am new to using the debug features of hotspot (probably posting to the > wrong list, as I haven't seen any list targetted to hotspot users), and was > interested in checking out the graph of a program that I wrote. The program > contains a method 'methodA' which I would like to inspect in terms of > optimizations performed. I verified using the PrintCompilation (and > PrintAssembly) flag that it was indeed JIT compiled. > > When I use the PrintIdeal flags, however, my output xml files do not > contain any mention of this method. Here is the command I use : > > $JAVA_HOME/bin/java -verbose:gc -server -d64 -XX:+UseCompressedOops > -XX:+DoEscapeAnalysis -XX:PrintIdealGraphLevel=1 > -XX:PrintIdealGraphFile="file.xml" -XX:+PrintIdeal $JAVA_OPTS "$@" > > Would the problem be due to not using the flags properly? > > Thanks a lot for your help, > Manohar > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20111125/231e0587/attachment.html From manojo10386 at gmail.com Fri Nov 25 02:12:33 2011 From: manojo10386 at gmail.com (Manohar Jonnalagedda) Date: Fri, 25 Nov 2011 11:12:33 +0100 Subject: proper usage of -XX:+PrintIdeal In-Reply-To: References: Message-ID: Hi Krystal, thanks for the reply. I will post this on the hotspot-compiler-dev list as well. Here is the link : http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2011-November/006782.html > Your command line arguments looks okay to me. I tried it on a fastdebug > build of HotSpot 20.0-b11 and it worked fine. Is it that the file.xml is > empty, or is it the particular method that you're after doesn't exist in > "file.xml"? For the latter case, did you see a "file1.xml" in the same > directory? Does it contain the method you're after? > I am using 20.0-b17 of the fastdebug build. I do have two files as well, file.xml and file1.xml, and neither contain the method I am looking for. I only have details for 4 methods, one of them being a decodeArrayLoop and the others being methods from the API (file input and string manipulation methods). Is it possible that methodA would not be JIT compiled following the extra instrumentation overhead? Cheers, Manohar > > - Kris > > > On Fri, Nov 25, 2011 at 12:57 AM, Manohar Jonnalagedda < > manojo10386 at gmail.com> wrote: > >> Hello all, >> >> I am new to using the debug features of hotspot (probably posting to the >> wrong list, as I haven't seen any list targetted to hotspot users), and was >> interested in checking out the graph of a program that I wrote. The program >> contains a method 'methodA' which I would like to inspect in terms of >> optimizations performed. I verified using the PrintCompilation (and >> PrintAssembly) flag that it was indeed JIT compiled. >> >> When I use the PrintIdeal flags, however, my output xml files do not >> contain any mention of this method. Here is the command I use : >> >> $JAVA_HOME/bin/java -verbose:gc -server -d64 -XX:+UseCompressedOops >> -XX:+DoEscapeAnalysis -XX:PrintIdealGraphLevel=1 >> -XX:PrintIdealGraphFile="file.xml" -XX:+PrintIdeal $JAVA_OPTS "$@" >> >> Would the problem be due to not using the flags properly? >> >> Thanks a lot for your help, >> Manohar >> >> > What version of HotSpot are you using? And, I assume you are using a fastdebug build, right? Otherwise the PrintIdeal* arguments won't even be accepted at VM start. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20111125/6af5326f/attachment.html From sebastian.sickelmann at gmx.de Fri Nov 25 06:33:04 2011 From: sebastian.sickelmann at gmx.de (Sebastian Sickelmann) Date: Fri, 25 Nov 2011 15:33:04 +0100 Subject: gamma and Interpreter Message-ID: <4ECFA720.9050205@gmx.de> Hi i actually try to prototype some thinks into the vm. Starting project setup from a description[1] how to debug hotspot i get something running put i think i run into an C2-Compiler issue of my change. To not complicate my prototype i want to use interpreter mode. But i cannot get it going(compiling) My Setup with i build my C2-Version is: DEBUG_NAME=debug LANG=C ALT_BOOTDIR=/usr/lib/jvm/java-7-openjdk make jvmg1 My Setup with i tried to build Interpreter-Version is: CC_INTERP=true DEBUG_NAME=debug LANG=C ALT_BOOTDIR=/usr/lib/jvm/java-7-openjdk make jvmg1 I get the this [1] error, which i can fix but than i run into more[2] errors. [1] https://raw.github.com/gist/1393620/a2eb4327dee28a39e776409819664aab1307e829/CC_INTERP_ERROR1.log [2] https://raw.github.com/gist/1393645/f0fddaf6a83b44aa94827b2e72280e2959dc78fb/CC_INTERP_ERROR2.log I think i got something wrong in my setup. Some tips on how to build and test in interpreter mode would be fine. Kind regards Sebastian From volker.simonis at gmail.com Fri Nov 25 08:16:41 2011 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 25 Nov 2011 17:16:41 +0100 Subject: gamma and Interpreter In-Reply-To: <4ECFA720.9050205@gmx.de> References: <4ECFA720.9050205@gmx.de> Message-ID: "jvmg1" builds the debug version of the C1 compiler, "jvmg" the debug version of the C2 compiler. I don't think there's any support for an "interpreter only" build. A long time ago there was a "core" target which did an interpreter only build but that has vanished (see bug "6812511: Allow interpreter-only builds" at http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6812511). Setting "CC_INTERP=true" will build the C-Interpreter instead of the default Template-Interpreter which isn't officially supported as well and probably not what you want. You can try to build "jvmgzero" which as far as I remember will build the VM with the C-Interpreter and without compiler, but I don't know what's the current status of Zero on x86. You may have a look at the following links for more information on Zero: http://openjdk.java.net/projects/zero/ http://today.java.net/pub/a/today/2009/05/21/zero-and-shark-openjdk-port.html Regards, Volker On Fri, Nov 25, 2011 at 3:33 PM, Sebastian Sickelmann wrote: > Hi > > i actually try to prototype some thinks into the vm. > Starting project setup from a description[1] how to debug hotspot i get > something running put i think > i run into an C2-Compiler issue of my change. To not complicate my prototype > i want to use interpreter mode. > > But i cannot get it going(compiling) > > My Setup with i build my C2-Version is: > DEBUG_NAME=debug LANG=C ALT_BOOTDIR=/usr/lib/jvm/java-7-openjdk make jvmg1 > > My Setup with i tried to build Interpreter-Version is: > CC_INTERP=true DEBUG_NAME=debug LANG=C > ALT_BOOTDIR=/usr/lib/jvm/java-7-openjdk make jvmg1 > > I get the this [1] error, which i can fix but than i run into more[2] > errors. > > [1] > https://raw.github.com/gist/1393620/a2eb4327dee28a39e776409819664aab1307e829/CC_INTERP_ERROR1.log > [2] > https://raw.github.com/gist/1393645/f0fddaf6a83b44aa94827b2e72280e2959dc78fb/CC_INTERP_ERROR2.log > > I think i got something wrong in my setup. > > Some tips on how to build and test in interpreter mode would be fine. > > Kind regards > Sebastian > From stefan.karlsson at oracle.com Mon Nov 28 06:34:24 2011 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Mon, 28 Nov 2011 15:34:24 +0100 Subject: Review request (s): 7116081: USE_PRECOMPILED_HEADER=0 triggers a single threaded build of the JVM Message-ID: <4ED39BF0.7040802@oracle.com> http://cr.openjdk.java.net/~stefank/7116081/webrev/ Turning off the precompiled headers is somewhat broken. It triggers a single threaded build even when HOTSPOT_BUILD_JOBS has been set. With this fix the compile times went from around 14 minutes to 2.5 minutes, on an 8 core machine. This affects both Linux and BSD builds, but has only been tested on Linux. It would be great if someone with access to a BSD machine could verify this fix. From jon.masamitsu at oracle.com Mon Nov 28 09:20:27 2011 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Mon, 28 Nov 2011 09:20:27 -0800 Subject: Project proposal: Remove the Permanent Generation Message-ID: <4ED3C2DB.7050703@oracle.com> I am going to be proposing the permanent generation removal as a OpenJDK project shortly. The project is described in the JEP 122 http://openjdk.java.net/jeps/122 This is not the formal proposal of the project but rather a chance to ask questions ahead of that proposal. From fweimer at bfk.de Mon Nov 28 10:14:59 2011 From: fweimer at bfk.de (Florian Weimer) Date: Mon, 28 Nov 2011 18:14:59 +0000 Subject: Project proposal: Remove the Permanent Generation In-Reply-To: <4ED3C2DB.7050703@oracle.com> (Jon Masamitsu's message of "Mon, 28 Nov 2011 09:20:27 -0800") References: <4ED3C2DB.7050703@oracle.com> Message-ID: <82r50st8po.fsf@mid.bfk.de> * Jon Masamitsu: > I am going to be proposing the permanent generation > removal as a OpenJDK project shortly. The project is > described in the JEP 122 > > http://openjdk.java.net/jeps/122 > > This is not the formal proposal of the project but rather > a chance to ask questions ahead of that proposal. Interned strings have already been moved out of the permanent generation: changeset: 2226:b099aaf51bf8 user: jcoomes date: Tue Mar 22 13:36:33 2011 -0700 summary: 6962931: move interned strings out of the perm gen This is in jdk7u2 (and perhaps earlier). How does the PermGen removal interact with anonymous classes (that is, classes whose metadata can be reclaimed individually, while the corresponding class loader still exists)? I'm not sure what happened to anonymous classes; originally, this was one of the features in JDK 7 targeted at dynamic languages. But if they still need to be supported, then this might complicate managing meta-data stored in the C heap. -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra?e 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From jon.masamitsu at oracle.com Mon Nov 28 11:24:12 2011 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Mon, 28 Nov 2011 11:24:12 -0800 Subject: Project proposal: Remove the Permanent Generation In-Reply-To: <82r50st8po.fsf@mid.bfk.de> References: <4ED3C2DB.7050703@oracle.com> <82r50st8po.fsf@mid.bfk.de> Message-ID: <4ED3DFDC.4010701@oracle.com> Florian, Thanks for the reminder that some changes have already been made to aid in the removal of perm gen. If anonymous classes are supported, they will complicate matters some but there are other classes that we will need to treat specially so it hopefully won't be too much additional code. Last I heard, anonymous classes were dropped from 292. Jon On 11/28/11 10:14, Florian Weimer wrote: > * Jon Masamitsu: > >> I am going to be proposing the permanent generation >> removal as a OpenJDK project shortly. The project is >> described in the JEP 122 >> >> http://openjdk.java.net/jeps/122 >> >> This is not the formal proposal of the project but rather >> a chance to ask questions ahead of that proposal. > Interned strings have already been moved out of the permanent > generation: > > changeset: 2226:b099aaf51bf8 > user: jcoomes > date: Tue Mar 22 13:36:33 2011 -0700 > summary: 6962931: move interned strings out of the perm gen > > This is in jdk7u2 (and perhaps earlier). > > How does the PermGen removal interact with anonymous classes (that is, > classes whose metadata can be reclaimed individually, while the > corresponding class loader still exists)? I'm not sure what happened to > anonymous classes; originally, this was one of the features in JDK 7 > targeted at dynamic languages. But if they still need to be supported, > then this might complicate managing meta-data stored in the C heap. > From david.holmes at oracle.com Mon Nov 28 15:48:59 2011 From: david.holmes at oracle.com (David Holmes) Date: Tue, 29 Nov 2011 09:48:59 +1000 Subject: Review request (s): 7116081: USE_PRECOMPILED_HEADER=0 triggers a single threaded build of the JVM In-Reply-To: <4ED39BF0.7040802@oracle.com> References: <4ED39BF0.7040802@oracle.com> Message-ID: <4ED41DEB.2000600@oracle.com> Hi Stefan, On 29/11/2011 12:34 AM, Stefan Karlsson wrote: > http://cr.openjdk.java.net/~stefank/7116081/webrev/ > > Turning off the precompiled headers is somewhat broken. It triggers a > single threaded build even when HOTSPOT_BUILD_JOBS has been set. With > this fix the compile times went from around 14 minutes to 2.5 minutes, > on an 8 core machine. Took me a while to figure out why this was the case :) > This affects both Linux and BSD builds, but has only been tested on > Linux. It would be great if someone with access to a BSD machine could > verify this fix. The problem here was using ifdef USE_PRECOMPILED_HEADER when defining it to 0 is used to turn it off - so it seems to me the better fix here was to simply change to: ifeq ($(USE_PRECOMPILED_HEADER),1) The removal of: PrecompiledOption = -DUSE_PRECOMPILED_HEADER seems okay. Cheers, David From stefan.karlsson at oracle.com Tue Nov 29 00:47:01 2011 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Tue, 29 Nov 2011 09:47:01 +0100 Subject: Review request (s): 7116081: USE_PRECOMPILED_HEADER=0 triggers a single threaded build of the JVM In-Reply-To: <4ED41DEB.2000600@oracle.com> References: <4ED39BF0.7040802@oracle.com> <4ED41DEB.2000600@oracle.com> Message-ID: <4ED49C05.5090306@oracle.com> David, Thanks for the review. All, Updated webrev: http://cr.openjdk.java.net/~stefank/7116081/webrev.2/ The rationale for this change is inlined: On 11/29/2011 12:48 AM, David Holmes wrote: > Hi Stefan, > > On 29/11/2011 12:34 AM, Stefan Karlsson wrote: >> http://cr.openjdk.java.net/~stefank/7116081/webrev/ >> >> Turning off the precompiled headers is somewhat broken. It triggers a >> single threaded build even when HOTSPOT_BUILD_JOBS has been set. With >> this fix the compile times went from around 14 minutes to 2.5 minutes, >> on an 8 core machine. > > Took me a while to figure out why this was the case :) > >> This affects both Linux and BSD builds, but has only been tested on >> Linux. It would be great if someone with access to a BSD machine could >> verify this fix. > > The problem here was using > > ifdef USE_PRECOMPILED_HEADER > > when defining it to 0 is used to turn it off - so it seems to me the > better fix here was to simply change to: > > ifeq ($(USE_PRECOMPILED_HEADER),1) I've changed the conditional to check USE_PRECOMPILED_HEADER instead. While doing that I found another issue. In gcc.make we try to redefine USE_PRECOMPILED_HEADER: 88 ifneq ($(USE_PRECOMPILED_HEADER),0) 89 USE_PRECOMPILED_HEADER=1 That doesn't work, so setting USE_PRECOMPILED_HEADER= on the command line will leave the precompiled headers on, but later logic: 219 ifneq ($(USE_PRECOMPILED_HEADER),1) 220 CFLAGS += -DDONT_USE_PRECOMPILED_HEADER will empty the precompiled.hpp file. From precompiled.hpp: // Precompiled headers are turned off for Sun Studion, // or if the user passes USE_PRECOMPILED_HEADER=0 to the makefiles. #ifndef DONT_USE_PRECOMPILED_HEADER In the new webrev I've changed all places where we read USE_PRECOMPILED_HEADER to always compare against 0. thanks, StefanK > > > The removal of: > > PrecompiledOption = -DUSE_PRECOMPILED_HEADER > > seems okay. > > Cheers, > David > > From spoole at linux.vnet.ibm.com Tue Nov 29 06:30:43 2011 From: spoole at linux.vnet.ibm.com (Steve Poole) Date: Tue, 29 Nov 2011 14:30:43 +0000 Subject: Improving the documention of the JVM implementation interface In-Reply-To: References: <1322058589.13674.7.camel@jazzette> Message-ID: <1322577043.6819.5.camel@jazzette> On Thu, 2011-11-24 at 11:26 +0800, Krystal Mok wrote: > Hi Steve, > > > There's been some efforts in this area before. There's an OpenJDK > project called "Common VM Interface" [1], ran by Dr Andrew John > Hughes. One of the earlier notes can be found at [2]. The aims of this > project seems to be in the same direction as what you're looking for. Hi Krystal - sorry for the delay in responding: been somewhat email server challenged. Its possible the cmvi project could be used to do this work but it seems very quiet at the moment. Besides, this proposal is about documenting what exists today, so I'd rather have the conversation on a mailing list that the people who know frequent :-) > > > Xi Yang has been working on integrating OpenJDK class libraries into > Jikes RVM this year. This work also needed a definition of the VM > interface in OpenJDK. He's made quite a lot of progress already, so he > might be able to help out with this documentation proposal. I'm cc'ing > this mail to him. > > > - Kris > > > [1]: http://openjdk.java.net/projects/cvmi/ > [2]: http://mail.openjdk.java.net/pipermail/cvmi-dev/2008-July/000006.html > > On Wed, Nov 23, 2011 at 10:29 PM, Steve Poole > wrote: > Hi all, I've been talking to Mikael Vidstedt and a few other > Oracle > luminaries about improving the documentation of the interface > between > the JVM and the rest of the SDK. > > We wanted to make that discussion public hence this post. > I'll start > and Mikael can jump in. > > What I'm trying to do is simply gain some agreement on what > code is JVM > implementation specific and what isn't. Then, where this JVM > implementation specific code interacts with the SDK, improve > the > documentation. > > A few examples to consider... > > JVM_* entry points in the VM that are there for the class > library code > to call: these are not part of the public JNI spec - I'd like > to get > them documented in more detail. > > These extra entry points can blur the line between the JVM and > the class > libraries: sometimes making it's difficult to work out if the > "real" > API is the C entry point or the calling Java class. To put it > another > way - there is Java code that is intentionally JVM > implementation > specific. I'd like to get that status documented. > > Another similar example is where Hotspot code leaks out of the > JVM into > the class libs and tools. The Late Attach API is a good (or > is that > bad) example. Sometimes it's difficult to work out if that > leakage is > intentional or inadvertent. I'd like to get that status > documented too. > > So to recap: what I'd like to do is discover and document the > API > between the JVM implementation specific code and everything > else. > Hopefully in the process improving everyone's awareness and > getting some > common agreement over actual behaviour or design versus > intention. This > work might discover areas that could benefit from improved > interface > design and some form of refactoring but that would be for > later. > > > Thanks > > Steve > > > > From mikael.gerdin at oracle.com Tue Nov 29 08:04:23 2011 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Tue, 29 Nov 2011 17:04:23 +0100 Subject: Review request: White box testing API for HotSpot Message-ID: <4ED50287.3070102@oracle.com> Hi I've been working on a white box testing API for HotSpot in order to allow for improved precision in vm testing. The basic idea is to open up the possibility for tests written in Java to call native methods which query or poke the vm in some way. The API is accessible by using the class sun/hotspot/WhiteBox which is not intended to be available in public builds. In order to allow the WhiteBox class access to the VM the registerNatives function is linked to JVM_RegisterWhiteBoxMethods. That function then links all the implementation functions using normal JNI RegisterNatives. The API is not meant to be used by end users for any intent or purpose and as such it is both guarded by "-XX:+UnlockDiagnosticVMOptions -XX:+EnableWhiteboxAPI" and the fact that the class files will not be present in an end user build of a JDK. If the VM crashes after this API has been accessed a note will be written in the hs_err file to signal that the API has been used. Webrev: http://cr.openjdk.java.net/~stefank/mgerdin/wbapi.0/webrev/ (thanks to stefank for hosting my webrev :) CR: I'll file a CR tomorrow. Change comments: make/jprt.properties Add a test target to make sure that the API is available on all supported platforms make/** Makefile changes to build the class sun/hotspot/WhiteBox, put it in a JAR file and copy it to the jre/lib/endorsed directory in the export targets. The BSD makefile changes are not tested since I don't have access to any BSD/OSX machine to test them on. src/share/vm/prims/nativeLookup.cpp Special-case the method sun/hotspot/WhiteBox/registerNatives and link it to JVM_RegisterWhiteBoxMethods src/share/vm/prims/whitebox.* The implementation of the white box API. The actual API functions are only examples of what we want to be able to do using the API. src/share/vm/runtime/globals.hpp Add the command line flag src/share/vm/utilities/vmError.cpp Print a message in hs_err files when white box API has been used. test/Makefile Add a makefile test target for the white box API test test/sanity/wbapi.java JTreg test to ensure that the API works. Thanks /Mikael Gerdin From paul.hohensee at oracle.com Tue Nov 29 12:32:21 2011 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Tue, 29 Nov 2011 15:32:21 -0500 Subject: Pls review 7116481 (S) Message-ID: <4ED54155.3080909@oracle.com> 7116481: Commercial features in Hotspot must be gated by a switch Commercial features (those for which Oracle charges for production use, though not for development and/or evaluation) must be gated by a "master" -XX switch. It works in the same manner as the existing UnlockDiagnosticVMOptions and UnlockExperimentalVMOptions switches, so the new switch's name is UnlockCommercialVMOptions. A commercial() macro designates which switches are gated by UnlockCommercialVMOptions. I added a single commercial() -XX flag named FlightRecorder, which does nothing, but will eventually gate use of the Java Flight Recorder now under development. Webrev here: http://cr.openjdk.java.net/~phh/7116481/ Tested from the command line. Hotspot accepts this: -XX:+UnlockCommercialVMOptions -XX:+FlightRecorder and doesn't accept this -XX:+FlightRecorder Thanks, Paul From jesper.wilhelmsson at oracle.com Tue Nov 29 13:35:50 2011 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Tue, 29 Nov 2011 22:35:50 +0100 Subject: Pls review 7116481 (S) In-Reply-To: <4ED54155.3080909@oracle.com> References: <4ED54155.3080909@oracle.com> Message-ID: Looks good to me. A few nits... In the documentation of the flags in globals.hpp:367-435, why did you chose to add the parenthesis after the flag type? If it doesn't have a specific meaning that you want to stress I think it makes the text less readable. Thanks for fixing the line break at globals.hpp:483-484. There are plenty more like that one in that macro ;-) I'm not a native english speaker, but to me the last s on line 3866 seems as a typo. "for JDK 6 and earliers". You did an unrelated change in that line, maybe you could remove the s as well while you're at it? Provided it is a typo of course. /Jesper 29 nov 2011 kl. 21:32 skrev Paul Hohensee : > 7116481: Commercial features in Hotspot must be gated by a switch > > Commercial features (those for which Oracle charges for production use, though > not for development and/or evaluation) must be gated by a "master" -XX switch. > It works in the same manner as the existing UnlockDiagnosticVMOptions and > UnlockExperimentalVMOptions switches, so the new switch's name is > UnlockCommercialVMOptions. A commercial() macro designates which > switches are gated by UnlockCommercialVMOptions. I added a single > commercial() -XX flag named FlightRecorder, which does nothing, but > will eventually gate use of the Java Flight Recorder now under development. > > Webrev here: > > http://cr.openjdk.java.net/~phh/7116481/ > > Tested from the command line. Hotspot accepts this: > > -XX:+UnlockCommercialVMOptions -XX:+FlightRecorder > > and doesn't accept this > > -XX:+FlightRecorder > > Thanks, > > Paul > > From paul.hohensee at oracle.com Tue Nov 29 13:48:53 2011 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Tue, 29 Nov 2011 16:48:53 -0500 Subject: Pls review 7116481 (S) In-Reply-To: References: <4ED54155.3080909@oracle.com> Message-ID: <4ED55345.5000605@oracle.com> Thanks for the prompt review. On 11/29/11 4:35 PM, Jesper Wilhelmsson wrote: > Looks good to me. > A few nits... > > In the documentation of the flags in globals.hpp:367-435, why did you chose to add the parenthesis after the flag type? If it doesn't have a specific meaning that you want to stress I think it makes the text less readable. I put them in as a reference to the macro that implements them. They're already lower case even though they begin a sentence. I'll take the parens out, since at least one person finds them confusing. :) > Thanks for fixing the line break at globals.hpp:483-484. There are plenty more like that one in that macro ;-) Yes. I do a few formatting fixes whenever I change a file that I think needs it :), but most reviewers don't want to be distracted by such changes so I keep them to a minimum. > > I'm not a native english speaker, but to me the last s on line 3866 seems as a typo. "for JDK 6 and earliers". You did an unrelated change in that line, maybe you could remove the s as well while you're at it? Provided it is a typo of course. Fixed. Paul > /Jesper > > > 29 nov 2011 kl. 21:32 skrev Paul Hohensee: > >> 7116481: Commercial features in Hotspot must be gated by a switch >> >> Commercial features (those for which Oracle charges for production use, though >> not for development and/or evaluation) must be gated by a "master" -XX switch. >> It works in the same manner as the existing UnlockDiagnosticVMOptions and >> UnlockExperimentalVMOptions switches, so the new switch's name is >> UnlockCommercialVMOptions. A commercial() macro designates which >> switches are gated by UnlockCommercialVMOptions. I added a single >> commercial() -XX flag named FlightRecorder, which does nothing, but >> will eventually gate use of the Java Flight Recorder now under development. >> >> Webrev here: >> >> http://cr.openjdk.java.net/~phh/7116481/ >> >> Tested from the command line. Hotspot accepts this: >> >> -XX:+UnlockCommercialVMOptions -XX:+FlightRecorder >> >> and doesn't accept this >> >> -XX:+FlightRecorder >> >> Thanks, >> >> Paul >> >> From david.holmes at oracle.com Tue Nov 29 13:52:52 2011 From: david.holmes at oracle.com (David Holmes) Date: Wed, 30 Nov 2011 07:52:52 +1000 Subject: Review request (s): 7116081: USE_PRECOMPILED_HEADER=0 triggers a single threaded build of the JVM In-Reply-To: <4ED49C05.5090306@oracle.com> References: <4ED39BF0.7040802@oracle.com> <4ED41DEB.2000600@oracle.com> <4ED49C05.5090306@oracle.com> Message-ID: <4ED55434.8080904@oracle.com> On 29/11/2011 6:47 PM, Stefan Karlsson wrote: > Updated webrev: http://cr.openjdk.java.net/~stefank/7116081/webrev.2/ > > The rationale for this change is inlined: > While doing that I found another issue. In gcc.make we try to redefine > USE_PRECOMPILED_HEADER: > > 88 ifneq ($(USE_PRECOMPILED_HEADER),0) > 89 USE_PRECOMPILED_HEADER=1 > > > That doesn't work, Why doesn't it work? We use similar logic elsewhere in the makefiles to ensure that if a variable is defined then it has an explicit value (0, 1, true or false etc). > so setting USE_PRECOMPILED_HEADER= (not 0)> on the command line will leave the precompiled headers on, but > later logic: > > 219 ifneq ($(USE_PRECOMPILED_HEADER),1) > 220 CFLAGS += -DDONT_USE_PRECOMPILED_HEADER > > will empty the precompiled.hpp file. From precompiled.hpp: > > // Precompiled headers are turned off for Sun Studion, > // or if the user passes USE_PRECOMPILED_HEADER=0 to the makefiles. > #ifndef DONT_USE_PRECOMPILED_HEADER > > In the new webrev I've changed all places where we read > USE_PRECOMPILED_HEADER to always compare against 0. That makes sense. Looks good to me. David ----- > thanks, > StefanK > >> >> >> The removal of: >> >> PrecompiledOption = -DUSE_PRECOMPILED_HEADER >> >> seems okay. >> >> Cheers, >> David >> >> > From stefan.karlsson at oracle.com Wed Nov 30 00:39:20 2011 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Wed, 30 Nov 2011 09:39:20 +0100 Subject: Review request (s): 7116081: USE_PRECOMPILED_HEADER=0 triggers a single threaded build of the JVM In-Reply-To: <4ED55434.8080904@oracle.com> References: <4ED39BF0.7040802@oracle.com> <4ED41DEB.2000600@oracle.com> <4ED49C05.5090306@oracle.com> <4ED55434.8080904@oracle.com> Message-ID: <4ED5EBB8.7020000@oracle.com> On 11/29/2011 10:52 PM, David Holmes wrote: > On 29/11/2011 6:47 PM, Stefan Karlsson wrote: >> Updated webrev: http://cr.openjdk.java.net/~stefank/7116081/webrev.2/ >> >> The rationale for this change is inlined: > >> While doing that I found another issue. In gcc.make we try to redefine >> USE_PRECOMPILED_HEADER: >> >> 88 ifneq ($(USE_PRECOMPILED_HEADER),0) >> 89 USE_PRECOMPILED_HEADER=1 >> >> >> That doesn't work, > > Why doesn't it work? We use similar logic elsewhere in the makefiles > to ensure that if a variable is defined then it has an explicit value > (0, 1, true or false etc). The variable wasn't overridden since it was specified on the command line, but I guess we could have used the 'override' keyword: http://www.gnu.org/software/make/manual/make.html#Override-Directive > >> so setting USE_PRECOMPILED_HEADER=> (not 0)> on the command line will leave the precompiled headers on, but >> later logic: >> >> 219 ifneq ($(USE_PRECOMPILED_HEADER),1) >> 220 CFLAGS += -DDONT_USE_PRECOMPILED_HEADER >> >> will empty the precompiled.hpp file. From precompiled.hpp: >> >> // Precompiled headers are turned off for Sun Studion, >> // or if the user passes USE_PRECOMPILED_HEADER=0 to the makefiles. >> #ifndef DONT_USE_PRECOMPILED_HEADER >> >> In the new webrev I've changed all places where we read >> USE_PRECOMPILED_HEADER to always compare against 0. > > That makes sense. > > Looks good to me. Thanks for the review, StefanK > > David > ----- > >> thanks, >> StefanK >> >>> >>> >>> The removal of: >>> >>> PrecompiledOption = -DUSE_PRECOMPILED_HEADER >>> >>> seems okay. >>> >>> Cheers, >>> David >>> >>> >> From stefan.karlsson at oracle.com Wed Nov 30 04:37:03 2011 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Wed, 30 Nov 2011 13:37:03 +0100 Subject: Review request (s): 7116081: USE_PRECOMPILED_HEADER=0 triggers a single threaded build of the JVM In-Reply-To: <4ED49C05.5090306@oracle.com> References: <4ED39BF0.7040802@oracle.com> <4ED41DEB.2000600@oracle.com> <4ED49C05.5090306@oracle.com> Message-ID: <4ED6236F.9060608@oracle.com> Looping in build-dev and build-infra-dev. StefanK On 11/29/2011 09:47 AM, Stefan Karlsson wrote: > David, > > Thanks for the review. > > All, > > Updated webrev: http://cr.openjdk.java.net/~stefank/7116081/webrev.2/ > > The rationale for this change is inlined: > > On 11/29/2011 12:48 AM, David Holmes wrote: >> Hi Stefan, >> >> On 29/11/2011 12:34 AM, Stefan Karlsson wrote: >>> http://cr.openjdk.java.net/~stefank/7116081/webrev/ >>> >>> Turning off the precompiled headers is somewhat broken. It triggers a >>> single threaded build even when HOTSPOT_BUILD_JOBS has been set. With >>> this fix the compile times went from around 14 minutes to 2.5 minutes, >>> on an 8 core machine. >> >> Took me a while to figure out why this was the case :) >> >>> This affects both Linux and BSD builds, but has only been tested on >>> Linux. It would be great if someone with access to a BSD machine could >>> verify this fix. >> >> The problem here was using >> >> ifdef USE_PRECOMPILED_HEADER >> >> when defining it to 0 is used to turn it off - so it seems to me the >> better fix here was to simply change to: >> >> ifeq ($(USE_PRECOMPILED_HEADER),1) > > I've changed the conditional to check USE_PRECOMPILED_HEADER instead. > > While doing that I found another issue. In gcc.make we try to redefine > USE_PRECOMPILED_HEADER: > > 88 ifneq ($(USE_PRECOMPILED_HEADER),0) > 89 USE_PRECOMPILED_HEADER=1 > > > That doesn't work, so setting USE_PRECOMPILED_HEADER= (not 0)> on the command line will leave the precompiled headers on, > but later logic: > > 219 ifneq ($(USE_PRECOMPILED_HEADER),1) > 220 CFLAGS += -DDONT_USE_PRECOMPILED_HEADER > > will empty the precompiled.hpp file. From precompiled.hpp: > > // Precompiled headers are turned off for Sun Studion, > // or if the user passes USE_PRECOMPILED_HEADER=0 to the makefiles. > #ifndef DONT_USE_PRECOMPILED_HEADER > > In the new webrev I've changed all places where we read > USE_PRECOMPILED_HEADER to always compare against 0. > > thanks, > StefanK > >> >> >> The removal of: >> >> PrecompiledOption = -DUSE_PRECOMPILED_HEADER >> >> seems okay. >> >> Cheers, >> David >> >> > From ahughes at redhat.com Wed Nov 30 09:19:22 2011 From: ahughes at redhat.com (Dr Andrew John Hughes) Date: Wed, 30 Nov 2011 17:19:22 +0000 Subject: Pls review 7116481 (S) In-Reply-To: <4ED54155.3080909@oracle.com> References: <4ED54155.3080909@oracle.com> Message-ID: <20111130171922.GB12569@rivendell.middle-earth.co.uk> On 15:32 Tue 29 Nov , Paul Hohensee wrote: > 7116481: Commercial features in Hotspot must be gated by a switch > > Commercial features (those for which Oracle charges for production use, > though > not for development and/or evaluation) must be gated by a "master" -XX > switch. > It works in the same manner as the existing UnlockDiagnosticVMOptions and > UnlockExperimentalVMOptions switches, so the new switch's name is > UnlockCommercialVMOptions. A commercial() macro designates which > switches are gated by UnlockCommercialVMOptions. I added a single > commercial() -XX flag named FlightRecorder, which does nothing, but > will eventually gate use of the Java Flight Recorder now under development. > > Webrev here: > > http://cr.openjdk.java.net/~phh/7116481/ > > Tested from the command line. Hotspot accepts this: > > -XX:+UnlockCommercialVMOptions -XX:+FlightRecorder > > and doesn't accept this > > -XX:+FlightRecorder > > Thanks, > > Paul > > Is it really necessary to add this into the open code base? Would this not be more appropriate in whatever proprietary fork you use at Oracle? 'Commercial' is also the wrong word to use, as this is nothing non-commercial about the rest of the OpenJDK code base. What you're referring to are proprietary features which you're not releasing the source code to. See http://www.gnu.org/philosophy/words-to-avoid.html#Commercial -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: Digital signature Url : http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20111130/ba134f38/attachment-0001.bin From paul.hohensee at oracle.com Wed Nov 30 09:25:54 2011 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Wed, 30 Nov 2011 12:25:54 -0500 Subject: Pls review 7116481 (S) In-Reply-To: <20111130171922.GB12569@rivendell.middle-earth.co.uk> References: <4ED54155.3080909@oracle.com> <20111130171922.GB12569@rivendell.middle-earth.co.uk> Message-ID: <4ED66722.7070808@oracle.com> Reversion on the way. Paul On 11/30/11 12:19 PM, Dr Andrew John Hughes wrote: > On 15:32 Tue 29 Nov , Paul Hohensee wrote: >> 7116481: Commercial features in Hotspot must be gated by a switch >> >> Commercial features (those for which Oracle charges for production use, >> though >> not for development and/or evaluation) must be gated by a "master" -XX >> switch. >> It works in the same manner as the existing UnlockDiagnosticVMOptions and >> UnlockExperimentalVMOptions switches, so the new switch's name is >> UnlockCommercialVMOptions. A commercial() macro designates which >> switches are gated by UnlockCommercialVMOptions. I added a single >> commercial() -XX flag named FlightRecorder, which does nothing, but >> will eventually gate use of the Java Flight Recorder now under development. >> >> Webrev here: >> >> http://cr.openjdk.java.net/~phh/7116481/ >> >> Tested from the command line. Hotspot accepts this: >> >> -XX:+UnlockCommercialVMOptions -XX:+FlightRecorder >> >> and doesn't accept this >> >> -XX:+FlightRecorder >> >> Thanks, >> >> Paul >> >> > Is it really necessary to add this into the open code base? Would this > not be more appropriate in whatever proprietary fork you use at Oracle? > > 'Commercial' is also the wrong word to use, as this is nothing > non-commercial about the rest of the OpenJDK code base. What you're > referring to are proprietary features which you're not releasing the > source code to. > > See http://www.gnu.org/philosophy/words-to-avoid.html#Commercial From paul.hohensee at oracle.com Wed Nov 30 09:28:46 2011 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Wed, 30 Nov 2011 12:28:46 -0500 Subject: Pls review 7116730 (reversion of 7116481) Message-ID: <4ED667CE.2080200@oracle.com> 7116730: Revert 7116481: Commercial features in Hotspot must be gated by a switch 7116481 should not have been pushed to openjdk. Here's a simple reversion. http://cr.openjdk.java.net/~phh/7116481/ Thanks, Paul From keith.mcguigan at oracle.com Wed Nov 30 09:33:19 2011 From: keith.mcguigan at oracle.com (Keith McGuigan) Date: Wed, 30 Nov 2011 12:33:19 -0500 Subject: Pls review 7116730 (reversion of 7116481) In-Reply-To: <4ED667CE.2080200@oracle.com> References: <4ED667CE.2080200@oracle.com> Message-ID: ok. On Nov 30, 2011, at 12:28 PM, Paul Hohensee wrote: > 7116730: Revert 7116481: Commercial features in Hotspot must be > gated by a switch > > 7116481 should not have been pushed to openjdk. Here's a simple > reversion. > > http://cr.openjdk.java.net/~phh/7116481/ > > Thanks, > > Paul > > From paul.hohensee at oracle.com Wed Nov 30 09:35:49 2011 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Wed, 30 Nov 2011 12:35:49 -0500 Subject: Pls review 7116730 (reversion of 7116481) In-Reply-To: References: <4ED667CE.2080200@oracle.com> Message-ID: <4ED66975.2080201@oracle.com> Thanks, Keith, for the quick review. Paul On 11/30/11 12:33 PM, Keith McGuigan wrote: > > ok. > > On Nov 30, 2011, at 12:28 PM, Paul Hohensee wrote: > >> 7116730: Revert 7116481: Commercial features in Hotspot must be gated >> by a switch >> >> 7116481 should not have been pushed to openjdk. Here's a simple >> reversion. >> >> http://cr.openjdk.java.net/~phh/7116481/ >> >> Thanks, >> >> Paul >> >> >