From dalibor.topic at oracle.com Tue Aug 2 16:37:14 2011 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Wed, 03 Aug 2011 01:37:14 +0200 Subject: Draft Repository Management In-Reply-To: <4E324BA3.9060208@oracle.com> References: <4E1E3778.7000206@oracle.com> <4E3088D2.50605@oracle.com> <4E324BA3.9060208@oracle.com> Message-ID: <4E388A2A.3060500@oracle.com> On 7/29/11 7:56 AM, Poonam Bajaj wrote: > Hi Dalibor, > > On the Repository Management page (http://openjdk.java.net/projects/jdk7u/repos.html), the location of 7u integration forest is mentioned. > > " > *Rule 2* > > jdk7u-dev - Integration - always-open mainline forest. Integration schedule is TBD, and will be published on the Project's web page. The push rights to the integration forest are available to current JDK 7 Committers. > > The OpenJDK JDK 7 Updates integation forest is located at http://hg.openjdk.java.net/jdk7u/jdk7u-dev/. > " > > But the location http://hg.openjdk.java.net/jdk7u/jdk7u-dev/ is not accessible. Is it correct or the forest has not been created yet ? The forest wasn't created yet, but it has been created now (thanks, John!). cheers, dalibor topic -- Oracle Dalibor Topic | Java F/OSS Ambassador Phone: +494023646738 | Mobile: +491772664192 Oracle Java Platform Group ORACLE Deutschland B.V. & Co. KG | Nagelsweg 55 | 20097 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: J?rgen Kunz, Marcel van de Molen, Alexander van der Ven Green Oracle Oracle is committed to developing practices and products that help protect the environment From dalibor.topic at oracle.com Tue Aug 2 16:42:07 2011 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Wed, 03 Aug 2011 01:42:07 +0200 Subject: Draft Repository Management In-Reply-To: <4E33192C.8010708@oracle.com> References: <4E1E3778.7000206@oracle.com> <4E3088D2.50605@oracle.com> <4E324BA3.9060208@oracle.com> <4E327368.10902@oracle.com> <4E32DFFD.30905@oracle.com> <4E33192C.8010708@oracle.com> Message-ID: <4E388B4F.8000602@oracle.com> On 7/29/11 10:33 PM, Erik Trimble wrote: > On 7/29/2011 9:29 AM, Jim Holmlund wrote: >> >> >> On 7/29/2011 1:46 AM, Se?n Coffey wrote: >>> Poonam, >>> >>> 7u repos are best viewed from http://hg.openjdk.java.net/ >>> >>> I've often wondered why the mercurial webserver doesn't show a sub-forest type view when using the link you've mentioned. e.g http://hg.openjdk.java.net/jdk7u/jdk7u/jdk/ is the forest I'm using. >> As I read the doc >> http://openjdk.java.net/projects/jdk7u/repos.html >> >> jdk7u/jdk7u is the master and people should not be pushing to it. Erik said that the integration repo(s) to which we should push have not yet been created. It isn't clear to me if we will have just one integration repo, or maybe different ones for core, client, hotspot, etc.) >> >> - jjh >> > > As far as I understand, jdk7u/jdk7u is analogous to the old jdk7/jdk7 forest, and is the RE master which only the Gatekeepers should be pushing to. > > There also will only be one forest (jdk7u/jdk7u-dev) for everyone to push fixes to (i.e just one Integration forest). There are a couple of reasons: Correct. Things are a bit more complicated on the closed side (aren't they always?), since we have two further repositories there, in addition to the closedjdk jdk7u-dev. But as far as OpenJDK goes, jdk7u-dev is the place to push fixes to. > (a) the number of fixes is expected to be significantly lower than the active development branch (jdk8) > (b) we'd like to have developers test a bit more themselves before pushing into the Integration repository; that is, since fixes to 7u are lower-risk (i.e. we should be doing almost exclusively bugfixing, with the exception of Hotspot) > (c) builds should be further apart than with jdk8, which allows for more time to QA the -dev repository and find any issues > > All this adds up to making it simpler to have just a single development forest repository, rather than individual group forests. It also means we can dedicate more QA testing hardware to that single forest, rather than spread our resources over multiple forests. > > Also, as we implement the Build Improvement project, full JDK forest builds will become *significantly* faster, which will allow us to build and test the entire jdk7u-dev forest frequently - ideally, every push from every developer to jdk7u-dev will require a full JDK build&test, but that's the goal; we'll see if that happens. All very good points - thanks, Erik. cheers, dalibor topic -- Oracle Dalibor Topic | Java F/OSS Ambassador Phone: +494023646738 | Mobile: +491772664192 Oracle Java Platform Group ORACLE Deutschland B.V. & Co. KG | Nagelsweg 55 | 20097 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: J?rgen Kunz, Marcel van de Molen, Alexander van der Ven Green Oracle Oracle is committed to developing practices and products that help protect the environment From james.holmlund at oracle.com Tue Aug 2 17:00:11 2011 From: james.holmlund at oracle.com (Jim Holmlund) Date: Tue, 02 Aug 2011 17:00:11 -0700 Subject: Draft Repository Management In-Reply-To: <4E388A2A.3060500@oracle.com> References: <4E1E3778.7000206@oracle.com> <4E3088D2.50605@oracle.com> <4E324BA3.9060208@oracle.com> <4E388A2A.3060500@oracle.com> Message-ID: <4E388F8B.8030001@oracle.com> On 8/2/2011 4:37 PM, Dalibor Topic wrote: > On 7/29/11 7:56 AM, Poonam Bajaj wrote: >> Hi Dalibor, >> >> On the Repository Management page (http://openjdk.java.net/projects/jdk7u/repos.html), the location of 7u integration forest is mentioned. >> >> " >> *Rule 2* >> >> jdk7u-dev - Integration - always-open mainline forest. Integration schedule is TBD, and will be published on the Project's web page. The push rights to the integration forest are available to current JDK 7 Committers. >> >> The OpenJDK JDK 7 Updates integation forest is located at http://hg.openjdk.java.net/jdk7u/jdk7u-dev/. >> " >> >> But the location http://hg.openjdk.java.net/jdk7u/jdk7u-dev/ is not accessible. Is it correct or the forest has not been created yet ? > The forest wasn't created yet, but it has been created now (thanks, John!). > Great! Let the games begin, eh? Ground rule 3 here http://openjdk.java.net/projects/jdk7u/groundrules.html says that changes going into a 7u forest must be approved by the maintainer of that forest. Who is the maintainer for jdk7u/jdk7u-dev? Do we just send this person an email requesting approval, and containing a link to the webrev, or to the changeset in JDK8 if it is the same change, eg: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/e427c42e1a7e ? I suppose this email should be cc'd to jdk7u-dev, and should contain the names of the reviewers too? Thanks - jjh > cheers, > dalibor topic > From dalibor.topic at oracle.com Tue Aug 2 17:14:16 2011 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Wed, 03 Aug 2011 02:14:16 +0200 Subject: jdk7u-dev maintainer Message-ID: <4E3892D8.2020906@oracle.com> Hi, I'll be off-line for a few days starting on Wednesday, so I'm delegating the maintainer duties for jdk7u-dev (and the corresponding closedjdk jdk7u forests) to Edvard Wendelin. cheers, dalibor topic -- Oracle Dalibor Topic | Java F/OSS Ambassador Phone: +494023646738 | Mobile: +491772664192 Oracle Java Platform Group ORACLE Deutschland B.V. & Co. KG | Nagelsweg 55 | 20097 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: J?rgen Kunz, Marcel van de Molen, Alexander van der Ven Green Oracle Oracle is committed to developing practices and products that help protect the environment From dalibor.topic at oracle.com Tue Aug 2 18:55:08 2011 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Wed, 03 Aug 2011 03:55:08 +0200 Subject: Draft Bulk Changes Proposal In-Reply-To: <4E1E506C.10902@oracle.com> References: <4E1E506C.10902@oracle.com> Message-ID: <4E38AA7C.7020805@oracle.com> Thanks everyone for the feedback, I've put the bulk changes with the discussed revisions up on the Project's web site. cheers, dalibor topic -- Oracle Dalibor Topic | Java F/OSS Ambassador Phone: +494023646738 | Mobile: +491772664192 Oracle Java Platform Group ORACLE Deutschland B.V. & Co. KG | Nagelsweg 55 | 20097 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: J?rgen Kunz, Marcel van de Molen, Alexander van der Ven Green Oracle Oracle is committed to developing practices and products that help protect the environment From dalibor.topic at oracle.com Tue Aug 2 20:03:43 2011 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Wed, 03 Aug 2011 05:03:43 +0200 Subject: Draft Public Code Review Proposal In-Reply-To: <4E1E77DF.8050505@oracle.com> References: <4E1E4A41.1060101@oracle.com> <4E1E77DF.8050505@oracle.com> Message-ID: <4E38BA8F.3020103@oracle.com> On 7/14/11 7:00 AM, David Holmes wrote: > Hi Dalibor, > > On 14/07/2011 11:45 AM, Dalibor Topic wrote: >> Next item on my draft list is code review. The proposal below is inspired by the developer guide section on code review, and in part inspired by the processes in OpenJDK 6. It tries to encourage transparency, and getting more eyes on the code, while at the same time allowing established practices, like asking component leads for additional reviews, to continue to work. >> >> Public code review: >> >> Preamble: The new infrastructure is not ready yet, so we won't switch to it for the next release in OpenJDK (i.e. 7u2, as 7u1 is a CPU) just yet. The process here may change for 7u4. >> >> Pre-requisite: Before asking for code review, make sure your fix is applied on the most recent revision of the code you intend to work on, that there are no build errors on the supported platforms for the release you're working on, and that any included or otherwise applicable tests pass without failures on all relevant platforms. If you're not able to build or test on all supported platforms, you MUST let the reviewers know which ones you were able to build and test on, as well as whether you anticipate any issues on the platforms you haven't been able to build and test on. >> >> Rule 0: Code reviews for public JDK 7 Update forests MUST be done publicly: Either through e-mail on jdk7u-dev at openjdk.java.net mailing list, or using some other suitable public mechanism. If a code review is not done on the jdk7u-dev at openjdk.java.net mailing list, as part of the approval request for inclusion of the fix into a public JDK 7 Updates forest, which you MUST send to the jdk7u-dev at openjdk.java.net mailing list, a URL for the public code review MUST be provided. > > At present who comprises the set of authors, commiters and reviewers for the jdk7u project? The initial set of committers is the set of individuals who have committed code into JDK 7, i.e. the output of for i in . corba/ hotspot/ jaxp jaxws/ jdk/ langtools/ ; do hg -R $i log --template "{author}\n" ; done | sort | uniq on jdk7. The initial set of reviewers is the set of individuals who have reviewed code committed into JDK 7, i.e. are mentioned in a Reviewed-by: line in a commit. I don't have a nice one liner for that yet, though. The initial set of authors is the set of individuals who have submitted code into JDK 7, without having committed it themselves, i.e. the individuals mentioned in Contributed-by lines who are not Committers. Again, no sweet one liner for that either, contributions welcome. The rationale for going with that broad set of individuals is that if you helped create or review changesets for JDK 7, you can now help in the same roles with the updates. >> Rule 1: If the content of a changeset submitted for review for a public JDK 7 Update forest is the same as the corresponding changeset submitted or committed for JDK 8, then it does not have to be resubmitted. In that case its URL will suffice. > > I don't understand what you mean by resubmitted. Do you just mean that we can give the URL to the original JDK8 webrev? Yes. Or the changeset, in case that it has been committed to JDK 8. > I assume review is still necessary. Yes. >> Rule 2: If the content of a changeset submitted for review for a public JDK 7 Update forest differs from the corresponding JDK 8 changeset, or if there is no corresponding JDK 8 changeset, then the changeset MUST be submitted publicly for review: >> >> * A very small changeset MAY be submitted as a simple patch, as described in http://openjdk.java.net/contribute/ >> >> * Other than that, changesets SHOULD be submitted as webrevs on the code review server, cr.openjdk.java.net. >> >> * Alternatively, a URL for the webrev of the changeset MAY be provided >> >> Rule 3: A changeset submitted for the JDK 7 Update mainline forest (jdk7u) MUST be reviewed by at least one reviewer. The maintainer responsible for approval of the changeset MAY request additional, specific reviewers to review the changeset, e. g. component leads. >> >> Rule 4: A changeset submitted for a JDK 7 Update release forest (like jdk7u2, once it's branched off) MUST be reviewed by at least two reviewers. The maintainer responsible for approval of the changeset MAY request additional, specific reviewers to review the changeset, e. g. component leads. > > So I don't understand how rules 3 and 4 interact. Let's assume that jdk7u exists and we haven't yet forked off jdk7u2. I have a fix that must be in 7u2 so I push to the jdk7u-dev repo. According to the above this requires a single reviewer. When 7u2 repos are created I assume they will contain the current contains of 7u mainline - is that right? Yes. Is it after that point that commits to 7u2 require two reviews (presumably because by that stage we anticipate 7u2 is fairly close and so we need to be extra careful when doing commits)? Yes. > > I assume that the approval of the Project and Technical leads are in addition to reviews themselves. Yes. > What is the process for obtaining approval? Send an e-mail to jdk7u-dev at openjdk, with Subject: Request for approval for CR $NR With the body containing a) a link to the publicly visible bug on the bugs.sun.com site (or its equivalent), or a description of the change in case no publicly visible bug is here b) a link to the publicly visible webrev or changeset (in case it's in JDK 8 already) c) if the review is taking place somewhere else, a link to the public review thread d) if the fix has already been reviewed for inclusion into jdk7u-dev, the list of reviewers e) once we branch off 7u2, you'll also need to add the forest the fix is targeted for > I would expect that approval, in principle at least, for a given CR needs to be given upfront, and then again once the final code change is ready. I think that approval up front + code review should be sufficient. That may change for phase 2 of a release. > What are the expectations and limitations on placing things into an update release? Proposed changes for the OpenJDK jdk7u-dev forest should fit into one of the following buckets: * Regressions from 7 GA * Significant issues raised through OpenJDK or otherwise * Fixes for crashes, hangs, corruption etc. * Fixes required to make new JDK 7 functionality usable * Low risk fixes with automated regression tests * Approved requirements for a specific Oracle release > FYI I have a fix (7039182) that is in 8 and needs to be in 7u2 and I'd like to move on this asap, so don't mind being the initial tester of the new process, as it were. Sorry for the delay, and thanks for volunteering. Edvard will be your host while I'm away. ;) cheers, dalibor topic -- Oracle Dalibor Topic | Java F/OSS Ambassador Phone: +494023646738 | Mobile: +491772664192 Oracle Java Platform Group ORACLE Deutschland B.V. & Co. KG | Nagelsweg 55 | 20097 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: J?rgen Kunz, Marcel van de Molen, Alexander van der Ven Green Oracle Oracle is committed to developing practices and products that help protect the environment From dalibor.topic at oracle.com Tue Aug 2 20:09:03 2011 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Wed, 03 Aug 2011 05:09:03 +0200 Subject: Draft Public Code Review Proposal In-Reply-To: <20110714215038.GF32334@rivendell.middle-earth.co.uk> References: <4E1E4A41.1060101@oracle.com> <20110714215038.GF32334@rivendell.middle-earth.co.uk> Message-ID: <4E38BBCF.80302@oracle.com> On 7/14/11 11:50 PM, Dr Andrew John Hughes wrote: > On 03:45 Thu 14 Jul , Dalibor Topic wrote: > >> Next item on my draft list is code review. The proposal below is > inspired by the developer guide section on code review, and in part > inspired by the processes in OpenJDK 6. It tries to encourage > transparency, and getting more eyes on the code, while at the same > time allowing established practices, like asking component leads for > additional reviews, to continue to work. > >> Public code review: > >> Preamble: The new infrastructure is not ready yet, so we won't >> switch to it for the next release in OpenJDK (i.e. 7u2, as 7u1 is a >> CPU) just yet. The process here may change for 7u4. > > What is this 'CPU'? You refer to it both here and in the last > document, but I assume it's not Central Processing Unit. > >> Pre-requisite: Before asking for code review, make sure your fix is > applied on the most recent revision of the code you intend to work > on, that there are no build errors on the supported platforms for > the release you're working on, and that any included or otherwise > applicable tests pass without failures on all relevant platforms. If > you're not able to build or test on all supported platforms, you > MUST let the reviewers know which ones you were able to build and > test on, as well as whether you anticipate any issues on the > platforms you haven't been able to build and test on. >> > > These rules are very stringent. I doubt anyone outside Oracle is going > to be able to build and test on all platforms. Running the full test suite > on any platform is non-trivial and something that should be provided by > mainline infrastructure, not something every developer has to set up. Yeah, I agree - that's why there is the escape hatch of letting the reviewers know that you couldn't run it on some platforms. >> Rule 0: Code reviews for public JDK 7 Update forests MUST be done >> publicly: Either through e-mail on jdk7u-dev at openjdk.java.net >> mailing list, or using some other suitable public mechanism. If a >> code review is not done on the jdk7u-dev at openjdk.java.net mailing >> list, as part of the approval request for inclusion of the fix into >> a public JDK 7 Updates forest, which you MUST send to the >> jdk7u-dev at openjdk.java.net mailing list, a URL for the public code >> review MUST be provided. > >> Rule 1: If the content of a changeset submitted for review for a >> public JDK 7 Update forest is the same as the corresponding >> changeset submitted or committed for JDK 8, then it does not have to >> be resubmitted. In that case its URL will suffice. > >> Rule 2: If the content of a changeset submitted for review for a public JDK 7 Update forest differs from the corresponding JDK 8 changeset, or if there is no corresponding JDK 8 changeset, then the changeset MUST be submitted publicly for review: >> >> * A very small changeset MAY be submitted as a simple patch, as described in http://openjdk.java.net/contribute/ >> >> * Other than that, changesets SHOULD be submitted as webrevs on the code review server, cr.openjdk.java.net. >> >> * Alternatively, a URL for the webrev of the changeset MAY be provided >> > > What is the reasoning behind continuing to use webrevs? They separate the patch > from the discussion and there seems to be no guarantee that they won't just disappear, > as they aren't archived with the mails. It's the currently ubiquitous low level option available to anyone inside and outside Oracle. When we move on to use another/a real code review system, then I expect the code review rules to be rewritten to take it into account. cheers, dalibor topic -- Oracle Dalibor Topic | Java F/OSS Ambassador Phone: +494023646738 | Mobile: +491772664192 Oracle Java Platform Group ORACLE Deutschland B.V. & Co. KG | Nagelsweg 55 | 20097 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: J?rgen Kunz, Marcel van de Molen, Alexander van der Ven Green Oracle Oracle is committed to developing practices and products that help protect the environment From dalibor.topic at oracle.com Tue Aug 2 20:09:47 2011 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Wed, 03 Aug 2011 05:09:47 +0200 Subject: Draft Public Code Review Proposal In-Reply-To: <4E24DDFF.1090300@oracle.COM> References: <4E1E4A41.1060101@oracle.com> <4E24DDFF.1090300@oracle.COM> Message-ID: <4E38BBFB.2080001@oracle.com> On 7/19/11 3:29 AM, Kumar Srinivasan wrote: > Hi Dalibor, Kelly, > > I take it once all this solidifies, there will be a recipe of the steps, posted on > http://openjdk.java.net/projects/jdk7u/ ? Yes. cheers, dalibor topic > > > Thanks > Kumar > > >> On Jul 13, 2011, at 6:45 PM, Dalibor Topic wrote: >> >>> Next item on my draft list is code review. The proposal below is inspired by the developer guide section on code review, and in part inspired by the processes in OpenJDK 6. It tries to encourage transparency, and getting more eyes on the code, while at the same time allowing established practices, like asking component leads for additional reviews, to continue to work. >>> >>> Public code review: >>> >>> Preamble: The new infrastructure is not ready yet, so we won't switch to it for the next release in OpenJDK (i.e. 7u2, as 7u1 is a CPU) just yet. The process here may change for 7u4. >>> >>> Pre-requisite: Before asking for code review, make sure your fix is applied on the most recent revision of the code you intend to work on, that there are no build errors on the supported platforms for the release you're working on, and that any included or otherwise applicable tests pass without failures on all relevant platforms. If you're not able to build or test on all supported platforms, you MUST let the reviewers know which ones you were able to build and test on, as well as whether you anticipate any issues on the platforms you haven't been able to build and test on. >>> >>> Rule 0: Code reviews for public JDK 7 Update forests MUST be done publicly: Either through e-mail on jdk7u-dev at openjdk.java.net mailing list, or using some other suitable public mechanism. If a code review is not done on the jdk7u-dev at openjdk.java.net mailing list, as part of the approval request for inclusion of the fix into a public JDK 7 Updates forest, which you MUST send to the jdk7u-dev at openjdk.java.net mailing list, a URL for the public code review MUST be provided. >> I'm having problems parsing the above sentences. Is it just me? >> I think I understand what it's basically saying though. >> >>> Rule 1: If the content of a changeset submitted for review for a public JDK 7 Update forest is the same as the corresponding changeset submitted or committed for JDK 8, then it does not have to be resubmitted. In that case its URL will suffice. >> I have a little issue with this. If it's in jdk8, then you can't just pull the exact same changeset into jdk7u, >> you can import the same patch and create a new changeset with the same patch, but the patch will be likely >> applied to different sources, so it's questionable in my mind that it can be called 'the same'. >> Perhaps the words 'same patch' here? >> >>> Rule 2: If the content of a changeset submitted for review for a public JDK 7 Update forest differs from the corresponding JDK 8 changeset, or if there is no corresponding JDK 8 changeset, then the changeset MUST be submitted publicly for review: >>> >>> * A very small changeset MAY be submitted as a simple patch, as described in http://openjdk.java.net/contribute/ >>> >>> * Other than that, changesets SHOULD be submitted as webrevs on the code review server, cr.openjdk.java.net. >>> >>> * Alternatively, a URL for the webrev of the changeset MAY be provided >>> >>> Rule 3: A changeset submitted for the JDK 7 Update mainline forest (jdk7u) MUST be reviewed by at least one reviewer. The maintainer responsible for approval of the changeset MAY request additional, specific reviewers to review the changeset, e. g. component leads. >>> >>> Rule 4: A changeset submitted for a JDK 7 Update release forest (like jdk7u2, once it's branched off) MUST be reviewed by at least two reviewers. The maintainer responsible for approval of the changeset MAY request additional, specific reviewers to review the changeset, e. g. component leads. >> Should we require that all changesets applied to the jdk7uN forests, also be applied to the jdk7u forest? >> >> -kto >> >>> cheers, >>> dalibor topic >>> -- >>> Oracle >>> Dalibor Topic | Java F/OSS Ambassador >>> Phone: +494023646738 | Mobile: +491772664192 >>> Oracle Java Platform Group >>> >>> ORACLE Deutschland B.V.& Co. KG | Nagelsweg 55 | 20097 Hamburg >>> >>> ORACLE Deutschland B.V.& Co. KG >>> Hauptverwaltung: Riesstr. 25, D-80992 M?nchen >>> Registergericht: Amtsgericht M?nchen, HRA 95603 >>> >>> Komplement?rin: ORACLE Deutschland Verwaltung B.V. >>> Hertogswetering 163/167, 3543 AS Utrecht, Niederlande >>> Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 >>> Gesch?ftsf?hrer: J?rgen Kunz, Marcel van de Molen, Alexander van der Ven >>> >>> Green Oracle Oracle is committed to developing practices and products that help protect the environment > -- Oracle Dalibor Topic | Java F/OSS Ambassador Phone: +494023646738 | Mobile: +491772664192 Oracle Java Platform Group ORACLE Deutschland B.V. & Co. KG | Nagelsweg 55 | 20097 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: J?rgen Kunz, Marcel van de Molen, Alexander van der Ven Green Oracle Oracle is committed to developing practices and products that help protect the environment From dalibor.topic at oracle.com Tue Aug 2 20:15:27 2011 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Wed, 03 Aug 2011 05:15:27 +0200 Subject: Draft Public Code Review Proposal In-Reply-To: References: <4E1E4A41.1060101@oracle.com> Message-ID: <4E38BD4F.9080702@oracle.com> On 7/15/11 12:55 AM, Kelly O'Hair wrote: > > On Jul 13, 2011, at 6:45 PM, Dalibor Topic wrote: > >> Next item on my draft list is code review. The proposal below is inspired by the developer guide section on code review, and in part inspired by the processes in OpenJDK 6. It tries to encourage transparency, and getting more eyes on the code, while at the same time allowing established practices, like asking component leads for additional reviews, to continue to work. >> >> Public code review: >> >> Preamble: The new infrastructure is not ready yet, so we won't switch to it for the next release in OpenJDK (i.e. 7u2, as 7u1 is a CPU) just yet. The process here may change for 7u4. >> >> Pre-requisite: Before asking for code review, make sure your fix is applied on the most recent revision of the code you intend to work on, that there are no build errors on the supported platforms for the release you're working on, and that any included or otherwise applicable tests pass without failures on all relevant platforms. If you're not able to build or test on all supported platforms, you MUST let the reviewers know which ones you were able to build and test on, as well as whether you anticipate any issues on the platforms you haven't been able to build and test on. >> >> Rule 0: Code reviews for public JDK 7 Update forests MUST be done publicly: Either through e-mail on jdk7u-dev at openjdk.java.net mailing list, or using some other suitable public mechanism. If a code review is not done on the jdk7u-dev at openjdk.java.net mailing list, as part of the approval request for inclusion of the fix into a public JDK 7 Updates forest, which you MUST send to the jdk7u-dev at openjdk.java.net mailing list, a URL for the public code review MUST be provided. > > I'm having problems parsing the above sentences. Is it just me? > > I think I understand what it's basically saying though. OK. Let me know if you can think of a better wording. >> Rule 1: If the content of a changeset submitted for review for a public JDK 7 Update forest is the same as the corresponding changeset submitted or committed for JDK 8, then it does not have to be resubmitted. In that case its URL will suffice. > > I have a little issue with this. If it's in jdk8, then you can't just pull the exact same changeset into jdk7u, > you can import the same patch and create a new changeset with the same patch, but the patch will be likely > applied to different sources, so it's questionable in my mind that it can be called 'the same'. > Perhaps the words 'same patch' here? Sounds good - thanks! >> >> Rule 2: If the content of a changeset submitted for review for a public JDK 7 Update forest differs from the corresponding JDK 8 changeset, or if there is no corresponding JDK 8 changeset, then the changeset MUST be submitted publicly for review: >> >> * A very small changeset MAY be submitted as a simple patch, as described in http://openjdk.java.net/contribute/ >> >> * Other than that, changesets SHOULD be submitted as webrevs on the code review server, cr.openjdk.java.net. >> >> * Alternatively, a URL for the webrev of the changeset MAY be provided >> >> Rule 3: A changeset submitted for the JDK 7 Update mainline forest (jdk7u) MUST be reviewed by at least one reviewer. The maintainer responsible for approval of the changeset MAY request additional, specific reviewers to review the changeset, e. g. component leads. >> >> Rule 4: A changeset submitted for a JDK 7 Update release forest (like jdk7u2, once it's branched off) MUST be reviewed by at least two reviewers. The maintainer responsible for approval of the changeset MAY request additional, specific reviewers to review the changeset, e. g. component leads. > > Should we require that all changesets applied to the jdk7uN forests, also be applied to the jdk7u forest? Not as part of a code review process, but it would make sense to put into a phase 2 process document. cheers, dalibor topic -- Oracle Dalibor Topic | Java F/OSS Ambassador Phone: +494023646738 | Mobile: +491772664192 Oracle Java Platform Group ORACLE Deutschland B.V. & Co. KG | Nagelsweg 55 | 20097 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: J?rgen Kunz, Marcel van de Molen, Alexander van der Ven Green Oracle Oracle is committed to developing practices and products that help protect the environment From dalibor.topic at oracle.com Tue Aug 2 20:38:50 2011 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Wed, 03 Aug 2011 05:38:50 +0200 Subject: Draft Public Code Review Proposal In-Reply-To: <4E1E4A41.1060101@oracle.com> References: <4E1E4A41.1060101@oracle.com> Message-ID: <4E38C2CA.5020608@oracle.com> On 7/14/11 3:45 AM, Dalibor Topic wrote: > Next item on my draft list is code review. thanks for the feedback, everyone - I posted the updated version on the Project's web site. cheers, dalibor topic -- Oracle Dalibor Topic | Java F/OSS Ambassador Phone: +494023646738 | Mobile: +491772664192 Oracle Java Platform Group ORACLE Deutschland B.V. & Co. KG | Nagelsweg 55 | 20097 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: J?rgen Kunz, Marcel van de Molen, Alexander van der Ven Green Oracle Oracle is committed to developing practices and products that help protect the environment From dalibor.topic at oracle.com Tue Aug 2 20:46:18 2011 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Wed, 03 Aug 2011 05:46:18 +0200 Subject: Draft Repository Management In-Reply-To: <4E388F8B.8030001@oracle.com> References: <4E1E3778.7000206@oracle.com> <4E3088D2.50605@oracle.com> <4E324BA3.9060208@oracle.com> <4E388A2A.3060500@oracle.com> <4E388F8B.8030001@oracle.com> Message-ID: <4E38C48A.2000901@oracle.com> On 8/3/11 2:00 AM, Jim Holmlund wrote: > > > On 8/2/2011 4:37 PM, Dalibor Topic wrote: >> On 7/29/11 7:56 AM, Poonam Bajaj wrote: >>> Hi Dalibor, >>> >>> On the Repository Management page (http://openjdk.java.net/projects/jdk7u/repos.html), the location of 7u integration forest is mentioned. >>> >>> " >>> *Rule 2* >>> >>> jdk7u-dev - Integration - always-open mainline forest. Integration schedule is TBD, and will be published on the Project's web page. The push rights to the integration forest are available to current JDK 7 Committers. >>> >>> The OpenJDK JDK 7 Updates integation forest is located at http://hg.openjdk.java.net/jdk7u/jdk7u-dev/. >>> " >>> >>> But the location http://hg.openjdk.java.net/jdk7u/jdk7u-dev/ is not accessible. Is it correct or the forest has not been created yet ? >> The forest wasn't created yet, but it has been created now (thanks, John!). >> > Great! Let the games begin, eh? Yes! We're open for fixes now. > Ground rule 3 here > http://openjdk.java.net/projects/jdk7u/groundrules.html > says that changes going into a 7u forest must be approved by the maintainer of that forest. Who is the maintainer for jdk7u/jdk7u-dev? Per my mail at http://mail.openjdk.java.net/pipermail/jdk7u-dev/2011-August/000061.html - Edvard is it. > Do we just send this person an email requesting approval, and containing a link to the webrev, or to the changeset in JDK8 if it is the same change, eg: > http://hg.openjdk.java.net/jdk8/tl/langtools/rev/e427c42e1a7e > ? I suppose this email should be cc'd to jdk7u-dev, and should contain the names of the reviewers too? Yes. See http://mail.openjdk.java.net/pipermail/jdk7u-dev/2011-August/000063.html for a description, and the suggested format for the approval mails. cheers, dalibor topic -- Oracle Dalibor Topic | Java F/OSS Ambassador Phone: +494023646738 | Mobile: +491772664192 Oracle Java Platform Group ORACLE Deutschland B.V. & Co. KG | Nagelsweg 55 | 20097 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: J?rgen Kunz, Marcel van de Molen, Alexander van der Ven Green Oracle Oracle is committed to developing practices and products that help protect the environment From dalibor.topic at oracle.com Tue Aug 2 21:34:14 2011 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Wed, 03 Aug 2011 06:34:14 +0200 Subject: Questions on Ground Rules In-Reply-To: <4E32ED58.6080202@oracle.com> References: <4E32ED58.6080202@oracle.com> Message-ID: <4E38CFC6.7040100@oracle.com> On 7/29/11 7:26 PM, Jim Holmlund wrote: > Hi Dalibor, a few questions > - If there is an intent that a change destined for both 7u and 8 be pushed into 8 first, how long must one wait after pushing to 8 before pushing to 7u: > - not specified - the push to 7u could be done immediately after the push to 8 After thinking a bit about it with Edvard and Roger, I think that's a fine default option, with exceptions to be specified by the approver. cheers, dalibor topic -- Oracle Dalibor Topic | Java F/OSS Ambassador Phone: +494023646738 | Mobile: +491772664192 Oracle Java Platform Group ORACLE Deutschland B.V. & Co. KG | Nagelsweg 55 | 20097 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: J?rgen Kunz, Marcel van de Molen, Alexander van der Ven Green Oracle Oracle is committed to developing practices and products that help protect the environment From erik.trimble at oracle.com Tue Aug 2 22:24:10 2011 From: erik.trimble at oracle.com (Erik Trimble) Date: Tue, 02 Aug 2011 22:24:10 -0700 Subject: Questions on Ground Rules In-Reply-To: <4E38CFC6.7040100@oracle.com> References: <4E32ED58.6080202@oracle.com> <4E38CFC6.7040100@oracle.com> Message-ID: <4E38DB7A.1050506@oracle.com> On 8/2/2011 9:34 PM, Dalibor Topic wrote: > On 7/29/11 7:26 PM, Jim Holmlund wrote: >> Hi Dalibor, a few questions >> - If there is an intent that a change destined for both 7u and 8 be pushed into 8 first, how long must one wait after pushing to 8 before pushing to 7u: >> - not specified - the push to 7u could be done immediately after the push to 8 > > After thinking a bit about it with Edvard and Roger, I think that's a fine default option, > with exceptions to be specified by the approver. > > cheers, > dalibor topic > Unless otherwise indicated as a critical path, I'd *strongly* suggest that any fix intended for both 7u and 8 be allowed to AT THE VERY LEAST pass a Nightly testing run in 8, before being pushed into 7u. Just to be cautious, I'd actually say that waiting for a full jdk8 promotion to occur before pushing into 7u is not unreasonable. -- Erik Trimble Java Platform Group Infrastructure Mailstop: usca22-317 Phone: x67195 Santa Clara, CA Timezone: US/Pacific (UTC-0800) From poonam.bajaj at oracle.com Tue Aug 2 23:28:55 2011 From: poonam.bajaj at oracle.com (Poonam Bajaj) Date: Wed, 03 Aug 2011 11:58:55 +0530 Subject: Draft Public Code Review Proposal In-Reply-To: <4E38BA8F.3020103@oracle.com> References: <4E1E4A41.1060101@oracle.com> <4E1E77DF.8050505@oracle.com> <4E38BA8F.3020103@oracle.com> Message-ID: <4E38EAA7.1030208@oracle.com> Hi Dalibor, On 8/3/2011 8:33 AM, Dalibor Topic wrote: > On 7/14/11 7:00 AM, David Holmes wrote: > >> Hi Dalibor, >> >> On 14/07/2011 11:45 AM, Dalibor Topic wrote: >> >>> Next item on my draft list is code review. The proposal below is inspired by the developer guide section on code review, and in part inspired by the processes in OpenJDK 6. It tries to encourage transparency, and getting more eyes on the code, while at the same time allowing established practices, like asking component leads for additional reviews, to continue to work. >>> >>> Public code review: >>> >>> Preamble: The new infrastructure is not ready yet, so we won't switch to it for the next release in OpenJDK (i.e. 7u2, as 7u1 is a CPU) just yet. The process here may change for 7u4. >>> >>> Pre-requisite: Before asking for code review, make sure your fix is applied on the most recent revision of the code you intend to work on, that there are no build errors on the supported platforms for the release you're working on, and that any included or otherwise applicable tests pass without failures on all relevant platforms. If you're not able to build or test on all supported platforms, you MUST let the reviewers know which ones you were able to build and test on, as well as whether you anticipate any issues on the platforms you haven't been able to build and test on. >>> >>> Rule 0: Code reviews for public JDK 7 Update forests MUST be done publicly: Either through e-mail on jdk7u-dev at openjdk.java.net mailing list, or using some other suitable public mechanism. If a code review is not done on the jdk7u-dev at openjdk.java.net mailing list, as part of the approval request for inclusion of the fix into a public JDK 7 Updates forest, which you MUST send to the jdk7u-dev at openjdk.java.net mailing list, a URL for the public code review MUST be provided. >>> >> At present who comprises the set of authors, commiters and reviewers for the jdk7u project? >> > > The initial set of committers is the set of individuals who have committed code into JDK 7, > i.e. the output of > > for i in . corba/ hotspot/ jaxp jaxws/ jdk/ langtools/ ; do hg -R $i log --template "{author}\n" ; done | sort | uniq > > on jdk7. > > The initial set of reviewers is the set of individuals who have reviewed code committed into JDK 7, i.e. are mentioned in a Reviewed-by: line in a commit. > I don't have a nice one liner for that yet, though. > > The initial set of authors is the set of individuals who have submitted code into JDK 7, without having committed it themselves, > i.e. the individuals mentioned in Contributed-by lines who are not Committers. Again, no sweet one liner for that either, > contributions welcome. > > The rationale for going with that broad set of individuals is that if you helped create or review changesets for JDK 7, you can now > help in the same roles with the updates. > > Can we have a page listing the names of authors, commiters and reviewers for jdk7u project ? Thanks, Poonam >>> Rule 1: If the content of a changeset submitted for review for a public JDK 7 Update forest is the same as the corresponding changeset submitted or committed for JDK 8, then it does not have to be resubmitted. In that case its URL will suffice. >>> >> I don't understand what you mean by resubmitted. Do you just mean that we can give the URL to the original JDK8 webrev? >> > > Yes. Or the changeset, in case that it has been committed to JDK 8. > > >> I assume review is still necessary. >> > > Yes. > > >>> Rule 2: If the content of a changeset submitted for review for a public JDK 7 Update forest differs from the corresponding JDK 8 changeset, or if there is no corresponding JDK 8 changeset, then the changeset MUST be submitted publicly for review: >>> >>> * A very small changeset MAY be submitted as a simple patch, as described in http://openjdk.java.net/contribute/ >>> >>> * Other than that, changesets SHOULD be submitted as webrevs on the code review server, cr.openjdk.java.net. >>> >>> * Alternatively, a URL for the webrev of the changeset MAY be provided >>> >>> Rule 3: A changeset submitted for the JDK 7 Update mainline forest (jdk7u) MUST be reviewed by at least one reviewer. The maintainer responsible for approval of the changeset MAY request additional, specific reviewers to review the changeset, e. g. component leads. >>> >>> Rule 4: A changeset submitted for a JDK 7 Update release forest (like jdk7u2, once it's branched off) MUST be reviewed by at least two reviewers. The maintainer responsible for approval of the changeset MAY request additional, specific reviewers to review the changeset, e. g. component leads. >>> >> So I don't understand how rules 3 and 4 interact. Let's assume that jdk7u exists and we haven't yet forked off jdk7u2. I have a fix that must be in 7u2 so I push to the jdk7u-dev repo. According to the above this requires a single reviewer. When 7u2 repos are created I assume they will contain the current contains of 7u mainline - is that right? >> > > Yes. > > Is it after that point that commits to 7u2 require two reviews (presumably because by that stage we anticipate 7u2 is fairly close and so we need to be extra careful when doing commits)? > > Yes. > > >> I assume that the approval of the Project and Technical leads are in addition to reviews themselves. >> > > Yes. > > >> What is the process for obtaining approval? >> > > Send an e-mail to jdk7u-dev at openjdk, with > > Subject: Request for approval for CR $NR > > With the body containing > > a) a link to the publicly visible bug on the bugs.sun.com site (or its equivalent), or a description of the change in case no publicly visible bug is here > b) a link to the publicly visible webrev or changeset (in case it's in JDK 8 already) > c) if the review is taking place somewhere else, a link to the public review thread > d) if the fix has already been reviewed for inclusion into jdk7u-dev, the list of reviewers > e) once we branch off 7u2, you'll also need to add the forest the fix is targeted for > > >> I would expect that approval, in principle at least, for a given CR needs to be given upfront, and then again once the final code change is ready. >> > > I think that approval up front + code review should be sufficient. That may change for phase 2 of a release. > > >> What are the expectations and limitations on placing things into an update release? >> > > Proposed changes for the OpenJDK jdk7u-dev forest should fit into one of the following buckets: > > * Regressions from 7 GA > * Significant issues raised through OpenJDK or otherwise > * Fixes for crashes, hangs, corruption etc. > * Fixes required to make new JDK 7 functionality usable > * Low risk fixes with automated regression tests > * Approved requirements for a specific Oracle release > > >> FYI I have a fix (7039182) that is in 8 and needs to be in 7u2 and I'd like to move on this asap, so don't mind being the initial tester of the new process, as it were. >> > > Sorry for the delay, and thanks for volunteering. Edvard will be your host while I'm away. ;) > > cheers, > dalibor topic > From David.Holmes at oracle.com Wed Aug 3 00:05:26 2011 From: David.Holmes at oracle.com (David Holmes) Date: Wed, 03 Aug 2011 17:05:26 +1000 Subject: Draft Public Code Review Proposal In-Reply-To: <4E38BA8F.3020103@oracle.com> References: <4E1E4A41.1060101@oracle.com> <4E1E77DF.8050505@oracle.com> <4E38BA8F.3020103@oracle.com> Message-ID: <4E38F336.1050908@oracle.com> Hi Dalibor, Dalibor Topic said the following on 08/03/11 13:03: > On 7/14/11 7:00 AM, David Holmes wrote: >> What is the process for obtaining approval? > > Send an e-mail to jdk7u-dev at openjdk, with > > Subject: Request for approval for CR $NR > > With the body containing > > a) a link to the publicly visible bug on the bugs.sun.com site (or its equivalent), or a description of the change in case no publicly visible bug is here > b) a link to the publicly visible webrev or changeset (in case it's in JDK 8 already) > c) if the review is taking place somewhere else, a link to the public review thread > d) if the fix has already been reviewed for inclusion into jdk7u-dev, the list of reviewers > e) once we branch off 7u2, you'll also need to add the forest the fix is targeted for > >> I would expect that approval, in principle at least, for a given CR needs to be given upfront, and then again once the final code change is ready. > > I think that approval up front + code review should be sufficient. That may change for phase 2 of a release. There is a risk with upfront approval and single-reviewer reviews that a change will be committed before being scrutinized by all the right people. (This is migitigated somewhat by the requirement that most changes must be in JDK8 first). Now we want upfront approval-in-principle so that we don't work on CRs that won't meet the criteria for inclusion in an update release, so I'd always seek approval first. But there's no timeline in the review rules to ensure that reviews are open for a minimum amount of time before the change is pushed. One way to fix this is to enforce a minimum review time (say 3 days?); the other is to require a final approval where the approver can insert a delay if they think more time is needed for review feedback to come in. The latter is more work for the approver of course. A combined approach would be a minimum review period with the ability to request an expedited push if needed. >> FYI I have a fix (7039182) that is in 8 and needs to be in 7u2 and I'd like to move on this asap, so don't mind being the initial tester of the new process, as it were. > > Sorry for the delay, and thanks for volunteering. Edvard will be your host while I'm away. ;) I must have missed the announcement that jdk7u/jdk7u-dev was open for business :) I will commence proceedings immediately. Cheers, David > cheers, > dalibor topic From edvard.wendelin at oracle.com Wed Aug 3 00:30:02 2011 From: edvard.wendelin at oracle.com (Edvard Wendelin) Date: Wed, 3 Aug 2011 09:30:02 +0200 Subject: Draft Public Code Review Proposal In-Reply-To: <4E38F336.1050908@oracle.com> References: <4E1E4A41.1060101@oracle.com> <4E1E77DF.8050505@oracle.com> <4E38BA8F.3020103@oracle.com> <4E38F336.1050908@oracle.com> Message-ID: Hi, On 3 aug 2011, at 09.05, David Holmes wrote: > Hi Dalibor, > > Dalibor Topic said the following on 08/03/11 13:03: >> On 7/14/11 7:00 AM, David Holmes wrote: >>> What is the process for obtaining approval? >> Send an e-mail to jdk7u-dev at openjdk, with >> Subject: Request for approval for CR $NR >> With the body containing a) a link to the publicly visible bug on >> the bugs.sun.com site (or its equivalent), or a description of the >> change in case no publicly visible bug is here >> b) a link to the publicly visible webrev or changeset (in case it's >> in JDK 8 already) >> c) if the review is taking place somewhere else, a link to the >> public review thread >> d) if the fix has already been reviewed for inclusion into jdk7u- >> dev, the list of reviewers >> e) once we branch off 7u2, you'll also need to add the forest the >> fix is targeted for >>> I would expect that approval, in principle at least, for a given >>> CR needs to be given upfront, and then again once the final code >>> change is ready. >> I think that approval up front + code review should be sufficient. >> That may change for phase 2 of a release. > > There is a risk with upfront approval and single-reviewer reviews > that a change will be committed before being scrutinized by all the > right people. (This is migitigated somewhat by the requirement that > most changes must be in JDK8 first). Now we want upfront approval-in- > principle so that we don't work on CRs that won't meet the criteria > for inclusion in an update release, so I'd always seek approval > first. But there's no timeline in the review rules to ensure that > reviews are open for a minimum amount of time before the change is > pushed. One way to fix this is to enforce a minimum review time (say > 3 days?); the other is to require a final approval where the > approver can insert a delay if they think more time is needed for > review feedback to come in. The latter is more work for the approver > of course. A combined approach would be a minimum review period with > the ability to request an expedited push if needed. I'd be happy to delay pushes for a few days or have two approvals if that's what people want :) If it turns out that code gets pushed without having been reviewed properly, we can take a more strict approach as we go forward. It's always a delicate balance between adding to much overhead and being to liberal. I think we'll have to accept that and fine-tune the process over the coming weeks and months. > >>> FYI I have a fix (7039182) that is in 8 and needs to be in 7u2 and >>> I'd like to move on this asap, so don't mind being the initial >>> tester of the new process, as it were. >> Sorry for the delay, and thanks for volunteering. Edvard will be >> your host while I'm away. ;) > > I must have missed the announcement that jdk7u/jdk7u-dev was open > for business :) I will commence proceedings immediately. Feel free :) Cheers, Edvard > > Cheers, > David > >> cheers, >> dalibor topic From weijun.wang at oracle.com Wed Aug 3 04:07:55 2011 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 03 Aug 2011 19:07:55 +0800 Subject: Push request: 7043737: klist does not detect non-existing keytab Message-ID: <4E392C0B.2040102@oracle.com> Hi All This is a request to backport a jdk8 fix into jdk7u2 b02. CR: 7043737: klist does not detect non-existing keytab Weblink: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7043737 Description: In JDK7 we support "dynamic" Kerberos keytabs so that a keytab can be empty or missing when app starts. Unfortunately, the ktab tool also reports no error or warning when keytab is missing. This behavior is different from old JDK and ktab tools from other vendors. The fix brings the old behavior back. The fix is already included in jdk8 as: Changeset: 9b678733fa51 Author: weijun Date: 2011-06-08 14:01 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9b678733fa51 7043737: klist does not detect non-existing keytab Reviewed-by: valeriep The patch for jdk7u2 is identical to the one in jdk8. I intend to push it to ssh://hg.openjdk.java.net/jdk7u/jdk7u-dev-gate/jdk Thanks Weijun From edvard.wendelin at oracle.com Wed Aug 3 05:17:06 2011 From: edvard.wendelin at oracle.com (Edvard Wendelin) Date: Wed, 3 Aug 2011 15:17:06 +0300 Subject: Push request: 7043737: klist does not detect non-existing keytab In-Reply-To: <4E392C0B.2040102@oracle.com> References: <4E392C0B.2040102@oracle.com> Message-ID: Approved! Please let me know if you run into any issues! Cheers, Edvard 3 aug 2011 kl. 14:07 skrev Weijun Wang : > Hi All > > This is a request to backport a jdk8 fix into jdk7u2 b02. > > CR: 7043737: klist does not detect non-existing keytab > Weblink: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7043737 > > Description: > > In JDK7 we support "dynamic" Kerberos keytabs so that a keytab can be > empty or missing when app starts. Unfortunately, the ktab tool also > reports no error or warning when keytab is missing. This behavior is > different from old JDK and ktab tools from other vendors. The fix brings > the old behavior back. > > The fix is already included in jdk8 as: > > Changeset: 9b678733fa51 > Author: weijun > Date: 2011-06-08 14:01 +0800 > URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9b678733fa51 > > 7043737: klist does not detect non-existing keytab > Reviewed-by: valeriep > > The patch for jdk7u2 is identical to the one in jdk8. > > I intend to push it to > > ssh://hg.openjdk.java.net/jdk7u/jdk7u-dev-gate/jdk > > Thanks > Weijun From weijun.wang at oracle.com Wed Aug 3 06:33:33 2011 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Wed, 03 Aug 2011 13:33:33 +0000 Subject: hg: jdk7u/jdk7u-dev/jdk: 7043737: klist does not detect non-existing keytab Message-ID: <20110803133344.85DFC478FA@hg.openjdk.java.net> Changeset: f01230bea4aa Author: weijun Date: 2011-08-03 21:32 +0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/jdk/rev/f01230bea4aa 7043737: klist does not detect non-existing keytab Reviewed-by: valeriep ! src/windows/classes/sun/security/krb5/internal/tools/Klist.java + test/sun/security/krb5/tools/ktmissing.sh From david.buck at oracle.com Wed Aug 3 07:35:23 2011 From: david.buck at oracle.com (David Buck) Date: Wed, 03 Aug 2011 23:35:23 +0900 Subject: Push request: 7029903 Splash screen is not shown in 64-bit Linux with 16-bit color depth Message-ID: <4E395CAB.3010802@oracle.com> Hi! This is a request to backport a jdk8 fix into jdk7u2. CR:7029903 Splash screen is not shown in 64-bit Linux with 16-bit color depth Weblink: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=2208636 (for some reason, the URL for the parent bug is not working. Sub CR (I believe that 2208636 will have all needed information.) Description: On X11, if image data for splash screen is small enough, it can remain in the Xlib client buffer until the JVM starts up and starts updating the GUI. I added an explicit call to Xflush() immediately after the splash screen image is updated. This is a regression introduced by the fix for cr6557810. The fix is already included in jdk8 as: Changeset: f7dd470d3794 Author: dbuck Date: Wed Aug 03 07:04:34 2011 -0700 URL: http://hg.openjdk.java.net/jdk8/swing/jdk/rev/f7dd470d3794 7029903: Splash screen is not shown in 64-bit Linux with 16-bit color depth Summary: Added Xflush() call after splash screen is updated to ensure update is no stuck in client side buffer until JVM starts up. See JET review request 4154 for details. Reviewed-by: kevinw, anthony Original jdk code review was done with JET (inernal Oracle code review tool. Will use correct review procedure from now on.). The patch for jdk7u2 is identical to the one in jdk8. Cheers, -Buck From david.buck at oracle.com Wed Aug 3 07:45:22 2011 From: david.buck at oracle.com (David Buck) Date: Wed, 03 Aug 2011 23:45:22 +0900 Subject: Push request: 7029903 Splash screen is not shown in 64-bit Linux with 16-bit color depth In-Reply-To: <4E395CAB.3010802@oracle.com> References: <4E395CAB.3010802@oracle.com> Message-ID: <4E395F02.7090209@oracle.com> I'm sure the webrev will make the change easier to review... http://cr.openjdk.java.net/~dbuck/7029903/webrev.01/ Sorry, not sure how I managed to forget the most important part of my request. Regards, -Buck On 08/03/11 23:35, David Buck wrote: > Hi! > > This is a request to backport a jdk8 fix into jdk7u2. > > CR:7029903 Splash screen is not shown in 64-bit Linux with 16-bit color > depth > > Weblink: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=2208636 > (for some reason, the URL for the parent bug is not working. Sub CR (I > believe that 2208636 will have all needed information.) > > Description: > On X11, if image data for splash screen is small enough, it can > remain in the Xlib client buffer until the JVM starts up and starts > updating the GUI. I added an explicit call to Xflush() immediately > after the splash screen image is updated. > > This is a regression introduced by the fix for cr6557810. > > > The fix is already included in jdk8 as: > > Changeset: f7dd470d3794 > Author: dbuck > Date: Wed Aug 03 07:04:34 2011 -0700 > URL: http://hg.openjdk.java.net/jdk8/swing/jdk/rev/f7dd470d3794 > > 7029903: Splash screen is not shown in 64-bit Linux with 16-bit color depth > Summary: Added Xflush() call after splash screen is updated to ensure > update is no stuck in client side buffer until JVM starts up. See JET > review request 4154 for details. > Reviewed-by: kevinw, anthony > > Original jdk code review was done with JET (inernal Oracle code review > tool. Will use correct review procedure from now on.). > > The patch for jdk7u2 is identical to the one in jdk8. > > Cheers, > -Buck From edvard.wendelin at oracle.com Wed Aug 3 07:56:22 2011 From: edvard.wendelin at oracle.com (Edvard Wendelin) Date: Wed, 3 Aug 2011 17:56:22 +0300 Subject: Push request: 7029903 Splash screen is not shown in 64-bit Linux with 16-bit color depth In-Reply-To: <4E395CAB.3010802@oracle.com> References: <4E395CAB.3010802@oracle.com> Message-ID: <1ECCC44B-80C0-43D1-80C7-6AC825C9AB35@oracle.com> Approved. Use hg.openjdk.java.net/jdk7u/jdk7u-dev-gate for the push. Let me know if you run into any problems. Cheers, Edvard Skickat fr?n min iPhone 3 aug 2011 kl. 17:35 skrev David Buck : > Hi! > > This is a request to backport a jdk8 fix into jdk7u2. > > CR:7029903 Splash screen is not shown in 64-bit Linux with 16-bit color depth > > Weblink: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=2208636 > (for some reason, the URL for the parent bug is not working. Sub CR (I believe that 2208636 will have all needed information.) > > Description: > On X11, if image data for splash screen is small enough, it can > remain in the Xlib client buffer until the JVM starts up and starts > updating the GUI. I added an explicit call to Xflush() immediately > after the splash screen image is updated. > > This is a regression introduced by the fix for cr6557810. > > > The fix is already included in jdk8 as: > > Changeset: f7dd470d3794 > Author: dbuck > Date: Wed Aug 03 07:04:34 2011 -0700 > URL: http://hg.openjdk.java.net/jdk8/swing/jdk/rev/f7dd470d3794 > > 7029903: Splash screen is not shown in 64-bit Linux with 16-bit color depth > Summary: Added Xflush() call after splash screen is updated to ensure update is no stuck in client side buffer until JVM starts up. See JET review request 4154 for details. > Reviewed-by: kevinw, anthony > > Original jdk code review was done with JET (inernal Oracle code review tool. Will use correct review procedure from now on.). > > The patch for jdk7u2 is identical to the one in jdk8. > > Cheers, > -Buck From david.buck at oracle.com Wed Aug 3 21:08:49 2011 From: david.buck at oracle.com (david.buck at oracle.com) Date: Thu, 04 Aug 2011 04:08:49 +0000 Subject: hg: jdk7u/jdk7u-dev/jdk: 7029903: Splash screen is not shown in 64-bit Linux with 16-bit color depth Message-ID: <20110804040858.E8ADC4791C@hg.openjdk.java.net> Changeset: 9847e43556fb Author: dbuck Date: 2011-08-03 21:06 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/jdk/rev/9847e43556fb 7029903: Splash screen is not shown in 64-bit Linux with 16-bit color depth Summary: Added Xflush() call after splash screen is updated to ensure update is no stuck in client side buffer until JVM starts up. See JET review request 4154 for details. Reviewed-by: kevinw, anthony ! src/solaris/native/sun/awt/splashscreen/splashscreen_sys.c From david.buck at oracle.com Thu Aug 4 05:02:23 2011 From: david.buck at oracle.com (David Buck) Date: Thu, 04 Aug 2011 21:02:23 +0900 Subject: Code Review Request : 7011591 JDWP socket transport should restart interrupted system calls (EINTR) Message-ID: <4E3A8A4F.60609@oracle.com> Hi! I would like to request that my fix for 7011591 be reviewed for push into JDK8 (and JDK7u if possible). CR: 7011591 JDWP socket transport should restart interrupted system calls (EINTR) Weblink: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=2205030 (for some reason, the public URL for the parent bug is not working. (I believe that SubCR 2205030 will have all needed information.) Webrev: http://cr.openjdk.java.net/~dbuck/7011591/webrev.00/ Description: Syscalls that can be interrupted by signal handling should automatically retry if they fail with EINTR. Unfortunately, the JDWP socket transport implementation does not do this. Since HotSpot does not use signals for thread suspension, HotSpot customers have not run into any problem (as far as I know). But because JRockit R27 and earlier releases use signals to suspend threads, all threads are constantly being interrupted thus JRockit customers are much more likely (almost guaranteed under some circumstances) to have system calls interrupted by signal handling. I have added a loop to automatically retry send(), recv(), sendto(), recvfrom(), accept(), and poll() calls if the call fails with EINTR. Note that I do not believe that the UDP versions of the calls (recvfrom() and sendto()) are actualy ever used in the JDK, but I fixed them in case they are used in the future. The implementation for connect() was more complicated because Solaris does not let us just call connect() again after EINTR. Once a call to connect() fails with EINTR on Solaris, the connection setup continues asynchronously and we need to use select() or poll() to determine when the socket can be used. The patch for jdk7u2 is identical to this (jdk8) fix, if possible, I would like to receive pre-approval to push to jdk7u-dev repository as well. This fix has already been done for 1.4.2/5/6 as part of the JRockit Simplification Project. This needs to be forward ported into 7 and 8 to avoid a regression. Best Regards, -Buck From kumar.x.srinivasan at oracle.COM Thu Aug 4 07:26:33 2011 From: kumar.x.srinivasan at oracle.COM (Kumar Srinivasan) Date: Thu, 04 Aug 2011 07:26:33 -0700 Subject: Request for push: 7062969 Message-ID: <4E3AAC19.7020607@oracle.COM> Hi, Request push approval for CR: 7062969 For some reason this does not appear on bugs.sun.com, so here is the description: Description: Java version: 1.7.0-b146 Problems: In the command line, if you do "java -help", you will see: "See http://java.sun.com/javase/reference for more details." at the end of the output. Should that sun.com be changed into Oracle.com? It already redirects http://www.oracle.com/technetwork/java/index.html but I think if the javadoc or java -help should also show above url as well in the command. File this bug to make sure the mentioned Sun.com url is changed to Oracle.com The webrev can be found here: http://cr.openjdk.java.net/~ksrini/7062969/webrev/ The changeset can be found here: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c0c983ca797b The review was dicussed/reviewed on corelibs-dev at openjdk.java.net The patch is identical to the jdk8 changeset. Thanks Kumar From kumar.x.srinivasan at oracle.COM Thu Aug 4 07:43:39 2011 From: kumar.x.srinivasan at oracle.COM (Kumar Srinivasan) Date: Thu, 04 Aug 2011 07:43:39 -0700 Subject: Request push 7067922 for 7u2 Message-ID: <4E3AB01B.2050708@oracle.COM> Hi, Request push to 7u2. CR Bug description : If you create a jar file WITHOUT a ?Main-Class? manifest field, and you try to run it by java ?jar xxx.jar using Java 7 b147, you get this: Exception in thread "main" java.lang.NullPointerException at sun.launcher.LauncherHelper.getMainClassFromJar(LauncherHelper.java:399) at sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:463) However if you do the same thing in Java 6, you get this: Failed to load Main-Class manifest attribute from stringbenchmarkmissingmainclass.jar Review discussion: http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-July/007165.html Webrev: http://cr.openjdk.java.net/~ksrini/7067922/webrev.0/ Changeset: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d17eb3380a49 Thanks Kumar From kumar.x.srinivasan at oracle.COM Thu Aug 4 07:58:59 2011 From: kumar.x.srinivasan at oracle.COM (Kumar Srinivasan) Date: Thu, 04 Aug 2011 07:58:59 -0700 Subject: Request for push: 7062969 In-Reply-To: <4E3AB30F.6040605@oracle.com> References: <4E3AAC19.7020607@oracle.COM> <4E3AB30F.6040605@oracle.com> Message-ID: <4E3AB3B3.8050600@oracle.COM> Hi Roger, > > The bug is visible: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7062969 > It was likely not visible yesterday and was made visible in this > mornings bugs.sun.com update. > > There was a problem with the update process between bugs.sun.com and > Bugtraq over the weekend and a number of bugs were removed. Since then > nightly process has been catching up and most of the bugs that were > removed are now visible once again. The rest should be take care of > early tomorrow morning. 7062969 had been visible up until Saturday and > then as affected by the update problem. > > Also, one thing to take in mind is that the search engine can take 1 > -2 days to spider bugs.sun.com. So if you have the bug ID, it is best > to enter the ID in the URL > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id= or you can > go to bugs.sun.com and enter the ID in the 'Bug ID' field. Thanks Roger, Jim Holmlund and I were wondering about this yesterday. Kumar > > Thank you, > Roger > > > On 8/4/11 7:26 AM, Kumar Srinivasan wrote: >> Hi, >> >> Request push approval for CR: 7062969 >> For some reason this does not appear on bugs.sun.com, so here is the >> description: >> >> Description: >> Java version: >> 1.7.0-b146 >> >> Problems: >> In the command line, if you do "java -help", you will see: >> "See http://java.sun.com/javase/reference for more details." at the >> end of the output. >> >> Should that sun.com be changed into Oracle.com? >> It already redirects http://www.oracle.com/technetwork/java/index.html >> but I think if the javadoc or java -help should also show above url >> as well in the command. >> >> File this bug to make sure the mentioned Sun.com url is changed to >> Oracle.com >> >> >> The webrev can be found here: >> http://cr.openjdk.java.net/~ksrini/7062969/webrev/ >> >> The changeset can be found here: >> http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c0c983ca797b >> >> The review was dicussed/reviewed on corelibs-dev at openjdk.java.net >> The patch is identical to the jdk8 changeset. >> >> Thanks >> Kumar >> >> From edvard.wendelin at oracle.com Thu Aug 4 08:03:33 2011 From: edvard.wendelin at oracle.com (Edvard Wendelin) Date: Thu, 4 Aug 2011 18:03:33 +0300 Subject: Request for push: 7062969 In-Reply-To: <4E3AAC19.7020607@oracle.COM> References: <4E3AAC19.7020607@oracle.COM> Message-ID: Approved. Use the gate for jdk7u/jdk7u-dev/ Let me know if you run into any issues! Cheers, Edvard Skickat fr?n min iPhone 4 aug 2011 kl. 17:26 skrev Kumar Srinivasan : > Hi, > > Request push approval for CR: 7062969 > For some reason this does not appear on bugs.sun.com, so here is the description: > > Description: > Java version: > 1.7.0-b146 > > Problems: > In the command line, if you do "java -help", you will see: > "See http://java.sun.com/javase/reference for more details." at the end of the output. > > Should that sun.com be changed into Oracle.com? > It already redirects http://www.oracle.com/technetwork/java/index.html > but I think if the javadoc or java -help should also show above url as well in the command. > > File this bug to make sure the mentioned Sun.com url is changed to Oracle.com > > > The webrev can be found here: > http://cr.openjdk.java.net/~ksrini/7062969/webrev/ > > The changeset can be found here: > http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c0c983ca797b > > The review was dicussed/reviewed on corelibs-dev at openjdk.java.net > The patch is identical to the jdk8 changeset. > > Thanks > Kumar > > From edvard.wendelin at oracle.com Thu Aug 4 08:10:50 2011 From: edvard.wendelin at oracle.com (Edvard Wendelin) Date: Thu, 4 Aug 2011 18:10:50 +0300 Subject: Request push 7067922 for 7u2 In-Reply-To: <4E3AB01B.2050708@oracle.COM> References: <4E3AB01B.2050708@oracle.COM> Message-ID: <125A4F4D-A834-4C78-9857-98837FBF6CE4@oracle.com> Approved! Cheers, Edvard Skickat fr?n min iPhone 4 aug 2011 kl. 17:43 skrev Kumar Srinivasan : > Hi, > > Request push to 7u2. > > CR Bug description : > > If you create a jar file WITHOUT a ?Main-Class? manifest field, and you try to run it by java ?jar xxx.jar using Java 7 b147, you get this: > > Exception in thread "main" java.lang.NullPointerException > at sun.launcher.LauncherHelper.getMainClassFromJar(LauncherHelper.java:399) > at sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:463) > > However if you do the same thing in Java 6, you get this: > Failed to load Main-Class manifest attribute from > stringbenchmarkmissingmainclass.jar > > > > > Review discussion: > http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-July/007165.html > > Webrev: > http://cr.openjdk.java.net/~ksrini/7067922/webrev.0/ > > Changeset: > http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d17eb3380a49 > > > Thanks > Kumar > > From kumar.x.srinivasan at oracle.COM Thu Aug 4 08:32:14 2011 From: kumar.x.srinivasan at oracle.COM (Kumar Srinivasan) Date: Thu, 04 Aug 2011 08:32:14 -0700 Subject: Request for push: 7062969 In-Reply-To: References: <4E3AAC19.7020607@oracle.COM> Message-ID: <4E3ABB7E.8040706@oracle.COM> Hi Edvard, Thanks for the approvals...... > Approved. > > Use the gate for jdk7u/jdk7u-dev/ this is what I get when I do a hg out. % hg out comparing with ssh://hg.openjdk.java.net/jdk7u/jdk7u-gate/jdk this is not quite the same as what you are suggesting ie. the jdk repo. name (sub-tree repo), this always has the invariant name "jdk", afaict. Am I missing something ? Kumar > * > * > Let me know if you run into any issues! > > Cheers, > Edvard > > Skickat fr?n min iPhone > > 4 aug 2011 kl. 17:26 skrev Kumar Srinivasan > >: > >> Hi, >> >> Request push approval for CR: 7062969 >> For some reason this does not appear on bugs.sun.com >> , so here is the description: >> >> Description: >> Java version: >> 1.7.0-b146 >> >> Problems: >> In the command line, if you do "java -help", you will see: >> "See http://java.sun.com/javase/reference for more details." at the >> end of the output. >> >> Should that sun.com be changed into Oracle.com >> ? >> It already redirects http://www.oracle.com/technetwork/java/index.html >> but I think if the javadoc or java -help should also show above url >> as well in the command. >> >> File this bug to make sure the mentioned Sun.com url >> is changed to Oracle.com >> >> >> The webrev can be found here: >> http://cr.openjdk.java.net/~ksrini/7062969/webrev/ >> >> >> The changeset can be found here: >> http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c0c983ca797b >> >> The review was dicussed/reviewed on corelibs-dev at openjdk.java.net >> >> The patch is identical to the jdk8 changeset. >> >> Thanks >> Kumar >> >> From shrode at subnature.com Thu Aug 4 08:43:35 2011 From: shrode at subnature.com (Jason Schroeder) Date: Thu, 4 Aug 2011 09:43:35 -0600 Subject: Newbie getting involved - compile error Message-ID: I have followed the directions, and here is the relevant history. Is this a legitimate build error? Or do the instructions need to be improved? hg clone http://hg.openjdk.java.net/jdk7/tl mytl cd mytl/ sh ./get_source.sh ALT_BOOTDIR=/usr/lib/jvm/java-6-openjdk . ./jdk/make/jdk_generic_profile.sh ALT_BOOTDIR=/usr/lib/jvm/java-6-openjdk make sanity ALT_BOOTDIR=/usr/lib/jvm/java-6-openjdk make all BUILD FAILED /home/shrode/jdk7/mytl/jaxp/build-defs.xml:70: ERROR: Cannot find source for project jaxp. HINT: Try setting drops.dir to indicate where the bundles can be found, or try setting the ant property allow.downloads=true to download the bundle from the URL. e.g. ant -Dallow.downloads=true -OR- ant -Ddrops.dir=some_directory From daniel.daugherty at oracle.com Thu Aug 4 08:45:09 2011 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 04 Aug 2011 09:45:09 -0600 Subject: Request for push: 7062969 In-Reply-To: <4E3ABB7E.8040706@oracle.COM> References: <4E3AAC19.7020607@oracle.COM> <4E3ABB7E.8040706@oracle.COM> Message-ID: <4E3ABE85.2000806@oracle.com> I think that's the gate for jdk7u/jdk7u ... which would be the one that the integrator pushes to and not Joe Developer... Dan On 8/4/11 9:32 AM, Kumar Srinivasan wrote: > Hi Edvard, > > Thanks for the approvals...... > >> Approved. >> >> Use the gate for jdk7u/jdk7u-dev/ > > this is what I get when I do a hg out. > > % hg out > comparing with ssh://hg.openjdk.java.net/jdk7u/jdk7u-gate/jdk > > this is not quite the same as what you are suggesting ie. the jdk > repo. name > (sub-tree repo), this always has the invariant name "jdk", afaict. > > Am I missing something ? > > Kumar > > >> * >> * >> Let me know if you run into any issues! >> >> Cheers, >> Edvard >> >> Skickat fr?n min iPhone >> >> 4 aug 2011 kl. 17:26 skrev Kumar Srinivasan >> >: >> >>> Hi, >>> >>> Request push approval for CR: 7062969 >>> For some reason this does not appear on bugs.sun.com >>> , so here is the description: >>> >>> Description: >>> Java version: >>> 1.7.0-b146 >>> >>> Problems: >>> In the command line, if you do "java -help", you will see: >>> "See http://java.sun.com/javase/reference for more details." at the >>> end of the output. >>> >>> Should that sun.com be changed into Oracle.com >>> ? >>> It already redirects http://www.oracle.com/technetwork/java/index.html >>> but I think if the javadoc or java -help should also show above url >>> as well in the command. >>> >>> File this bug to make sure the mentioned Sun.com >>> url is changed to Oracle.com >>> >>> >>> The webrev can be found here: >>> http://cr.openjdk.java.net/~ksrini/7062969/webrev/ >>> >>> >>> The changeset can be found here: >>> http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c0c983ca797b >>> >>> The review was dicussed/reviewed on corelibs-dev at openjdk.java.net >>> >>> The patch is identical to the jdk8 changeset. >>> >>> Thanks >>> Kumar >>> >>> > From Alan.Bateman at oracle.com Thu Aug 4 08:50:38 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 04 Aug 2011 16:50:38 +0100 Subject: Code Review Request : 7011591 JDWP socket transport should restart interrupted system calls (EINTR) In-Reply-To: <4E3A8A4F.60609@oracle.com> References: <4E3A8A4F.60609@oracle.com> Message-ID: <4E3ABFCE.3070408@oracle.com> David Buck wrote: > Hi! > > I would like to request that my fix for 7011591 be reviewed for push > into JDK8 (and JDK7u if possible). > > CR: 7011591 JDWP socket transport should restart interrupted system > calls (EINTR) > : > > Webrev: http://cr.openjdk.java.net/~dbuck/7011591/webrev.00/ I've added serviceability-dev to the CC list as that is where the debugger code is. I looked at the webrev and it mostly looks okay to me. One issue is that dbgsysPoll probably should adjust the timeout when interrupted. A minor nit is that you've changed the copyright date on the file from 1998 to 1997. -Alan. From daniel.daugherty at oracle.com Thu Aug 4 09:19:10 2011 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 04 Aug 2011 10:19:10 -0600 Subject: Code Review Request : 7011591 JDWP socket transport should restart interrupted system calls (EINTR) In-Reply-To: <4E3ABFCE.3070408@oracle.com> References: <4E3A8A4F.60609@oracle.com> <4E3ABFCE.3070408@oracle.com> Message-ID: <4E3AC67E.7080208@oracle.com> On 8/4/11 9:50 AM, Alan Bateman wrote: > David Buck wrote: >> Hi! >> >> I would like to request that my fix for 7011591 be reviewed for push >> into JDK8 (and JDK7u if possible). >> >> CR: 7011591 JDWP socket transport should restart interrupted system >> calls (EINTR) >> : >> >> Webrev: http://cr.openjdk.java.net/~dbuck/7011591/webrev.00/ > I've added serviceability-dev to the CC list as that is where the > debugger code is. Alan, thanks for adding in serviceability-dev... Thumbs up from me since this matches my earlier reviews. > I looked at the webrev and it mostly looks okay to me. One issue is > that dbgsysPoll probably should adjust the timeout when interrupted. Adjust it how? (Just curious) > A minor nit is that you've changed the copyright date on the file from > 1998 to 1997. Don't know how I missed that with the earlier reviews, but the Teamware history shows that the earliest date for this file is indeed in 1998 and not 1997: $ sccs prs -r1.1 src/solaris/transport/socket/socket_md.c src/solaris/transport/socket/SCCS/s.socket_md.c: D 1.1 98/11/21 21:20:56 gordonh 1 0 00149/00000/00000 MRs: COMMENTS: Dan From erik.trimble at oracle.com Thu Aug 4 09:39:38 2011 From: erik.trimble at oracle.com (Erik Trimble) Date: Thu, 04 Aug 2011 09:39:38 -0700 Subject: Request for push: 7062969 In-Reply-To: <4E3ABB7E.8040706@oracle.COM> References: <4E3AAC19.7020607@oracle.COM> <4E3ABB7E.8040706@oracle.COM> Message-ID: <1312475978.1843.5.camel@ghostbox> On Thu, 2011-08-04 at 08:32 -0700, Kumar Srinivasan wrote: > Hi Edvard, > > Thanks for the approvals...... > > > Approved. > > > > Use the gate for jdk7u/jdk7u-dev/ > > this is what I get when I do a hg out. > > % hg out > comparing with ssh://hg.openjdk.java.net/jdk7u/jdk7u-gate/jdk > > this is not quite the same as what you are suggesting ie. the jdk repo. name > (sub-tree repo), this always has the invariant name "jdk", afaict. > > Am I missing something ? > > Kumar > No, Edvard was just giving the general root for the entire integration forest, not the just the 'jdk' repo. You need to push to: ssh://hg.openjdk.java.net/jdk7u/jdk7u-dev-gate/jdk That is, you need to run: hg fdefpath -u -g -v -s http://closedjdk.us.oracle.com/jdk7u/jdk7u-dev/jdk http://hg.openjdk.java.net/jdk7u/jdk7u-dev/jdk inside your jdk repository. Only the integrators and RE should ever be pushing directory to the jdk7u/jdk7u/* repositories. -Erik > > > * > > * > > Let me know if you run into any issues! > > > > Cheers, > > Edvard > > > > Skickat fr?n min iPhone > > > > 4 aug 2011 kl. 17:26 skrev Kumar Srinivasan > > >: > > > >> Hi, > >> > >> Request push approval for CR: 7062969 > >> For some reason this does not appear on bugs.sun.com > >> , so here is the description: > >> > >> Description: > >> Java version: > >> 1.7.0-b146 > >> > >> Problems: > >> In the command line, if you do "java -help", you will see: > >> "See http://java.sun.com/javase/reference for more details." at the > >> end of the output. > >> > >> Should that sun.com be changed into Oracle.com > >> ? > >> It already redirects http://www.oracle.com/technetwork/java/index.html > >> but I think if the javadoc or java -help should also show above url > >> as well in the command. > >> > >> File this bug to make sure the mentioned Sun.com url > >> is changed to Oracle.com > >> > >> > >> The webrev can be found here: > >> http://cr.openjdk.java.net/~ksrini/7062969/webrev/ > >> > >> > >> The changeset can be found here: > >> http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c0c983ca797b > >> > >> The review was dicussed/reviewed on corelibs-dev at openjdk.java.net > >> > >> The patch is identical to the jdk8 changeset. > >> > >> Thanks > >> Kumar > >> > >> > -- Erik Trimble Java Platform Group - Infrastructure Mailstop: usca22-317 Phone: x67195 Santa Clara, CA Timezone: US/Pacific (UTC-0800) From kumar.x.srinivasan at oracle.COM Thu Aug 4 09:41:39 2011 From: kumar.x.srinivasan at oracle.COM (Kumar Srinivasan) Date: Thu, 04 Aug 2011 09:41:39 -0700 Subject: Request for push: 7062969 In-Reply-To: <1312475978.1843.5.camel@ghostbox> References: <4E3AAC19.7020607@oracle.COM> <4E3ABB7E.8040706@oracle.COM> <1312475978.1843.5.camel@ghostbox> Message-ID: <4E3ACBC3.5040600@oracle.COM> Hi Erik, Got it. Thanks Kumar > On Thu, 2011-08-04 at 08:32 -0700, Kumar Srinivasan wrote: >> Hi Edvard, >> >> Thanks for the approvals...... >> >>> Approved. >>> >>> Use the gate for jdk7u/jdk7u-dev/ >> this is what I get when I do a hg out. >> >> % hg out >> comparing with ssh://hg.openjdk.java.net/jdk7u/jdk7u-gate/jdk >> >> this is not quite the same as what you are suggesting ie. the jdk repo. name >> (sub-tree repo), this always has the invariant name "jdk", afaict. >> >> Am I missing something ? >> >> Kumar >> > No, Edvard was just giving the general root for the entire integration > forest, not the just the 'jdk' repo. > > You need to push to: > > ssh://hg.openjdk.java.net/jdk7u/jdk7u-dev-gate/jdk > > > That is, you need to run: > > hg fdefpath -u -g -v -s > http://closedjdk.us.oracle.com/jdk7u/jdk7u-dev/jdk > http://hg.openjdk.java.net/jdk7u/jdk7u-dev/jdk > > > inside your jdk repository. > > > > Only the integrators and RE should ever be pushing directory to the > jdk7u/jdk7u/* repositories. > > -Erik > > >>> * >>> * >>> Let me know if you run into any issues! >>> >>> Cheers, >>> Edvard >>> >>> Skickat fr?n min iPhone >>> >>> 4 aug 2011 kl. 17:26 skrev Kumar Srinivasan >>> >: >>> >>>> Hi, >>>> >>>> Request push approval for CR: 7062969 >>>> For some reason this does not appear on bugs.sun.com >>>> , so here is the description: >>>> >>>> Description: >>>> Java version: >>>> 1.7.0-b146 >>>> >>>> Problems: >>>> In the command line, if you do "java -help", you will see: >>>> "See http://java.sun.com/javase/reference for more details." at the >>>> end of the output. >>>> >>>> Should that sun.com be changed into Oracle.com >>>> ? >>>> It already redirects http://www.oracle.com/technetwork/java/index.html >>>> but I think if the javadoc or java -help should also show above url >>>> as well in the command. >>>> >>>> File this bug to make sure the mentioned Sun.com url >>>> is changed to Oracle.com >>>> >>>> >>>> The webrev can be found here: >>>> http://cr.openjdk.java.net/~ksrini/7062969/webrev/ >>>> >>>> >>>> The changeset can be found here: >>>> http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c0c983ca797b >>>> >>>> The review was dicussed/reviewed on corelibs-dev at openjdk.java.net >>>> >>>> The patch is identical to the jdk8 changeset. >>>> >>>> Thanks >>>> Kumar >>>> >>>> From david.buck at oracle.com Thu Aug 4 09:45:53 2011 From: david.buck at oracle.com (David Buck) Date: Thu, 4 Aug 2011 09:45:53 -0700 (PDT) Subject: Code Review Request : 7011591 JDWP socket transport should restart interrupted system calls (EINTR) In-Reply-To: <4E3AC67E.7080208@oracle.com> References: <4E3A8A4F.60609@oracle.com> <4E3ABFCE.3070408@oracle.com 4E3AC67E.7080208@oracle.com> Message-ID: <29d02ec2-8274-41b9-a607-b0fc1453eef5@default> Hi The technical issues will need to be looked at tomorrow as I need sleep, but just one thing: > > A minor nit is that you've changed the copyright date on the file from >> 1998 to 1997. > > Don't know how I missed that with the earlier reviews, but the > Teamware history shows that the earliest date for this file > is indeed in 1998 and not 1997: > > $ sccs prs -r1.1 src/solaris/transport/socket/socket_md.c > src/solaris/transport/socket/SCCS/s.socket_md.c: > > D 1.1 98/11/21 21:20:56 gordonh 1 0 00149/00000/00000 > MRs: > COMMENTS: Not sure where I got the 1997 from, it's been a while since I did this change in 1.4.2/5/6. But I probably tried to find the earliest version of the file on Sean Coffey's opengrok server. Unfortunately, I think they are moving the lab today and the server looks like it is down, so I can't try to retrace my steps. I just tried to manually find the oldest version of this file on Kevin Walls LXR server, and I came up with an even older date! http://cheesypoof.uk.oracle.com/lxr2/source/j2sdk1.3.1/ext/jpda/src/solaris/transport/socket/socket_md.c?v=Java_1.3.1 === 002 * @(#)socket_md.c 1.6 00/02/02 003 * 004 * Copyright 1995-2000 Sun Microsystems, Inc. All Rights Reserved. 005 * 006 * This software is the proprietary information of Sun Microsystems, Inc. 007 * Use is subject to license terms. 008 * 009 */ === This really begs the question: what standard (if any) do we use to try to determine the beginning copyright date for a given file? Regards, -Buck -----Original Message----- From: Daniel D. Daugherty Sent: Friday, August 05, 2011 1:19 AM Cc: David Buck; serviceability-dev at openjdk.java.net; jdk7u-dev at openjdk.java.net; java_sustaining; core-libs-dev at openjdk.java.net Subject: Re: Code Review Request : 7011591 JDWP socket transport should restart interrupted system calls (EINTR) On 8/4/11 9:50 AM, Alan Bateman wrote: > David Buck wrote: >> Hi! >> >> I would like to request that my fix for 7011591 be reviewed for push >> into JDK8 (and JDK7u if possible). >> >> CR: 7011591 JDWP socket transport should restart interrupted system >> calls (EINTR) >> : >> >> Webrev: http://cr.openjdk.java.net/~dbuck/7011591/webrev.00/ > I've added serviceability-dev to the CC list as that is where the > debugger code is. Alan, thanks for adding in serviceability-dev... Thumbs up from me since this matches my earlier reviews. > I looked at the webrev and it mostly looks okay to me. One issue is > that dbgsysPoll probably should adjust the timeout when interrupted. Adjust it how? (Just curious) > A minor nit is that you've changed the copyright date on the file from > 1998 to 1997. Don't know how I missed that with the earlier reviews, but the Teamware history shows that the earliest date for this file is indeed in 1998 and not 1997: $ sccs prs -r1.1 src/solaris/transport/socket/socket_md.c src/solaris/transport/socket/SCCS/s.socket_md.c: D 1.1 98/11/21 21:20:56 gordonh 1 0 00149/00000/00000 MRs: COMMENTS: Dan From edvard.wendelin at oracle.com Thu Aug 4 10:48:31 2011 From: edvard.wendelin at oracle.com (Edvard Wendelin) Date: Thu, 4 Aug 2011 19:48:31 +0200 Subject: Newbie getting involved - compile error In-Reply-To: References: Message-ID: Hi, You will probably want to set export ANT_OPTS="-Dallow.downloads=true" before typing make. I'll see if I can get someone to update the guide. Good luck! Cheers, Edvard On 4 aug 2011, at 17.43, Jason Schroeder wrote: > I have followed the directions, and here is the relevant history. > Is this a legitimate build error? Or do the instructions need to be > improved? > > hg clone http://hg.openjdk.java.net/jdk7/tl mytl > cd mytl/ > sh ./get_source.sh > ALT_BOOTDIR=/usr/lib/jvm/java-6-openjdk . ./jdk/make/ > jdk_generic_profile.sh > ALT_BOOTDIR=/usr/lib/jvm/java-6-openjdk make sanity > > > > ALT_BOOTDIR=/usr/lib/jvm/java-6-openjdk make all > > > > BUILD FAILED > /home/shrode/jdk7/mytl/jaxp/build-defs.xml:70: ERROR: Cannot find > source for project jaxp. > > HINT: Try setting drops.dir to indicate where the bundles can be > found, or try setting the ant property allow.downloads=true to > download the bundle from the URL. > e.g. ant -Dallow.downloads=true -OR- ant -Ddrops.dir=some_directory From edvard.wendelin at oracle.com Thu Aug 4 10:49:29 2011 From: edvard.wendelin at oracle.com (Edvard Wendelin) Date: Thu, 4 Aug 2011 19:49:29 +0200 Subject: Request for push: 7062969 In-Reply-To: <4E3ACBC3.5040600@oracle.COM> References: <4E3AAC19.7020607@oracle.COM> <4E3ABB7E.8040706@oracle.COM> <1312475978.1843.5.camel@ghostbox> <4E3ACBC3.5040600@oracle.COM> Message-ID: <62AB9960-1509-47AD-9195-26E26E38FA49@oracle.com> Sorry for not being clear enough! Cheers, Edvard On 4 aug 2011, at 18.41, Kumar Srinivasan wrote: > Hi Erik, > > Got it. > > Thanks > Kumar > >> On Thu, 2011-08-04 at 08:32 -0700, Kumar Srinivasan wrote: >>> Hi Edvard, >>> >>> Thanks for the approvals...... >>> >>>> Approved. >>>> >>>> Use the gate for jdk7u/jdk7u-dev/ >>> this is what I get when I do a hg out. >>> >>> % hg out >>> comparing with ssh://hg.openjdk.java.net/jdk7u/jdk7u-gate/jdk >>> >>> this is not quite the same as what you are suggesting ie. the jdk >>> repo. name >>> (sub-tree repo), this always has the invariant name "jdk", afaict. >>> >>> Am I missing something ? >>> >>> Kumar >>> >> No, Edvard was just giving the general root for the entire >> integration >> forest, not the just the 'jdk' repo. >> >> You need to push to: >> >> ssh://hg.openjdk.java.net/jdk7u/jdk7u-dev-gate/jdk >> >> >> That is, you need to run: >> >> hg fdefpath -u -g -v -s >> http://closedjdk.us.oracle.com/jdk7u/jdk7u-dev/jdk >> http://hg.openjdk.java.net/jdk7u/jdk7u-dev/jdk >> >> >> inside your jdk repository. >> >> >> >> Only the integrators and RE should ever be pushing directory to the >> jdk7u/jdk7u/* repositories. >> >> -Erik >> >> >>>> * >>>> * >>>> Let me know if you run into any issues! >>>> >>>> Cheers, >>>> Edvard >>>> >>>> Skickat fr?n min iPhone >>>> >>>> 4 aug 2011 kl. 17:26 skrev Kumar Srinivasan >>>> < >>>> kumar >>>> .x.srinivasan at oracle.com>: >>>> >>>>> Hi, >>>>> >>>>> Request push approval for CR: 7062969 >>>>> For some reason this does not appear on bugs.sun.com >>>>> , so here is the description: >>>>> >>>>> Description: >>>>> Java version: >>>>> 1.7.0-b146 >>>>> >>>>> Problems: >>>>> In the command line, if you do "java -help", you will see: >>>>> "See http://java.sun.com/javase/reference for more details." at >>>>> the >>>>> end of the output. >>>>> >>>>> Should that sun.com be changed into Oracle.com >>>>> ? >>>>> It already redirects http://www.oracle.com/technetwork/java/index.html >>>>> but I think if the javadoc or java -help should also show above >>>>> url >>>>> as well in the command. >>>>> >>>>> File this bug to make sure the mentioned Sun.com>>>> Sun.com> url >>>>> is changed to Oracle.com >>>>> >>>>> >>>>> The webrev can be found here: >>>>> http://cr.openjdk.java.net/~ksrini/7062969/webrev/ >>>>> >>>>> >>>>> The changeset can be found here: >>>>> http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c0c983ca797b >>>>> >>>>> The review was dicussed/reviewed on corelibs-dev at openjdk.java.net >>>>> >>>>> The patch is identical to the jdk8 changeset. >>>>> >>>>> Thanks >>>>> Kumar >>>>> >>>>> > From ahughes at redhat.com Thu Aug 4 19:11:16 2011 From: ahughes at redhat.com (Dr Andrew John Hughes) Date: Fri, 5 Aug 2011 03:11:16 +0100 Subject: Request for push: 7062969 In-Reply-To: <4E3AAC19.7020607@oracle.COM> References: <4E3AAC19.7020607@oracle.COM> Message-ID: <20110805021116.GE31431@rivendell.middle-earth.co.uk> On 07:26 Thu 04 Aug , Kumar Srinivasan wrote: > Hi, > > Request push approval for CR: 7062969 > For some reason this does not appear on bugs.sun.com, so here is the > description: > > Description: > Java version: > 1.7.0-b146 > > Problems: > In the command line, if you do "java -help", you will see: > "See http://java.sun.com/javase/reference for more details." at the end > of the output. > > Should that sun.com be changed into Oracle.com? > It already redirects http://www.oracle.com/technetwork/java/index.html > but I think if the javadoc or java -help should also show above url as > well in the command. > > File this bug to make sure the mentioned Sun.com url is changed to > Oracle.com > Is there a way this can be overridden? I'm wondering if other providers of OpenJDK binaries (Red Hat and other GNU/Linux distros, IBM, Apple) would want a different URL here. -- 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: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37 From David.Holmes at oracle.com Thu Aug 4 20:02:38 2011 From: David.Holmes at oracle.com (David Holmes) Date: Fri, 05 Aug 2011 13:02:38 +1000 Subject: Request for review: 7039182 Message-ID: <4E3B5D4E.20102@oracle.com> 7039182 is not a public CR so I'll summarize the issue. When the NIO libs are built there are a few files that contain constants that represent platform specific I/O constants found in various C header files. Normally the build process compiles and runs a small C program which will generate the .java file for that platform. When I integrated the basic support for cross-compilation I modified this process to use the host C compiler not the cross-compiler for the target, as we couldn't execute the resulting C program. That wasn't the correct thing to do because it means we generate values for the build platform not the target platform. Luckily these values are mostly the same on the Linux platforms we care about, but not all the same (hence this bug report where a read system call returned EINVAL because we thought we were passing O_NOFOLLOW but in fact passed O_DIRECT). The simplest fix is to not try to generate a file when cross-compiling but allow the developer to specify where these files can be found. This is done using the NIO_PLATFORM_CLASSES_ROOT_DIR variable which is expected to be the "root" directory for where classes can be found and the directories under that are expected to follow the package hierarchy for the files, so, for example we will look for: $(NIO_PLATFORM_CLASSES_ROOT_DIR)/sun/nio/ch/SocketOptionRegistry-$(PLATFORM)-$(ARCH).java the platform and arch are used in the filename as we don't have platform/arch directories in the JDK repo. In addition I reverted the original change to use the host C compiler as this allows you to specifically build the generator program using the cross-compiler (which will get the right values) then copy it across to the target system and run it to generate the file. --- Here's the webrev against 7u-dev: http://cr.openjdk.java.net/~dholmes/7039182/webrev.u2/ --- Here's the information from the JDK 8 submission: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3abc52f0a4dc 7039182: PPC: NIO: java.io.IOException: Invalid argument in sun.nio.ch.FileDispatcherImpl.read0 author dholmes Mon Jun 27 20:13:48 2011 -0400 (5 weeks ago) changeset 4369 3abc52f0a4dc parent 4368 a053c28304e8 child 4371 585cc4a4528d 7039182: PPC: NIO: java.io.IOException: Invalid argument in sun.nio.ch.FileDispatcherImpl.read0 Summary: Allow platform specific files to be located at build time instead of generating them Reviewed-by: alanb, ohair Thanks, David Holmes From kumar.x.srinivasan at oracle.com Thu Aug 4 20:38:50 2011 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Thu, 4 Aug 2011 20:38:50 -0700 (PDT) Subject: Request for push: 7062969 Message-ID: Hi Andrew, Sure, it can be done by some makeology (if you will) to replace that String during a build, but that would be well beyond the scope of this work. If you can craft such a thing, I will be happy to review it for you. Thanks for your review. Kumar ----- ahughes at redhat.com wrote: > From: ahughes at redhat.com > To: kumar.x.srinivasan at oracle.com > Cc: jdk7u-dev at openjdk.java.net > Sent: Thursday, August 4, 2011 7:11:29 PM GMT -08:00 US/Canada Pacific > Subject: Re: Request for push: 7062969 > > On 07:26 Thu 04 Aug , Kumar Srinivasan wrote: > > Hi, > > > > Request push approval for CR: 7062969 > > For some reason this does not appear on bugs.sun.com, so here is the > > > description: > > > > Description: > > Java version: > > 1.7.0-b146 > > > > Problems: > > In the command line, if you do "java -help", you will see: > > "See http://java.sun.com/javase/reference for more details." at the > end > > of the output. > > > > Should that sun.com be changed into Oracle.com? > > It already redirects > http://www.oracle.com/technetwork/java/index.html > > but I think if the javadoc or java -help should also show above url > as > > well in the command. > > > > File this bug to make sure the mentioned Sun.com url is changed to > > Oracle.com > > > > Is there a way this can be overridden? I'm wondering if other > providers > of OpenJDK binaries (Red Hat and other GNU/Linux distros, IBM, Apple) > would want a different URL here. > -- > 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: F5862A37 (https://keys.indymedia.org/) > Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37 From weijun.wang at oracle.com Thu Aug 4 23:50:10 2011 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 05 Aug 2011 14:50:10 +0800 Subject: Push request: 7061379: [Kerberos] Cross-realm authentication fails, due to nameType problem Message-ID: <4E3B92A2.1060806@oracle.com> Hi All This is a request to backport a jdk8 fix into jdk7u2 b02. CR: 7061379: [Kerberos] Cross-realm authentication fails, due to nameType problem Weblink: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7061379 Description: A Kerberos PrincipalName is defined as PrincipalName ::= SEQUENCE { name-type [0] Int32, name-string [1] SEQUENCE OF KerberosString } and RFC 4120 6.2 says -- The name-type field that is part of the principal name indicates the kind of information implied by the name. The name-type SHOULD be treated only as a hint to interpreting the meaning of a name. It is not significant when checking for equivalence. However, in Java's PrincipalName.equals(), we do check for equality of both the name-type and name-string. This led to a failure in customer's working environment. The fix is already included in jdk8 as: Changeset: e68db408d08c Author: weijun Date: 2011-08-04 18:18 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e68db408d08c 7061379: [Kerberos] Cross-realm authentication fails, due to nameType problem Reviewed-by: valeriep The patch for jdk7u2 is identical to the one in jdk8. Thanks Weijun From kelly.ohair at oracle.com Fri Aug 5 00:15:36 2011 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Fri, 5 Aug 2011 09:15:36 +0200 Subject: Newbie getting involved - compile error In-Reply-To: References: Message-ID: <77462E94-FDCB-4D23-BFA3-65E7ECFDFC36@oracle.com> See http://hg.openjdk.java.net/jdk7/build/raw-file/tip/README-builds.html#drops -kto On Aug 4, 2011, at 7:48 PM, Edvard Wendelin wrote: > Hi, > > You will probably want to set export ANT_OPTS="-Dallow.downloads=true" before typing make. I'll see if I can get someone to update the guide. > > Good luck! > > Cheers, > Edvard > > > On 4 aug 2011, at 17.43, Jason Schroeder wrote: > >> I have followed the directions, and here is the relevant history. >> Is this a legitimate build error? Or do the instructions need to be improved? >> >> hg clone http://hg.openjdk.java.net/jdk7/tl mytl >> cd mytl/ >> sh ./get_source.sh >> ALT_BOOTDIR=/usr/lib/jvm/java-6-openjdk . ./jdk/make/jdk_generic_profile.sh >> ALT_BOOTDIR=/usr/lib/jvm/java-6-openjdk make sanity >> >> >> >> ALT_BOOTDIR=/usr/lib/jvm/java-6-openjdk make all >> >> >> >> BUILD FAILED >> /home/shrode/jdk7/mytl/jaxp/build-defs.xml:70: ERROR: Cannot find >> source for project jaxp. >> >> HINT: Try setting drops.dir to indicate where the bundles can be >> found, or try setting the ant property allow.downloads=true to >> download the bundle from the URL. >> e.g. ant -Dallow.downloads=true -OR- ant -Ddrops.dir=some_directory > From edvard.wendelin at oracle.com Fri Aug 5 01:13:43 2011 From: edvard.wendelin at oracle.com (Edvard Wendelin) Date: Fri, 5 Aug 2011 10:13:43 +0200 Subject: Push request: 7061379: [Kerberos] Cross-realm authentication fails, due to nameType problem In-Reply-To: <4E3B92A2.1060806@oracle.com> References: <4E3B92A2.1060806@oracle.com> Message-ID: <70D0E5E7-2DCD-4092-A7B0-1C53F00ED85A@oracle.com> Approved! Please use hg.openjdk.java.net/jdk7u/jdk7u-dev-gate/jdk/ /Edvard Skickat fr?n min iPhone 5 aug 2011 kl. 08:50 skrev Weijun Wang : > Hi All > > This is a request to backport a jdk8 fix into jdk7u2 b02. > > CR: 7061379: [Kerberos] Cross-realm authentication fails, due to nameType problem > Weblink: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7061379 > > Description: > > A Kerberos PrincipalName is defined as > > PrincipalName ::= SEQUENCE { > name-type [0] Int32, > name-string [1] SEQUENCE OF KerberosString > } > > and RFC 4120 6.2 says -- > > The name-type field that is part of the principal name indicates the > kind of information implied by the name. The name-type SHOULD be > treated only as a hint to interpreting the meaning of a name. It is > not significant when checking for equivalence. > > However, in Java's PrincipalName.equals(), we do check for equality of both the name-type and name-string. This led to a failure in customer's working environment. > > The fix is already included in jdk8 as: > > Changeset: e68db408d08c > Author: weijun > Date: 2011-08-04 18:18 +0800 > URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e68db408d08c > > 7061379: [Kerberos] Cross-realm authentication fails, > due to nameType problem > Reviewed-by: valeriep > > The patch for jdk7u2 is identical to the one in jdk8. > > Thanks > Weijun From Dmitry.Samersoff at oracle.com Thu Aug 4 06:25:09 2011 From: Dmitry.Samersoff at oracle.com (Dmitry Samersoff) Date: Thu, 04 Aug 2011 17:25:09 +0400 Subject: Code Review Request : 7011591 JDWP socket transport should restart interrupted system calls (EINTR) In-Reply-To: <4E3A8A4F.60609@oracle.com> References: <4E3A8A4F.60609@oracle.com> Message-ID: <4E3A9DB5.8080909@oracle.com> David, To be on safe side with connect() (on Linux, not sure for Solaris) you need to call connect() again and if it returns EINPROGRESS, run polling loop. After poll() it's recommended to call getsockopt() and read the SO_ERROR to determine whether connect was successful or not. -Dmitry On 2011-08-04 16:02, David Buck wrote: > Hi! > > I would like to request that my fix for 7011591 be reviewed for push > into JDK8 (and JDK7u if possible). > > CR: 7011591 JDWP socket transport should restart interrupted system > calls (EINTR) > > Weblink: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=2205030 > (for some reason, the public URL for the parent bug is not working. (I > believe that SubCR 2205030 will have all needed information.) > > Webrev: http://cr.openjdk.java.net/~dbuck/7011591/webrev.00/ > > Description: > Syscalls that can be interrupted by signal handling should automatically > retry if they fail with EINTR. Unfortunately, the JDWP socket transport > implementation does not do this. Since HotSpot does not use signals for > thread suspension, HotSpot customers have not run into any problem (as > far as I know). But because JRockit R27 and earlier releases use signals > to suspend threads, all threads are constantly being interrupted thus > JRockit customers are much more likely (almost guaranteed under some > circumstances) to have system calls interrupted by signal handling. > > I have added a loop to automatically retry send(), recv(), sendto(), > recvfrom(), accept(), and poll() calls if the call fails with EINTR. > Note that I do not believe that the UDP versions of the calls > (recvfrom() and sendto()) are actualy ever used in the JDK, but I fixed > them in case they are used in the future. > > The implementation for connect() was more complicated because Solaris > does not let us just call connect() again after EINTR. Once a call to > connect() fails with EINTR on Solaris, the connection setup continues > asynchronously and we need to use select() or poll() to determine when > the socket can be used. > > The patch for jdk7u2 is identical to this (jdk8) fix, if possible, I > would like to receive pre-approval to push to jdk7u-dev repository as well. > > This fix has already been done for 1.4.2/5/6 as part of the JRockit > Simplification Project. This needs to be forward ported into 7 and 8 to > avoid a regression. > > Best Regards, > -Buck -- Dmitry Samersoff Java Hotspot development team, SPB04 * There will come soft rains ... From Dmitry.Samersoff at oracle.com Thu Aug 4 09:35:00 2011 From: Dmitry.Samersoff at oracle.com (Dmitry Samersoff) Date: Thu, 04 Aug 2011 20:35:00 +0400 Subject: Code Review Request : 7011591 JDWP socket transport should restart interrupted system calls (EINTR) In-Reply-To: <4E3AC67E.7080208@oracle.com> References: <4E3A8A4F.60609@oracle.com> <4E3ABFCE.3070408@oracle.com> <4E3AC67E.7080208@oracle.com> Message-ID: <4E3ACA34.9090509@oracle.com> On 2011-08-04 20:19, Daniel D. Daugherty wrote: > >> I looked at the webrev and it mostly looks okay to me. One issue is >> that dbgsysPoll probably should adjust the timeout when interrupted. > > Adjust it how? (Just curious) If my memory is not bogus poll could be interrupted before first request only. So no need to adjust timeout. We may consider to use ppoll under linux but it's a RFE ... -Dmitry > > >> A minor nit is that you've changed the copyright date on the file from >> 1998 to 1997. > > Don't know how I missed that with the earlier reviews, but the > Teamware history shows that the earliest date for this file > is indeed in 1998 and not 1997: > > $ sccs prs -r1.1 src/solaris/transport/socket/socket_md.c > src/solaris/transport/socket/SCCS/s.socket_md.c: > > D 1.1 98/11/21 21:20:56 gordonh 1 0 00149/00000/00000 > MRs: > COMMENTS: > > Dan > -- Dmitry Samersoff Java Hotspot development team, SPB04 * There will come soft rains ... From jim.holmlund at sun.com Thu Aug 4 22:45:10 2011 From: jim.holmlund at sun.com (jim.holmlund at sun.com) Date: Fri, 05 Aug 2011 05:45:10 +0000 Subject: hg: jdk7u/jdk7u-dev/langtools: 7060926: Attr.PostAttrAnalyzer misses a case Message-ID: <20110805054515.AF63547958@hg.openjdk.java.net> Changeset: ceb7ca04b7eb Author: jjh Date: 2011-08-04 14:25 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/langtools/rev/ceb7ca04b7eb 7060926: Attr.PostAttrAnalyzer misses a case Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/comp/Attr.java + test/tools/javac/failover/FailOver15.java + test/tools/javac/failover/FailOver15.out From kumar.x.srinivasan at oracle.COM Fri Aug 5 07:58:02 2011 From: kumar.x.srinivasan at oracle.COM (Kumar Srinivasan) Date: Fri, 05 Aug 2011 07:58:02 -0700 Subject: Request for push: 7062969 In-Reply-To: <20110805021116.GE31431@rivendell.middle-earth.co.uk> References: <4E3AAC19.7020607@oracle.COM> <20110805021116.GE31431@rivendell.middle-earth.co.uk> Message-ID: <4E3C04FA.7000600@oracle.COM> Hi, Please see my comment below, > On 07:26 Thu 04 Aug , Kumar Srinivasan wrote: >> Hi, >> >> Request push approval for CR: 7062969 >> For some reason this does not appear on bugs.sun.com, so here is the >> description: >> >> Description: >> Java version: >> 1.7.0-b146 >> >> Problems: >> In the command line, if you do "java -help", you will see: >> "See http://java.sun.com/javase/reference for more details." at the end >> of the output. >> >> Should that sun.com be changed into Oracle.com? >> It already redirects http://www.oracle.com/technetwork/java/index.html >> but I think if the javadoc or java -help should also show above url as >> well in the command. >> >> File this bug to make sure the mentioned Sun.com url is changed to >> Oracle.com >> > Is there a way this can be overridden? I'm wondering if other providers > of OpenJDK binaries (Red Hat and other GNU/Linux distros, IBM, Apple) > would want a different URL here. I am afraid not, this is a key/value pair in the resource file. We need some build scripts to do the replacement (maybe), and importantly we need a comprehensive branding plan and methodology to do this, which is well beyond the scope of this issue, perhaps a discussion/proposal on build-dev would be a good starting point. Thanks for your review. Kumar From james.holmlund at oracle.com Fri Aug 5 10:56:00 2011 From: james.holmlund at oracle.com (Jim Holmlund) Date: Fri, 05 Aug 2011 10:56:00 -0700 Subject: Request for approval for 7061125 to be fixed in jdk7u-dev/langtools Message-ID: <4E3C2EB0.5030102@oracle.com> - bugs.sun.com: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7061125 - The patch is the same as that in jdk 8. The patch has been in the tl forest of JDK 8 for 4 weeks: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/7337295434b6 - testing: - built the jdk forest on windows - ran all the langtools/regression tests on windows Thanks - jjh From edvard.wendelin at oracle.com Fri Aug 5 11:11:09 2011 From: edvard.wendelin at oracle.com (Edvard Wendelin) Date: Fri, 5 Aug 2011 20:11:09 +0200 Subject: Request for approval for 7061125 to be fixed in jdk7u-dev/langtools In-Reply-To: <4E3C2EB0.5030102@oracle.com> References: <4E3C2EB0.5030102@oracle.com> Message-ID: Approved. Please use hg.openjdk.java.net/jdk7u/jdk7u-dev-gate/langtools/ for the push. Cheers, Edvard On 5 aug 2011, at 19.56, Jim Holmlund wrote: > - bugs.sun.com: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7061125 > > - The patch is the same as that in jdk 8. The patch has been in the > tl forest of JDK 8 for 4 weeks: > http://hg.openjdk.java.net/jdk8/tl/langtools/rev/7337295434b6 > > - testing: > - built the jdk forest on windows > - ran all the langtools/regression tests on windows > > Thanks > - jjh > From kumar.x.srinivasan at oracle.COM Fri Aug 5 11:24:10 2011 From: kumar.x.srinivasan at oracle.COM (Kumar Srinivasan) Date: Fri, 05 Aug 2011 11:24:10 -0700 Subject: Request push approval : 7059905 Message-ID: <4E3C354A.1030005@oracle.COM> Hi, Request approval for 7u2 push, the bug description is here: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7059905 the changeset in jdk8 is here: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/b0909f992710 The changeset for 7u is identical to jdk8, all regressions and builds work, the changes will be pushed to: default-push = ssh://hg.openjdk.java.net/jdk7u/jdk7u-dev-gate/langtools Thanks Kumar From jim.holmlund at sun.com Fri Aug 5 11:27:32 2011 From: jim.holmlund at sun.com (jim.holmlund at sun.com) Date: Fri, 05 Aug 2011 18:27:32 +0000 Subject: hg: jdk7u/jdk7u-dev/langtools: 7061125: Proposed javac argument processing performance improvement Message-ID: <20110805182738.7921147978@hg.openjdk.java.net> Changeset: 2f2ac80b6836 Author: jjh Date: 2011-08-05 11:25 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/langtools/rev/2f2ac80b6836 7061125: Proposed javac argument processing performance improvement Reviewed-by: jjg, dlsmith, mcimadamore, forax Contributed-by: schlosna at gmail.com ! src/share/classes/com/sun/tools/javac/api/JavacTaskImpl.java ! src/share/classes/com/sun/tools/javac/main/Main.java ! test/tools/javac/T6358166.java ! test/tools/javac/T6358168.java From edvard.wendelin at oracle.com Fri Aug 5 11:40:37 2011 From: edvard.wendelin at oracle.com (Edvard Wendelin) Date: Fri, 5 Aug 2011 20:40:37 +0200 Subject: Request push approval : 7059905 In-Reply-To: <4E3C354A.1030005@oracle.COM> References: <4E3C354A.1030005@oracle.COM> Message-ID: <8FB71D89-DE98-40F5-9CEF-6BC9B1DDB21B@oracle.com> Approved! /Edvard On 5 aug 2011, at 20.24, Kumar Srinivasan wrote: > Hi, > > Request approval for 7u2 push, > > the bug description is here: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7059905 > > the changeset in jdk8 is here: > http://hg.openjdk.java.net/jdk8/tl/langtools/rev/b0909f992710 > > The changeset for 7u is identical to jdk8, all regressions and > builds work, > the changes will be pushed to: > default-push = ssh://hg.openjdk.java.net/jdk7u/jdk7u-dev-gate/ > langtools > > Thanks > Kumar > > > From kumar.x.srinivasan at oracle.COM Fri Aug 5 13:00:19 2011 From: kumar.x.srinivasan at oracle.COM (Kumar Srinivasan) Date: Fri, 05 Aug 2011 13:00:19 -0700 Subject: Request push approval Message-ID: <4E3C4BD3.40300@oracle.COM> Hi, Request approval for 7u2 push, the bug description is here: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6735320 the changeset in jdk8 is here: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/409b104f8b86 The changeset for 7u is identical to jdk8, all regressions and builds work, the changes will be pushed to: default-push = ssh://hg.openjdk.java.net/jdk7u/jdk7u-dev-gate/langtools Thanks Kumar From kumar.x.srinivasan at oracle.COM Fri Aug 5 13:01:38 2011 From: kumar.x.srinivasan at oracle.COM (Kumar Srinivasan) Date: Fri, 05 Aug 2011 13:01:38 -0700 Subject: Request push approval : 6735320 In-Reply-To: <4E3C4BD3.40300@oracle.COM> References: <4E3C4BD3.40300@oracle.COM> Message-ID: <4E3C4C22.1000500@oracle.COM> added the CR id in the subject line. Kumar > Hi, > > Request approval for 7u2 push, > > the bug description is here: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6735320 > > the changeset in jdk8 is here: > http://hg.openjdk.java.net/jdk8/tl/langtools/rev/409b104f8b86 > > > The changeset for 7u is identical to jdk8, all regressions and builds > work, > the changes will be pushed to: > default-push = ssh://hg.openjdk.java.net/jdk7u/jdk7u-dev-gate/langtools > > Thanks > Kumar From edvard.wendelin at oracle.com Fri Aug 5 13:57:50 2011 From: edvard.wendelin at oracle.com (Edvard Wendelin) Date: Fri, 5 Aug 2011 23:57:50 +0300 Subject: Request push approval : 6735320 In-Reply-To: <4E3C4C22.1000500@oracle.COM> References: <4E3C4BD3.40300@oracle.COM> <4E3C4C22.1000500@oracle.COM> Message-ID: <05993197-4643-471D-B1BB-E57DD4CECD69@oracle.com> Approved! /Edvard Skickat fr?n min iPhone 5 aug 2011 kl. 23:01 skrev Kumar Srinivasan : > added the CR id in the subject line. > > Kumar > >> Hi, >> >> Request approval for 7u2 push, >> >> the bug description is here: >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6735320 >> >> the changeset in jdk8 is here: >> http://hg.openjdk.java.net/jdk8/tl/langtools/rev/409b104f8b86 >> >> >> The changeset for 7u is identical to jdk8, all regressions and builds work, >> the changes will be pushed to: >> default-push = ssh://hg.openjdk.java.net/jdk7u/jdk7u-dev-gate/langtools >> >> Thanks >> Kumar > From kumar.x.srinivasan at oracle.COM Fri Aug 5 15:35:38 2011 From: kumar.x.srinivasan at oracle.COM (Kumar Srinivasan) Date: Fri, 05 Aug 2011 15:35:38 -0700 Subject: Request push approval 7060642 In-Reply-To: <4E3C4BD3.40300@oracle.COM> References: <4E3C4BD3.40300@oracle.COM> Message-ID: <4E3C703A.30703@oracle.COM> Hi, Request approval for 7u2 push, the bug description is here: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7060642 the changeset in jdk8 is here: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/0d8edba73d70 The changeset for 7u is identical to jdk8, all regressions and builds work, the changes will be pushed to: default-push = ssh://hg.openjdk.java.net/jdk7u/jdk7u-dev-gate/langtools Thanks Kumar From kumar.x.srinivasan at oracle.COM Fri Aug 5 15:40:36 2011 From: kumar.x.srinivasan at oracle.COM (Kumar Srinivasan) Date: Fri, 05 Aug 2011 15:40:36 -0700 Subject: Request push approval 7068902 Message-ID: <4E3C7164.1030309@oracle.COM> Hi, Request approval for 7u2 push, the bug description is here: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7068902 the changeset in jdk8 is here: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/0d6d41563040 The changeset for 7u is identical to jdk8, all regressions and builds work, the changes will be pushed to: default-push = ssh://hg.openjdk.java.net/jdk7u/jdk7u-dev-gate/langtools Thanks Kumar From kumar.x.srinivasan at oracle.com Fri Aug 5 16:09:54 2011 From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com) Date: Fri, 05 Aug 2011 23:09:54 +0000 Subject: hg: jdk7u/jdk7u-dev/jdk: 2 new changesets Message-ID: <20110805231037.9B34D47985@hg.openjdk.java.net> Changeset: 175f98d43a12 Author: ksrini Date: 2011-07-15 16:38 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/jdk/rev/175f98d43a12 7062969: java -help still shows http://java.sun.com/javase/reference Reviewed-by: ohair, darcy ! src/share/classes/sun/launcher/resources/launcher.properties Changeset: 440d5a3cfdf8 Author: ksrini Date: 2011-07-19 10:58 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/jdk/rev/440d5a3cfdf8 7067922: (launcher) java -jar throws NPE if JAR file does not contain Main-Class attribute Reviewed-by: darcy, ohair, alanb, mduigou ! src/share/classes/sun/launcher/LauncherHelper.java ! test/tools/launcher/Arrrghs.java ! test/tools/launcher/TestHelper.java From edvard.wendelin at oracle.com Fri Aug 5 22:44:37 2011 From: edvard.wendelin at oracle.com (Edvard Wendelin) Date: Sat, 6 Aug 2011 08:44:37 +0300 Subject: Request push approval 7068902 In-Reply-To: <4E3C7164.1030309@oracle.COM> References: <4E3C7164.1030309@oracle.COM> Message-ID: <779CE95D-8DEA-4552-A518-9FA8284952E7@oracle.com> Approved! Cheers, Edvard Skickat fr?n min iPhone 6 aug 2011 kl. 01:40 skrev Kumar Srinivasan : > Hi, > > Request approval for 7u2 push, > > the bug description is here: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7068902 > > the changeset in jdk8 is here: > http://hg.openjdk.java.net/jdk8/tl/langtools/rev/0d6d41563040 > > > The changeset for 7u is identical to jdk8, all regressions and builds work, > the changes will be pushed to: > default-push = ssh://hg.openjdk.java.net/jdk7u/jdk7u-dev-gate/langtools > > Thanks > Kumar From kumar.x.srinivasan at oracle.COM Sat Aug 6 09:24:30 2011 From: kumar.x.srinivasan at oracle.COM (Kumar Srinivasan) Date: Sat, 06 Aug 2011 09:24:30 -0700 Subject: Fwd: Request push approval 7060642 Message-ID: <4E3D6ABE.4070704@oracle.COM> Resending, this one did not make it to the distribution list. Kumar -------- Original Message -------- Subject: Request push approval 7060642 Date: Fri, 05 Aug 2011 15:35:38 -0700 From: Kumar Srinivasan To: jdk7u-dev at openjdk.java.net Hi, Request approval for 7u2 push, the bug description is here: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7060642 the changeset in jdk8 is here: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/0d8edba73d70 The changeset for 7u is identical to jdk8, all regressions and builds work, the changes will be pushed to: default-push = ssh://hg.openjdk.java.net/jdk7u/jdk7u-dev-gate/langtools Thanks Kumar From edvard.wendelin at oracle.com Sat Aug 6 10:02:36 2011 From: edvard.wendelin at oracle.com (Edvard Wendelin) Date: Sat, 6 Aug 2011 19:02:36 +0200 Subject: Request push approval 7060642 In-Reply-To: <4E3D6ABE.4070704@oracle.COM> References: <4E3D6ABE.4070704@oracle.COM> Message-ID: <6351E2BA-CFBD-4162-B5D1-218B87D6712A@oracle.com> Approved /Edvard On 6 aug 2011, at 18.24, Kumar Srinivasan wrote: > Resending, this one did not make it to the distribution list. > > Kumar > > > -------- Original Message -------- > Subject: Request push approval 7060642 > Date: Fri, 05 Aug 2011 15:35:38 -0700 > From: Kumar Srinivasan > To: jdk7u-dev at openjdk.java.net > > > > Hi, > > Request approval for 7u2 push, > > the bug description is here: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7060642 > > the changeset in jdk8 is here: > http://hg.openjdk.java.net/jdk8/tl/langtools/rev/0d8edba73d70 > > > The changeset for 7u is identical to jdk8, all regressions and > builds work, > the changes will be pushed to: > default-push = ssh://hg.openjdk.java.net/jdk7u/jdk7u-dev-gate/ > langtools > > Thanks > Kumar > From kumar.x.srinivasan at oracle.com Sat Aug 6 15:32:41 2011 From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com) Date: Sat, 06 Aug 2011 22:32:41 +0000 Subject: hg: jdk7u/jdk7u-dev/langtools: 4 new changesets Message-ID: <20110806223251.EF460479B9@hg.openjdk.java.net> Changeset: 130154dbafc8 Author: ksrini Date: 2011-07-27 11:53 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/langtools/rev/130154dbafc8 7068902: (javac) allow enabling or disabling of String folding Summary: Contributed by netbeans team, modified to suit by the langtools team. Reviewed-by: jjg, mcimadamore ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java + test/tools/javac/parser/StringFoldingTest.java Changeset: 8b6f8a4bc8b8 Author: ksrini Date: 2011-07-01 14:28 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/langtools/rev/8b6f8a4bc8b8 7060642: (javadoc) improve performance on accessing inlinedTags Reviewed-by: jjg, bpatel ! src/share/classes/com/sun/tools/javadoc/ParamTagImpl.java ! src/share/classes/com/sun/tools/javadoc/ThrowsTagImpl.java Changeset: fda5571c663a Author: ksrini Date: 2011-07-01 13:34 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/langtools/rev/fda5571c663a 6735320: StringIndexOutOfBoundsException for empty @serialField tag Reviewed-by: jjg, bpatel ! src/share/classes/com/sun/tools/javadoc/SerialFieldTagImpl.java + test/com/sun/javadoc/T6735320/SerialFieldTest.java + test/com/sun/javadoc/T6735320/T6735320.java ! test/com/sun/javadoc/lib/JavadocTester.java Changeset: add40922e84d Author: ksrini Date: 2011-06-30 14:33 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/langtools/rev/add40922e84d 7059905: (javadoc) promote method visibility for netbeans usage Reviewed-by: jjg, bpatel ! src/share/classes/com/sun/tools/javadoc/AnnotationTypeDocImpl.java ! src/share/classes/com/sun/tools/javadoc/AnnotationTypeElementDocImpl.java ! src/share/classes/com/sun/tools/javadoc/DocEnv.java ! src/share/classes/com/sun/tools/javadoc/DocImpl.java ! src/share/classes/com/sun/tools/javadoc/JavadocClassReader.java ! src/share/classes/com/sun/tools/javadoc/JavadocMemberEnter.java ! src/share/classes/com/sun/tools/javadoc/PackageDocImpl.java From David.Holmes at oracle.com Sun Aug 7 23:00:30 2011 From: David.Holmes at oracle.com (David Holmes) Date: Mon, 08 Aug 2011 16:00:30 +1000 Subject: Request for approval (was Re: Request for review: 7039182) In-Reply-To: <4E3B5D4E.20102@oracle.com> References: <4E3B5D4E.20102@oracle.com> Message-ID: <4E3F7B7E.8010704@oracle.com> As this is identical to the JDK8 fix it seems I need only seek approval and not re-review. Thanks, David David Holmes said the following on 08/05/11 13:02: > 7039182 is not a public CR so I'll summarize the issue. > > When the NIO libs are built there are a few files that contain constants > that represent platform specific I/O constants found in various C header > files. Normally the build process compiles and runs a small C program > which will generate the .java file for that platform. > > When I integrated the basic support for cross-compilation I modified > this process to use the host C compiler not the cross-compiler for the > target, as we couldn't execute the resulting C program. That wasn't the > correct thing to do because it means we generate values for the build > platform not the target platform. Luckily these values are mostly the > same on the Linux platforms we care about, but not all the same (hence > this bug report where a read system call returned EINVAL because we > thought we were passing O_NOFOLLOW but in fact passed O_DIRECT). > > The simplest fix is to not try to generate a file when cross-compiling > but allow the developer to specify where these files can be found. This > is done using the NIO_PLATFORM_CLASSES_ROOT_DIR variable which is > expected to be the "root" directory for where classes can be found and > the directories under that are expected to follow the package hierarchy > for the files, so, for example we will look for: > > $(NIO_PLATFORM_CLASSES_ROOT_DIR)/sun/nio/ch/SocketOptionRegistry-$(PLATFORM)-$(ARCH).java > > > the platform and arch are used in the filename as we don't have > platform/arch directories in the JDK repo. > > In addition I reverted the original change to use the host C compiler as > this allows you to specifically build the generator program using the > cross-compiler (which will get the right values) then copy it across to > the target system and run it to generate the file. > > --- > > Here's the webrev against 7u-dev: > > http://cr.openjdk.java.net/~dholmes/7039182/webrev.u2/ > > --- > > Here's the information from the JDK 8 submission: > > http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3abc52f0a4dc > > 7039182: PPC: NIO: java.io.IOException: Invalid argument in > sun.nio.ch.FileDispatcherImpl.read0 > author dholmes > Mon Jun 27 20:13:48 2011 -0400 (5 weeks ago) > changeset 4369 3abc52f0a4dc > parent 4368 a053c28304e8 > child 4371 585cc4a4528d > 7039182: PPC: NIO: java.io.IOException: Invalid argument in > sun.nio.ch.FileDispatcherImpl.read0 > Summary: Allow platform specific files to be located at build time > instead of generating them > Reviewed-by: alanb, ohair > > Thanks, > David Holmes From edvard.wendelin at oracle.com Sun Aug 7 23:47:46 2011 From: edvard.wendelin at oracle.com (Edvard Wendelin) Date: Mon, 08 Aug 2011 08:47:46 +0200 Subject: Request for approval (was Re: Request for review: 7039182) In-Reply-To: <4E3F7B7E.8010704@oracle.com> References: <4E3B5D4E.20102@oracle.com> <4E3F7B7E.8010704@oracle.com> Message-ID: <4E3F8692.2040408@oracle.com> Approved! Use http://hg.openjdk.java.net/jdk7u/jdk7u-dev-gate/jdk/ for the push Cheers, Edvard On 08/08/2011 08:00 AM, David Holmes wrote: > As this is identical to the JDK8 fix it seems I need only seek > approval and not re-review. > > Thanks, > David > > David Holmes said the following on 08/05/11 13:02: >> 7039182 is not a public CR so I'll summarize the issue. >> >> When the NIO libs are built there are a few files that contain >> constants that represent platform specific I/O constants found in >> various C header files. Normally the build process compiles and runs >> a small C program which will generate the .java file for that platform. >> >> When I integrated the basic support for cross-compilation I modified >> this process to use the host C compiler not the cross-compiler for >> the target, as we couldn't execute the resulting C program. That >> wasn't the correct thing to do because it means we generate values >> for the build platform not the target platform. Luckily these values >> are mostly the same on the Linux platforms we care about, but not all >> the same (hence this bug report where a read system call returned >> EINVAL because we thought we were passing O_NOFOLLOW but in fact >> passed O_DIRECT). >> >> The simplest fix is to not try to generate a file when >> cross-compiling but allow the developer to specify where these files >> can be found. This is done using the NIO_PLATFORM_CLASSES_ROOT_DIR >> variable which is expected to be the "root" directory for where >> classes can be found and the directories under that are expected to >> follow the package hierarchy for the files, so, for example we will >> look for: >> >> $(NIO_PLATFORM_CLASSES_ROOT_DIR)/sun/nio/ch/SocketOptionRegistry-$(PLATFORM)-$(ARCH).java >> >> >> the platform and arch are used in the filename as we don't have >> platform/arch directories in the JDK repo. >> >> In addition I reverted the original change to use the host C compiler >> as this allows you to specifically build the generator program using >> the cross-compiler (which will get the right values) then copy it >> across to the target system and run it to generate the file. >> >> --- >> >> Here's the webrev against 7u-dev: >> >> http://cr.openjdk.java.net/~dholmes/7039182/webrev.u2/ >> >> --- >> >> Here's the information from the JDK 8 submission: >> >> http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3abc52f0a4dc >> >> 7039182: PPC: NIO: java.io.IOException: Invalid argument in >> sun.nio.ch.FileDispatcherImpl.read0 >> author dholmes >> Mon Jun 27 20:13:48 2011 -0400 (5 weeks ago) >> changeset 4369 3abc52f0a4dc >> parent 4368 a053c28304e8 >> child 4371 585cc4a4528d >> 7039182: PPC: NIO: java.io.IOException: Invalid argument in >> sun.nio.ch.FileDispatcherImpl.read0 >> Summary: Allow platform specific files to be located at build time >> instead of generating them >> Reviewed-by: alanb, ohair >> >> Thanks, >> David Holmes From david.holmes at oracle.com Sun Aug 7 23:53:47 2011 From: david.holmes at oracle.com (david.holmes at oracle.com) Date: Mon, 08 Aug 2011 06:53:47 +0000 Subject: hg: jdk7u/jdk7u-dev/jdk: 7039182: PPC: NIO: java.io.IOException: Invalid argument in sun.nio.ch.FileDispatcherImpl.read0 Message-ID: <20110808065409.1119D47A02@hg.openjdk.java.net> Changeset: a5ea1f537169 Author: dholmes Date: 2011-08-08 02:51 -0400 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/jdk/rev/a5ea1f537169 7039182: PPC: NIO: java.io.IOException: Invalid argument in sun.nio.ch.FileDispatcherImpl.read0 Summary: Allow platform specific files to be located at build time instead of generating them (as per JDK8 changeset) Reviewed-by: alanb, ohair ! make/common/Defs-embedded.gmk ! make/java/nio/Makefile From david.buck at oracle.com Mon Aug 8 23:18:47 2011 From: david.buck at oracle.com (David Buck) Date: Tue, 09 Aug 2011 15:18:47 +0900 Subject: Code Review Request : 7011591 JDWP socket transport should restart interrupted system calls (EINTR) In-Reply-To: <4E3A9DB5.8080909@oracle.com> References: <4E3A8A4F.60609@oracle.com> <4E3A9DB5.8080909@oracle.com> Message-ID: <4E40D147.9000107@oracle.com> Hi Dmitry! Thank you for the helpful feedback. Even on Solaris, I should have called getsockopt() after poll() returns. Not sure how I missed that. Thanks for the catch! I am not so sure i should include a second call to connect() after the first one returns with EINTR. All of the "standard" unix docs (SUS, Richard Steven's "Unix Network Programming") for connect() clearly require that an interrupted call to connect() (on a blocking socket) result in a asynchronous connection setup. This seems to work fine on Linux as well. My understanding is that the fact that Linux will sometimes let us just re-call connect() and get the blocking behavior (just like our original call) or return EINPROGRESS is more of a convenience (that encourages programmers to write non-portable code). In other words, I don't think you HAVE to call connect() again before doing a poll() or select(). The specification guarantees an asynchronous attempt at connection setup and if we found an instance where it didn't do that, we would be justified in calling it a bug. If possible, I would like one implementation that works on both (and follows the specification strictly) and avoid adding any ifdefs to the code. Cheers, -Buck On 08/04/11 22:25, Dmitry Samersoff wrote: > David, > > To be on safe side with connect() (on Linux, not sure for Solaris) > you need to call connect() again and if it returns EINPROGRESS, run > polling loop. After poll() it's recommended to call getsockopt() and > read the SO_ERROR to determine whether connect was successful or not. > > -Dmitry > > > On 2011-08-04 16:02, David Buck wrote: >> Hi! >> >> I would like to request that my fix for 7011591 be reviewed for push >> into JDK8 (and JDK7u if possible). >> >> CR: 7011591 JDWP socket transport should restart interrupted system >> calls (EINTR) >> >> Weblink: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=2205030 >> (for some reason, the public URL for the parent bug is not working. (I >> believe that SubCR 2205030 will have all needed information.) >> >> Webrev: http://cr.openjdk.java.net/~dbuck/7011591/webrev.00/ >> >> Description: >> Syscalls that can be interrupted by signal handling should automatically >> retry if they fail with EINTR. Unfortunately, the JDWP socket transport >> implementation does not do this. Since HotSpot does not use signals for >> thread suspension, HotSpot customers have not run into any problem (as >> far as I know). But because JRockit R27 and earlier releases use signals >> to suspend threads, all threads are constantly being interrupted thus >> JRockit customers are much more likely (almost guaranteed under some >> circumstances) to have system calls interrupted by signal handling. >> >> I have added a loop to automatically retry send(), recv(), sendto(), >> recvfrom(), accept(), and poll() calls if the call fails with EINTR. >> Note that I do not believe that the UDP versions of the calls >> (recvfrom() and sendto()) are actualy ever used in the JDK, but I fixed >> them in case they are used in the future. >> >> The implementation for connect() was more complicated because Solaris >> does not let us just call connect() again after EINTR. Once a call to >> connect() fails with EINTR on Solaris, the connection setup continues >> asynchronously and we need to use select() or poll() to determine when >> the socket can be used. >> >> The patch for jdk7u2 is identical to this (jdk8) fix, if possible, I >> would like to receive pre-approval to push to jdk7u-dev repository as >> well. >> >> This fix has already been done for 1.4.2/5/6 as part of the JRockit >> Simplification Project. This needs to be forward ported into 7 and 8 to >> avoid a regression. >> >> Best Regards, >> -Buck > > From joe.darcy at oracle.com Mon Aug 8 23:20:52 2011 From: joe.darcy at oracle.com (Joe Darcy) Date: Mon, 08 Aug 2011 23:20:52 -0700 Subject: Request for approval to backport 7071246: "Enclosing string literal in parenthesis in switch-case crashes javac" to jdk7u-dev/langtools Message-ID: <4E40D1C4.3000506@oracle.com> Hello. I hereby request to approval to backport 7071246: "Enclosing string literal in parenthesis in switch-case crashes javac" http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7071246 to jdk7u-dev/langtools. The changeset from JDK 8, http://hg.openjdk.java.net/jdk8/tl/langtools/rev/64b9b7ae3366 hg imports cleanly and all langtools tests continue to pass. Thanks, -Joe From edvard.wendelin at oracle.com Mon Aug 8 23:40:47 2011 From: edvard.wendelin at oracle.com (Edvard Wendelin) Date: Tue, 09 Aug 2011 08:40:47 +0200 Subject: Request for approval to backport 7071246: "Enclosing string literal in parenthesis in switch-case crashes javac" to jdk7u-dev/langtools In-Reply-To: <4E40D1C4.3000506@oracle.com> References: <4E40D1C4.3000506@oracle.com> Message-ID: <4E40D66F.8000109@oracle.com> Hi, Glad to see this request show up in my inbox :) Approved. Please use http://hg.openjdk.java.net/jdk7u/jdk7u-dev-gate/langtools for the push. Cheers, Edvard On 08/09/2011 08:20 AM, Joe Darcy wrote: > Hello. > > I hereby request to approval to backport > > 7071246: "Enclosing string literal in parenthesis in switch-case > crashes javac" > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7071246 > > to jdk7u-dev/langtools. The changeset from JDK 8, > > http://hg.openjdk.java.net/jdk8/tl/langtools/rev/64b9b7ae3366 > > hg imports cleanly and all langtools tests continue to pass. > > Thanks, > > -Joe From joe.darcy at oracle.com Tue Aug 9 00:33:06 2011 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Tue, 09 Aug 2011 07:33:06 +0000 Subject: hg: jdk7u/jdk7u-dev/langtools: 7071246: Enclosing string literal in parenthesis in switch-case crashes javac Message-ID: <20110809073308.DCBB747A40@hg.openjdk.java.net> Changeset: e2ace862236a Author: darcy Date: 2011-08-04 11:15 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/langtools/rev/e2ace862236a 7071246: Enclosing string literal in parenthesis in switch-case crashes javac Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/comp/Lower.java ! test/tools/javac/StringsInSwitch/StringSwitches.java From Dmitry.Samersoff at oracle.com Tue Aug 9 01:39:16 2011 From: Dmitry.Samersoff at oracle.com (Dmitry Samersoff) Date: Tue, 09 Aug 2011 12:39:16 +0400 Subject: Code Review Request : 7011591 JDWP socket transport should restart interrupted system calls (EINTR) In-Reply-To: <4E40D147.9000107@oracle.com> References: <4E3A8A4F.60609@oracle.com> <4E3A9DB5.8080909@oracle.com> <4E40D147.9000107@oracle.com> Message-ID: <4E40F234.2030807@oracle.com> On 2011-08-09 10:18, David Buck wrote: > Hi Dmitry! > > Thank you for the helpful feedback. > > Even on Solaris, I should have called getsockopt() after poll() returns. > Not sure how I missed that. Thanks for the catch! > > I am not so sure i should include a second call to connect() after the > first one returns with EINTR. All of the "standard" unix docs (SUS, > Richard Steven's "Unix Network Programming") for connect() clearly > require that an interrupted call to connect() (on a blocking socket) > result in a asynchronous connection setup. connect() continues async setup for both blocking/non-blocking socket. > This seems to work fine on > Linux as well. My understanding is that the fact that Linux will > sometimes let us just re-call connect() and get the blocking behavior > (just like our original call) or return EINPROGRESS is more of a > convenience (that encourages programmers to write non-portable code). Behavior of second connect() call is portable: for blocking/non-blocking sockets it can: - block/retry; return EISCONN; return EALREADY/EINPROGRESS. Generally speaking it allows better error handling than just poll because it can catch an error happened between connect and poll calls (e.g. a peer reset connection) but in you probably don't need it. See http://pubs.opengroup.org/onlinepubs/009695399/functions/connect.html -Dmitry > In > other words, I don't think you HAVE to call connect() again before doing > a poll() or select(). The specification guarantees an asynchronous > attempt at connection setup and if we found an instance where it didn't > do that, we would be justified in calling it a bug. > > If possible, I would like one implementation that works on both (and > follows the specification strictly) and avoid adding any ifdefs to the > code. > > Cheers, > -Buck > > On 08/04/11 22:25, Dmitry Samersoff wrote: >> David, >> >> To be on safe side with connect() (on Linux, not sure for Solaris) >> you need to call connect() again and if it returns EINPROGRESS, run >> polling loop. After poll() it's recommended to call getsockopt() and >> read the SO_ERROR to determine whether connect was successful or not. >> >> -Dmitry >> >> >> On 2011-08-04 16:02, David Buck wrote: >>> Hi! >>> >>> I would like to request that my fix for 7011591 be reviewed for push >>> into JDK8 (and JDK7u if possible). >>> >>> CR: 7011591 JDWP socket transport should restart interrupted system >>> calls (EINTR) >>> >>> Weblink: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=2205030 >>> (for some reason, the public URL for the parent bug is not working. (I >>> believe that SubCR 2205030 will have all needed information.) >>> >>> Webrev: http://cr.openjdk.java.net/~dbuck/7011591/webrev.00/ >>> >>> Description: >>> Syscalls that can be interrupted by signal handling should automatically >>> retry if they fail with EINTR. Unfortunately, the JDWP socket transport >>> implementation does not do this. Since HotSpot does not use signals for >>> thread suspension, HotSpot customers have not run into any problem (as >>> far as I know). But because JRockit R27 and earlier releases use signals >>> to suspend threads, all threads are constantly being interrupted thus >>> JRockit customers are much more likely (almost guaranteed under some >>> circumstances) to have system calls interrupted by signal handling. >>> >>> I have added a loop to automatically retry send(), recv(), sendto(), >>> recvfrom(), accept(), and poll() calls if the call fails with EINTR. >>> Note that I do not believe that the UDP versions of the calls >>> (recvfrom() and sendto()) are actualy ever used in the JDK, but I fixed >>> them in case they are used in the future. >>> >>> The implementation for connect() was more complicated because Solaris >>> does not let us just call connect() again after EINTR. Once a call to >>> connect() fails with EINTR on Solaris, the connection setup continues >>> asynchronously and we need to use select() or poll() to determine when >>> the socket can be used. >>> >>> The patch for jdk7u2 is identical to this (jdk8) fix, if possible, I >>> would like to receive pre-approval to push to jdk7u-dev repository as >>> well. >>> >>> This fix has already been done for 1.4.2/5/6 as part of the JRockit >>> Simplification Project. This needs to be forward ported into 7 and 8 to >>> avoid a regression. >>> >>> Best Regards, >>> -Buck >> >> -- Dmitry Samersoff Java Hotspot development team, SPB04 * There will come soft rains ... From sean.coffey at oracle.com Tue Aug 9 04:51:29 2011 From: sean.coffey at oracle.com (=?ISO-8859-1?Q?Se=E1n_Coffey?=) Date: Tue, 09 Aug 2011 12:51:29 +0100 Subject: Request for approval to backport 7041125 to jdk7u-dev/jdk Message-ID: <4E411F41.4000608@oracle.com> Request to backport following from JDK 8 : 7041125: LDAP API does not catch malformed filters that contain two operands for the ! operator http://bugs.sun.com/view_bug.do?bug_id=7041125 Identical changeset from JDK 8 : http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e88093d75e36 Builds and tests fine. regards, Sean. From edvard.wendelin at oracle.com Tue Aug 9 05:12:55 2011 From: edvard.wendelin at oracle.com (Edvard Wendelin) Date: Tue, 09 Aug 2011 14:12:55 +0200 Subject: Request for approval to backport 7041125 to jdk7u-dev/jdk In-Reply-To: <4E411F41.4000608@oracle.com> References: <4E411F41.4000608@oracle.com> Message-ID: <4E412447.3030703@oracle.com> Approved. Use http://hg.openjdk.java.net/jdk7u/jdk7u-dev-gate/jdk/ for the push. Cheers, Edvard On 08/09/2011 01:51 PM, Se?n Coffey wrote: > Request to backport following from JDK 8 : > > 7041125: LDAP API does not catch malformed filters that contain two > operands for the ! operator > http://bugs.sun.com/view_bug.do?bug_id=7041125 > > Identical changeset from JDK 8 : > http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e88093d75e36 > > Builds and tests fine. > > regards, > Sean. From maurizio.cimadamore at oracle.com Tue Aug 9 05:14:08 2011 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Tue, 09 Aug 2011 13:14:08 +0100 Subject: Request for approval for 7062745 to be fixed in jdk7u-dev/langtools Message-ID: <4E412490.9060104@oracle.com> Hi I would like to request to backport the following bug from the JDK 8 repo: 7062745: Regression: difference in overload resolution when two methods are maximally specific [1] The patch is the same as that in jdk 8 [2]. All regression tests and JCK tests pass. [1] -http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7062745 [2] -http://hg.openjdk.java.net/jdk8/tl/langtools/rev/0b5beb9562c6 Thanks Maurizio From maurizio.cimadamore at oracle.com Tue Aug 9 05:19:29 2011 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Tue, 09 Aug 2011 13:19:29 +0100 Subject: Request for approval for 7046778 to be fixed in jdk7u-dev/langtools Message-ID: <4E4125D1.8040406@oracle.com> Hi I would like to request to backport the following bug from the JDK 8 repo: 7046778:Project Coin: problem with diamond and member inner classes [1] The patch is the same as that in jdk 8 [2]. All regression tests and JCK tests pass. [1] -http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7046778 [2] -http://hg.openjdk.java.net/jdk8/tl/langtools/rev/d5f33267a06d Thanks Maurizio From maurizio.cimadamore at oracle.com Tue Aug 9 05:21:16 2011 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Tue, 09 Aug 2011 13:21:16 +0100 Subject: Request for approval for 7057297 to be fixed in jdk7u-dev/langtools Message-ID: <4E41263C.7070904@oracle.com> Hi I would like to request to backport the following bug from the JDK 8 repo: 7057297: Project Coin: diamond erroneously accepts in array initializer expressions The patch is the same as that in jdk 8 [2]. All regression tests and JCK tests pass. [1] -http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7057297 [2] -http://hg.openjdk.java.net/jdk8/tl/langtools/rev/e427c42e1a7e Thanks Maurizio From edvard.wendelin at oracle.com Tue Aug 9 05:27:30 2011 From: edvard.wendelin at oracle.com (Edvard Wendelin) Date: Tue, 09 Aug 2011 14:27:30 +0200 Subject: Request for approval for 7046778 to be fixed in jdk7u-dev/langtools In-Reply-To: <4E4125D1.8040406@oracle.com> References: <4E4125D1.8040406@oracle.com> Message-ID: <4E4127B2.6000100@oracle.com> Approved, Use http://hg.openjdk.java.net/jdk7u/jdk7u-dev-gate/langtools for the push. Cheers, Edvard On 08/09/2011 02:19 PM, Maurizio Cimadamore wrote: > Hi > I would like to request to backport the following bug from the JDK 8 > repo: > > 7046778:Project Coin: problem with diamond and member inner classes [1] > > The patch is the same as that in jdk 8 [2]. All regression tests and > JCK tests pass. > > [1] -http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7046778 > > [2] -http://hg.openjdk.java.net/jdk8/tl/langtools/rev/d5f33267a06d > > Thanks > Maurizio > > From edvard.wendelin at oracle.com Tue Aug 9 05:28:10 2011 From: edvard.wendelin at oracle.com (Edvard Wendelin) Date: Tue, 09 Aug 2011 14:28:10 +0200 Subject: Request for approval for 7062745 to be fixed in jdk7u-dev/langtools In-Reply-To: <4E412490.9060104@oracle.com> References: <4E412490.9060104@oracle.com> Message-ID: <4E4127DA.4040102@oracle.com> Approved, Use http://hg.openjdk.java.net/jdk7u/jdk7u-dev-gate/langtools for the push. Cheers, Edvard On 08/09/2011 02:14 PM, Maurizio Cimadamore wrote: > Hi > I would like to request to backport the following bug from the JDK 8 > repo: > > 7062745: Regression: difference in overload resolution when two > methods are maximally specific [1] > > The patch is the same as that in jdk 8 [2]. All regression tests and > JCK tests pass. > > [1] -http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7062745 > [2] -http://hg.openjdk.java.net/jdk8/tl/langtools/rev/0b5beb9562c6 > > Thanks > Maurizio > > From edvard.wendelin at oracle.com Tue Aug 9 05:38:51 2011 From: edvard.wendelin at oracle.com (Edvard Wendelin) Date: Tue, 09 Aug 2011 14:38:51 +0200 Subject: Request for approval for 7057297 to be fixed in jdk7u-dev/langtools In-Reply-To: <4E41263C.7070904@oracle.com> References: <4E41263C.7070904@oracle.com> Message-ID: <4E412A5B.1000005@oracle.com> Approved, Use http://hg.openjdk.java.net/jdk7u/jdk7u-dev-gate/langtools for the push. Cheers, Edvard On 08/09/2011 02:21 PM, Maurizio Cimadamore wrote: > Hi > I would like to request to backport the following bug from the JDK 8 > repo: > > 7057297: Project Coin: diamond erroneously accepts in array > initializer expressions > > The patch is the same as that in jdk 8 [2]. All regression tests and > JCK tests pass. > > [1] -http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7057297 > [2] -http://hg.openjdk.java.net/jdk8/tl/langtools/rev/e427c42e1a7e > > Thanks > Maurizio > > From sean.coffey at oracle.com Tue Aug 9 06:03:14 2011 From: sean.coffey at oracle.com (sean.coffey at oracle.com) Date: Tue, 09 Aug 2011 13:03:14 +0000 Subject: hg: jdk7u/jdk7u-dev/jdk: 7041125: LDAP API does not catch malformed filters that contain two operands for the ! operator Message-ID: <20110809130338.DCC6E47A4E@hg.openjdk.java.net> Changeset: 8841e2149dfb Author: coffeys Date: 2011-08-09 14:02 +0100 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/jdk/rev/8841e2149dfb 7041125: LDAP API does not catch malformed filters that contain two operands for the ! operator Reviewed-by: weijun, xuelei ! src/share/classes/com/sun/jndi/ldap/Filter.java ! test/com/sun/jndi/ldap/InvalidLdapFilters.java From pavel.porvatov at oracle.com Tue Aug 9 03:18:51 2011 From: pavel.porvatov at oracle.com (Pavel Porvatov) Date: Tue, 09 Aug 2011 14:18:51 +0400 Subject: Request for approval: 7019963 Message-ID: <4E41098B.7040209@oracle.com> Hi, Could you please approve the fix of CR 7019963 (The goto parent directory button doesn't operate in JFileChooser) for 7u2? Bug description is here: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7019963 Some time ago the fix was prepared, approved and pushed in jdk8: http://hg.openjdk.java.net/jdk8/swing/jdk/rev/afb5895da744 For 7u2 the fix is the same and doesn't contains any modifications. Regards, Pavel From edvard.wendelin at oracle.com Tue Aug 9 07:14:00 2011 From: edvard.wendelin at oracle.com (Edvard Wendelin) Date: Tue, 09 Aug 2011 16:14:00 +0200 Subject: Request for approval: 7019963 In-Reply-To: <4E41098B.7040209@oracle.com> References: <4E41098B.7040209@oracle.com> Message-ID: <4E4140A8.8020508@oracle.com> Approved, Use http://hg.openjdk.java.net/jdk7u/jdk7u-dev-gate/jdk/ for the push. Cheers, Edvard On 08/09/2011 12:18 PM, Pavel Porvatov wrote: > Hi, > > Could you please approve the fix of CR 7019963 (The goto parent > directory button doesn't operate in JFileChooser) for 7u2? Bug > description is here: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7019963 > > Some time ago the fix was prepared, approved and pushed in jdk8: > http://hg.openjdk.java.net/jdk8/swing/jdk/rev/afb5895da744 > > For 7u2 the fix is the same and doesn't contains any modifications. > > Regards, Pavel From Sergey.Malenkov at oracle.com Tue Aug 9 07:03:29 2011 From: Sergey.Malenkov at oracle.com (Sergey Malenkov) Date: Tue, 09 Aug 2011 18:03:29 +0400 Subject: Request for approval: 7057459 Message-ID: <4E413E31.60602@oracle.com> Hi all, Could you please approve the fix of CR 7057459 for JDK7u2? Regression: Performance degradation with java.beans.XMLEncoder http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7057459 Earlier the fix was prepared, approved and pushed into JDK8: http://hg.openjdk.java.net/jdk8/swing/jdk/rev/494e61ff0eac The fix for JDK7u2 is the same and doesn't contain any changes. Thanks, SAM From edvard.wendelin at oracle.com Tue Aug 9 07:35:45 2011 From: edvard.wendelin at oracle.com (Edvard Wendelin) Date: Tue, 09 Aug 2011 16:35:45 +0200 Subject: Request for approval: 7057459 In-Reply-To: <4E413E31.60602@oracle.com> References: <4E413E31.60602@oracle.com> Message-ID: <4E4145C1.7070000@oracle.com> Approved. Use http://hg.openjdk.java.net/jdk7u/jdk7u-dev-gate/jdk/ for the push. Cheers, Edvard On 08/09/2011 04:03 PM, Sergey Malenkov wrote: > Hi all, > > Could you please approve the fix of CR 7057459 for JDK7u2? > > Regression: Performance degradation with java.beans.XMLEncoder > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7057459 > > Earlier the fix was prepared, approved and pushed into JDK8: > http://hg.openjdk.java.net/jdk8/swing/jdk/rev/494e61ff0eac > > The fix for JDK7u2 is the same and doesn't contain any changes. > > Thanks, > SAM From lana.steuck at oracle.com Tue Aug 9 11:23:17 2011 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Tue, 09 Aug 2011 18:23:17 +0000 Subject: hg: jdk7u/jdk7u/langtools: 6 new changesets Message-ID: <20110809182333.8C90C47A5E@hg.openjdk.java.net> Changeset: ceb7ca04b7eb Author: jjh Date: 2011-08-04 14:25 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/langtools/rev/ceb7ca04b7eb 7060926: Attr.PostAttrAnalyzer misses a case Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/comp/Attr.java + test/tools/javac/failover/FailOver15.java + test/tools/javac/failover/FailOver15.out Changeset: 2f2ac80b6836 Author: jjh Date: 2011-08-05 11:25 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/langtools/rev/2f2ac80b6836 7061125: Proposed javac argument processing performance improvement Reviewed-by: jjg, dlsmith, mcimadamore, forax Contributed-by: schlosna at gmail.com ! src/share/classes/com/sun/tools/javac/api/JavacTaskImpl.java ! src/share/classes/com/sun/tools/javac/main/Main.java ! test/tools/javac/T6358166.java ! test/tools/javac/T6358168.java Changeset: 130154dbafc8 Author: ksrini Date: 2011-07-27 11:53 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/langtools/rev/130154dbafc8 7068902: (javac) allow enabling or disabling of String folding Summary: Contributed by netbeans team, modified to suit by the langtools team. Reviewed-by: jjg, mcimadamore ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java + test/tools/javac/parser/StringFoldingTest.java Changeset: 8b6f8a4bc8b8 Author: ksrini Date: 2011-07-01 14:28 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/langtools/rev/8b6f8a4bc8b8 7060642: (javadoc) improve performance on accessing inlinedTags Reviewed-by: jjg, bpatel ! src/share/classes/com/sun/tools/javadoc/ParamTagImpl.java ! src/share/classes/com/sun/tools/javadoc/ThrowsTagImpl.java Changeset: fda5571c663a Author: ksrini Date: 2011-07-01 13:34 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/langtools/rev/fda5571c663a 6735320: StringIndexOutOfBoundsException for empty @serialField tag Reviewed-by: jjg, bpatel ! src/share/classes/com/sun/tools/javadoc/SerialFieldTagImpl.java + test/com/sun/javadoc/T6735320/SerialFieldTest.java + test/com/sun/javadoc/T6735320/T6735320.java ! test/com/sun/javadoc/lib/JavadocTester.java Changeset: add40922e84d Author: ksrini Date: 2011-06-30 14:33 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/langtools/rev/add40922e84d 7059905: (javadoc) promote method visibility for netbeans usage Reviewed-by: jjg, bpatel ! src/share/classes/com/sun/tools/javadoc/AnnotationTypeDocImpl.java ! src/share/classes/com/sun/tools/javadoc/AnnotationTypeElementDocImpl.java ! src/share/classes/com/sun/tools/javadoc/DocEnv.java ! src/share/classes/com/sun/tools/javadoc/DocImpl.java ! src/share/classes/com/sun/tools/javadoc/JavadocClassReader.java ! src/share/classes/com/sun/tools/javadoc/JavadocMemberEnter.java ! src/share/classes/com/sun/tools/javadoc/PackageDocImpl.java From lana.steuck at oracle.com Tue Aug 9 11:23:18 2011 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Tue, 09 Aug 2011 18:23:18 +0000 Subject: hg: jdk7u/jdk7u/jdk: 5 new changesets Message-ID: <20110809182514.8B75247A60@hg.openjdk.java.net> Changeset: f01230bea4aa Author: weijun Date: 2011-08-03 21:32 +0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/jdk/rev/f01230bea4aa 7043737: klist does not detect non-existing keytab Reviewed-by: valeriep ! src/windows/classes/sun/security/krb5/internal/tools/Klist.java + test/sun/security/krb5/tools/ktmissing.sh Changeset: 9847e43556fb Author: dbuck Date: 2011-08-03 21:06 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/jdk/rev/9847e43556fb 7029903: Splash screen is not shown in 64-bit Linux with 16-bit color depth Summary: Added Xflush() call after splash screen is updated to ensure update is no stuck in client side buffer until JVM starts up. See JET review request 4154 for details. Reviewed-by: kevinw, anthony ! src/solaris/native/sun/awt/splashscreen/splashscreen_sys.c Changeset: 175f98d43a12 Author: ksrini Date: 2011-07-15 16:38 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/jdk/rev/175f98d43a12 7062969: java -help still shows http://java.sun.com/javase/reference Reviewed-by: ohair, darcy ! src/share/classes/sun/launcher/resources/launcher.properties Changeset: 440d5a3cfdf8 Author: ksrini Date: 2011-07-19 10:58 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/jdk/rev/440d5a3cfdf8 7067922: (launcher) java -jar throws NPE if JAR file does not contain Main-Class attribute Reviewed-by: darcy, ohair, alanb, mduigou ! src/share/classes/sun/launcher/LauncherHelper.java ! test/tools/launcher/Arrrghs.java ! test/tools/launcher/TestHelper.java Changeset: a5ea1f537169 Author: dholmes Date: 2011-08-08 02:51 -0400 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/jdk/rev/a5ea1f537169 7039182: PPC: NIO: java.io.IOException: Invalid argument in sun.nio.ch.FileDispatcherImpl.read0 Summary: Allow platform specific files to be located at build time instead of generating them (as per JDK8 changeset) Reviewed-by: alanb, ohair ! make/common/Defs-embedded.gmk ! make/java/nio/Makefile From dalibor.topic at oracle.com Tue Aug 9 14:33:04 2011 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Tue, 09 Aug 2011 23:33:04 +0200 Subject: mailing list administrator rights Message-ID: <4E41A790.6000208@oracle.com> Hi, just a quick note that I've made Edvard an administrator & moderator for this mailing list, so if you run into issues, either of us is capable of taking a go at fixing them. cheers, dalibor topic -- Oracle Dalibor Topic | Java F/OSS Ambassador Phone: +494023646738 | Mobile: +491772664192 Oracle Java Platform Group ORACLE Deutschland B.V. & Co. KG | Nagelsweg 55 | 20097 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: J?rgen Kunz, Marcel van de Molen, Alexander van der Ven Green Oracle Oracle is committed to developing practices and products that help protect the environment From kumar.x.srinivasan at oracle.COM Tue Aug 9 15:19:48 2011 From: kumar.x.srinivasan at oracle.COM (Kumar Srinivasan) Date: Tue, 09 Aug 2011 15:19:48 -0700 Subject: Request push approval : 7064544 In-Reply-To: <4E3C354A.1030005@oracle.COM> References: <4E3C354A.1030005@oracle.COM> Message-ID: <4E41B284.5070703@oracle.COM> Hi, Request approval for 7u2 push, The bug description is here: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7064544 The changeset in jdk8 is here: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/e9f118c2bd3c The changeset for 7u is identical to jdk8. No issues found in nightly testing ie. regressions, SQE and JCK tests. The changes will be pushed to: default-push = ssh://hg.openjdk.java.net/jdk7u/jdk7u-dev-gate/langtools Thanks Kumar From dalibor.topic at oracle.com Tue Aug 9 16:06:07 2011 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Wed, 10 Aug 2011 01:06:07 +0200 Subject: Request push approval : 7064544 In-Reply-To: <4E41B284.5070703@oracle.COM> References: <4E3C354A.1030005@oracle.COM> <4E41B284.5070703@oracle.COM> Message-ID: <4E41BD5F.7020601@oracle.com> On 8/10/11 12:19 AM, Kumar Srinivasan wrote: > Hi, > > Request approval for 7u2 push, > > The bug description is here: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7064544 > > The changeset in jdk8 is here: > http://hg.openjdk.java.net/jdk8/tl/langtools/rev/e9f118c2bd3c > > > The changeset for 7u is identical to jdk8. > No issues found in nightly testing ie. regressions, SQE and JCK tests. > > The changes will be pushed to: > default-push = ssh://hg.openjdk.java.net/jdk7u/jdk7u-dev-gate/langtools > > Thanks > Kumar > Thanks, Kumar - approved. cheers, dalibor topic -- Oracle Dalibor Topic | Java F/OSS Ambassador Phone: +494023646738 | Mobile: +491772664192 Oracle Java Platform Group ORACLE Deutschland B.V. & Co. KG | Nagelsweg 55 | 20097 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: J?rgen Kunz, Marcel van de Molen, Alexander van der Ven Green Oracle Oracle is committed to developing practices and products that help protect the environment From kumar.x.srinivasan at oracle.com Tue Aug 9 16:10:41 2011 From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com) Date: Tue, 09 Aug 2011 23:10:41 +0000 Subject: hg: jdk7u/jdk7u-dev/langtools: 7064544: (javadoc) miscellaneous fixes requested by netbeans Message-ID: <20110809231047.DB84A47A6E@hg.openjdk.java.net> Changeset: d5d8654d8180 Author: ksrini Date: 2011-08-05 19:41 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/langtools/rev/d5d8654d8180 7064544: (javadoc) miscellaneous fixes requested by netbeans Summary: Contributed by netbeans team, modified to suit by the langtools team. Reviewed-by: jjg, bpatel ! src/share/classes/com/sun/tools/javadoc/ClassDocImpl.java ! src/share/classes/com/sun/tools/javadoc/Comment.java ! src/share/classes/com/sun/tools/javadoc/JavadocEnter.java ! test/com/sun/javadoc/testLinkTaglet/TestLinkTaglet.java ! test/com/sun/javadoc/testLinkTaglet/pkg/C.java From lana.steuck at oracle.com Tue Aug 9 18:26:15 2011 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Tue, 9 Aug 2011 18:26:15 -0700 (PDT) Subject: jdk7u-b02: jdk7u-dev Message-ID: <201108100126.p7A1QFDN017693@jano-app.us.oracle.com> http://hg.openjdk.java.net/jdk7u/jdk7u/rev/91954c06ba1e http://hg.openjdk.java.net/jdk7u/jdk7u/langtools/rev/add40922e84d http://hg.openjdk.java.net/jdk7u/jdk7u/jdk/rev/a5ea1f537169 http://hg.openjdk.java.net/jdk7u/jdk7u/jaxws/rev/e94a8b7a9629 http://hg.openjdk.java.net/jdk7u/jdk7u/jaxp/rev/4b0c44f2f7f1 http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/790b18399cd4 http://hg.openjdk.java.net/jdk7u/jdk7u/corba/rev/e1a1c0d72264 --- All the fixes will be tested during promotion (no PIT testing at this point): 7029903 classes_awt Splash screen is not shown in 64-bit Linux with 16-bit color 7060926 compiler Attr.PostAttrAnalyzer misses a case 7061125 compiler Proposed javac argument processing performance improvement 7039182 embedded PPC: NIO: java.io.IOException: Invalid argument in sun.nio.c 6735320 javadoctool StringIndexOutOfBoundsException for empty @serialField tag 7059905 javadoctool (javadoc) promote method visibility for netbeans usage 7060642 tools (javadoc) improve performance on accessing inlinedTags 7062969 tools java -help still shows http://java.sun.com/javase/reference 7067922 tools (launcher) java -jar throws NPE if JAR file does not contain 7068902 tools (javac) allow enabling or disabling of String folding 7043737 krb5plugin klist does not detect non-existing keytab From dalibor.topic at oracle.com Tue Aug 9 18:39:00 2011 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Wed, 10 Aug 2011 03:39:00 +0200 Subject: Bulk changes: hotspot repository is open for business Message-ID: <4E41E134.5030403@oracle.com> Hi, It's time for our first set of bulk changes. The repository in question is hotspot, and the purpose is to integrate HotSpot Express 22 builds into 7u2. cheers, dalibor topic -- Oracle Dalibor Topic | Java F/OSS Ambassador Phone: +494023646738 | Mobile: +491772664192 Oracle Java Platform Group ORACLE Deutschland B.V. & Co. KG | Nagelsweg 55 | 20097 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: J?rgen Kunz, Marcel van de Molen, Alexander van der Ven Green Oracle Oracle is committed to developing practices and products that help protect the environment From xuelei.fan at oracle.com Tue Aug 9 20:00:05 2011 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 10 Aug 2011 11:00:05 +0800 Subject: Push request: 7065972, Some race condition may happen in SSLSocketImpl class Message-ID: <4E41F435.9080200@oracle.com> Hi All This is a request to backport a jdk8 fix into jdk7u2 b02. CR: 7065972: Some race condition may happen in SSLSocketImpl class Weblink: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7065972 Description: Initially, the TLS handshake listeners are supposed to be immutable. However, the deploy code need to update the TLS handshake listener collection since CR 6357710. As requires the multiple-thread-safe access to TLS handshake listener collection. The fix is already included in jdk8 as: Changeset: 99dc852080e1 Author: xuelei Date: 2011-07-19 21:47 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/99dc852080e1 7065972: Some race condition may happen in SSLSocketImpl class Reviewed-by: wetmore, weijun, dgu ! src/share/classes/sun/security/ssl/SSLSocketImpl.java The patch for jdk7u2 is identical to the one in jdk8. The webrev for JDK 7u2 is here: http://javaweb.us.oracle.com/~xf138604/bugbios/7065972.jdk7u/webrev.00/ I intend to push it to ssh://hg.openjdk.java.net/jdk7u/jdk7u-dev-gate/jdk Thanks Xuelei From dalibor.topic at oracle.com Tue Aug 9 20:05:09 2011 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Wed, 10 Aug 2011 05:05:09 +0200 Subject: Push request: 7065972, Some race condition may happen in SSLSocketImpl class In-Reply-To: <4E41F435.9080200@oracle.com> References: <4E41F435.9080200@oracle.com> Message-ID: <4E41F565.5070003@oracle.com> On 8/10/11 5:00 AM, Xuelei Fan wrote: > Hi All > > This is a request to backport a jdk8 fix into jdk7u2 b02. > > CR: 7065972: Some race condition may happen in SSLSocketImpl class > Weblink: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7065972 > > > Description: > > Initially, the TLS handshake listeners are supposed to be immutable. > However, the deploy code need to update the TLS handshake listener > collection since CR 6357710. As requires the multiple-thread-safe access > to TLS handshake listener collection. > > The fix is already included in jdk8 as: > > Changeset: 99dc852080e1 > Author: xuelei > Date: 2011-07-19 21:47 -0700 > URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/99dc852080e1 > > 7065972: Some race condition may happen in SSLSocketImpl class > Reviewed-by: wetmore, weijun, dgu > > ! src/share/classes/sun/security/ssl/SSLSocketImpl.java > > The patch for jdk7u2 is identical to the one in jdk8. > > The webrev for JDK 7u2 is here: > http://javaweb.us.oracle.com/~xf138604/bugbios/7065972.jdk7u/webrev.00/ > > I intend to push it to > > ssh://hg.openjdk.java.net/jdk7u/jdk7u-dev-gate/jdk > > Thanks > Xuelei Thanks, Xuelei, approved. cheers, dalibor topic -- Oracle Dalibor Topic | Java F/OSS Ambassador Phone: +494023646738 | Mobile: +491772664192 Oracle Java Platform Group ORACLE Deutschland B.V. & Co. KG | Nagelsweg 55 | 20097 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: J?rgen Kunz, Marcel van de Molen, Alexander van der Ven Green Oracle Oracle is committed to developing practices and products that help protect the environment From xuelei.fan at oracle.com Tue Aug 9 22:04:23 2011 From: xuelei.fan at oracle.com (xuelei.fan at oracle.com) Date: Wed, 10 Aug 2011 05:04:23 +0000 Subject: hg: jdk7u/jdk7u-dev/jdk: 7065972: Some race condition may happen in SSLSocketImpl class Message-ID: <20110810050434.0727B47A7C@hg.openjdk.java.net> Changeset: 62d3e2c51aa8 Author: xuelei Date: 2011-08-09 22:03 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/jdk/rev/62d3e2c51aa8 7065972: Some race condition may happen in SSLSocketImpl class Reviewed-by: wetmore, weijun, dgu ! src/share/classes/sun/security/ssl/SSLSocketImpl.java From sean.coffey at oracle.com Wed Aug 10 00:38:19 2011 From: sean.coffey at oracle.com (=?ISO-8859-1?Q?Se=E1n_Coffey?=) Date: Wed, 10 Aug 2011 08:38:19 +0100 Subject: Request for approval: 7049774 Message-ID: <4E42356B.5000604@oracle.com> resend #4 regards, Sean. -------- Original Message -------- Subject: Request for approval: 7049774 Date: Tue, 09 Aug 2011 15:35:23 +0100 From: Se?n Coffey To: jdk7u-dev at openjdk.java.net resend #3 On 09/08/2011 12:59, Se?n Coffey wrote: > Request to backport following from JDK 8 : > > UID construction appears to hang if time changed backwards > http://bugs.sun.com/view_bug.do?bug_id=7049774 > > Identical changeset from JDK 8 : > http://hg.openjdk.java.net/jdk8/tl/jdk/rev/08fdfdb19ad6 > > Builds fine. Other regression tests run. > > regards, > Sean. From sean.coffey at oracle.com Wed Aug 10 01:09:08 2011 From: sean.coffey at oracle.com (sean.coffey at oracle.com) Date: Wed, 10 Aug 2011 08:09:08 +0000 Subject: hg: jdk7u/jdk7u-dev/jdk: 7049774: UID construction appears to hang if time changed backwards Message-ID: <20110810080920.14E7B47A84@hg.openjdk.java.net> Changeset: 2c93c0965f99 Author: coffeys Date: 2011-08-10 09:08 +0100 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/jdk/rev/2c93c0965f99 7049774: UID construction appears to hang if time changed backwards Reviewed-by: alanb, dholmes, chegar, mduigou ! src/share/classes/java/rmi/server/UID.java From pavel.porvatov at oracle.com Wed Aug 10 07:51:48 2011 From: pavel.porvatov at oracle.com (pavel.porvatov at oracle.com) Date: Wed, 10 Aug 2011 14:51:48 +0000 Subject: hg: jdk7u/jdk7u-dev/jdk: 7019963: The goto parent directory button doesn't operate in JFileChooser Message-ID: <20110810145158.3026447A98@hg.openjdk.java.net> Changeset: 72b2b2a3f228 Author: rupashka Date: 2011-08-10 18:51 +0400 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/jdk/rev/72b2b2a3f228 7019963: The goto parent directory button doesn't operate in JFileChooser Reviewed-by: alexp ! src/share/classes/javax/swing/plaf/basic/BasicFileChooserUI.java From sergey.malenkov at sun.com Wed Aug 10 07:48:02 2011 From: sergey.malenkov at sun.com (sergey.malenkov at sun.com) Date: Wed, 10 Aug 2011 14:48:02 +0000 Subject: hg: jdk7u/jdk7u-dev/jdk: 7057459: Regression: Performance degradation with java.beans.XMLEncoder Message-ID: <20110810144823.CBB3747A96@hg.openjdk.java.net> Changeset: e01325b53a12 Author: malenkov Date: 2011-08-10 18:47 +0400 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/jdk/rev/e01325b53a12 7057459: Regression: Performance degradation with java.beans.XMLEncoder Reviewed-by: rupashka ! src/share/classes/java/beans/Encoder.java From pavel.porvatov at oracle.com Wed Aug 10 08:02:03 2011 From: pavel.porvatov at oracle.com (Pavel Porvatov) Date: Wed, 10 Aug 2011 19:02:03 +0400 Subject: Request for approval: 4909150 In-Reply-To: <4E41098B.7040209@oracle.com> References: <4E41098B.7040209@oracle.com> Message-ID: <4E429D6B.6070700@oracle.com> Hi, Could you please approve the fix of CR 4909150 (WindowsTreeUI can cause NullPointerException occasionally) for 7u2? Bug description is here: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4909150 Some time ago the fix was prepared, approved and pushed in jdk8: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/5c22624d193e For 7u2 the fix is the same and doesn't contain any modifications. Regards, Pavel From edvard.wendelin at oracle.com Wed Aug 10 08:04:15 2011 From: edvard.wendelin at oracle.com (Edvard Wendelin) Date: Wed, 10 Aug 2011 17:04:15 +0200 Subject: Request for approval: 4909150 In-Reply-To: <4E429D6B.6070700@oracle.com> References: <4E41098B.7040209@oracle.com> <4E429D6B.6070700@oracle.com> Message-ID: <4E429DEF.9060103@oracle.com> Approved. Use hg.openjdk.java.net/jdk7u/jdk7u-dev-gate/jdk/ for the push. Cheers, Edvard On 08/10/2011 05:02 PM, Pavel Porvatov wrote: > Hi, > > Could you please approve the fix of CR 4909150 (WindowsTreeUI can > cause NullPointerException occasionally) for 7u2? Bug description is > here: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4909150 > > Some time ago the fix was prepared, approved and pushed in jdk8: > http://hg.openjdk.java.net/jdk8/awt/jdk/rev/5c22624d193e > > For 7u2 the fix is the same and doesn't contain any modifications. > > Regards, Pavel From erik.trimble at oracle.com Wed Aug 10 19:16:41 2011 From: erik.trimble at oracle.com (Erik Trimble) Date: Wed, 10 Aug 2011 19:16:41 -0700 Subject: Process proposal for Updating JDK 7u with Hotspot Express... Message-ID: <1313029001.1843.242.camel@ghostbox> Hi folks. This email is to descibe the the process of integrating Hotspot Express versions into the JDK 7u series, and open a comment on the this process. It's rather long, so please read it carefully. Unlike work which is put into the other repositories in the jdk7u/ forest, Hotspot does not push individual (or small groups) of fixes in. This is because the Hotspot Express model eschews fixing existing Hotspot versions in favor of delivering fixes into a constantly-moving development train, then pushing that development train back into existing Update release (both 6 and 7, in this case). This prevents the Hotspot folks from having a maintain a huge number of disparate releases, and trying to backport fixes from the mainline development train. It also allows for the inclusion of advanced features into older JDK versions. --- The very latest Hotspot development version is always found here: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot Current, latest Hotspot version is HSX22.0. A copy of the latest STABLE version of HSX22 (i.e. one which has undergone a QA cycle) is found here: http://hg.openjdk.java.net/hsx/hsx22/hotspot Now, normally, after a QA cycle has passed, and the contents of hsx22/hotspot are refreshed with the newest stable bits, it is then promoted into the OpenJDK 8 repository ( hg.openjdk.java.net/jdk8/jdk8/hotspot ) Using the Hotspot Express model in the 7u series involves these steps [note that all references to '7u' or '7u-dev' refer to either http://hg.openjdk.java.net/jdk7u/jdk7u or http://hg.openjdk.java.net/jdk7u/jdk7u-dev, respectively]: 1.) Periodically, the contents of the latest hsx/hsxN/hotspot repository (i.e. the version matching the one currently in hsx/hotspot-main/hotspot ) will be put through a new QA cycle, as a candidate for inclusion in the 7u series. 2.) To be explicit, the QA cycle using this Hotspot Express snapshot will be using the latest 7u JDK, NOT the 8 JDK. Thus, we expect to discover any 7-specific issues with Hotspot BEFORE it is pushed into the Integration repository (7u-dev). 2a.) In addition, there will never be a Hotspot->7u integration until AFTER the same Hotspot version has been promoted into the JDK 8 forest, and undergone a full Release promotion cycle. This will be to make sure that the Hotspot version in hsx/hsxN/hotspot is indeed stabilized and we have worked out any immediately apparent serious issues. This may very well mean that Hotspot will not immediately promote all Hotspot builds unto 7u. E.g. HS20 b01 may go to JDK 8 Build 01, but if there are problems detected, then HS22 will not be pushed into 7u until those issues are addressed in a new HS build. So, it is entirely possible that an integration into 7u will actually encompass several Hotspot build numbers. 3.) At the beginning of this QA cycle, a webrev will be created, detailing ALL the changes vs the existing 7u/hotspot repository. That is, this will be a very large webrev, as it includes all the fixes between the latest development Hotspot and the existing 7u Hotspot. 4.) This webrev will be posted to cr.openjdk.java.net, and a "request for integration" notice will be sent to jdk7u-dev at openjdk.java.net, as normal for other integration requests. 5.) The 7u Technical Lead will approve the Hotspot update, taking into consideration the timing of the push - that is, approvals should be concerned with whether a new Hotspot version is appropriate given build schedules, NOT on the technical merits. 6.) After the approval has been received, the Hotspot snapshot undergoing QA will be pushed into the 7u-dev/hotspot Integration area. 7.) Upon receipt of the QA certification (PIT cert) that Hotspot has successfully passed all relevant testing (or, there are only inconsequential errors which aren't large enough to warrant a respin), the contents of 7u-dev/hotspot will be pushed up to the Master area (7u/hotspot ). A couple of notes: a) I expect that #3 and #4 will happen almost simultaneously. That is, our internal snapshot scripts will submit the job to QA and generate the webrev together. b) #5 should likely happen very shortly after #4, probably the same day. c) Frankly, technical discussion of the merits of the Hotspot push is not expected to be possible here (in the context of the integration, that is). The webrev is an informational post, not a "please review and approve" post. This is due to the very large number of CRs being fixed (several dozen or more), and the highly complex nature of all of them. Such review is carried out when the code is first pushed into hsx/hotspot-main and JDK8, so a duplicate review here is not necessary and is unlikely to be reasonably possible within the limited timeframe that an integration must have. (Translation: we can't post the webrev and wait 2 weeks for people to fully review and comment on things before integrating it). d) People interested in hotspot development (which will concern use of Hotspot in ALL JDK versions, 6, 7, and 8), should subscribe to hotspot-dev at openjdk.java.net. e) the 7uN repositories will NOT follow the above procedure - as they are "stabilization-only" repositories, Hotspot developers will be pushing changes directly to the /hotspot repository under the relevant 7uN forest in the same manner as all other stabilization fixes from other JDK developers. Thus, all fixes for Hotspot for 7uN releases will follow the standard JDK processes. One specific point where I'm not sure how we want to proceed is this: Should #6 (the push of the Hotspot snapshot into 7u-dev/hotspot) happen right after approval from the Technical Lead happen? If so, then it likely will be BEFORE QA has finished on the snapshot. This would be in line with the other JDK fixes, since they do not undergo QA before being pushed to 7u-dev/*. However, Hotspot is "special", so do we care to be extra sure that 7u-dev/hotspot is stable? Note that code being pushed to 7u-dev/hotspot will ALWAYS have passed a JPRT build (the basic all-platform build and sanity-check system internal to Oracle), so even if we do chose to push the Hotspot snapshot into 7u-dev before the QA cycle completes, we have reasonable assurances that it works (at the very least, will build). The push from 7u-dev/hotspot to 7u/hotspot will NEVER occur until a passed QA cycle (PIT) has occurred. Do people think it's OK to pushed to 7u-dev before PIT completes or not? If not, then the push to 7u-dev/hotspot will occur just before the push to 7u/hotspot (i.e. in essentially the same operation). --- If you have any comments or questions above the above, please speak up NOW. I've tried to be very clear about this process, and I think everything above is both reasonable and clear, but it may not be to some folks. Please ask or comment Right Now. I'd like to get this comment period over by 12pm (noon) Pacific Time, Friday, 12 August, so we can do the first Hotspot->7u integration later that day (so the RE folks can do a 7u build over the weekend). -- Erik Trimble Java Platform Group - Infrastructure Mailstop: usca22-317 Phone: x67195 Santa Clara, CA Timezone: US/Pacific (UTC-0800) From erik.trimble at oracle.com Wed Aug 10 19:50:38 2011 From: erik.trimble at oracle.com (Erik Trimble) Date: Wed, 10 Aug 2011 19:50:38 -0700 Subject: Community Input on Hotspot 22 integration into 7u Message-ID: <1313031038.1843.276.camel@ghostbox> Please see my related post on the process around integrating Hotspot Express versions into JDK 7u. This email is specifically about a technical question around the integration of Hotspot 22 b01 into the 7u series. The current situation is this: The contents of http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot (and jdk7u-dev/hotspot ) are derived from the JDK 7 FCS Hotspot, which is Hotspot 21 Build 17. Hotspot 22 is a fork from Hotspot 21 build 13, as HS21 was being stabilized for the JDK 7 release, and additional work needed a new place to reside. Thus, the current contents of jdk7u/hotspot are not an ancestor (in Hg terms) of the HS22 repository (http://hg.openjdk.java.net/hsx/hsx22/hotspot ). In particular, there are a multitude of instances where the same CR is fixed in both HS22 and HS21 in a different changeset. While the jcheck restriction on duplicate CRs has been relaxed for the 7u repositories (i.e. jcheck will complain, but will allow one to push a changeset that has an already-existing CR in the summary), there is a technical issue here. We have two options: A) We can delete the existing copy of jdk7u/jdk7u/hotspot (and all derived repositories, e.g. jdk7u/jdk7u-dev/hotspot ), and simply copy the new Hotspot 22 repository files into those places. This is done INSIDE the Hg servers, as a filesystem-level delete and copy. B) We can do a merge of the HS22 repo into the existing HS21 repo. From a technical standpoint, I've been informed that it's about a 4 on a 10-scale of difficulty to do. Here's the tradeoffs: Option A will require everyone to re-clone any repository they have made from any repo derived from jdk7u/jdk7u/hotspot. Obviously, we (Oracle) would have to publish a complete list of all repositories which were so affected. Option B would be simply business-as-usual. Option B would result in a repository with several dozen changesets which have both the same bugID (CR), AND which also perform the exact same code change. This can make code review a bit dicey, and results in a much "messier" history than Option A. Option B retains all the JDK 7 FCS-related tags (e.g. hs21-b1[4-7] and jdk7-b14[4-7]), while Option A does not have them (it stops at hs21-b13/jdk7-b143). The Option A replacement would be a one-time occurrence - no future update to the 7u/hotspot repo would ever have to undergo this replacement again (as all such future updates would be a direct descendant of the existing HS22 repo). The Option B merge would of course also be a one-time thing, though the "messy" history would remain forever. Both A and B require about the same level of work on our (Oracle's) end. B is slightly more risky than A, due to the added burden of making sure the merge is correct. Given that it is very, very early in the development process for 7u (we're on what, about build 02?), I would vote for cleanliness over some minor temporary inconvenience in re-cloning. Thus, personally, I would prefer Option A, avoiding the messy merge history, and forcing everyone to re-clone. But, this being a community, and I not being Dictator-for-Life, I put it to everyone here: A, or B? Replace or Merge? I'd like to do this HS22 integration right after the resolution to my "Process proposal for Updating JDK 7u with Hotspot Express..." proposal. Thus, please have your votes (and, of course, comments/questions) in by no later than 12pm (noon), on Friday, 12 August. Thanks, everyone! -- Erik Trimble Java Platform Group - Infrastructure Mailstop: usca22-317 Phone: x67195 Santa Clara, CA Timezone: US/Pacific (UTC-0800) From daniel.daugherty at oracle.com Wed Aug 10 21:12:08 2011 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 10 Aug 2011 22:12:08 -0600 Subject: Community Input on Hotspot 22 integration into 7u In-Reply-To: <1313031038.1843.276.camel@ghostbox> References: <1313031038.1843.276.camel@ghostbox> Message-ID: <4E435698.7060105@oracle.com> On 8/10/11 8:50 PM, Erik Trimble wrote: > But, this being a community, and I not being Dictator-for-Life, I put it > to everyone here: > > A, or B? Replace or Merge? Replace. Dan From pavel.porvatov at oracle.com Thu Aug 11 04:11:44 2011 From: pavel.porvatov at oracle.com (pavel.porvatov at oracle.com) Date: Thu, 11 Aug 2011 11:11:44 +0000 Subject: hg: jdk7u/jdk7u-dev/jdk: 4909150: WindowsTreeUI can cause NullPointerException occasionally Message-ID: <20110811111204.D1BB147ACA@hg.openjdk.java.net> Changeset: 22f8570179e7 Author: rupashka Date: 2011-08-11 15:10 +0400 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/jdk/rev/22f8570179e7 4909150: WindowsTreeUI can cause NullPointerException occasionally Reviewed-by: alexp ! src/share/classes/com/sun/java/swing/plaf/windows/WindowsTreeUI.java From ahughes at redhat.com Thu Aug 11 06:10:10 2011 From: ahughes at redhat.com (Dr Andrew John Hughes) Date: Thu, 11 Aug 2011 14:10:10 +0100 Subject: Push request: 7065972, Some race condition may happen in SSLSocketImpl class In-Reply-To: <4E41F435.9080200@oracle.com> References: <4E41F435.9080200@oracle.com> Message-ID: <20110811131009.GA7669@rivendell.middle-earth.co.uk> On 11:00 Wed 10 Aug , Xuelei Fan wrote: > Hi All > > This is a request to backport a jdk8 fix into jdk7u2 b02. > > CR: 7065972: Some race condition may happen in SSLSocketImpl class > Weblink: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7065972 > snip... > The webrev for JDK 7u2 is here: > http://javaweb.us.oracle.com/~xf138604/bugbios/7065972.jdk7u/webrev.00/ > This link is not accessible. Please only post public links to a public mailing list. -- 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: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37 From dalibor.topic at oracle.com Thu Aug 11 06:13:43 2011 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Thu, 11 Aug 2011 15:13:43 +0200 Subject: Push request: 7065972, Some race condition may happen in SSLSocketImpl class In-Reply-To: <20110811131009.GA7669@rivendell.middle-earth.co.uk> References: <4E41F435.9080200@oracle.com> <20110811131009.GA7669@rivendell.middle-earth.co.uk> Message-ID: <4E43D587.9020502@oracle.com> On 8/11/11 3:10 PM, Dr Andrew John Hughes wrote: > On 11:00 Wed 10 Aug , Xuelei Fan wrote: >> Hi All >> >> This is a request to backport a jdk8 fix into jdk7u2 b02. >> >> CR: 7065972: Some race condition may happen in SSLSocketImpl class >> Weblink: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7065972 >> > > snip... > >> The webrev for JDK 7u2 is here: >> http://javaweb.us.oracle.com/~xf138604/bugbios/7065972.jdk7u/webrev.00/ >> > > This link is not accessible. Please only post public links to a public > mailing list. Thanks for catching that, Andrew. cheers, dalibor topic -- Oracle Dalibor Topic | Java F/OSS Ambassador Phone: +494023646738 | Mobile: +491772664192 Oracle Java Platform Group ORACLE Deutschland B.V. & Co. KG | Nagelsweg 55 | 20097 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: J?rgen Kunz, Marcel van de Molen, Alexander van der Ven Green Oracle Oracle is committed to developing practices and products that help protect the environment From edvard.wendelin at oracle.com Thu Aug 11 07:21:46 2011 From: edvard.wendelin at oracle.com (Edvard Wendelin) Date: Thu, 11 Aug 2011 16:21:46 +0200 Subject: Community Input on Hotspot 22 integration into 7u In-Reply-To: <1313031038.1843.276.camel@ghostbox> References: <1313031038.1843.276.camel@ghostbox> Message-ID: <4E43E57A.9040300@oracle.com> Hi, In this case I'd vote for replace + good documentation of which repos you need to re-clone. Cheers, Edvard On 08/11/2011 04:50 AM, Erik Trimble wrote: > Please see my related post on the process around integrating Hotspot > Express versions into JDK 7u. > > > This email is specifically about a technical question around the > integration of Hotspot 22 b01 into the 7u series. > > The current situation is this: > > The contents of http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot (and > jdk7u-dev/hotspot ) are derived from the JDK 7 FCS Hotspot, which is > Hotspot 21 Build 17. > > Hotspot 22 is a fork from Hotspot 21 build 13, as HS21 was being > stabilized for the JDK 7 release, and additional work needed a new place > to reside. > > Thus, the current contents of jdk7u/hotspot are not an ancestor (in Hg > terms) of the HS22 repository > (http://hg.openjdk.java.net/hsx/hsx22/hotspot ). In particular, there > are a multitude of instances where the same CR is fixed in both HS22 and > HS21 in a different changeset. > > While the jcheck restriction on duplicate CRs has been relaxed for the > 7u repositories (i.e. jcheck will complain, but will allow one to push a > changeset that has an already-existing CR in the summary), there is a > technical issue here. > > We have two options: > > A) We can delete the existing copy of jdk7u/jdk7u/hotspot (and all > derived repositories, e.g. jdk7u/jdk7u-dev/hotspot ), and simply copy > the new Hotspot 22 repository files into those places. This is done > INSIDE the Hg servers, as a filesystem-level delete and copy. > > B) We can do a merge of the HS22 repo into the existing HS21 repo. From > a technical standpoint, I've been informed that it's about a 4 on a > 10-scale of difficulty to do. > > > Here's the tradeoffs: > > Option A will require everyone to re-clone any repository they have made > from any repo derived from jdk7u/jdk7u/hotspot. Obviously, we (Oracle) > would have to publish a complete list of all repositories which were so > affected. Option B would be simply business-as-usual. > > Option B would result in a repository with several dozen changesets > which have both the same bugID (CR), AND which also perform the exact > same code change. This can make code review a bit dicey, and results in > a much "messier" history than Option A. > > Option B retains all the JDK 7 FCS-related tags (e.g. hs21-b1[4-7] and > jdk7-b14[4-7]), while Option A does not have them (it stops at > hs21-b13/jdk7-b143). > > The Option A replacement would be a one-time occurrence - no future > update to the 7u/hotspot repo would ever have to undergo this > replacement again (as all such future updates would be a direct > descendant of the existing HS22 repo). The Option B merge would of > course also be a one-time thing, though the "messy" history would remain > forever. > > Both A and B require about the same level of work on our (Oracle's) end. > B is slightly more risky than A, due to the added burden of making sure > the merge is correct. > > > > Given that it is very, very early in the development process for 7u > (we're on what, about build 02?), I would vote for cleanliness over some > minor temporary inconvenience in re-cloning. Thus, personally, I would > prefer Option A, avoiding the messy merge history, and forcing everyone > to re-clone. > > But, this being a community, and I not being Dictator-for-Life, I put it > to everyone here: > > A, or B? Replace or Merge? > > > I'd like to do this HS22 integration right after the resolution to my > "Process proposal for Updating JDK 7u with Hotspot Express..." proposal. > Thus, please have your votes (and, of course, comments/questions) in by > no later than 12pm (noon), on Friday, 12 August. > > Thanks, everyone! > > > From edvard.wendelin at oracle.com Thu Aug 11 07:23:45 2011 From: edvard.wendelin at oracle.com (Edvard Wendelin) Date: Thu, 11 Aug 2011 16:23:45 +0200 Subject: Process proposal for Updating JDK 7u with Hotspot Express... In-Reply-To: <1313029001.1843.242.camel@ghostbox> References: <1313029001.1843.242.camel@ghostbox> Message-ID: <4E43E5F1.30508@oracle.com> Hi, My vote would be that you push to 7u-dev early and wait for QA cycle before integrating into master. It's better to find bugs sooner than later :) Cheers, Edvard On 08/11/2011 04:16 AM, Erik Trimble wrote: > Hi folks. > > This email is to descibe the the process of integrating Hotspot Express > versions into the JDK 7u series, and open a comment on the this process. > It's rather long, so please read it carefully. > > Unlike work which is put into the other repositories in the jdk7u/ > forest, Hotspot does not push individual (or small groups) of fixes in. > This is because the Hotspot Express model eschews fixing existing > Hotspot versions in favor of delivering fixes into a constantly-moving > development train, then pushing that development train back into > existing Update release (both 6 and 7, in this case). > > This prevents the Hotspot folks from having a maintain a huge number of > disparate releases, and trying to backport fixes from the mainline > development train. It also allows for the inclusion of advanced > features into older JDK versions. > > --- > > The very latest Hotspot development version is always found here: > > http://hg.openjdk.java.net/hsx/hotspot-main/hotspot > > Current, latest Hotspot version is HSX22.0. A copy of the latest STABLE > version of HSX22 (i.e. one which has undergone a QA cycle) is found > here: > > http://hg.openjdk.java.net/hsx/hsx22/hotspot > > > Now, normally, after a QA cycle has passed, and the contents of > hsx22/hotspot are refreshed with the newest stable bits, it is then > promoted into the OpenJDK 8 repository > ( hg.openjdk.java.net/jdk8/jdk8/hotspot ) > > Using the Hotspot Express model in the 7u series involves these steps > [note that all references to '7u' or '7u-dev' refer to either > http://hg.openjdk.java.net/jdk7u/jdk7u or > http://hg.openjdk.java.net/jdk7u/jdk7u-dev, respectively]: > > 1.) Periodically, the contents of the latest hsx/hsxN/hotspot repository > (i.e. the version matching the one currently in > hsx/hotspot-main/hotspot ) will be put through a new QA cycle, as a > candidate for inclusion in the 7u series. > > 2.) To be explicit, the QA cycle using this Hotspot Express snapshot > will be using the latest 7u JDK, NOT the 8 JDK. Thus, we expect to > discover any 7-specific issues with Hotspot BEFORE it is pushed into the > Integration repository (7u-dev). > > 2a.) In addition, there will never be a Hotspot->7u integration until > AFTER the same Hotspot version has been promoted into the JDK 8 forest, > and undergone a full Release promotion cycle. This will be to make sure > that the Hotspot version in hsx/hsxN/hotspot is indeed stabilized and we > have worked out any immediately apparent serious issues. This may very > well mean that Hotspot will not immediately promote all Hotspot builds > unto 7u. E.g. HS20 b01 may go to JDK 8 Build 01, but if there are > problems detected, then HS22 will not be pushed into 7u until those > issues are addressed in a new HS build. So, it is entirely possible that > an integration into 7u will actually encompass several Hotspot build > numbers. > > 3.) At the beginning of this QA cycle, a webrev will be created, > detailing ALL the changes vs the existing 7u/hotspot repository. That > is, this will be a very large webrev, as it includes all the fixes > between the latest development Hotspot and the existing 7u Hotspot. > > 4.) This webrev will be posted to cr.openjdk.java.net, and a "request > for integration" notice will be sent to jdk7u-dev at openjdk.java.net, as > normal for other integration requests. > > 5.) The 7u Technical Lead will approve the Hotspot update, taking into > consideration the timing of the push - that is, approvals should be > concerned with whether a new Hotspot version is appropriate given build > schedules, NOT on the technical merits. > > 6.) After the approval has been received, the Hotspot snapshot > undergoing QA will be pushed into the 7u-dev/hotspot Integration area. > > 7.) Upon receipt of the QA certification (PIT cert) that Hotspot has > successfully passed all relevant testing (or, there are only > inconsequential errors which aren't large enough to warrant a respin), > the contents of 7u-dev/hotspot will be pushed up to the Master area > (7u/hotspot ). > > A couple of notes: > > a) I expect that #3 and #4 will happen almost simultaneously. That is, > our internal snapshot scripts will submit the job to QA and generate the > webrev together. > > b) #5 should likely happen very shortly after #4, probably the same day. > > c) Frankly, technical discussion of the merits of the Hotspot push is > not expected to be possible here (in the context of the integration, > that is). The webrev is an informational post, not a "please review and > approve" post. This is due to the very large number of CRs being fixed > (several dozen or more), and the highly complex nature of all of them. > Such review is carried out when the code is first pushed into > hsx/hotspot-main and JDK8, so a duplicate review here is not necessary > and is unlikely to be reasonably possible within the limited timeframe > that an integration must have. (Translation: we can't post the webrev > and wait 2 weeks for people to fully review and comment on things before > integrating it). > > d) People interested in hotspot development (which will concern use of > Hotspot in ALL JDK versions, 6, 7, and 8), should subscribe to > hotspot-dev at openjdk.java.net. > > e) the 7uN repositories will NOT follow the above procedure - as they > are "stabilization-only" repositories, Hotspot developers will be > pushing changes directly to the /hotspot repository under the relevant > 7uN forest in the same manner as all other stabilization fixes from > other JDK developers. Thus, all fixes for Hotspot for 7uN releases will > follow the standard JDK processes. > > > One specific point where I'm not sure how we want to proceed is this: > > Should #6 (the push of the Hotspot snapshot into 7u-dev/hotspot) happen > right after approval from the Technical Lead happen? If so, then it > likely will be BEFORE QA has finished on the snapshot. This would be in > line with the other JDK fixes, since they do not undergo QA before being > pushed to 7u-dev/*. However, Hotspot is "special", so do we care to be > extra sure that 7u-dev/hotspot is stable? > > Note that code being pushed to 7u-dev/hotspot will ALWAYS have passed a > JPRT build (the basic all-platform build and sanity-check system > internal to Oracle), so even if we do chose to push the Hotspot snapshot > into 7u-dev before the QA cycle completes, we have reasonable assurances > that it works (at the very least, will build). > > The push from 7u-dev/hotspot to 7u/hotspot will NEVER occur until a > passed QA cycle (PIT) has occurred. > > Do people think it's OK to pushed to 7u-dev before PIT completes or not? > If not, then the push to 7u-dev/hotspot will occur just before the push > to 7u/hotspot (i.e. in essentially the same operation). > > --- > > If you have any comments or questions above the above, please speak up > NOW. I've tried to be very clear about this process, and I think > everything above is both reasonable and clear, but it may not be to some > folks. Please ask or comment Right Now. I'd like to get this comment > period over by 12pm (noon) Pacific Time, Friday, 12 August, so we can do > the first Hotspot->7u integration later that day (so the RE folks can do > a 7u build over the weekend). > > > > From dalibor.topic at oracle.com Thu Aug 11 07:37:16 2011 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Thu, 11 Aug 2011 16:37:16 +0200 Subject: Community Input on Hotspot 22 integration into 7u In-Reply-To: <1313031038.1843.276.camel@ghostbox> References: <1313031038.1843.276.camel@ghostbox> Message-ID: <4E43E91C.9080002@oracle.com> Thanks for the great & detailed post, Erik, and the insight into how the different options would play out. I agree that your proposal to replace and document is the better of the two choices. cheers, dalibor topic On 8/11/11 4:50 AM, Erik Trimble wrote: > Please see my related post on the process around integrating Hotspot > Express versions into JDK 7u. > > > This email is specifically about a technical question around the > integration of Hotspot 22 b01 into the 7u series. > > The current situation is this: > > The contents of http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot (and > jdk7u-dev/hotspot ) are derived from the JDK 7 FCS Hotspot, which is > Hotspot 21 Build 17. > > Hotspot 22 is a fork from Hotspot 21 build 13, as HS21 was being > stabilized for the JDK 7 release, and additional work needed a new place > to reside. > > Thus, the current contents of jdk7u/hotspot are not an ancestor (in Hg > terms) of the HS22 repository > (http://hg.openjdk.java.net/hsx/hsx22/hotspot ). In particular, there > are a multitude of instances where the same CR is fixed in both HS22 and > HS21 in a different changeset. > > While the jcheck restriction on duplicate CRs has been relaxed for the > 7u repositories (i.e. jcheck will complain, but will allow one to push a > changeset that has an already-existing CR in the summary), there is a > technical issue here. > > We have two options: > > A) We can delete the existing copy of jdk7u/jdk7u/hotspot (and all > derived repositories, e.g. jdk7u/jdk7u-dev/hotspot ), and simply copy > the new Hotspot 22 repository files into those places. This is done > INSIDE the Hg servers, as a filesystem-level delete and copy. > > B) We can do a merge of the HS22 repo into the existing HS21 repo. From > a technical standpoint, I've been informed that it's about a 4 on a > 10-scale of difficulty to do. > > > Here's the tradeoffs: > > Option A will require everyone to re-clone any repository they have made > from any repo derived from jdk7u/jdk7u/hotspot. Obviously, we (Oracle) > would have to publish a complete list of all repositories which were so > affected. Option B would be simply business-as-usual. > > Option B would result in a repository with several dozen changesets > which have both the same bugID (CR), AND which also perform the exact > same code change. This can make code review a bit dicey, and results in > a much "messier" history than Option A. > > Option B retains all the JDK 7 FCS-related tags (e.g. hs21-b1[4-7] and > jdk7-b14[4-7]), while Option A does not have them (it stops at > hs21-b13/jdk7-b143). > > The Option A replacement would be a one-time occurrence - no future > update to the 7u/hotspot repo would ever have to undergo this > replacement again (as all such future updates would be a direct > descendant of the existing HS22 repo). The Option B merge would of > course also be a one-time thing, though the "messy" history would remain > forever. > > Both A and B require about the same level of work on our (Oracle's) end. > B is slightly more risky than A, due to the added burden of making sure > the merge is correct. > > > > Given that it is very, very early in the development process for 7u > (we're on what, about build 02?), I would vote for cleanliness over some > minor temporary inconvenience in re-cloning. Thus, personally, I would > prefer Option A, avoiding the messy merge history, and forcing everyone > to re-clone. > > But, this being a community, and I not being Dictator-for-Life, I put it > to everyone here: > > A, or B? Replace or Merge? > > > I'd like to do this HS22 integration right after the resolution to my > "Process proposal for Updating JDK 7u with Hotspot Express..." proposal. > Thus, please have your votes (and, of course, comments/questions) in by > no later than 12pm (noon), on Friday, 12 August. > > Thanks, everyone! > > > -- Oracle Dalibor Topic | Java F/OSS Ambassador Phone: +494023646738 | Mobile: +491772664192 Oracle Java Platform Group ORACLE Deutschland B.V. & Co. KG | Nagelsweg 55 | 20097 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: J?rgen Kunz, Marcel van de Molen, Alexander van der Ven Green Oracle Oracle is committed to developing practices and products that help protect the environment From dalibor.topic at oracle.com Thu Aug 11 08:19:37 2011 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Thu, 11 Aug 2011 17:19:37 +0200 Subject: Process proposal for Updating JDK 7u with Hotspot Express... In-Reply-To: <1313029001.1843.242.camel@ghostbox> References: <1313029001.1843.242.camel@ghostbox> Message-ID: <4E43F309.7020205@oracle.com> Thanks for putting a lot of though into this process, Erik, this is great writeup. I think Edvard's spot on here, i.e. "push to 7u-dev early and wait for QA cycle before integrating into master". cheers, dalibor topic On 8/11/11 4:16 AM, Erik Trimble wrote: > Hi folks. > > This email is to descibe the the process of integrating Hotspot Express > versions into the JDK 7u series, and open a comment on the this process. > It's rather long, so please read it carefully. > > Unlike work which is put into the other repositories in the jdk7u/ > forest, Hotspot does not push individual (or small groups) of fixes in. > This is because the Hotspot Express model eschews fixing existing > Hotspot versions in favor of delivering fixes into a constantly-moving > development train, then pushing that development train back into > existing Update release (both 6 and 7, in this case). > > This prevents the Hotspot folks from having a maintain a huge number of > disparate releases, and trying to backport fixes from the mainline > development train. It also allows for the inclusion of advanced > features into older JDK versions. > > --- > > The very latest Hotspot development version is always found here: > > http://hg.openjdk.java.net/hsx/hotspot-main/hotspot > > Current, latest Hotspot version is HSX22.0. A copy of the latest STABLE > version of HSX22 (i.e. one which has undergone a QA cycle) is found > here: > > http://hg.openjdk.java.net/hsx/hsx22/hotspot > > > Now, normally, after a QA cycle has passed, and the contents of > hsx22/hotspot are refreshed with the newest stable bits, it is then > promoted into the OpenJDK 8 repository > ( hg.openjdk.java.net/jdk8/jdk8/hotspot ) > > Using the Hotspot Express model in the 7u series involves these steps > [note that all references to '7u' or '7u-dev' refer to either > http://hg.openjdk.java.net/jdk7u/jdk7u or > http://hg.openjdk.java.net/jdk7u/jdk7u-dev, respectively]: > > 1.) Periodically, the contents of the latest hsx/hsxN/hotspot repository > (i.e. the version matching the one currently in > hsx/hotspot-main/hotspot ) will be put through a new QA cycle, as a > candidate for inclusion in the 7u series. > > 2.) To be explicit, the QA cycle using this Hotspot Express snapshot > will be using the latest 7u JDK, NOT the 8 JDK. Thus, we expect to > discover any 7-specific issues with Hotspot BEFORE it is pushed into the > Integration repository (7u-dev). > > 2a.) In addition, there will never be a Hotspot->7u integration until > AFTER the same Hotspot version has been promoted into the JDK 8 forest, > and undergone a full Release promotion cycle. This will be to make sure > that the Hotspot version in hsx/hsxN/hotspot is indeed stabilized and we > have worked out any immediately apparent serious issues. This may very > well mean that Hotspot will not immediately promote all Hotspot builds > unto 7u. E.g. HS20 b01 may go to JDK 8 Build 01, but if there are > problems detected, then HS22 will not be pushed into 7u until those > issues are addressed in a new HS build. So, it is entirely possible that > an integration into 7u will actually encompass several Hotspot build > numbers. > > 3.) At the beginning of this QA cycle, a webrev will be created, > detailing ALL the changes vs the existing 7u/hotspot repository. That > is, this will be a very large webrev, as it includes all the fixes > between the latest development Hotspot and the existing 7u Hotspot. > > 4.) This webrev will be posted to cr.openjdk.java.net, and a "request > for integration" notice will be sent to jdk7u-dev at openjdk.java.net, as > normal for other integration requests. > > 5.) The 7u Technical Lead will approve the Hotspot update, taking into > consideration the timing of the push - that is, approvals should be > concerned with whether a new Hotspot version is appropriate given build > schedules, NOT on the technical merits. > > 6.) After the approval has been received, the Hotspot snapshot > undergoing QA will be pushed into the 7u-dev/hotspot Integration area. > > 7.) Upon receipt of the QA certification (PIT cert) that Hotspot has > successfully passed all relevant testing (or, there are only > inconsequential errors which aren't large enough to warrant a respin), > the contents of 7u-dev/hotspot will be pushed up to the Master area > (7u/hotspot ). > > A couple of notes: > > a) I expect that #3 and #4 will happen almost simultaneously. That is, > our internal snapshot scripts will submit the job to QA and generate the > webrev together. > > b) #5 should likely happen very shortly after #4, probably the same day. > > c) Frankly, technical discussion of the merits of the Hotspot push is > not expected to be possible here (in the context of the integration, > that is). The webrev is an informational post, not a "please review and > approve" post. This is due to the very large number of CRs being fixed > (several dozen or more), and the highly complex nature of all of them. > Such review is carried out when the code is first pushed into > hsx/hotspot-main and JDK8, so a duplicate review here is not necessary > and is unlikely to be reasonably possible within the limited timeframe > that an integration must have. (Translation: we can't post the webrev > and wait 2 weeks for people to fully review and comment on things before > integrating it). > > d) People interested in hotspot development (which will concern use of > Hotspot in ALL JDK versions, 6, 7, and 8), should subscribe to > hotspot-dev at openjdk.java.net. > > e) the 7uN repositories will NOT follow the above procedure - as they > are "stabilization-only" repositories, Hotspot developers will be > pushing changes directly to the /hotspot repository under the relevant > 7uN forest in the same manner as all other stabilization fixes from > other JDK developers. Thus, all fixes for Hotspot for 7uN releases will > follow the standard JDK processes. > > > One specific point where I'm not sure how we want to proceed is this: > > Should #6 (the push of the Hotspot snapshot into 7u-dev/hotspot) happen > right after approval from the Technical Lead happen? If so, then it > likely will be BEFORE QA has finished on the snapshot. This would be in > line with the other JDK fixes, since they do not undergo QA before being > pushed to 7u-dev/*. However, Hotspot is "special", so do we care to be > extra sure that 7u-dev/hotspot is stable? > > Note that code being pushed to 7u-dev/hotspot will ALWAYS have passed a > JPRT build (the basic all-platform build and sanity-check system > internal to Oracle), so even if we do chose to push the Hotspot snapshot > into 7u-dev before the QA cycle completes, we have reasonable assurances > that it works (at the very least, will build). > > The push from 7u-dev/hotspot to 7u/hotspot will NEVER occur until a > passed QA cycle (PIT) has occurred. > > Do people think it's OK to pushed to 7u-dev before PIT completes or not? > If not, then the push to 7u-dev/hotspot will occur just before the push > to 7u/hotspot (i.e. in essentially the same operation). > > --- > > If you have any comments or questions above the above, please speak up > NOW. I've tried to be very clear about this process, and I think > everything above is both reasonable and clear, but it may not be to some > folks. Please ask or comment Right Now. I'd like to get this comment > period over by 12pm (noon) Pacific Time, Friday, 12 August, so we can do > the first Hotspot->7u integration later that day (so the RE folks can do > a 7u build over the weekend). > > > > -- Oracle Dalibor Topic | Java F/OSS Ambassador Phone: +494023646738 | Mobile: +491772664192 Oracle Java Platform Group ORACLE Deutschland B.V. & Co. KG | Nagelsweg 55 | 20097 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: J?rgen Kunz, Marcel van de Molen, Alexander van der Ven Green Oracle Oracle is committed to developing practices and products that help protect the environment From james.holmlund at oracle.com Thu Aug 11 10:31:05 2011 From: james.holmlund at oracle.com (Jim Holmlund) Date: Thu, 11 Aug 2011 10:31:05 -0700 Subject: Community Input on Hotspot 22 integration into 7u In-Reply-To: <1313031038.1843.276.camel@ghostbox> References: <1313031038.1843.276.camel@ghostbox> Message-ID: <4E4411D9.4070200@oracle.com> HS 22 b01 causes a JCK test failure, see http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7076985 which was closed as a dup of this http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7075623 which I think is fixed in HS 22 b03. How long before HS 22 b03 is available to put into JDK 7u? - jjh On 8/10/2011 7:50 PM, Erik Trimble wrote: > Please see my related post on the process around integrating Hotspot > Express versions into JDK 7u. > > > This email is specifically about a technical question around the > integration of Hotspot 22 b01 into the 7u series. > > The current situation is this: > > The contents of http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot (and > jdk7u-dev/hotspot ) are derived from the JDK 7 FCS Hotspot, which is > Hotspot 21 Build 17. > > Hotspot 22 is a fork from Hotspot 21 build 13, as HS21 was being > stabilized for the JDK 7 release, and additional work needed a new place > to reside. > > Thus, the current contents of jdk7u/hotspot are not an ancestor (in Hg > terms) of the HS22 repository > (http://hg.openjdk.java.net/hsx/hsx22/hotspot ). In particular, there > are a multitude of instances where the same CR is fixed in both HS22 and > HS21 in a different changeset. > > While the jcheck restriction on duplicate CRs has been relaxed for the > 7u repositories (i.e. jcheck will complain, but will allow one to push a > changeset that has an already-existing CR in the summary), there is a > technical issue here. > > We have two options: > > A) We can delete the existing copy of jdk7u/jdk7u/hotspot (and all > derived repositories, e.g. jdk7u/jdk7u-dev/hotspot ), and simply copy > the new Hotspot 22 repository files into those places. This is done > INSIDE the Hg servers, as a filesystem-level delete and copy. > > B) We can do a merge of the HS22 repo into the existing HS21 repo. From > a technical standpoint, I've been informed that it's about a 4 on a > 10-scale of difficulty to do. > > > Here's the tradeoffs: > > Option A will require everyone to re-clone any repository they have made > from any repo derived from jdk7u/jdk7u/hotspot. Obviously, we (Oracle) > would have to publish a complete list of all repositories which were so > affected. Option B would be simply business-as-usual. > > Option B would result in a repository with several dozen changesets > which have both the same bugID (CR), AND which also perform the exact > same code change. This can make code review a bit dicey, and results in > a much "messier" history than Option A. > > Option B retains all the JDK 7 FCS-related tags (e.g. hs21-b1[4-7] and > jdk7-b14[4-7]), while Option A does not have them (it stops at > hs21-b13/jdk7-b143). > > The Option A replacement would be a one-time occurrence - no future > update to the 7u/hotspot repo would ever have to undergo this > replacement again (as all such future updates would be a direct > descendant of the existing HS22 repo). The Option B merge would of > course also be a one-time thing, though the "messy" history would remain > forever. > > Both A and B require about the same level of work on our (Oracle's) end. > B is slightly more risky than A, due to the added burden of making sure > the merge is correct. > > > > Given that it is very, very early in the development process for 7u > (we're on what, about build 02?), I would vote for cleanliness over some > minor temporary inconvenience in re-cloning. Thus, personally, I would > prefer Option A, avoiding the messy merge history, and forcing everyone > to re-clone. > > But, this being a community, and I not being Dictator-for-Life, I put it > to everyone here: > > A, or B? Replace or Merge? > > > I'd like to do this HS22 integration right after the resolution to my > "Process proposal for Updating JDK 7u with Hotspot Express..." proposal. > Thus, please have your votes (and, of course, comments/questions) in by > no later than 12pm (noon), on Friday, 12 August. > > Thanks, everyone! > > > From poonam.bajaj at oracle.com Thu Aug 11 11:10:46 2011 From: poonam.bajaj at oracle.com (Poonam Bajaj) Date: Thu, 11 Aug 2011 23:40:46 +0530 Subject: Process proposal for Updating JDK 7u with Hotspot Express... In-Reply-To: <1313029001.1843.242.camel@ghostbox> References: <1313029001.1843.242.camel@ghostbox> Message-ID: <4E441B26.70103@oracle.com> Hi Erik, > e) the 7uN repositories will NOT follow the above procedure - as they > are "stabilization-only" repositories, Hotspot developers will be > pushing changes directly to the /hotspot repository under the relevant > 7uN forest in the same manner as all other stabilization fixes from > other JDK developers. Thus, all fixes for Hotspot for 7uN releases will > follow the standard JDK processes. How will the versioning of hotspot under 7uN be handled ? Will we add minor version number to it or will just increment its build number ? e.g. if 7u2 gets hs22-b01 and integrations(stabilization fixes) are later made to 7u2/hotspot, what will be the 'hotspot' version after 7u2 promotion - something like hs22.1(or an appropriate higher minor version number) or hs22-b02 (or a higher build number depending upon the builds we'd have) ? > Should #6 (the push of the Hotspot snapshot into 7u-dev/hotspot) happen > right after approval from the Technical Lead happen? If so, then it > likely will be BEFORE QA has finished on the snapshot. This would be in > line with the other JDK fixes, since they do not undergo QA before being > pushed to 7u-dev/*. However, Hotspot is "special", so do we care to be > extra sure that 7u-dev/hotspot is stable? The changes going in with Hotspot push would be significantly large and so can not be compared with the other individual JDK fixes going into 7u-dev (without undergoing QA). I think we should be extra careful with hotspot and should be sure that things are stable before pushing hotspot-snapshot to 7u-dev/hotspot. Thanks, Poonam On 8/11/2011 7:46 AM, Erik Trimble wrote: > Hi folks. > > This email is to descibe the the process of integrating Hotspot Express > versions into the JDK 7u series, and open a comment on the this process. > It's rather long, so please read it carefully. > > Unlike work which is put into the other repositories in the jdk7u/ > forest, Hotspot does not push individual (or small groups) of fixes in. > This is because the Hotspot Express model eschews fixing existing > Hotspot versions in favor of delivering fixes into a constantly-moving > development train, then pushing that development train back into > existing Update release (both 6 and 7, in this case). > > This prevents the Hotspot folks from having a maintain a huge number of > disparate releases, and trying to backport fixes from the mainline > development train. It also allows for the inclusion of advanced > features into older JDK versions. > > --- > > The very latest Hotspot development version is always found here: > > http://hg.openjdk.java.net/hsx/hotspot-main/hotspot > > Current, latest Hotspot version is HSX22.0. A copy of the latest STABLE > version of HSX22 (i.e. one which has undergone a QA cycle) is found > here: > > http://hg.openjdk.java.net/hsx/hsx22/hotspot > > > Now, normally, after a QA cycle has passed, and the contents of > hsx22/hotspot are refreshed with the newest stable bits, it is then > promoted into the OpenJDK 8 repository > ( hg.openjdk.java.net/jdk8/jdk8/hotspot ) > > Using the Hotspot Express model in the 7u series involves these steps > [note that all references to '7u' or '7u-dev' refer to either > http://hg.openjdk.java.net/jdk7u/jdk7u or > http://hg.openjdk.java.net/jdk7u/jdk7u-dev, respectively]: > > 1.) Periodically, the contents of the latest hsx/hsxN/hotspot repository > (i.e. the version matching the one currently in > hsx/hotspot-main/hotspot ) will be put through a new QA cycle, as a > candidate for inclusion in the 7u series. > > 2.) To be explicit, the QA cycle using this Hotspot Express snapshot > will be using the latest 7u JDK, NOT the 8 JDK. Thus, we expect to > discover any 7-specific issues with Hotspot BEFORE it is pushed into the > Integration repository (7u-dev). > > 2a.) In addition, there will never be a Hotspot->7u integration until > AFTER the same Hotspot version has been promoted into the JDK 8 forest, > and undergone a full Release promotion cycle. This will be to make sure > that the Hotspot version in hsx/hsxN/hotspot is indeed stabilized and we > have worked out any immediately apparent serious issues. This may very > well mean that Hotspot will not immediately promote all Hotspot builds > unto 7u. E.g. HS20 b01 may go to JDK 8 Build 01, but if there are > problems detected, then HS22 will not be pushed into 7u until those > issues are addressed in a new HS build. So, it is entirely possible that > an integration into 7u will actually encompass several Hotspot build > numbers. > > 3.) At the beginning of this QA cycle, a webrev will be created, > detailing ALL the changes vs the existing 7u/hotspot repository. That > is, this will be a very large webrev, as it includes all the fixes > between the latest development Hotspot and the existing 7u Hotspot. > > 4.) This webrev will be posted to cr.openjdk.java.net, and a "request > for integration" notice will be sent to jdk7u-dev at openjdk.java.net, as > normal for other integration requests. > > 5.) The 7u Technical Lead will approve the Hotspot update, taking into > consideration the timing of the push - that is, approvals should be > concerned with whether a new Hotspot version is appropriate given build > schedules, NOT on the technical merits. > > 6.) After the approval has been received, the Hotspot snapshot > undergoing QA will be pushed into the 7u-dev/hotspot Integration area. > > 7.) Upon receipt of the QA certification (PIT cert) that Hotspot has > successfully passed all relevant testing (or, there are only > inconsequential errors which aren't large enough to warrant a respin), > the contents of 7u-dev/hotspot will be pushed up to the Master area > (7u/hotspot ). > > A couple of notes: > > a) I expect that #3 and #4 will happen almost simultaneously. That is, > our internal snapshot scripts will submit the job to QA and generate the > webrev together. > > b) #5 should likely happen very shortly after #4, probably the same day. > > c) Frankly, technical discussion of the merits of the Hotspot push is > not expected to be possible here (in the context of the integration, > that is). The webrev is an informational post, not a "please review and > approve" post. This is due to the very large number of CRs being fixed > (several dozen or more), and the highly complex nature of all of them. > Such review is carried out when the code is first pushed into > hsx/hotspot-main and JDK8, so a duplicate review here is not necessary > and is unlikely to be reasonably possible within the limited timeframe > that an integration must have. (Translation: we can't post the webrev > and wait 2 weeks for people to fully review and comment on things before > integrating it). > > d) People interested in hotspot development (which will concern use of > Hotspot in ALL JDK versions, 6, 7, and 8), should subscribe to > hotspot-dev at openjdk.java.net. > > e) the 7uN repositories will NOT follow the above procedure - as they > are "stabilization-only" repositories, Hotspot developers will be > pushing changes directly to the /hotspot repository under the relevant > 7uN forest in the same manner as all other stabilization fixes from > other JDK developers. Thus, all fixes for Hotspot for 7uN releases will > follow the standard JDK processes. > > > One specific point where I'm not sure how we want to proceed is this: > > Should #6 (the push of the Hotspot snapshot into 7u-dev/hotspot) happen > right after approval from the Technical Lead happen? If so, then it > likely will be BEFORE QA has finished on the snapshot. This would be in > line with the other JDK fixes, since they do not undergo QA before being > pushed to 7u-dev/*. However, Hotspot is "special", so do we care to be > extra sure that 7u-dev/hotspot is stable? > > Note that code being pushed to 7u-dev/hotspot will ALWAYS have passed a > JPRT build (the basic all-platform build and sanity-check system > internal to Oracle), so even if we do chose to push the Hotspot snapshot > into 7u-dev before the QA cycle completes, we have reasonable assurances > that it works (at the very least, will build). > > The push from 7u-dev/hotspot to 7u/hotspot will NEVER occur until a > passed QA cycle (PIT) has occurred. > > Do people think it's OK to pushed to 7u-dev before PIT completes or not? > If not, then the push to 7u-dev/hotspot will occur just before the push > to 7u/hotspot (i.e. in essentially the same operation). > > --- > > If you have any comments or questions above the above, please speak up > NOW. I've tried to be very clear about this process, and I think > everything above is both reasonable and clear, but it may not be to some > folks. Please ask or comment Right Now. I'd like to get this comment > period over by 12pm (noon) Pacific Time, Friday, 12 August, so we can do > the first Hotspot->7u integration later that day (so the RE folks can do > a 7u build over the weekend). > > > > > -- Best regards, Poonam Sun, an Oracle company Sun, an Oracle Company Poonam Bajaj | Staff Engineer Phone: +66937451 | Mobile: +9844511366 JVM Sustaining Engineering | Bangalore Green Oracle Oracle is committed to developing practices and products that help protect the environment From poonam.bajaj at oracle.com Thu Aug 11 11:58:42 2011 From: poonam.bajaj at oracle.com (Poonam Bajaj) Date: Fri, 12 Aug 2011 00:28:42 +0530 Subject: Process proposal for Updating JDK 7u with Hotspot Express... In-Reply-To: <4E441B26.70103@oracle.com> References: <1313029001.1843.242.camel@ghostbox> <4E441B26.70103@oracle.com> Message-ID: <4E442662.3020806@oracle.com> On 8/11/2011 11:40 PM, Poonam Bajaj wrote: > Hi Erik, > >> e) the 7uN repositories will NOT follow the above procedure - as they >> are "stabilization-only" repositories, Hotspot developers will be >> pushing changes directly to the /hotspot repository under the relevant >> 7uN forest in the same manner as all other stabilization fixes from >> other JDK developers. Thus, all fixes for Hotspot for 7uN releases will >> follow the standard JDK processes. > How will the versioning of hotspot under 7uN be handled ? Will we add > minor version number > to it or will just increment its build number ? > > e.g. if 7u2 gets hs22-b01 and integrations(stabilization fixes) are > later made to 7u2/hotspot, > what will be the 'hotspot' version after 7u2 promotion - something > like hs22.1(or an appropriate > higher minor version number) or hs22-b02 (or a higher build number > depending upon the builds > we'd have) ? Answering part of my own question, we can not have HSxx-bxx to represent the hotspot verisons in 7uN as that represents the builds from the mainline Hotspot Express development train. >> Should #6 (the push of the Hotspot snapshot into 7u-dev/hotspot) happen >> right after approval from the Technical Lead happen? If so, then it >> likely will be BEFORE QA has finished on the snapshot. This would be in >> line with the other JDK fixes, since they do not undergo QA before being >> pushed to 7u-dev/*. However, Hotspot is "special", so do we care to be >> extra sure that 7u-dev/hotspot is stable? > The changes going in with Hotspot push would be significantly large > and so can not be > compared with the other individual JDK fixes going into 7u-dev > (without undergoing QA). > I think we should be extra careful with hotspot and should be sure > that things are stable before > pushing hotspot-snapshot to 7u-dev/hotspot. > Thanks, Poonam > Thanks, > Poonam > > On 8/11/2011 7:46 AM, Erik Trimble wrote: >> Hi folks. >> >> This email is to descibe the the process of integrating Hotspot Express >> versions into the JDK 7u series, and open a comment on the this process. >> It's rather long, so please read it carefully. >> >> Unlike work which is put into the other repositories in the jdk7u/ >> forest, Hotspot does not push individual (or small groups) of fixes in. >> This is because the Hotspot Express model eschews fixing existing >> Hotspot versions in favor of delivering fixes into a constantly-moving >> development train, then pushing that development train back into >> existing Update release (both 6 and 7, in this case). >> >> This prevents the Hotspot folks from having a maintain a huge number of >> disparate releases, and trying to backport fixes from the mainline >> development train. It also allows for the inclusion of advanced >> features into older JDK versions. >> >> --- >> >> The very latest Hotspot development version is always found here: >> >> http://hg.openjdk.java.net/hsx/hotspot-main/hotspot >> >> Current, latest Hotspot version is HSX22.0. A copy of the latest STABLE >> version of HSX22 (i.e. one which has undergone a QA cycle) is found >> here: >> >> http://hg.openjdk.java.net/hsx/hsx22/hotspot >> >> >> Now, normally, after a QA cycle has passed, and the contents of >> hsx22/hotspot are refreshed with the newest stable bits, it is then >> promoted into the OpenJDK 8 repository >> ( hg.openjdk.java.net/jdk8/jdk8/hotspot ) >> >> Using the Hotspot Express model in the 7u series involves these steps >> [note that all references to '7u' or '7u-dev' refer to either >> http://hg.openjdk.java.net/jdk7u/jdk7u or >> http://hg.openjdk.java.net/jdk7u/jdk7u-dev, respectively]: >> >> 1.) Periodically, the contents of the latest hsx/hsxN/hotspot repository >> (i.e. the version matching the one currently in >> hsx/hotspot-main/hotspot ) will be put through a new QA cycle, as a >> candidate for inclusion in the 7u series. >> >> 2.) To be explicit, the QA cycle using this Hotspot Express snapshot >> will be using the latest 7u JDK, NOT the 8 JDK. Thus, we expect to >> discover any 7-specific issues with Hotspot BEFORE it is pushed into the >> Integration repository (7u-dev). >> 2a.) In addition, there will never be a Hotspot->7u integration until >> AFTER the same Hotspot version has been promoted into the JDK 8 forest, >> and undergone a full Release promotion cycle. This will be to make sure >> that the Hotspot version in hsx/hsxN/hotspot is indeed stabilized and we >> have worked out any immediately apparent serious issues. This may very >> well mean that Hotspot will not immediately promote all Hotspot builds >> unto 7u. E.g. HS20 b01 may go to JDK 8 Build 01, but if there are >> problems detected, then HS22 will not be pushed into 7u until those >> issues are addressed in a new HS build. So, it is entirely possible that >> an integration into 7u will actually encompass several Hotspot build >> numbers. >> >> 3.) At the beginning of this QA cycle, a webrev will be created, >> detailing ALL the changes vs the existing 7u/hotspot repository. That >> is, this will be a very large webrev, as it includes all the fixes >> between the latest development Hotspot and the existing 7u Hotspot. >> >> 4.) This webrev will be posted to cr.openjdk.java.net, and a "request >> for integration" notice will be sent to jdk7u-dev at openjdk.java.net, as >> normal for other integration requests. >> >> 5.) The 7u Technical Lead will approve the Hotspot update, taking into >> consideration the timing of the push - that is, approvals should be >> concerned with whether a new Hotspot version is appropriate given build >> schedules, NOT on the technical merits. >> 6.) After the approval has been received, the Hotspot snapshot >> undergoing QA will be pushed into the 7u-dev/hotspot Integration area. >> >> 7.) Upon receipt of the QA certification (PIT cert) that Hotspot has >> successfully passed all relevant testing (or, there are only >> inconsequential errors which aren't large enough to warrant a respin), >> the contents of 7u-dev/hotspot will be pushed up to the Master area >> (7u/hotspot ). >> >> A couple of notes: >> >> a) I expect that #3 and #4 will happen almost simultaneously. That is, >> our internal snapshot scripts will submit the job to QA and generate the >> webrev together. >> >> b) #5 should likely happen very shortly after #4, probably the same day. >> >> c) Frankly, technical discussion of the merits of the Hotspot push is >> not expected to be possible here (in the context of the integration, >> that is). The webrev is an informational post, not a "please review and >> approve" post. This is due to the very large number of CRs being fixed >> (several dozen or more), and the highly complex nature of all of them. >> Such review is carried out when the code is first pushed into >> hsx/hotspot-main and JDK8, so a duplicate review here is not necessary >> and is unlikely to be reasonably possible within the limited timeframe >> that an integration must have. (Translation: we can't post the webrev >> and wait 2 weeks for people to fully review and comment on things before >> integrating it). >> d) People interested in hotspot development (which will concern use of >> Hotspot in ALL JDK versions, 6, 7, and 8), should subscribe to >> hotspot-dev at openjdk.java.net. >> e) the 7uN repositories will NOT follow the above procedure - as they >> are "stabilization-only" repositories, Hotspot developers will be >> pushing changes directly to the /hotspot repository under the relevant >> 7uN forest in the same manner as all other stabilization fixes from >> other JDK developers. Thus, all fixes for Hotspot for 7uN releases will >> follow the standard JDK processes. >> >> >> One specific point where I'm not sure how we want to proceed is this: >> >> Should #6 (the push of the Hotspot snapshot into 7u-dev/hotspot) happen >> right after approval from the Technical Lead happen? If so, then it >> likely will be BEFORE QA has finished on the snapshot. This would be in >> line with the other JDK fixes, since they do not undergo QA before being >> pushed to 7u-dev/*. However, Hotspot is "special", so do we care to be >> extra sure that 7u-dev/hotspot is stable? >> Note that code being pushed to 7u-dev/hotspot will ALWAYS have passed a >> JPRT build (the basic all-platform build and sanity-check system >> internal to Oracle), so even if we do chose to push the Hotspot snapshot >> into 7u-dev before the QA cycle completes, we have reasonable assurances >> that it works (at the very least, will build). >> >> The push from 7u-dev/hotspot to 7u/hotspot will NEVER occur until a >> passed QA cycle (PIT) has occurred. >> Do people think it's OK to pushed to 7u-dev before PIT completes or not? >> If not, then the push to 7u-dev/hotspot will occur just before the push >> to 7u/hotspot (i.e. in essentially the same operation). >> >> --- >> >> If you have any comments or questions above the above, please speak up >> NOW. I've tried to be very clear about this process, and I think >> everything above is both reasonable and clear, but it may not be to some >> folks. Please ask or comment Right Now. I'd like to get this comment >> period over by 12pm (noon) Pacific Time, Friday, 12 August, so we can do >> the first Hotspot->7u integration later that day (so the RE folks can do >> a 7u build over the weekend). >> >> >> >> >> From erik.trimble at oracle.com Thu Aug 11 14:02:36 2011 From: erik.trimble at oracle.com (Erik Trimble) Date: Thu, 11 Aug 2011 14:02:36 -0700 Subject: Process proposal for Updating JDK 7u with Hotspot Express... In-Reply-To: <4E442662.3020806@oracle.com> References: <1313029001.1843.242.camel@ghostbox> <4E441B26.70103@oracle.com> <4E442662.3020806@oracle.com> Message-ID: <4E44436C.7080206@oracle.com> On 8/11/2011 11:58 AM, Poonam Bajaj wrote: > > On 8/11/2011 11:40 PM, Poonam Bajaj wrote: >> Hi Erik, >> >>> e) the 7uN repositories will NOT follow the above procedure - as they >>> are "stabilization-only" repositories, Hotspot developers will be >>> pushing changes directly to the /hotspot repository under the relevant >>> 7uN forest in the same manner as all other stabilization fixes from >>> other JDK developers. Thus, all fixes for Hotspot for 7uN releases will >>> follow the standard JDK processes. >> How will the versioning of hotspot under 7uN be handled ? Will we add >> minor version number >> to it or will just increment its build number ? >> >> e.g. if 7u2 gets hs22-b01 and integrations(stabilization fixes) are >> later made to 7u2/hotspot, >> what will be the 'hotspot' version after 7u2 promotion - something >> like hs22.1(or an appropriate >> higher minor version number) or hs22-b02 (or a higher build number >> depending upon the builds >> we'd have) ? > Answering part of my own question, we can not have HSxx-bxx to represent > the hotspot verisons in 7uN as that represents the builds from the > mainline > Hotspot Express development train. > Once a 7uN is forked from the mainline 7u development, it will "inherit" the Hotspot version from mainline. E.g. in the current case, where HS22 is the 7u mainline Hotspot, when 7u2 forks off for stabilization, 7u2 will remain Hotspot 22, with increasing build numbers as we do stabilization The mainline 7u Hotspot will bump up in Major version at that time (e.g. it will go to Hotspot 23) - actually, we'll bump the Major version in the Hotspot development area (hsx/hotspot-main/hotspot), and the next push from there in 7u will increment the Major number (and reset the build to 01). Generally speaking, Minor number bumps will be reserved for 6Update use, or JFB (or CPU) releases of 7Updates. >>> Should #6 (the push of the Hotspot snapshot into 7u-dev/hotspot) happen >>> right after approval from the Technical Lead happen? If so, then it >>> likely will be BEFORE QA has finished on the snapshot. This would be in >>> line with the other JDK fixes, since they do not undergo QA before >>> being >>> pushed to 7u-dev/*. However, Hotspot is "special", so do we care to be >>> extra sure that 7u-dev/hotspot is stable? >> The changes going in with Hotspot push would be significantly large >> and so can not be >> compared with the other individual JDK fixes going into 7u-dev >> (without undergoing QA). >> I think we should be extra careful with hotspot and should be sure >> that things are stable before >> pushing hotspot-snapshot to 7u-dev/hotspot. >> > > Thanks, > Poonam -- Erik Trimble Java Platform Group Infrastructure Mailstop: usca22-317 Phone: x67195 Santa Clara, CA Timezone: US/Pacific (UTC-0800) From xuelei.fan at oracle.com Thu Aug 11 17:39:00 2011 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 12 Aug 2011 08:39:00 +0800 Subject: Push request: 7065972, Some race condition may happen in SSLSocketImpl class In-Reply-To: <4E43D587.9020502@oracle.com> References: <4E41F435.9080200@oracle.com> <20110811131009.GA7669@rivendell.middle-earth.co.uk> <4E43D587.9020502@oracle.com> Message-ID: <4E447624.10908@oracle.com> On 8/11/2011 9:13 PM, Dalibor Topic wrote: > On 8/11/11 3:10 PM, Dr Andrew John Hughes wrote: >> On 11:00 Wed 10 Aug , Xuelei Fan wrote: >>> Hi All >>> >>> This is a request to backport a jdk8 fix into jdk7u2 b02. >>> >>> CR: 7065972: Some race condition may happen in SSLSocketImpl class >>> Weblink: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7065972 >>> >> >> snip... >> >>> The webrev for JDK 7u2 is here: >>> http://javaweb.us.oracle.com/~xf138604/bugbios/7065972.jdk7u/webrev.00/ >>> >> >> This link is not accessible. Please only post public links to a public >> mailing list. A bad link. The open webrev should be: http://cr.openjdk.java.net/~xuelei/7065972.jdk7u/webrev.00/ Thanks for catching. Xuelei > > Thanks for catching that, Andrew. > > cheers, > dalibor topic > From weijun.wang at oracle.com Thu Aug 11 20:15:14 2011 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Fri, 12 Aug 2011 03:15:14 +0000 Subject: hg: jdk7u/jdk7u-dev/jdk: 7061379: [Kerberos] Cross-realm authentication fails, due to nameType problem Message-ID: <20110812031524.4222647AF8@hg.openjdk.java.net> Changeset: 56fc480ef969 Author: weijun Date: 2011-08-12 11:14 +0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/jdk/rev/56fc480ef969 7061379: [Kerberos] Cross-realm authentication fails, due to nameType problem Reviewed-by: valeriep ! src/share/classes/sun/security/krb5/PrincipalName.java ! test/sun/security/krb5/auto/KDC.java + test/sun/security/krb5/auto/PrincipalNameEquals.java From ahughes at redhat.com Fri Aug 12 00:23:37 2011 From: ahughes at redhat.com (Dr Andrew John Hughes) Date: Fri, 12 Aug 2011 08:23:37 +0100 Subject: Community Input on Hotspot 22 integration into 7u In-Reply-To: <1313031038.1843.276.camel@ghostbox> References: <1313031038.1843.276.camel@ghostbox> Message-ID: <20110812072337.GD25807@rivendell.middle-earth.co.uk> On 19:50 Wed 10 Aug , Erik Trimble wrote: > Please see my related post on the process around integrating Hotspot > Express versions into JDK 7u. > > > This email is specifically about a technical question around the > integration of Hotspot 22 b01 into the 7u series. > > The current situation is this: > > The contents of http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot (and > jdk7u-dev/hotspot ) are derived from the JDK 7 FCS Hotspot, which is > Hotspot 21 Build 17. > > Hotspot 22 is a fork from Hotspot 21 build 13, as HS21 was being > stabilized for the JDK 7 release, and additional work needed a new place > to reside. > > Thus, the current contents of jdk7u/hotspot are not an ancestor (in Hg > terms) of the HS22 repository > (http://hg.openjdk.java.net/hsx/hsx22/hotspot ). In particular, there > are a multitude of instances where the same CR is fixed in both HS22 and > HS21 in a different changeset. > > While the jcheck restriction on duplicate CRs has been relaxed for the > 7u repositories (i.e. jcheck will complain, but will allow one to push a > changeset that has an already-existing CR in the summary), there is a > technical issue here. > > We have two options: > > A) We can delete the existing copy of jdk7u/jdk7u/hotspot (and all > derived repositories, e.g. jdk7u/jdk7u-dev/hotspot ), and simply copy > the new Hotspot 22 repository files into those places. This is done > INSIDE the Hg servers, as a filesystem-level delete and copy. > > B) We can do a merge of the HS22 repo into the existing HS21 repo. From > a technical standpoint, I've been informed that it's about a 4 on a > 10-scale of difficulty to do. > > > Here's the tradeoffs: > > Option A will require everyone to re-clone any repository they have made > from any repo derived from jdk7u/jdk7u/hotspot. Obviously, we (Oracle) > would have to publish a complete list of all repositories which were so > affected. Option B would be simply business-as-usual. > > Option B would result in a repository with several dozen changesets > which have both the same bugID (CR), AND which also perform the exact > same code change. This can make code review a bit dicey, and results in > a much "messier" history than Option A. > > Option B retains all the JDK 7 FCS-related tags (e.g. hs21-b1[4-7] and > jdk7-b14[4-7]), while Option A does not have them (it stops at > hs21-b13/jdk7-b143). > > The Option A replacement would be a one-time occurrence - no future > update to the 7u/hotspot repo would ever have to undergo this > replacement again (as all such future updates would be a direct > descendant of the existing HS22 repo). The Option B merge would of > course also be a one-time thing, though the "messy" history would remain > forever. > > Both A and B require about the same level of work on our (Oracle's) end. > B is slightly more risky than A, due to the added burden of making sure > the merge is correct. > > > > Given that it is very, very early in the development process for 7u > (we're on what, about build 02?), I would vote for cleanliness over some > minor temporary inconvenience in re-cloning. Thus, personally, I would > prefer Option A, avoiding the messy merge history, and forcing everyone > to re-clone. > > But, this being a community, and I not being Dictator-for-Life, I put it > to everyone here: > > A, or B? Replace or Merge? > > > I'd like to do this HS22 integration right after the resolution to my > "Process proposal for Updating JDK 7u with Hotspot Express..." proposal. > Thus, please have your votes (and, of course, comments/questions) in by > no later than 12pm (noon), on Friday, 12 August. > > Thanks, everyone! > > > > -- > Erik Trimble > Java Platform Group - Infrastructure > Mailstop: usca22-317 > Phone: x67195 > Santa Clara, CA > Timezone: US/Pacific (UTC-0800) > > Merge. Doing otherwise would destroy history that may be needed at a later juncture. We've been careful to retain everything with OpenJDK6. These still have the same common ancestors, right? As in you don't need to rebase? -- 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: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37 From sean.coffey at oracle.com Fri Aug 12 01:24:17 2011 From: sean.coffey at oracle.com (=?ISO-8859-1?Q?Se=E1n_Coffey?=) Date: Fri, 12 Aug 2011 09:24:17 +0100 Subject: Request for approval: 7047325 - 7u-dev Message-ID: <4E44E331.7030501@oracle.com> CR 7047325 is an internal RFE : Internal API to improve management of direct buffers This RFE was introduced in a 6 update release and with jdk 7u & jdk 8 in the open, I'm porting this change forward from the proprietary jdk6 updates. The change adds an internal API to improve the management of direct buffers. The changeset is identical is that which recently went into jdk8/tl : http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ddcb874581eb Regards, Sean. From edvard.wendelin at oracle.com Fri Aug 12 01:32:56 2011 From: edvard.wendelin at oracle.com (Edvard Wendelin) Date: Fri, 12 Aug 2011 10:32:56 +0200 Subject: Request for approval: 7047325 - 7u-dev In-Reply-To: <4E44E331.7030501@oracle.com> References: <4E44E331.7030501@oracle.com> Message-ID: <27959A48-3E7B-41C6-972A-1783B0239934@oracle.com> Approved! Please use hg.openjdk.java.net/jdk7u/jdk7u-dev-gate/jdk/ for the push. Cheers, Edvard On 12 aug 2011, at 10.24, Se?n Coffey wrote: > CR 7047325 is an internal RFE : Internal API to improve management > of direct buffers > > This RFE was introduced in a 6 update release and with jdk 7u & jdk > 8 in the open, I'm porting this change forward from the proprietary > jdk6 updates. The change adds an internal API to improve the > management of direct buffers. > > The changeset is identical is that which recently went into jdk8/tl : > > http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ddcb874581eb > > Regards, > Sean. > > From sean.coffey at oracle.com Fri Aug 12 01:41:38 2011 From: sean.coffey at oracle.com (sean.coffey at oracle.com) Date: Fri, 12 Aug 2011 08:41:38 +0000 Subject: hg: jdk7u/jdk7u-dev/jdk: 7047325: Internal API to improve management of direct buffers Message-ID: <20110812084157.76DAD47B07@hg.openjdk.java.net> Changeset: 449f7f1bb735 Author: coffeys Date: 2011-08-12 09:40 +0100 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/jdk/rev/449f7f1bb735 7047325: Internal API to improve management of direct buffers Reviewed-by: alanb, mduigou ! make/com/oracle/Makefile - make/com/oracle/net/Makefile ! make/common/Release.gmk ! src/share/classes/java/nio/Bits.java ! src/share/classes/java/nio/Buffer.java ! src/share/classes/java/nio/Direct-X-Buffer.java.template ! src/share/classes/sun/misc/JavaNioAccess.java ! src/share/classes/sun/nio/ch/DirectBuffer.java From jonathan.gibbons at oracle.com Fri Aug 12 14:48:00 2011 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 12 Aug 2011 14:48:00 -0700 Subject: Request for approval for 7074189 Message-ID: <4E459F90.3040308@oracle.com> Bug: 7074189 JDK 8 Changeset: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/c0d5f93af048 The bug is not currently visible on bugs.sun.com. Here is the relevant info: *Synopsis*: some javac tests fail with latest jtreg 4.1 b03 ===*Description* ============================================================ 3 tests fail using jtreg 4.1 b03 ===*Evaluation* ============================================================= There are three test failures: tools/javac/processing/errors/TestOptionSyntaxErrors.java tools/javac/processing/errors/TestReturnCode.java tools/javac/warnings/Serial.java *** (#1 of 4): 2011-08-03 17:03:10 GMT+00:00jonathan.gibbons at oracle.com 1. test/tools/javac/warnings/Serial.java The action * @compile/fail -Werror -Xlint:all,-path T4994049/ Serial.java is nonsensical, and succeeding because the compilation fails for the wrong reason. The line should be deleted. *** (#2 of 4): 2011-08-03 17:03:10 GMT+00:00jonathan.gibbons at oracle.com 2. The other two tests are expecting "less common" exit codes from javac. The best way to fix them is to write a library class, CompileFail, which emulates @compile/fail but which also allows the specific exit code to be tested. *** (#3 of 4): 2011-08-03 22:31:37 GMT+00:00jonathan.gibbons at oracle.com Hmmm, we've uncovered a curiousity in TestReturnCode.java. Errors thrown from annotation processors are treated different (and less severely) than exceptions. Errors cause EXIT_ERROR, exit code 1, equivalent to a compile-time error Exceptions cause EXIT_SYSERR, exit code 3, system error or resource exhaustion *** (#4 of 4): 2011-08-03 22:43:58 GMT+00:00jonathan.gibbons at oracle.com From dalibor.topic at oracle.com Fri Aug 12 15:58:20 2011 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Sat, 13 Aug 2011 00:58:20 +0200 Subject: Request for approval for 7074189 In-Reply-To: <4E459F90.3040308@oracle.com> References: <4E459F90.3040308@oracle.com> Message-ID: <4E45B00C.3010707@oracle.com> Thanks, Jon - approved! cheers, dalibor topic On 8/12/11 11:48 PM, Jonathan Gibbons wrote: > Bug: 7074189 > > JDK 8 Changeset: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/c0d5f93af048 > > The bug is not currently visible on bugs.sun.com. Here is the relevant info: > > *Synopsis*: some javac tests fail with latest jtreg 4.1 b03 > > ===*Description* ============================================================ > 3 tests fail using jtreg 4.1 b03 > > ===*Evaluation* ============================================================= > There are three test failures: > > tools/javac/processing/errors/TestOptionSyntaxErrors.java > tools/javac/processing/errors/TestReturnCode.java > tools/javac/warnings/Serial.java > > *** (#1 of 4): 2011-08-03 17:03:10 GMT+00:00jonathan.gibbons at oracle.com > > 1. test/tools/javac/warnings/Serial.java > > The action > * @compile/fail -Werror -Xlint:all,-path T4994049/ Serial.java > is nonsensical, and succeeding because the compilation fails for the wrong reason. > > The line should be deleted. > > *** (#2 of 4): 2011-08-03 17:03:10 GMT+00:00jonathan.gibbons at oracle.com > > 2. The other two tests are expecting "less common" exit codes from javac. The best way to fix them is to write a library class, CompileFail, which emulates @compile/fail but which also allows the specific exit code to be tested. > > *** (#3 of 4): 2011-08-03 22:31:37 GMT+00:00jonathan.gibbons at oracle.com > > Hmmm, we've uncovered a curiousity in TestReturnCode.java. Errors thrown from annotation processors are treated different (and less severely) than exceptions. > > Errors cause EXIT_ERROR, exit code 1, equivalent to a compile-time error > > Exceptions cause EXIT_SYSERR, exit code 3, system error or resource exhaustion > > *** (#4 of 4): 2011-08-03 22:43:58 GMT+00:00jonathan.gibbons at oracle.com > > > -- Oracle Dalibor Topic | Java F/OSS Ambassador Phone: +494023646738 | Mobile: +491772664192 Oracle Java Platform Group ORACLE Deutschland B.V. & Co. KG | Nagelsweg 55 | 20097 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: J?rgen Kunz, Marcel van de Molen, Alexander van der Ven Green Oracle Oracle is committed to developing practices and products that help protect the environment From erik.trimble at oracle.com Fri Aug 12 16:51:32 2011 From: erik.trimble at oracle.com (Erik Trimble) Date: Fri, 12 Aug 2011 16:51:32 -0700 Subject: Bulk Push request for Hotspot 22 Build 01... Message-ID: <1313193092.1843.432.camel@ghostbox> This is a request to integrate the new Hotspot 22 Build 01 codebase into the JDK 7u train. Unfortunately, after thorough investigation, we *cannot* do a merge of the Hotspot 22 repository with the existing Hotspot 21-b17 -based repository currently residing in jdk7u/jdk7u-dev/hotspot . Earlier today, I had hoped to be able to this merge, which, while it originally looked a bit messy, would retain all history and all tags. However, we have run into serious Mercurial issues with the merge. Here is the problem: jdk7u/jdk7u/hotspot is based on HS21-b17. HS22-b01 forked off HS21 at b13. Thereafter, codefixes were pushed into both repositories separately, so there are different changesets with the same code changes and CRs in the two repositories. In addition, HS22 has unique work interspersed with the cross-ported work from HS21. So, both repos are divergent. While the relaxed jcheck rules allow for duplicate CRs in 7u, the Mercurial merge is much trickier than it originally looked. John Coomes has done several passes at the merge, and we're having extreme difficulty in getting the merged repository (that is, the result of pulling HS22 into HS21-b17) to be identical (code-wise) to HS22. That is, the merged results *must* result in the codebase being identical to HS22, and that is not currently happening. We've tried a couple of options, including telling Mercurial to use the incoming file in all cases of a conflict, but we're still ending up with a diff of the merge vs raw HS22 repositories showing output (i.e. differences existing). We can't resolve these merge problems. So, we're left with the only option to wholesale replace - that is, blow away the existing jdk7u/jdk7u/hotspot repository (and, all dependent repositories), and copy in the HS22 repository. We're going to lose a bit of history; I'm sorry, but this is unavoidable. Code consistency is paramount. As a side note, John has also found a couple of changes that are in HS21-b17 that AREN'T in HS22 (mostly copyright, but there's at least one other outstanding fix not in HS22). We will have to audit this, and add them to a future HS22 build. I'm not using a merge of code that results in something which hasn't been tested together. On a similar note, there can be no webrev for this push. Webrev will attempt to do a merge itself when computing changes, and since the merge won't work correctly, the webrev output is garbage (i.e. it will produce output, but incorrect output). So, no webrev, either. I deeply apologize for this situation, but I see no other recourse. So, we're proposing to do this: 1) delete the jdk7u/jdk7u-dev/hotspot and all dependent repositories 2) copy in the hsx/hsx22/hotspot repository to all the above places; said copy will happen INSIDE the Hg repositories, and is a filesystem, rather than Mercurial, operation 3) add to the push blacklist one changeset from the HS21-b17 build, to insure that any pushes from that older repository are rejected 4) publish a list of all repositories which have been affected 5) along with that list, make it explicit that everyone needs to delete their local copies and re-clone any affected repository -- Erik Trimble Java Platform Group - Infrastructure Mailstop: usca22-317 Phone: x67195 Santa Clara, CA Timezone: US/Pacific (UTC-0800) From dalibor.topic at oracle.com Fri Aug 12 17:15:30 2011 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Sat, 13 Aug 2011 02:15:30 +0200 Subject: Bulk Push request for Hotspot 22 Build 01... In-Reply-To: <1313193092.1843.432.camel@ghostbox> References: <1313193092.1843.432.camel@ghostbox> Message-ID: <4E45C222.60401@oracle.com> Hi Erik, hi John, Thanks for the detailed account of the issues with the merge, and for investigating that path. I approve the proposal to replace & document and integrate without a webrev as outlined in steps 1-5 of your e-mail. Edvard, the Technical Lead for JDK 7 Updates has voted in preference of replace & document as well here: http://mail.openjdk.java.net/pipermail/jdk7u-dev/2011-August/000166.html so you have green light for this hopefully not too exciting bit of repository brain surgery. cheers, dalibor topic On 8/13/11 1:51 AM, Erik Trimble wrote: > This is a request to integrate the new Hotspot 22 Build 01 codebase into > the JDK 7u train. > > Unfortunately, after thorough investigation, we *cannot* do a merge of > the Hotspot 22 repository with the existing Hotspot 21-b17 -based > repository currently residing in jdk7u/jdk7u-dev/hotspot . > > Earlier today, I had hoped to be able to this merge, which, while it > originally looked a bit messy, would retain all history and all tags. > > However, we have run into serious Mercurial issues with the merge. > > Here is the problem: > > jdk7u/jdk7u/hotspot is based on HS21-b17. HS22-b01 forked off HS21 at > b13. Thereafter, codefixes were pushed into both repositories > separately, so there are different changesets with the same code changes > and CRs in the two repositories. In addition, HS22 has unique work > interspersed with the cross-ported work from HS21. So, both repos are > divergent. > > While the relaxed jcheck rules allow for duplicate CRs in 7u, the > Mercurial merge is much trickier than it originally looked. > > John Coomes has done several passes at the merge, and we're having > extreme difficulty in getting the merged repository (that is, the result > of pulling HS22 into HS21-b17) to be identical (code-wise) to HS22. > > That is, the merged results *must* result in the codebase being > identical to HS22, and that is not currently happening. We've tried a > couple of options, including telling Mercurial to use the incoming file > in all cases of a conflict, but we're still ending up with a diff of the > merge vs raw HS22 repositories showing output (i.e. differences > existing). > > We can't resolve these merge problems. So, we're left with the only > option to wholesale replace - that is, blow away the existing > jdk7u/jdk7u/hotspot repository (and, all dependent repositories), and > copy in the HS22 repository. > > We're going to lose a bit of history; I'm sorry, but this is > unavoidable. Code consistency is paramount. As a side note, John has > also found a couple of changes that are in HS21-b17 that AREN'T in HS22 > (mostly copyright, but there's at least one other outstanding fix not in > HS22). We will have to audit this, and add them to a future HS22 build. > I'm not using a merge of code that results in something which hasn't > been tested together. > > On a similar note, there can be no webrev for this push. Webrev will > attempt to do a merge itself when computing changes, and since the merge > won't work correctly, the webrev output is garbage (i.e. it will produce > output, but incorrect output). > > So, no webrev, either. > > > I deeply apologize for this situation, but I see no other recourse. > > > So, we're proposing to do this: > > 1) delete the jdk7u/jdk7u-dev/hotspot and all dependent repositories > > 2) copy in the hsx/hsx22/hotspot repository to all the above places; > said copy will happen INSIDE the Hg repositories, and is a filesystem, > rather than Mercurial, operation > > 3) add to the push blacklist one changeset from the HS21-b17 build, to > insure that any pushes from that older repository are rejected > > 4) publish a list of all repositories which have been affected > > 5) along with that list, make it explicit that everyone needs to delete > their local copies and re-clone any affected repository > > > > -- Oracle Dalibor Topic | Java F/OSS Ambassador Phone: +494023646738 | Mobile: +491772664192 Oracle Java Platform Group ORACLE Deutschland B.V. & Co. KG | Nagelsweg 55 | 20097 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: J?rgen Kunz, Marcel van de Molen, Alexander van der Ven Green Oracle Oracle is committed to developing practices and products that help protect the environment From erik.trimble at oracle.com Fri Aug 12 17:27:35 2011 From: erik.trimble at oracle.com (Erik Trimble) Date: Fri, 12 Aug 2011 17:27:35 -0700 Subject: Called Off [Re: Bulk Push request for Hotspot 22 Build 01...] In-Reply-To: <4E45C222.60401@oracle.com> References: <1313193092.1843.432.camel@ghostbox> <4E45C222.60401@oracle.com> Message-ID: <1313195255.1843.468.camel@ghostbox> OK, One final note here: We've now taken a very hard look at the differences, and discovered we're missing at least one fix from HS21-b17 that is NOT in HS22. We do not want to regress on fixes. So, we're calling the whole thing off. The Hotspot team will investigate fully the differences between HS22-b01 and HS21-b17 this coming week, and report on them later. We will also report on the possibility of doing a merge into 7u at that time, as fixing these differences may (or may not) result in a more merge-able solution. This is TBD. This means we will not make the current build of jdk7u, happening later tonight. I expect that HS22-b02 will be the proper candidate for inclusion in jdk7u. Sorry for all the noise and confusion on this. -Erik On Sat, 2011-08-13 at 02:15 +0200, Dalibor Topic wrote: > Hi Erik, hi John, > > Thanks for the detailed account of the issues with the merge, and > for investigating that path. I approve the proposal to replace & document > and integrate without a webrev as outlined in steps 1-5 of your e-mail. > > Edvard, the Technical Lead for JDK 7 Updates has voted in preference of > replace & document as well here: > http://mail.openjdk.java.net/pipermail/jdk7u-dev/2011-August/000166.html > so you have green light for this hopefully not too exciting bit of > repository brain surgery. > > cheers, > dalibor topic > > On 8/13/11 1:51 AM, Erik Trimble wrote: > > This is a request to integrate the new Hotspot 22 Build 01 codebase into > > the JDK 7u train. > > > > Unfortunately, after thorough investigation, we *cannot* do a merge of > > the Hotspot 22 repository with the existing Hotspot 21-b17 -based > > repository currently residing in jdk7u/jdk7u-dev/hotspot . > > > > Earlier today, I had hoped to be able to this merge, which, while it > > originally looked a bit messy, would retain all history and all tags. > > > > However, we have run into serious Mercurial issues with the merge. > > > > Here is the problem: > > > > jdk7u/jdk7u/hotspot is based on HS21-b17. HS22-b01 forked off HS21 at > > b13. Thereafter, codefixes were pushed into both repositories > > separately, so there are different changesets with the same code changes > > and CRs in the two repositories. In addition, HS22 has unique work > > interspersed with the cross-ported work from HS21. So, both repos are > > divergent. > > > > While the relaxed jcheck rules allow for duplicate CRs in 7u, the > > Mercurial merge is much trickier than it originally looked. > > > > John Coomes has done several passes at the merge, and we're having > > extreme difficulty in getting the merged repository (that is, the result > > of pulling HS22 into HS21-b17) to be identical (code-wise) to HS22. > > > > That is, the merged results *must* result in the codebase being > > identical to HS22, and that is not currently happening. We've tried a > > couple of options, including telling Mercurial to use the incoming file > > in all cases of a conflict, but we're still ending up with a diff of the > > merge vs raw HS22 repositories showing output (i.e. differences > > existing). > > > > We can't resolve these merge problems. So, we're left with the only > > option to wholesale replace - that is, blow away the existing > > jdk7u/jdk7u/hotspot repository (and, all dependent repositories), and > > copy in the HS22 repository. > > > > We're going to lose a bit of history; I'm sorry, but this is > > unavoidable. Code consistency is paramount. As a side note, John has > > also found a couple of changes that are in HS21-b17 that AREN'T in HS22 > > (mostly copyright, but there's at least one other outstanding fix not in > > HS22). We will have to audit this, and add them to a future HS22 build. > > I'm not using a merge of code that results in something which hasn't > > been tested together. > > > > On a similar note, there can be no webrev for this push. Webrev will > > attempt to do a merge itself when computing changes, and since the merge > > won't work correctly, the webrev output is garbage (i.e. it will produce > > output, but incorrect output). > > > > So, no webrev, either. > > > > > > I deeply apologize for this situation, but I see no other recourse. > > > > > > So, we're proposing to do this: > > > > 1) delete the jdk7u/jdk7u-dev/hotspot and all dependent repositories > > > > 2) copy in the hsx/hsx22/hotspot repository to all the above places; > > said copy will happen INSIDE the Hg repositories, and is a filesystem, > > rather than Mercurial, operation > > > > 3) add to the push blacklist one changeset from the HS21-b17 build, to > > insure that any pushes from that older repository are rejected > > > > 4) publish a list of all repositories which have been affected > > > > 5) along with that list, make it explicit that everyone needs to delete > > their local copies and re-clone any affected repository > > > > > > > > > > > > -- > Oracle > Dalibor Topic | Java F/OSS Ambassador > Phone: +494023646738 | Mobile: +491772664192 > Oracle Java Platform Group > > ORACLE Deutschland B.V. & Co. KG | Nagelsweg 55 | 20097 Hamburg > > ORACLE Deutschland B.V. & Co. KG > Hauptverwaltung: Riesstr. 25, D-80992 M?nchen > Registergericht: Amtsgericht M?nchen, HRA 95603 > > Komplement?rin: ORACLE Deutschland Verwaltung B.V. > Hertogswetering 163/167, 3543 AS Utrecht, Niederlande > Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 > Gesch?ftsf?hrer: J?rgen Kunz, Marcel van de Molen, Alexander van der Ven > > Green Oracle Oracle is committed to developing practices and products that help protect the environment -- Erik Trimble Java Platform Group - Infrastructure Mailstop: usca22-317 Phone: x67195 Santa Clara, CA Timezone: US/Pacific (UTC-0800) From erik.trimble at oracle.com Fri Aug 12 17:42:38 2011 From: erik.trimble at oracle.com (Erik Trimble) Date: Fri, 12 Aug 2011 17:42:38 -0700 Subject: Retiring Hotspot gatekeeper... Message-ID: <1313196158.1843.497.camel@ghostbox> After almost 4 years as the OpenJDK Hotspot gatekeeper (and over 7 years as the Hotspot gatekeeper), I'm stepping down. My place will be taken by Alejandro Murillo. Interim assistance will be given by John Coomes. Hotspot gatekeeping is quite complex, as the Hotspot Express model demands a large amount of coordination as to where it goes and how it is tested. I greatly appreciate everyone's forbearance on some of the glitches that have happened, and plead with folks to be nice to Alejandro for a couple of months, while he comes up to speed. It's certainly never been dull. Thanks for everything, folks. -- Erik Trimble Java Platform Group - Infrastructure Mailstop: usca22-317 Phone: x67195 Santa Clara, CA Timezone: US/Pacific (UTC-0800) From pavel.porvatov at oracle.com Mon Aug 15 07:18:01 2011 From: pavel.porvatov at oracle.com (Pavel Porvatov) Date: Mon, 15 Aug 2011 18:18:01 +0400 Subject: Request for approval: 7071166 Message-ID: <4E492A99.7020205@oracle.com> Hi, Could you please approve the fix of CR 7071166 (LayoutStyle.getPreferredGap() - IAE is expected but not thrown) for 7u2? Bug description is here: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7071166 Some time ago the fix was prepared, approved and pushed in jdk8: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/86098b3f7789 For 7u2 the fix is the same and doesn't contain any modifications. Regards, Pavel From pavel.porvatov at oracle.com Mon Aug 15 07:21:58 2011 From: pavel.porvatov at oracle.com (Pavel Porvatov) Date: Mon, 15 Aug 2011 18:21:58 +0400 Subject: Request for approval: 7071609 Message-ID: <4E492B86.908@oracle.com> Hi, Could you please approve the fix of CR 7071609 (javax/swing/JPopupMenu/6694823/bug6694823.java failed on solaris10) for 7u2? Bug description is here: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7071609 Some time ago the fix was prepared, approved and pushed in jdk8: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/4e0340c4f443 For 7u2 the fix is the same and doesn't contain any modifications. Regards, Pavel From edvard.wendelin at oracle.com Mon Aug 15 09:38:03 2011 From: edvard.wendelin at oracle.com (Edvard Wendelin) Date: Mon, 15 Aug 2011 18:38:03 +0200 Subject: Request for approval: 7071609 In-Reply-To: <4E492B86.908@oracle.com> References: <4E492B86.908@oracle.com> Message-ID: <4E494B6B.40901@oracle.com> Approved, Use hg.openjdk.java.net/jdk7u/jdk7u-dev-gate/jdk/ for the push. Cheers, Edvard On 08/15/2011 04:21 PM, Pavel Porvatov wrote: > Hi, > > Could you please approve the fix of CR 7071609 > (javax/swing/JPopupMenu/6694823/bug6694823.java failed on solaris10) > for 7u2? Bug description is here: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7071609 > > Some time ago the fix was prepared, approved and pushed in jdk8: > http://hg.openjdk.java.net/jdk8/awt/jdk/rev/4e0340c4f443 > > For 7u2 the fix is the same and doesn't contain any modifications. > > Regards, Pavel From edvard.wendelin at oracle.com Mon Aug 15 09:38:14 2011 From: edvard.wendelin at oracle.com (Edvard Wendelin) Date: Mon, 15 Aug 2011 18:38:14 +0200 Subject: Request for approval: 7071166 In-Reply-To: <4E492A99.7020205@oracle.com> References: <4E492A99.7020205@oracle.com> Message-ID: <4E494B76.6020808@oracle.com> Approved, Use hg.openjdk.java.net/jdk7u/jdk7u-dev-gate/jdk/ for the push. Cheers, Edvard On 08/15/2011 04:18 PM, Pavel Porvatov wrote: > Hi, > > Could you please approve the fix of CR 7071166 > (LayoutStyle.getPreferredGap() - IAE is expected but not thrown) for > 7u2? Bug description is here: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7071166 > > Some time ago the fix was prepared, approved and pushed in jdk8: > http://hg.openjdk.java.net/jdk8/awt/jdk/rev/86098b3f7789 > > For 7u2 the fix is the same and doesn't contain any modifications. > > Regards, Pavel From dalibor.topic at oracle.com Mon Aug 15 09:41:28 2011 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Mon, 15 Aug 2011 18:41:28 +0200 Subject: Called Off [Re: Bulk Push request for Hotspot 22 Build 01...] In-Reply-To: <1313195255.1843.468.camel@ghostbox> References: <1313193092.1843.432.camel@ghostbox> <4E45C222.60401@oracle.com> <1313195255.1843.468.camel@ghostbox> Message-ID: <4E494C38.9080805@oracle.com> Thanks, Erik. Just to clarify - the approval was for this attempt, and is now no longer valid, since the push has been called off. The next HS22 bulk merge attempt will have to go through the the same approval procedure as this one again, of course. cheers, dalibor topic On 8/13/11 2:27 AM, Erik Trimble wrote: > OK, > > One final note here: > > We've now taken a very hard look at the differences, and discovered > we're missing at least one fix from HS21-b17 that is NOT in HS22. We do > not want to regress on fixes. > > So, we're calling the whole thing off. > > The Hotspot team will investigate fully the differences between HS22-b01 > and HS21-b17 this coming week, and report on them later. We will also > report on the possibility of doing a merge into 7u at that time, as > fixing these differences may (or may not) result in a more merge-able > solution. This is TBD. > > This means we will not make the current build of jdk7u, happening later > tonight. > > I expect that HS22-b02 will be the proper candidate for inclusion in > jdk7u. > > Sorry for all the noise and confusion on this. > > -Erik > > On Sat, 2011-08-13 at 02:15 +0200, Dalibor Topic wrote: >> Hi Erik, hi John, >> >> Thanks for the detailed account of the issues with the merge, and >> for investigating that path. I approve the proposal to replace & document >> and integrate without a webrev as outlined in steps 1-5 of your e-mail. >> >> Edvard, the Technical Lead for JDK 7 Updates has voted in preference of >> replace & document as well here: >> http://mail.openjdk.java.net/pipermail/jdk7u-dev/2011-August/000166.html >> so you have green light for this hopefully not too exciting bit of >> repository brain surgery. >> >> cheers, >> dalibor topic >> >> On 8/13/11 1:51 AM, Erik Trimble wrote: >>> This is a request to integrate the new Hotspot 22 Build 01 codebase into >>> the JDK 7u train. >>> >>> Unfortunately, after thorough investigation, we *cannot* do a merge of >>> the Hotspot 22 repository with the existing Hotspot 21-b17 -based >>> repository currently residing in jdk7u/jdk7u-dev/hotspot . >>> >>> Earlier today, I had hoped to be able to this merge, which, while it >>> originally looked a bit messy, would retain all history and all tags. >>> >>> However, we have run into serious Mercurial issues with the merge. >>> >>> Here is the problem: >>> >>> jdk7u/jdk7u/hotspot is based on HS21-b17. HS22-b01 forked off HS21 at >>> b13. Thereafter, codefixes were pushed into both repositories >>> separately, so there are different changesets with the same code changes >>> and CRs in the two repositories. In addition, HS22 has unique work >>> interspersed with the cross-ported work from HS21. So, both repos are >>> divergent. >>> >>> While the relaxed jcheck rules allow for duplicate CRs in 7u, the >>> Mercurial merge is much trickier than it originally looked. >>> >>> John Coomes has done several passes at the merge, and we're having >>> extreme difficulty in getting the merged repository (that is, the result >>> of pulling HS22 into HS21-b17) to be identical (code-wise) to HS22. >>> >>> That is, the merged results *must* result in the codebase being >>> identical to HS22, and that is not currently happening. We've tried a >>> couple of options, including telling Mercurial to use the incoming file >>> in all cases of a conflict, but we're still ending up with a diff of the >>> merge vs raw HS22 repositories showing output (i.e. differences >>> existing). >>> >>> We can't resolve these merge problems. So, we're left with the only >>> option to wholesale replace - that is, blow away the existing >>> jdk7u/jdk7u/hotspot repository (and, all dependent repositories), and >>> copy in the HS22 repository. >>> >>> We're going to lose a bit of history; I'm sorry, but this is >>> unavoidable. Code consistency is paramount. As a side note, John has >>> also found a couple of changes that are in HS21-b17 that AREN'T in HS22 >>> (mostly copyright, but there's at least one other outstanding fix not in >>> HS22). We will have to audit this, and add them to a future HS22 build. >>> I'm not using a merge of code that results in something which hasn't >>> been tested together. >>> >>> On a similar note, there can be no webrev for this push. Webrev will >>> attempt to do a merge itself when computing changes, and since the merge >>> won't work correctly, the webrev output is garbage (i.e. it will produce >>> output, but incorrect output). >>> >>> So, no webrev, either. >>> >>> >>> I deeply apologize for this situation, but I see no other recourse. >>> >>> >>> So, we're proposing to do this: >>> >>> 1) delete the jdk7u/jdk7u-dev/hotspot and all dependent repositories >>> >>> 2) copy in the hsx/hsx22/hotspot repository to all the above places; >>> said copy will happen INSIDE the Hg repositories, and is a filesystem, >>> rather than Mercurial, operation >>> >>> 3) add to the push blacklist one changeset from the HS21-b17 build, to >>> insure that any pushes from that older repository are rejected >>> >>> 4) publish a list of all repositories which have been affected >>> >>> 5) along with that list, make it explicit that everyone needs to delete >>> their local copies and re-clone any affected repository >>> >>> >>> >>> >> >> >> >> -- >> Oracle >> Dalibor Topic | Java F/OSS Ambassador >> Phone: +494023646738 | Mobile: +491772664192 >> Oracle Java Platform Group >> >> ORACLE Deutschland B.V. & Co. KG | Nagelsweg 55 | 20097 Hamburg >> >> ORACLE Deutschland B.V. & Co. KG >> Hauptverwaltung: Riesstr. 25, D-80992 M?nchen >> Registergericht: Amtsgericht M?nchen, HRA 95603 >> >> Komplement?rin: ORACLE Deutschland Verwaltung B.V. >> Hertogswetering 163/167, 3543 AS Utrecht, Niederlande >> Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 >> Gesch?ftsf?hrer: J?rgen Kunz, Marcel van de Molen, Alexander van der Ven >> >> Green Oracle Oracle is committed to developing practices and products that help protect the environment > -- Oracle Dalibor Topic | Java F/OSS Ambassador Phone: +494023646738 | Mobile: +491772664192 Oracle Java Platform Group ORACLE Deutschland B.V. & Co. KG | Nagelsweg 55 | 20097 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: J?rgen Kunz, Marcel van de Molen, Alexander van der Ven Green Oracle Oracle is committed to developing practices and products that help protect the environment From jonathan.gibbons at oracle.com Mon Aug 15 14:01:03 2011 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Mon, 15 Aug 2011 21:01:03 +0000 Subject: hg: jdk7u/jdk7u-dev/langtools: 7074189: some javac tests fail with latest jtreg 4.1 b03 Message-ID: <20110815210111.248DA47BD2@hg.openjdk.java.net> Changeset: 5b682f7c980e Author: jjg Date: 2011-08-15 14:01 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/langtools/rev/5b682f7c980e 7074189: some javac tests fail with latest jtreg 4.1 b03 Reviewed-by: darcy + test/tools/javac/lib/CompileFail.java ! test/tools/javac/processing/errors/TestOptionSyntaxErrors.java ! test/tools/javac/processing/errors/TestReturnCode.java ! test/tools/javac/warnings/Serial.java From pavel.porvatov at oracle.com Wed Aug 17 01:46:12 2011 From: pavel.porvatov at oracle.com (pavel.porvatov at oracle.com) Date: Wed, 17 Aug 2011 08:46:12 +0000 Subject: hg: jdk7u/jdk7u-dev/jdk: 7071609: javax/swing/JPopupMenu/6694823/bug6694823.java failed on solaris10 Message-ID: <20110817084635.06E0047C4B@hg.openjdk.java.net> Changeset: a15d2672aad0 Author: rupashka Date: 2011-08-17 12:45 +0400 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/jdk/rev/a15d2672aad0 7071609: javax/swing/JPopupMenu/6694823/bug6694823.java failed on solaris10 Reviewed-by: alexp ! test/javax/swing/JPopupMenu/6694823/bug6694823.java From pavel.porvatov at oracle.com Wed Aug 17 01:59:58 2011 From: pavel.porvatov at oracle.com (pavel.porvatov at oracle.com) Date: Wed, 17 Aug 2011 08:59:58 +0000 Subject: hg: jdk7u/jdk7u-dev/jdk: 7071166: LayoutStyle.getPreferredGap() - IAE is expected but not thrown Message-ID: <20110817090009.0B8BE47C4D@hg.openjdk.java.net> Changeset: d2fbe93b6361 Author: rupashka Date: 2011-08-17 12:58 +0400 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/jdk/rev/d2fbe93b6361 7071166: LayoutStyle.getPreferredGap() - IAE is expected but not thrown Reviewed-by: peterz ! src/share/classes/sun/swing/DefaultLayoutStyle.java + test/javax/swing/GroupLayout/7071166/bug7071166.java From edvard.wendelin at oracle.com Wed Aug 17 04:56:45 2011 From: edvard.wendelin at oracle.com (Edvard Wendelin) Date: Wed, 17 Aug 2011 13:56:45 +0200 Subject: Changes to build schedule for JDK 7u2 Message-ID: <4E4BAC7D.2090107@oracle.com> Hi all, I just wanted to announce that we are increasing the build frequency of the master forest. Instead of building bi-weekly release engineering will start building every Wednesday. The builds will be published on java.net under the early access pages. Building more frequently will give the integrators more flexibility, make it easier to find slots for large bulk changes and reduce the number of fixes per build. Cheers, Edvard From dalibor.topic at oracle.com Wed Aug 17 08:06:52 2011 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Wed, 17 Aug 2011 17:06:52 +0200 Subject: Request for approval for 7057297 to be fixed in jdk7u-dev/langtools In-Reply-To: <4E412A5B.1000005@oracle.com> References: <4E41263C.7070904@oracle.com> <4E412A5B.1000005@oracle.com> Message-ID: <4E4BD90C.2050908@oracle.com> This one and the previous two approval requests have been approved a week ago, but don't seem to have made it in looking at the Mercurial logs. Maurizio, did you run into an issue? cheers, dalibor topic On 8/9/11 2:38 PM, Edvard Wendelin wrote: > Approved, > > Use http://hg.openjdk.java.net/jdk7u/jdk7u-dev-gate/langtools for the push. > > Cheers, > Edvard > > > On 08/09/2011 02:21 PM, Maurizio Cimadamore wrote: >> Hi >> I would like to request to backport the following bug from the JDK 8 repo: >> >> 7057297: Project Coin: diamond erroneously accepts in array initializer expressions >> >> The patch is the same as that in jdk 8 [2]. All regression tests and JCK tests pass. >> >> [1] -http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7057297 >> [2] -http://hg.openjdk.java.net/jdk8/tl/langtools/rev/e427c42e1a7e >> >> Thanks >> Maurizio >> >> -- Oracle Dalibor Topic | Java F/OSS Ambassador Phone: +494023646738 | Mobile: +491772664192 Oracle Java Platform Group ORACLE Deutschland B.V. & Co. KG | Nagelsweg 55 | 20097 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: J?rgen Kunz, Marcel van de Molen, Alexander van der Ven Green Oracle Oracle is committed to developing practices and products that help protect the environment From james.holmlund at oracle.com Wed Aug 17 11:12:56 2011 From: james.holmlund at oracle.com (Jim Holmlund) Date: Wed, 17 Aug 2011 11:12:56 -0700 Subject: Request for approval for 7057297 to be fixed in jdk7u-dev/langtools In-Reply-To: <4E4BD90C.2050908@oracle.com> References: <4E41263C.7070904@oracle.com> <4E412A5B.1000005@oracle.com> <4E4BD90C.2050908@oracle.com> Message-ID: <4E4C04A8.30102@oracle.com> Maurizio is on vacation and will be back Aug 25. - jjh On 8/17/2011 8:06 AM, Dalibor Topic wrote: > This one and the previous two approval requests have been approved a week ago, > but don't seem to have made it in looking at the Mercurial logs. Maurizio, did > you run into an issue? > > cheers, > dalibor topic > > On 8/9/11 2:38 PM, Edvard Wendelin wrote: >> Approved, >> >> Use http://hg.openjdk.java.net/jdk7u/jdk7u-dev-gate/langtools for the push. >> >> Cheers, >> Edvard >> >> >> On 08/09/2011 02:21 PM, Maurizio Cimadamore wrote: >>> Hi >>> I would like to request to backport the following bug from the JDK 8 repo: >>> >>> 7057297: Project Coin: diamond erroneously accepts in array initializer expressions >>> >>> The patch is the same as that in jdk 8 [2]. All regression tests and JCK tests pass. >>> >>> [1] -http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7057297 >>> [2] -http://hg.openjdk.java.net/jdk8/tl/langtools/rev/e427c42e1a7e >>> >>> Thanks >>> Maurizio >>> >>> > > From lana.steuck at oracle.com Wed Aug 17 19:31:55 2011 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Thu, 18 Aug 2011 02:31:55 +0000 Subject: hg: jdk7u/jdk7u/langtools: 2 new changesets Message-ID: <20110818023202.9121C47CA2@hg.openjdk.java.net> Changeset: e2ace862236a Author: darcy Date: 2011-08-04 11:15 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/langtools/rev/e2ace862236a 7071246: Enclosing string literal in parenthesis in switch-case crashes javac Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/comp/Lower.java ! test/tools/javac/StringsInSwitch/StringSwitches.java Changeset: d5d8654d8180 Author: ksrini Date: 2011-08-05 19:41 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/langtools/rev/d5d8654d8180 7064544: (javadoc) miscellaneous fixes requested by netbeans Summary: Contributed by netbeans team, modified to suit by the langtools team. Reviewed-by: jjg, bpatel ! src/share/classes/com/sun/tools/javadoc/ClassDocImpl.java ! src/share/classes/com/sun/tools/javadoc/Comment.java ! src/share/classes/com/sun/tools/javadoc/JavadocEnter.java ! test/com/sun/javadoc/testLinkTaglet/TestLinkTaglet.java ! test/com/sun/javadoc/testLinkTaglet/pkg/C.java From lana.steuck at oracle.com Wed Aug 17 19:31:56 2011 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Thu, 18 Aug 2011 02:31:56 +0000 Subject: hg: jdk7u/jdk7u/jdk: 8 new changesets Message-ID: <20110818023329.F2DD147CA8@hg.openjdk.java.net> Changeset: 8841e2149dfb Author: coffeys Date: 2011-08-09 14:02 +0100 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/jdk/rev/8841e2149dfb 7041125: LDAP API does not catch malformed filters that contain two operands for the ! operator Reviewed-by: weijun, xuelei ! src/share/classes/com/sun/jndi/ldap/Filter.java ! test/com/sun/jndi/ldap/InvalidLdapFilters.java Changeset: 62d3e2c51aa8 Author: xuelei Date: 2011-08-09 22:03 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/jdk/rev/62d3e2c51aa8 7065972: Some race condition may happen in SSLSocketImpl class Reviewed-by: wetmore, weijun, dgu ! src/share/classes/sun/security/ssl/SSLSocketImpl.java Changeset: 2c93c0965f99 Author: coffeys Date: 2011-08-10 09:08 +0100 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/jdk/rev/2c93c0965f99 7049774: UID construction appears to hang if time changed backwards Reviewed-by: alanb, dholmes, chegar, mduigou ! src/share/classes/java/rmi/server/UID.java Changeset: e01325b53a12 Author: malenkov Date: 2011-08-10 18:47 +0400 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/jdk/rev/e01325b53a12 7057459: Regression: Performance degradation with java.beans.XMLEncoder Reviewed-by: rupashka ! src/share/classes/java/beans/Encoder.java Changeset: 72b2b2a3f228 Author: rupashka Date: 2011-08-10 18:51 +0400 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/jdk/rev/72b2b2a3f228 7019963: The goto parent directory button doesn't operate in JFileChooser Reviewed-by: alexp ! src/share/classes/javax/swing/plaf/basic/BasicFileChooserUI.java Changeset: 22f8570179e7 Author: rupashka Date: 2011-08-11 15:10 +0400 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/jdk/rev/22f8570179e7 4909150: WindowsTreeUI can cause NullPointerException occasionally Reviewed-by: alexp ! src/share/classes/com/sun/java/swing/plaf/windows/WindowsTreeUI.java Changeset: 56fc480ef969 Author: weijun Date: 2011-08-12 11:14 +0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/jdk/rev/56fc480ef969 7061379: [Kerberos] Cross-realm authentication fails, due to nameType problem Reviewed-by: valeriep ! src/share/classes/sun/security/krb5/PrincipalName.java ! test/sun/security/krb5/auto/KDC.java + test/sun/security/krb5/auto/PrincipalNameEquals.java Changeset: 449f7f1bb735 Author: coffeys Date: 2011-08-12 09:40 +0100 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/jdk/rev/449f7f1bb735 7047325: Internal API to improve management of direct buffers Reviewed-by: alanb, mduigou ! make/com/oracle/Makefile - make/com/oracle/net/Makefile ! make/common/Release.gmk ! src/share/classes/java/nio/Bits.java ! src/share/classes/java/nio/Buffer.java ! src/share/classes/java/nio/Direct-X-Buffer.java.template ! src/share/classes/sun/misc/JavaNioAccess.java ! src/share/classes/sun/nio/ch/DirectBuffer.java From lana.steuck at oracle.com Wed Aug 17 21:40:51 2011 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 17 Aug 2011 21:40:51 -0700 (PDT) Subject: jdk7u-b03: jdk7u-dev Message-ID: <201108180440.p7I4epDg013583@jano-app.us.oracle.com> http://hg.openjdk.java.net/jdk7u/jdk7u/rev/91954c06ba1e http://hg.openjdk.java.net/jdk7u/jdk7u/langtools/rev/d5d8654d8180 http://hg.openjdk.java.net/jdk7u/jdk7u/jdk/rev/449f7f1bb735 http://hg.openjdk.java.net/jdk7u/jdk7u/jaxws/rev/e94a8b7a9629 http://hg.openjdk.java.net/jdk7u/jdk7u/jaxp/rev/4b0c44f2f7f1 http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/790b18399cd4 http://hg.openjdk.java.net/jdk7u/jdk7u/corba/rev/e1a1c0d72264 --- All the fixes will be tested during promotion (no PIT testing at this point): 7057459 ja classes_beans Regression: Performance degradation with java.beans.XMLEnco 7047325 ja classes_nio (bf) API to support recycling of direct memory for use by ot 4909150 ja classes_swing WindowsTreeUI can cause NullPointerException occasionally 7019963 ja classes_swing The goto parent directory button doesn?t operate in JFileCho 7071246 ja compiler Enclosing string literal in parenthesis in switch-case crash 7039182 ja embedded PPC: NIO: java.io.IOException: Invalid argument in sun.nio.c 7064544 ja javadoctool (javadoc) miscellaneous fixes requested by netbeans 7049774 ja rmi UID construction appears to hang if time changed backwards 7061379 jg krb5plugin [Kerberos] Cross-realm authentication fails, due to nameType 7041125 jn ldap LDAP API does not catch malformed filters that contain two o 7065972 js runtime Some race condition may happen in SSLSocketImpl class From yong.huang at oracle.com Wed Aug 17 23:11:26 2011 From: yong.huang at oracle.com (Yong Jeffrey Huang) Date: Thu, 18 Aug 2011 14:11:26 +0800 Subject: Request for approval: 7066203 Message-ID: <4E4CAD0E.7070802@oracle.com> Hi, Could you please review the CR fix 7066203: Update currency data to the latest ISO 4217 standard. The CR is http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7066203 The Change set in Java 8 is http://hg.openjdk.java.net/jdk8/l10n/jdk/rev/c9956a6753fb It's approved and fix available in Java 8 b01, and will be integrated to jdk8 master repository in b02. thanks, Yong From edvard.wendelin at oracle.com Wed Aug 17 23:25:28 2011 From: edvard.wendelin at oracle.com (Edvard Wendelin) Date: Thu, 18 Aug 2011 08:25:28 +0200 Subject: Request for approval: 7066203 In-Reply-To: <4E4CAD0E.7070802@oracle.com> References: <4E4CAD0E.7070802@oracle.com> Message-ID: <4E4CB058.8020205@oracle.com> Approved, Please use hg.openjdk.java.net/jdk7u/jdk7u-dev-gate/jdk/ for the push. Cheers, Edvard On 08/18/2011 08:11 AM, Yong Jeffrey Huang wrote: > Hi, > > Could you please review the CR fix 7066203: Update currency data to > the latest ISO 4217 standard. > > The CR is http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7066203 > > The Change set in Java 8 is > http://hg.openjdk.java.net/jdk8/l10n/jdk/rev/c9956a6753fb > > It's approved and fix available in Java 8 b01, and will be integrated > to jdk8 master repository in b02. > > thanks, > Yong From dalibor.topic at oracle.com Thu Aug 18 01:56:18 2011 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Thu, 18 Aug 2011 10:56:18 +0200 Subject: Request for approval for 7057297 to be fixed in jdk7u-dev/langtools In-Reply-To: <4E4C04A8.30102@oracle.com> References: <4E41263C.7070904@oracle.com> <4E412A5B.1000005@oracle.com> <4E4BD90C.2050908@oracle.com> <4E4C04A8.30102@oracle.com> Message-ID: <4E4CD3B2.2020007@oracle.com> Thanks for your help, everyone & have a great vacation, Maurizio! cheers, dalibor topic On 8/17/11 8:12 PM, Jim Holmlund wrote: > Maurizio is on vacation and will be back Aug 25. > - jjh > > > On 8/17/2011 8:06 AM, Dalibor Topic wrote: >> This one and the previous two approval requests have been approved a week ago, >> but don't seem to have made it in looking at the Mercurial logs. Maurizio, did >> you run into an issue? >> >> cheers, >> dalibor topic >> >> On 8/9/11 2:38 PM, Edvard Wendelin wrote: >>> Approved, >>> >>> Use http://hg.openjdk.java.net/jdk7u/jdk7u-dev-gate/langtools for the push. >>> >>> Cheers, >>> Edvard >>> >>> >>> On 08/09/2011 02:21 PM, Maurizio Cimadamore wrote: >>>> Hi >>>> I would like to request to backport the following bug from the JDK 8 repo: >>>> >>>> 7057297: Project Coin: diamond erroneously accepts in array initializer expressions >>>> >>>> The patch is the same as that in jdk 8 [2]. All regression tests and JCK tests pass. >>>> >>>> [1] -http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7057297 >>>> [2] -http://hg.openjdk.java.net/jdk8/tl/langtools/rev/e427c42e1a7e >>>> >>>> Thanks >>>> Maurizio >>>> >>>> >> >> -- Oracle Dalibor Topic | Java F/OSS Ambassador Phone: +494023646738 | Mobile: +491772664192 Oracle Java Platform Group ORACLE Deutschland B.V. & Co. KG | Nagelsweg 55 | 20097 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: J?rgen Kunz, Marcel van de Molen, Alexander van der Ven Green Oracle Oracle is committed to developing practices and products that help protect the environment From dalibor.topic at oracle.com Thu Aug 18 08:49:26 2011 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Thu, 18 Aug 2011 17:49:26 +0200 Subject: hg: jdk7u/jdk7u: Added tag jdk7u2-b01 for changeset 831f1dadcc35 In-Reply-To: <20110721194645.9D93E475BC@hg.openjdk.java.net> References: <20110721194645.9D93E475BC@hg.openjdk.java.net> Message-ID: <4E4D3486.4090207@oracle.com> On 7/21/11 9:46 PM, suchen.chien at oracle.com wrote: > Changeset: 91954c06ba1e > Author: schien > Date: 2011-07-21 12:39 -0700 > URL: http://hg.openjdk.java.net/jdk7u/jdk7u/rev/91954c06ba1e > > Added tag jdk7u2-b01 for changeset 831f1dadcc35 > > ! .hgtags > Hi Suchen, I haven't seen you tag jdk7u2-b02 last week (or b03 this week for that matter). Is something causing a delay? cheers, dalibor topic -- Oracle Dalibor Topic | Java F/OSS Ambassador Phone: +494023646738 | Mobile: +491772664192 Oracle Java Platform Group ORACLE Deutschland B.V. & Co. KG | Nagelsweg 55 | 20097 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: J?rgen Kunz, Marcel van de Molen, Alexander van der Ven Green Oracle Oracle is committed to developing practices and products that help protect the environment From lana.steuck at oracle.com Thu Aug 18 12:00:18 2011 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Thu, 18 Aug 2011 12:00:18 -0700 (PDT) Subject: Auto Reply: jdk7u-dev Digest, Vol 2, Issue 27 Message-ID: This is an auto-reply message. I am away on vacation Thu, Aug 18 - Fri, Aug 26. Back on Mon, Aug 29. In my absence, please contact: - Igor Nekrestyanov for any SA Webrobot requests/issues (sa.us.oracle.com) (thank you, Igor!!) - file an Express Ticket for any lab related issues https://expresssr.oraclecorp.com/myd_sso/ct_expresssr_user.create_sr?p_aste_id=16 Be sure to put [ILM] at the beginning in the Summary field for faster routing. If this is urgent, please contact my manager - Jeff Dinkins. For Jdk8/Jdk7u JCG code freeze and integration dates please refer to the corresponding sections of Jdk SE Home Integration page: https://sunspace.sfbay.sun.com/display/JAVASE/Integrations Regards, Lana From weijun.wang at oracle.com Thu Aug 18 23:00:32 2011 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 19 Aug 2011 14:00:32 +0800 Subject: Push request: nnnnnnn: so so Message-ID: <4E4DFC00.5020507@oracle.com> Hi All This is a request to backport several jdk8 fix into jdk7u2 b03: CR: 7043847: NTML impl of SaslServer throws UnsupportedOperationException from (un)wrap method 7043860: NTML impl of SaslServer doesn't throw ISE from getAuthorizationID() method 7043882: NTML impl of SaslServer doesn't throw ISE from getNegotiatedProperty() method 7043938: NTML impl of SaslClientFactory throws NPE instead of SaslException 7043959: NTML impl of SaslClientFactory throws NPE for null CallBackHandler instance Weblink: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7043847 http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7043860 http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7043882 http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7043938 http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7043959 Description: The NTLM mechanism for SASL has several API compliance issues when an error occurs during the communication, say, throwing an UnsupportedOperationException when an IllegalStateException is expected, or, throwing a NullPointerException when a SaslException is expected. The fix is already included in jdk8 as: Changeset: 55952703809f Author: weijun Date: 2011-08-19 13:42 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/55952703809f 7043847: NTML impl of SaslServer throws UnsupportedOperationException from (un)wrap method 7043860: NTML impl of SaslServer doesn't throw ISE from getAuthorizationID() method 7043882: NTML impl of SaslServer doesn't throw ISE from getNegotiatedProperty() method 7043938: NTML impl of SaslClientFactory throws NPE instead of SaslException 7043959: NTML impl of SaslClientFactory throws NPE for null CallBackHandler instance Reviewed-by: vinnie The patch for jdk7u2 is almost identical to the one in jdk8. There are only 2 places where the context differs a little. I intend to push it to ssh://hg.openjdk.java.net/jdk7u/jdk7u-dev-gate/jdk Thanks Weijun From weijun.wang at oracle.com Thu Aug 18 23:09:44 2011 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 19 Aug 2011 14:09:44 +0800 Subject: Resent: Push request: 7043847...: NTLM API compliances issues Message-ID: <4E4DFE28.3080604@oracle.com> Sorry, forget to update the subject line in my template. Sent again. -------- Original Message -------- Subject: Push request: nnnnnnn: so so Date: Fri, 19 Aug 2011 14:00:32 +0800 From: Weijun Wang To: jdk7u-dev at openjdk.java.net Hi All This is a request to backport several jdk8 fix into jdk7u2 b03: CR: 7043847: NTML impl of SaslServer throws UnsupportedOperationException from (un)wrap method 7043860: NTML impl of SaslServer doesn't throw ISE from getAuthorizationID() method 7043882: NTML impl of SaslServer doesn't throw ISE from getNegotiatedProperty() method 7043938: NTML impl of SaslClientFactory throws NPE instead of SaslException 7043959: NTML impl of SaslClientFactory throws NPE for null CallBackHandler instance Weblink: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7043847 http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7043860 http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7043882 http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7043938 http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7043959 Description: The NTLM mechanism for SASL has several API compliance issues when an error occurs during the communication, say, throwing an UnsupportedOperationException when an IllegalStateException is expected, or, throwing a NullPointerException when a SaslException is expected. The fix is already included in jdk8 as: Changeset: 55952703809f Author: weijun Date: 2011-08-19 13:42 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/55952703809f 7043847: NTML impl of SaslServer throws UnsupportedOperationException from (un)wrap method 7043860: NTML impl of SaslServer doesn't throw ISE from getAuthorizationID() method 7043882: NTML impl of SaslServer doesn't throw ISE from getNegotiatedProperty() method 7043938: NTML impl of SaslClientFactory throws NPE instead of SaslException 7043959: NTML impl of SaslClientFactory throws NPE for null CallBackHandler instance Reviewed-by: vinnie The patch for jdk7u2 is almost identical to the one in jdk8. There are only 2 places where the context differs a little. I intend to push it to ssh://hg.openjdk.java.net/jdk7u/jdk7u-dev-gate/jdk Thanks Weijun From edvard.wendelin at oracle.com Thu Aug 18 23:41:22 2011 From: edvard.wendelin at oracle.com (Edvard Wendelin) Date: Fri, 19 Aug 2011 08:41:22 +0200 Subject: Resent: Push request: 7043847...: NTLM API compliances issues In-Reply-To: <4E4DFE28.3080604@oracle.com> References: <4E4DFE28.3080604@oracle.com> Message-ID: <7F0140BD-D461-4D17-91BE-63F943B6B6F0@oracle.com> Hi, Thanks for the request! Since the fix is not identical to the one in 8 (I know, nagging about two small changes is picky, but we had to draw the line somewhere), you'll need to post a webrev on cr.openjdk.java.net and get one additional review. Once the webrev is uploaded, please send us a link to it. Cheers, Edvard On 19 aug 2011, at 08.09, Weijun Wang wrote: > Sorry, forget to update the subject line in my template. Sent again. > > -------- Original Message -------- > Subject: Push request: nnnnnnn: so so > Date: Fri, 19 Aug 2011 14:00:32 +0800 > From: Weijun Wang > To: jdk7u-dev at openjdk.java.net > > Hi All > > This is a request to backport several jdk8 fix into jdk7u2 b03: > > CR: > > 7043847: NTML impl of SaslServer throws UnsupportedOperationException > from (un)wrap method > 7043860: NTML impl of SaslServer doesn't throw ISE from > getAuthorizationID() method > 7043882: NTML impl of SaslServer doesn't throw ISE from > getNegotiatedProperty() method > 7043938: NTML impl of SaslClientFactory throws NPE instead of > SaslException > 7043959: NTML impl of SaslClientFactory throws NPE for null > CallBackHandler instance > > Weblink: > > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7043847 > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7043860 > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7043882 > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7043938 > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7043959 > > Description: > > The NTLM mechanism for SASL has several API compliance issues when an > error occurs during the communication, say, throwing an > UnsupportedOperationException when an IllegalStateException is > expected, > or, throwing a NullPointerException when a SaslException is expected. > > The fix is already included in jdk8 as: > > Changeset: 55952703809f > Author: weijun > Date: 2011-08-19 13:42 +0800 > URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/55952703809f > > 7043847: NTML impl of SaslServer throws > UnsupportedOperationException from (un)wrap method > 7043860: NTML impl of SaslServer doesn't throw ISE from > getAuthorizationID() method > 7043882: NTML impl of SaslServer doesn't throw ISE from > getNegotiatedProperty() method > 7043938: NTML impl of SaslClientFactory throws NPE instead of > SaslException > 7043959: NTML impl of SaslClientFactory throws NPE for null > CallBackHandler instance > Reviewed-by: vinnie > > The patch for jdk7u2 is almost identical to the one in jdk8. There are > only 2 places where the context differs a little. > > I intend to push it to > > ssh://hg.openjdk.java.net/jdk7u/jdk7u-dev-gate/jdk > > Thanks > Weijun From weijun.wang at oracle.com Fri Aug 19 00:03:49 2011 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 19 Aug 2011 15:03:49 +0800 Subject: Resent: Push request: 7043847...: NTLM API compliances issues In-Reply-To: <7F0140BD-D461-4D17-91BE-63F943B6B6F0@oracle.com> References: <4E4DFE28.3080604@oracle.com> <7F0140BD-D461-4D17-91BE-63F943B6B6F0@oracle.com> Message-ID: <4E4E0AD5.1000405@oracle.com> Hi Edvard I've just uploaded a webrev at -- http://cr.openjdk.java.net/~weijun/7043847-7u/webrev.00/ After comparing it with the webrev for JDK 8 at -- http://cr.openjdk.java.net/~weijun/7043847/webrev.00/ I found they are actually identical! In fact, it is inside JDK 8 that another changeset on the same files was pushed after my local changeset is created. Therefore when it's time for me to push my changeset, I see a conflict and have to do a merge and push an updated one. I use Mercurial Queue, so there is no "Merge" changeset. So, precisely I should say: The webrev for jdk7u2 is identical to the one in jdk8. The changeset is a little different due to the merge. Do I still need a code review? :) Thanks Max On 08/19/2011 02:41 PM, Edvard Wendelin wrote: > Hi, > > Thanks for the request! Since the fix is not identical to the one in 8 > (I know, nagging about two small changes is picky, but we had to draw > the line somewhere), you'll need to post a webrev on cr.openjdk.java.net > and get one additional review. Once the webrev is uploaded, please send > us a link to it. > > Cheers, > Edvard > > On 19 aug 2011, at 08.09, Weijun Wang wrote: > >> Sorry, forget to update the subject line in my template. Sent again. >> >> -------- Original Message -------- >> Subject: Push request: nnnnnnn: so so >> Date: Fri, 19 Aug 2011 14:00:32 +0800 >> From: Weijun Wang >> To: jdk7u-dev at openjdk.java.net >> >> Hi All >> >> This is a request to backport several jdk8 fix into jdk7u2 b03: >> >> CR: >> >> 7043847: NTML impl of SaslServer throws UnsupportedOperationException >> from (un)wrap method >> 7043860: NTML impl of SaslServer doesn't throw ISE from >> getAuthorizationID() method >> 7043882: NTML impl of SaslServer doesn't throw ISE from >> getNegotiatedProperty() method >> 7043938: NTML impl of SaslClientFactory throws NPE instead of >> SaslException >> 7043959: NTML impl of SaslClientFactory throws NPE for null >> CallBackHandler instance >> >> Weblink: >> >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7043847 >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7043860 >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7043882 >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7043938 >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7043959 >> >> Description: >> >> The NTLM mechanism for SASL has several API compliance issues when an >> error occurs during the communication, say, throwing an >> UnsupportedOperationException when an IllegalStateException is expected, >> or, throwing a NullPointerException when a SaslException is expected. >> >> The fix is already included in jdk8 as: >> >> Changeset: 55952703809f >> Author: weijun >> Date: 2011-08-19 13:42 +0800 >> URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/55952703809f >> >> 7043847: NTML impl of SaslServer throws >> UnsupportedOperationException from (un)wrap method >> 7043860: NTML impl of SaslServer doesn't throw ISE from >> getAuthorizationID() method >> 7043882: NTML impl of SaslServer doesn't throw ISE from >> getNegotiatedProperty() method >> 7043938: NTML impl of SaslClientFactory throws NPE instead of >> SaslException >> 7043959: NTML impl of SaslClientFactory throws NPE for null >> CallBackHandler instance >> Reviewed-by: vinnie >> >> The patch for jdk7u2 is almost identical to the one in jdk8. There are >> only 2 places where the context differs a little. >> >> I intend to push it to >> >> ssh://hg.openjdk.java.net/jdk7u/jdk7u-dev-gate/jdk >> >> Thanks >> Weijun > From dalibor.topic at oracle.com Fri Aug 19 02:20:50 2011 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Fri, 19 Aug 2011 11:20:50 +0200 Subject: Resent: Push request: 7043847...: NTLM API compliances issues In-Reply-To: <4E4E0AD5.1000405@oracle.com> References: <4E4DFE28.3080604@oracle.com> <7F0140BD-D461-4D17-91BE-63F943B6B6F0@oracle.com> <4E4E0AD5.1000405@oracle.com> Message-ID: <4E4E2AF2.6060303@oracle.com> On 8/19/11 9:03 AM, Weijun Wang wrote: > Hi Edvard > > I've just uploaded a webrev at -- > > http://cr.openjdk.java.net/~weijun/7043847-7u/webrev.00/ > > After comparing it with the webrev for JDK 8 at -- > > http://cr.openjdk.java.net/~weijun/7043847/webrev.00/ > > I found they are actually identical! > > In fact, it is inside JDK 8 that another changeset on the same files was pushed after my local changeset is created. Therefore when it's time for me to push my changeset, I see a conflict and have to do a merge and push an updated one. I use Mercurial Queue, so there is no "Merge" changeset. > > So, precisely I should say: > > The webrev for jdk7u2 is identical to the one in jdk8. The changeset is a little different due to the merge. > > Do I still need a code review? :) Nope - if it's the same patch as in 8, you're good to go, and it is in this case. cheers, dalibor topic -- Oracle Dalibor Topic | Java F/OSS Ambassador Phone: +494023646738 | Mobile: +491772664192 Oracle Java Platform Group ORACLE Deutschland B.V. & Co. KG | Nagelsweg 55 | 20097 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: J?rgen Kunz, Marcel van de Molen, Alexander van der Ven Green Oracle Oracle is committed to developing practices and products that help protect the environment From John.Coomes at oracle.com Sat Aug 20 00:36:12 2011 From: John.Coomes at oracle.com (John Coomes) Date: Sat, 20 Aug 2011 00:36:12 -0700 Subject: HotSpot bulk change request - hs22-b02 into jdk7u-b03 Message-ID: <20047.25580.527511.583623@oracle.com> Requesting approval to integrate hs22-b02 into jdk7u-b03. The webrev (XXL) can be found at: http://cr.openjdk.java.net/~jcoomes/webrev.hs22-b02-7u2-b03/ The source can be found at http://hg.openjdk.java.net/hsx/hsx22/hotspot The changes have passed JPRT builds + tests on all platforms and are currently undergoing PIT; results are expected Tuesday. I've reserved the PM slot on Tue 8/23 for the integration (pending approval, of course). A list of the bug fixes included in this request is attached. -John -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: bug-fixes.hs22-b02-7u2-b03 Url: http://mail.openjdk.java.net/pipermail/jdk7u-dev/attachments/20110820/eec39e83/attachment.ksh From dmdabbs at gmail.com Sat Aug 20 07:02:43 2011 From: dmdabbs at gmail.com (David Dabbs) Date: Sat, 20 Aug 2011 09:02:43 -0500 Subject: Are 7u builds available for download & testing? Message-ID: <00ea01cc5f41$d68cb3c0$83a61b40$@com> If so, could someone provide a link to the download page? Thank you, david From weijun.wang at oracle.com Mon Aug 22 00:20:31 2011 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Mon, 22 Aug 2011 07:20:31 +0000 Subject: hg: jdk7u/jdk7u-dev/jdk: 7043847: NTML impl of SaslServer throws UnsupportedOperationException from (un)wrap method; ... Message-ID: <20110822072043.BC98547FC5@hg.openjdk.java.net> Changeset: 0dcb939eff08 Author: weijun Date: 2011-08-22 15:17 +0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/jdk/rev/0dcb939eff08 7043847: NTML impl of SaslServer throws UnsupportedOperationException from (un)wrap method 7043860: NTML impl of SaslServer doesn't throw ISE from getAuthorizationID() method 7043882: NTML impl of SaslServer doesn't throw ISE from getNegotiatedProperty() method 7043938: NTML impl of SaslClientFactory throws NPE instead of SaslException 7043959: NTML impl of SaslClientFactory throws NPE for null CallBackHandler instance Reviewed-by: vinnie ! src/share/classes/com/sun/security/ntlm/Client.java ! src/share/classes/com/sun/security/ntlm/NTLMException.java ! src/share/classes/com/sun/security/ntlm/Server.java ! src/share/classes/com/sun/security/sasl/ntlm/FactoryImpl.java ! src/share/classes/com/sun/security/sasl/ntlm/NTLMClient.java ! src/share/classes/com/sun/security/sasl/ntlm/NTLMServer.java + test/com/sun/security/sasl/ntlm/Conformance.java From dalibor.topic at oracle.com Mon Aug 22 08:02:22 2011 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Mon, 22 Aug 2011 17:02:22 +0200 Subject: HotSpot bulk change request - hs22-b02 into jdk7u-b03 In-Reply-To: <20047.25580.527511.583623@oracle.com> References: <20047.25580.527511.583623@oracle.com> Message-ID: <4E526F7E.7040800@oracle.com> On 8/20/11 9:36 AM, John Coomes wrote: > Requesting approval to integrate hs22-b02 into jdk7u-b03. > The webrev (XXL) can be found at: > > http://cr.openjdk.java.net/~jcoomes/webrev.hs22-b02-7u2-b03/ > > The source can be found at > > http://hg.openjdk.java.net/hsx/hsx22/hotspot > > The changes have passed JPRT builds + tests on all platforms and are > currently undergoing PIT; results are expected Tuesday. I've reserved > the PM slot on Tue 8/23 for the integration (pending approval, of > course). > > A list of the bug fixes included in this request is attached. Thanks, John - approved. cheers, dalibor topic -- Oracle Dalibor Topic | Java F/OSS Ambassador Phone: +494023646738 | Mobile: +491772664192 Oracle Java Platform Group ORACLE Deutschland B.V. & Co. KG | Nagelsweg 55 | 20097 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: J?rgen Kunz, Marcel van de Molen, Alexander van der Ven Green Oracle Oracle is committed to developing practices and products that help protect the environment From michael.fang at sun.com Mon Aug 22 11:18:22 2011 From: michael.fang at sun.com (michael.fang at sun.com) Date: Mon, 22 Aug 2011 18:18:22 +0000 Subject: hg: jdk7u/jdk7u-dev/jdk: 3 new changesets Message-ID: <20110822181911.CE19C47FE1@hg.openjdk.java.net> Changeset: 17110b287f27 Author: yhuang Date: 2011-08-17 23:37 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/jdk/rev/17110b287f27 7066203: Update currency data to the latest ISO 4217 standard Reviewed-by: naoto ! make/java/util/FILES_properties.gmk ! make/tools/src/build/tools/generatecurrencydata/GenerateCurrencyData.java ! src/share/classes/java/util/CurrencyData.properties ! src/share/classes/java/util/LocaleISOData.java ! src/share/classes/sun/util/resources/CurrencyNames.properties ! src/share/classes/sun/util/resources/CurrencyNames_de.properties ! src/share/classes/sun/util/resources/CurrencyNames_es.properties + src/share/classes/sun/util/resources/CurrencyNames_es_CU.properties ! src/share/classes/sun/util/resources/CurrencyNames_et_EE.properties ! src/share/classes/sun/util/resources/CurrencyNames_fr.properties ! src/share/classes/sun/util/resources/CurrencyNames_ja.properties ! src/share/classes/sun/util/resources/CurrencyNames_ko.properties ! src/share/classes/sun/util/resources/CurrencyNames_pt.properties ! src/share/classes/sun/util/resources/CurrencyNames_sk_SK.properties ! src/share/classes/sun/util/resources/CurrencyNames_zh_CN.properties ! src/share/classes/sun/util/resources/CurrencyNames_zh_TW.properties ! src/share/classes/sun/util/resources/LocaleNames.properties ! test/java/util/Currency/ValidateISO4217.java ! test/java/util/Currency/tablea1.txt ! test/java/util/Locale/LocaleTest.java ! test/sun/text/resources/LocaleData ! test/sun/text/resources/LocaleDataTest.java Changeset: 1976c0d6ec52 Author: mfang Date: 2011-08-19 12:35 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/jdk/rev/1976c0d6ec52 Merge Changeset: 4ff462fd9de2 Author: mfang Date: 2011-08-22 10:15 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/jdk/rev/4ff462fd9de2 Merge From joe.darcy at oracle.com Mon Aug 22 18:08:12 2011 From: joe.darcy at oracle.com (Joe Darcy) Date: Mon, 22 Aug 2011 18:08:12 -0700 Subject: Request for approval to backport 7080038: "(ann) Serializable types in sun.reflect.annotation do not declare serialVersionUIDs" to jdk7u-dev/jdk Message-ID: <4E52FD7C.5000001@oracle.com> Hello. I hereby request to approval to backport 7080038: (ann) Serializable types in sun.reflect.annotation do not declare serialVersionUIDs http://hg.openjdk.java.net/jdk8/tl/jdk/rev/71e353aba896 to jdk7u-dev/jdk. Some more description of the change is on http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-August/007490.html The patch applies cleanly to 7 update. (In order to reduce the window of exposure of this problem in the 7 train, this patch may in the end be present in 7u1 as well as 7u2.) Thanks, -Joe From dalibor.topic at oracle.com Mon Aug 22 18:22:56 2011 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Tue, 23 Aug 2011 03:22:56 +0200 Subject: Request for approval to backport 7080038: "(ann) Serializable types in sun.reflect.annotation do not declare serialVersionUIDs" to jdk7u-dev/jdk In-Reply-To: <4E52FD7C.5000001@oracle.com> References: <4E52FD7C.5000001@oracle.com> Message-ID: <4E5300F0.40005@oracle.com> On 8/23/11 3:08 AM, Joe Darcy wrote: > Hello. > > I hereby request to approval to backport > > 7080038: (ann) Serializable types in sun.reflect.annotation do not declare serialVersionUIDs > http://hg.openjdk.java.net/jdk8/tl/jdk/rev/71e353aba896 > > to jdk7u-dev/jdk. Some more description of the change is on > > http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-August/007490.html > > The patch applies cleanly to 7 update. (In order to reduce the window of exposure of this problem in the 7 train, this patch may in the end be present in 7u1 as well as 7u2.) > > Thanks, > > -Joe > Thanks, Joe - approved. cheers, dalibor topic -- Oracle Dalibor Topic | Java F/OSS Ambassador Phone: +494023646738 | Mobile: +491772664192 Oracle Java Platform Group ORACLE Deutschland B.V. & Co. KG | Nagelsweg 55 | 20097 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: J?rgen Kunz, Marcel van de Molen, Alexander van der Ven Green Oracle Oracle is committed to developing practices and products that help protect the environment From joe.darcy at oracle.com Mon Aug 22 18:47:34 2011 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Tue, 23 Aug 2011 01:47:34 +0000 Subject: hg: jdk7u/jdk7u-dev/jdk: 7080038: (ann) Serializable types in sun.reflect.annotation do not declare serialVersionUIDs Message-ID: <20110823014745.319EF47FFD@hg.openjdk.java.net> Changeset: 611bcd930ed1 Author: darcy Date: 2011-08-22 18:45 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/jdk/rev/611bcd930ed1 7080038: (ann) Serializable types in sun.reflect.annotation do not declare serialVersionUIDs Reviewed-by: alanb ! src/share/classes/sun/reflect/annotation/AnnotationInvocationHandler.java ! src/share/classes/sun/reflect/annotation/AnnotationTypeMismatchExceptionProxy.java ! src/share/classes/sun/reflect/annotation/EnumConstantNotPresentExceptionProxy.java ! src/share/classes/sun/reflect/annotation/TypeNotPresentExceptionProxy.java From denis.fokin at oracle.com Tue Aug 23 07:15:01 2011 From: denis.fokin at oracle.com (Denis S. Fokin) Date: Tue, 23 Aug 2011 18:15:01 +0400 Subject: Request for approval to backport 7072645: "Toolkit.addPropertyChangeListener(name, pcl) throws NPE for null name" to jdk7u-dev/jdk In-Reply-To: <4E52FD7C.5000001@oracle.com> References: <4E52FD7C.5000001@oracle.com> Message-ID: <4E53B5E5.5070201@oracle.com> Good day. I hereby request to approval to backport 7072645: Toolkit.addPropertyChangeListener(name, pcl) throws NPE for null name http://hg.openjdk.java.net/jdk8/awt/jdk/rev/7968d9677f9a to jdk7u-dev/jdk. This is a direct backport of the change. The fix has been reviewed by art and JCK team (Dmitry Bessonov). Thank you, Denis. From edvard.wendelin at oracle.com Tue Aug 23 07:28:42 2011 From: edvard.wendelin at oracle.com (Edvard Wendelin) Date: Tue, 23 Aug 2011 16:28:42 +0200 Subject: Request for approval to backport 7072645: "Toolkit.addPropertyChangeListener(name, pcl) throws NPE for null name" to jdk7u-dev/jdk In-Reply-To: <4E53B5E5.5070201@oracle.com> References: <4E52FD7C.5000001@oracle.com> <4E53B5E5.5070201@oracle.com> Message-ID: <4E53B91A.6090402@oracle.com> Approved. Use the http://hg.openjdk.java.net/jdk7u/jdk7u-dev-gate/jdk/ repository for the push. Cheers, Edvard On 08/23/2011 04:15 PM, Denis S. Fokin wrote: > Good day. > > I hereby request to approval to backport > > 7072645: Toolkit.addPropertyChangeListener(name, pcl) throws NPE for > null name > http://hg.openjdk.java.net/jdk8/awt/jdk/rev/7968d9677f9a > > to jdk7u-dev/jdk. > > This is a direct backport of the change. The fix has been reviewed by > art and JCK team (Dmitry Bessonov). > > Thank you, > Denis. From edvard.wendelin at oracle.com Tue Aug 23 07:48:51 2011 From: edvard.wendelin at oracle.com (Edvard Wendelin) Date: Tue, 23 Aug 2011 16:48:51 +0200 Subject: Are 7u builds available for download & testing? In-Reply-To: <00ea01cc5f41$d68cb3c0$83a61b40$@com> References: <00ea01cc5f41$d68cb3c0$83a61b40$@com> Message-ID: <4E53BDD3.4060307@oracle.com> Hi, You can find 7u2 b02 here: http://jdk7.java.net/preview/ Cheers, Edvard On 08/20/2011 04:02 PM, David Dabbs wrote: > If so, could someone provide a link to the download page? > > > > Thank you, > > > > david > > > > > From John.Coomes at oracle.com Tue Aug 23 10:10:13 2011 From: John.Coomes at oracle.com (John Coomes) Date: Tue, 23 Aug 2011 10:10:13 -0700 Subject: Process proposal for Updating JDK 7u with Hotspot Express... In-Reply-To: <1313029001.1843.242.camel@ghostbox> References: <1313029001.1843.242.camel@ghostbox> Message-ID: <20051.57077.708965.353840@oracle.com> Erik Trimble (erik.trimble at oracle.com) wrote: > Hi folks. > > This email is to descibe the the process of integrating Hotspot Express > versions into the JDK 7u series, and open a comment on the this process. > It's rather long, so please read it carefully. > ... Since Erik has left Oracle, I'll be filling in until a permanent hotspot gatekeeper is able to take over. I have some corrections and recommendations below. > The very latest Hotspot development version is always found here: > > http://hg.openjdk.java.net/hsx/hotspot-main/hotspot > > Current, latest Hotspot version is HSX22.0. A copy of the latest STABLE > version of HSX22 (i.e. one which has undergone a QA cycle) is found > here: > > http://hg.openjdk.java.net/hsx/hsx22/hotspot > > Now, normally, after a QA cycle has passed, and the contents of > hsx22/hotspot are refreshed with the newest stable bits, it is then > promoted into the OpenJDK 8 repository > ( hg.openjdk.java.net/jdk8/jdk8/hotspot ) Correction: the hsxNN/hotspot repository is not guaranteed to be completely stable; it's a snapshot area used to capture the source that is about to undergo a PIT (pre-integration test) cycle. So at times it will contain changes that have not yet passed PIT. In practice it turns out to be stable because HotSpot snapshots have already undergone one or more nightly testing cycles and historically have almost always passed PIT. The basic process is: 1. Check the nightly test results for hsx/hotspot-main/ and if no significant failures are found, push a snapshot of the contents to the current numbered hsx repo, (e.g., hsx/hsx22). jprt is used to generate binaries and do the push. 2. Start a PIT cycle using the jprt-generated binaries, testing with the JDK version into which hotspot will be integrated (e.g., jdk7u2). The PIT usually starts on Friday and results are available on Tuesday. 3. While PIT is running, do a complete build of the JDK on all platforms using the hotspot source from the snapshot (a 'control build'). This is also done using jprt, primarily for convenience. 4. If the control build succeeds and the PIT results are acceptable (as determined by SQE), integrate the snapshot into the target release repository (e.g., into jdk8/jdk8/hotspot or jdk7u/jdk7u-dev/hotspot). > Using the Hotspot Express model in the 7u series involves these steps > [note that all references to '7u' or '7u-dev' refer to either > http://hg.openjdk.java.net/jdk7u/jdk7u or > http://hg.openjdk.java.net/jdk7u/jdk7u-dev, respectively]: > > 1.) Periodically, the contents of the latest hsx/hsxN/hotspot repository > (i.e. the version matching the one currently in > hsx/hotspot-main/hotspot ) will be put through a new QA cycle, as a > candidate for inclusion in the 7u series. > > 2.) To be explicit, the QA cycle using this Hotspot Express snapshot > will be using the latest 7u JDK, NOT the 8 JDK. Thus, we expect to > discover any 7-specific issues with Hotspot BEFORE it is pushed into the > Integration repository (7u-dev). > > 2a.) In addition, there will never be a Hotspot->7u integration until > AFTER the same Hotspot version has been promoted into the JDK 8 forest, > and undergone a full Release promotion cycle. This will be to make sure > that the Hotspot version in hsx/hsxN/hotspot is indeed stabilized and we > have worked out any immediately apparent serious issues. This may very > well mean that Hotspot will not immediately promote all Hotspot builds > unto 7u. E.g. HS20 b01 may go to JDK 8 Build 01, but if there are > problems detected, then HS22 will not be pushed into 7u until those > issues are addressed in a new HS build. So, it is entirely possible that > an integration into 7u will actually encompass several Hotspot build > numbers. This restriction (2a) will have to be relaxed, at least somewhat. Since jdk8 builds are not yet happening regularly, requiring the hotspot snapshot to appear in a promoted jdk8 build before it can be integrated into 7u will delay 7u integrations for indefinite periods. So the requirement that a hotspot snapshot complete what Erik calls 'a full Release promotion cycle' in jdk8 before being integrated into 7u should be dropped. In addition, given that build schedules and release dates for 7u and 8 are not aligned, I can easily foresee the case when deadlines will necessitate integration into 7u before integration into the jdk8 master forest. So we should change the requirement that a hotspot snapshot be integrated into the jdk8 *master* before before being integrated into 7u. Instead, the presence of a fix in *hsx/hotspot-main* should be enough to meet the requirement that a fix be present in jdk8. The hsx/hotspot-main forest is used very much like the jdk8 integration forests used by other groups (e.g., jdk8/build/*, jdk8/tl/*, etc.), in that it is regularly pushed up to the jdk8 master. The only difference is that it also delivers into other releases. The process for approving individual fixes for 7u deems the presence of the fix in a jdk8 integration forest (e.g., jdk8/tl) as sufficient to meet the requirement that a fix be included in jdk8; the same should apply to hotspot. [More comments below.] > 3.) At the beginning of this QA cycle, a webrev will be created, > detailing ALL the changes vs the existing 7u/hotspot repository. That > is, this will be a very large webrev, as it includes all the fixes > between the latest development Hotspot and the existing 7u Hotspot. > > 4.) This webrev will be posted to cr.openjdk.java.net, and a "request > for integration" notice will be sent to jdk7u-dev at openjdk.java.net, as > normal for other integration requests. > > 5.) The 7u Technical Lead will approve the Hotspot update, taking into > consideration the timing of the push - that is, approvals should be > concerned with whether a new Hotspot version is appropriate given build > schedules, NOT on the technical merits. > > 6.) After the approval has been received, the Hotspot snapshot > undergoing QA will be pushed into the 7u-dev/hotspot Integration area. > > 7.) Upon receipt of the QA certification (PIT cert) that Hotspot has > successfully passed all relevant testing (or, there are only > inconsequential errors which aren't large enough to warrant a respin), > the contents of 7u-dev/hotspot will be pushed up to the Master area > (7u/hotspot ). > > A couple of notes: > > a) I expect that #3 and #4 will happen almost simultaneously. That is, > our internal snapshot scripts will submit the job to QA and generate the > webrev together. > > b) #5 should likely happen very shortly after #4, probably the same day. > > c) Frankly, technical discussion of the merits of the Hotspot push is > not expected to be possible here (in the context of the integration, > that is). The webrev is an informational post, not a "please review and > approve" post. This is due to the very large number of CRs being fixed > (several dozen or more), and the highly complex nature of all of them. > Such review is carried out when the code is first pushed into > hsx/hotspot-main and JDK8, so a duplicate review here is not necessary > and is unlikely to be reasonably possible within the limited timeframe > that an integration must have. (Translation: we can't post the webrev > and wait 2 weeks for people to fully review and comment on things before > integrating it). > > d) People interested in hotspot development (which will concern use of > Hotspot in ALL JDK versions, 6, 7, and 8), should subscribe to > hotspot-dev at openjdk.java.net. > > e) the 7uN repositories will NOT follow the above procedure - as they > are "stabilization-only" repositories, Hotspot developers will be > pushing changes directly to the /hotspot repository under the relevant > 7uN forest in the same manner as all other stabilization fixes from > other JDK developers. Thus, all fixes for Hotspot for 7uN releases will > follow the standard JDK processes. > > One specific point where I'm not sure how we want to proceed is this: > > Should #6 (the push of the Hotspot snapshot into 7u-dev/hotspot) happen > right after approval from the Technical Lead happen? If so, then it > likely will be BEFORE QA has finished on the snapshot. This would be in > line with the other JDK fixes, since they do not undergo QA before being > pushed to 7u-dev/*. However, Hotspot is "special", so do we care to be > extra sure that 7u-dev/hotspot is stable? > ... I think hotspot should complete both a PIT cycle and a control build of the JDK before we integrate into 7u-dev since (a) we're doing bulk integrations and the amount of change may be rather large, and (b) we want to ensure that the hotspot in 7u-dev can be used as a bootstrap for a JDK build. We currently don't test the latest hotspot as a bootstrap to build the JDK as part of our automated nightly or JPRT tests, so it should be done before integrating into 7u-dev. We'll follow this order (integrate into jdk7u/jdk7u-dev only after passing PIT, and into jdk7u/jdk7u shortly afterward) for the current integration of hs22 b02 into 7u2 b03, expected today. PIT results are still pending, but all other requirements have been met. -John From trims at netdemons.com Tue Aug 23 11:07:19 2011 From: trims at netdemons.com (Erik Trimble) Date: Tue, 23 Aug 2011 11:07:19 -0700 Subject: Process proposal for Updating JDK 7u with Hotspot Express... In-Reply-To: <20051.57077.708965.353840@oracle.com> References: <1313029001.1843.242.camel@ghostbox> <20051.57077.708965.353840@oracle.com> Message-ID: <4E53EC57.2010207@netdemons.com> On 8/23/2011 10:10 AM, John Coomes wrote: > Since Erik has left Oracle, I'll be filling in until a permanent > hotspot gatekeeper is able to take over. > > I have some corrections and recommendations below. > All of John's comments make sense to me. More importantly, his changes reflect reality of what the current 7u and 8 situation is. My one comment is on the following section: > 2a.) In addition, there will never be a Hotspot->7u integration until > AFTER the same Hotspot version has been promoted into the JDK 8 forest, > and undergone a full Release promotion cycle. This will be to make sure > that the Hotspot version in hsx/hsxN/hotspot is indeed stabilized and we > have worked out any immediately apparent serious issues. This may very > well mean that Hotspot will not immediately promote all Hotspot builds > unto 7u. E.g. HS20 b01 may go to JDK 8 Build 01, but if there are > problems detected, then HS22 will not be pushed into 7u until those > issues are addressed in a new HS build. So, it is entirely possible that > an integration into 7u will actually encompass several Hotspot build > numbers. > This restriction (2a) will have to be relaxed, at least somewhat. > Since jdk8 builds are not yet happening regularly, requiring the > hotspot snapshot to appear in a promoted jdk8 build before it can be > integrated into 7u will delay 7u integrations for indefinite periods. > So the requirement that a hotspot snapshot complete what Erik calls 'a > full Release promotion cycle' in jdk8 before being integrated into 7u > should be dropped. > > In addition, given that build schedules and release dates for 7u and 8 > are not aligned, I can easily foresee the case when deadlines will > necessitate integration into 7u before integration into the jdk8 > master forest. > > So we should change the requirement that a hotspot snapshot be > integrated into the jdk8 *master* before before being integrated into > 7u. Instead, the presence of a fix in *hsx/hotspot-main* should be > enough to meet the requirement that a fix be present in jdk8. The > hsx/hotspot-main forest is used very much like the jdk8 integration > forests used by other groups (e.g., jdk8/build/*, jdk8/tl/*, etc.), in > that it is regularly pushed up to the jdk8 master. The only > difference is that it also delivers into other releases. The process > for approving individual fixes for 7u deems the presence of the fix in > a jdk8 integration forest (e.g., jdk8/tl) as sufficient to meet the > requirement that a fix be included in jdk8; the same should apply to > hotspot. I'd think that what I originally described for the 7u process (i.e. never integrate to 7u until that change has been pushed into 8) is the goal process - that is, if all the QA systems are up and running, and all JDK 8 and JDK 7u development work is going full steam, then the we should adhere to the No 7u Before 8 restriction. I know that's not the case now, and that 7u is currently being given more priority than 8, so John's proposal is a good one (and, reflects the facts on the ground). Maybe about the time 7u2 gets pushed out, things will have settled down sufficiently, and we can look forward to going back to requiring a tested 8 push before the equivalent 7u push. >> One specific point where I'm not sure how we want to proceed is this: >> >> Should #6 (the push of the Hotspot snapshot into 7u-dev/hotspot) happen >> right after approval from the Technical Lead happen? If so, then it >> likely will be BEFORE QA has finished on the snapshot. This would be in >> line with the other JDK fixes, since they do not undergo QA before being >> pushed to 7u-dev/*. However, Hotspot is "special", so do we care to be >> extra sure that 7u-dev/hotspot is stable? >> ... > I think hotspot should complete both a PIT cycle and a control build > of the JDK before we integrate into 7u-dev since (a) we're doing bulk > integrations and the amount of change may be rather large, and (b) we > want to ensure that the hotspot in 7u-dev can be used as a bootstrap > for a JDK build. We currently don't test the latest hotspot as a > bootstrap to build the JDK as part of our automated nightly or JPRT > tests, so it should be done before integrating into 7u-dev. > > We'll follow this order (integrate into jdk7u/jdk7u-dev only after > passing PIT, and into jdk7u/jdk7u shortly afterward) for the current > integration of hs22 b02 into 7u2 b03, expected today. PIT results are > still pending, but all other requirements have been met. > > -John John's proposal here is the more conservative one, which is entirely acceptable. I think the only salient notable result is that people will see the 7u-dev/hotspot updated very shortly before the 7u/hotspot repository (likely only a few hours before, if that). So, people should be aware that this happens, and not to expect a large amount of time to review and/or look at things in the 7u-dev/hotspot repository before those changes hit 7u/hotspot. Lastly, John is correct in that I'm no longer at Oracle. I've moved to a company in downtown San Francisco; however, I'm going to be a heavy user of the JDK at my new employer (who's building something that will hammer the living crap out of the JVM), and expect to continue participating in the OpenJDK project. Email from me will use this (my personal email) account, until it becomes appropriate for me to use my new employer's address. So, set your email filters appropriately. :-) -Erik trims at netdemons.com From xueming.shen at oracle.com Tue Aug 23 10:46:34 2011 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Tue, 23 Aug 2011 17:46:34 +0000 Subject: hg: jdk7u/jdk7u-dev/jdk: 7066490: @since 1.7 tag is missing for java.util.regex.Matcher.group(java.lang.String) Message-ID: <20110823174703.9CD3747036@hg.openjdk.java.net> Changeset: be4a3afb7438 Author: sherman Date: 2011-08-23 10:53 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/jdk/rev/be4a3afb7438 7066490: @since 1.7 tag is missing for java.util.regex.Matcher.group(java.lang.String) Summary: Added the @since 1.7 tag Reviewed-by: mduigou ! src/share/classes/java/util/regex/Matcher.java From dalibor.topic at oracle.com Tue Aug 23 15:00:22 2011 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Wed, 24 Aug 2011 00:00:22 +0200 Subject: hg: jdk7u/jdk7u-dev/jdk: 7066490: @since 1.7 tag is missing for java.util.regex.Matcher.group(java.lang.String) In-Reply-To: <20110823174703.9CD3747036@hg.openjdk.java.net> References: <20110823174703.9CD3747036@hg.openjdk.java.net> Message-ID: <4E5422F6.5030908@oracle.com> Hi, I don't think that we saw a request for approval for this change to be pushed into 7u. If I'm mistaken, I'd appreciate a pointer to the mail archive, otherwise, please post one in accordance with the 7u development processes. Thanks! cheers, dalibor topic On 8/23/11 7:46 PM, xueming.shen at oracle.com wrote: > Changeset: be4a3afb7438 > Author: sherman > Date: 2011-08-23 10:53 -0700 > URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/jdk/rev/be4a3afb7438 > > 7066490: @since 1.7 tag is missing for java.util.regex.Matcher.group(java.lang.String) > Summary: Added the @since 1.7 tag > Reviewed-by: mduigou > > ! src/share/classes/java/util/regex/Matcher.java > -- Oracle Dalibor Topic | Java F/OSS Ambassador Phone: +494023646738 | Mobile: +491772664192 Oracle Java Platform Group ORACLE Deutschland B.V. & Co. KG | Nagelsweg 55 | 20097 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: J?rgen Kunz, Marcel van de Molen, Alexander van der Ven Green Oracle Oracle is committed to developing practices and products that help protect the environment From xueming.shen at oracle.com Tue Aug 23 15:35:00 2011 From: xueming.shen at oracle.com (Xueming Shen) Date: Tue, 23 Aug 2011 15:35:00 -0700 Subject: hg: jdk7u/jdk7u-dev/jdk: 7066490: @since 1.7 tag is missing for java.util.regex.Matcher.group(java.lang.String) In-Reply-To: <4E5422F6.5030908@oracle.com> References: <20110823174703.9CD3747036@hg.openjdk.java.net> <4E5422F6.5030908@oracle.com> Message-ID: <4E542B14.1040508@oracle.com> My apology, forgot the process. Will post one soon. On 8/23/2011 3:00 PM, Dalibor Topic wrote: > Hi, > > I don't think that we saw a request for approval for this change to be pushed into 7u. > If I'm mistaken, I'd appreciate a pointer to the mail archive, otherwise, please post > one in accordance with the 7u development processes. Thanks! > > cheers, > dalibor topic > > On 8/23/11 7:46 PM, xueming.shen at oracle.com wrote: >> Changeset: be4a3afb7438 >> Author: sherman >> Date: 2011-08-23 10:53 -0700 >> URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/jdk/rev/be4a3afb7438 >> >> 7066490: @since 1.7 tag is missing for java.util.regex.Matcher.group(java.lang.String) >> Summary: Added the @since 1.7 tag >> Reviewed-by: mduigou >> >> ! src/share/classes/java/util/regex/Matcher.java >> > > From john.coomes at oracle.com Tue Aug 23 21:48:39 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Wed, 24 Aug 2011 04:48:39 +0000 Subject: hg: jdk7u/jdk7u-dev/hotspot: 131 new changesets Message-ID: <20110824045238.28E084707E@hg.openjdk.java.net> Changeset: 303a4d63b484 Author: jcoomes Date: 2011-08-23 21:11 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/hotspot/rev/303a4d63b484 7082689: allow duplicate bug ids in jdk7u repos Reviewed-by: johnc ! .jcheck/conf Changeset: c7c81f18c834 Author: kvn Date: 2011-05-25 21:17 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/hotspot/rev/c7c81f18c834 7048332: Cadd_cmpLTMask doesn't handle 64-bit tmp register properly Summary: Use ins_encode %{ %} form to encode cadd_cmpLTMask() instruction and remove unused code. Reviewed-by: never ! src/cpu/x86/vm/x86_64.ad + test/compiler/7048332/Test7048332.java Changeset: 28263a73ebfb Author: iveresov Date: 2011-05-26 13:15 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/hotspot/rev/28263a73ebfb 7047491: C1: registers saved incorrectly when calling checkcast_arraycopy stub Summary: Save and restore the argument registers around the call to checkcast_arraycopy Reviewed-by: never, roland ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp Changeset: 5ac411b3b8fc Author: never Date: 2011-05-26 14:44 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/hotspot/rev/5ac411b3b8fc 7047961: JSR 292 MethodHandleWalk swap args doesn't handle T_LONG and T_DOUBLE properly Reviewed-by: kvn, jrose ! src/share/vm/prims/methodHandleWalk.cpp ! src/share/vm/prims/methodHandleWalk.hpp ! src/share/vm/prims/methodHandles.cpp Changeset: c76c13577460 Author: never Date: 2011-05-26 16:39 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/hotspot/rev/c76c13577460 Merge Changeset: b2cb497dec28 Author: kvn Date: 2011-05-27 12:47 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/hotspot/rev/b2cb497dec28 7047069: Array can dynamically change size when assigned to an object field Summary: Fix initialization of a newly-allocated array with arraycopy Reviewed-by: never ! src/share/vm/opto/library_call.cpp + test/compiler/7047069/Test7047069.java Changeset: 33e2b8f1d466 Author: kvn Date: 2011-05-31 10:05 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/hotspot/rev/33e2b8f1d466 6956668: misbehavior of XOR operator (^) with int Summary: optimize cmp_ne(xor(X,1),0) to cmp_eq(X,0) only for boolean values X. Reviewed-by: never ! src/share/vm/opto/subnode.cpp + test/compiler/6956668/Test6956668.java Changeset: 60b8287df30e Author: jrose Date: 2011-06-01 23:25 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/hotspot/rev/60b8287df30e 7049415: Failure of resolution of sym.reference to the c.s.s. should be wrapped in BootstrapMethodError Summary: Delegate invokedynamic linkage errors to MethodHandleNatives.raiseException. Reviewed-by: never ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/prims/methodHandles.hpp Changeset: a93146d0e4be Author: jrose Date: 2011-06-01 23:25 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/hotspot/rev/a93146d0e4be 7049410: JSR 292 old method name MethodHandle.invokeGeneric should not be accepted by the JVM Summary: change the default setting of the flag AllowInvokeGeneric to false Reviewed-by: never ! src/share/vm/runtime/globals.hpp Changeset: 537a4053b0f9 Author: ysr Date: 2011-05-23 16:42 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/hotspot/rev/537a4053b0f9 7042740: CMS: assert(n> q) failed: Looping at: ... blockOffsetTable.cpp:557 Summary: Do a one-step look-ahead, when sweeping free or garbage blocks, to avoid overstepping sweep limit, which may become a non-block-boundary because of a heap expansion delta coalescing with a previously co-terminal free block. Reviewed-by: brutisso, tonyp ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp ! src/share/vm/memory/blockOffsetTable.cpp Changeset: f153114134c8 Author: jcoomes Date: 2011-06-07 13:17 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/hotspot/rev/f153114134c8 Merge Changeset: d3b9f2be46ab Author: coleenp Date: 2011-05-21 15:39 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/hotspot/rev/d3b9f2be46ab 7033141: assert(has_cp_cache(i)) failed: oob Summary: Unrewrite bytecodes for OOM error allocating the constant pool cache. Reviewed-by: dcubed, acorn, never ! src/share/vm/interpreter/rewriter.cpp ! src/share/vm/interpreter/rewriter.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/methodOop.cpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/prims/methodHandleWalk.cpp Changeset: 9dd6c4ba364f Author: coleenp Date: 2011-06-02 14:17 -0400 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/hotspot/rev/9dd6c4ba364f 7049928: VM crashes with "assert(_adapter != NULL) failed: must have" at methodOop.cpp:63 Summary: Removed extra change from another bug fix that caused this regression Reviewed-by: phh, dcubed, kvn, kamg, never ! src/share/vm/oops/methodOop.cpp Changeset: 96c891ebe56a Author: coleenp Date: 2011-06-02 21:01 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/hotspot/rev/96c891ebe56a Merge ! src/share/vm/prims/methodHandleWalk.cpp Changeset: ae1d716e395c Author: dsamersoff Date: 2011-06-09 01:33 +0400 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/hotspot/rev/ae1d716e395c Merge Changeset: f918d6096e23 Author: never Date: 2011-06-02 13:36 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/hotspot/rev/f918d6096e23 7050554: JSR 292 - need optimization for selectAlternative Reviewed-by: kvn, jrose ! src/share/vm/ci/ciCallProfile.hpp ! src/share/vm/ci/ciMethodHandle.cpp ! src/share/vm/ci/ciMethodHandle.hpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/opto/callGenerator.cpp ! src/share/vm/opto/callGenerator.hpp ! src/share/vm/opto/doCall.cpp Changeset: cba7b5c2d53f Author: never Date: 2011-06-03 22:31 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/hotspot/rev/cba7b5c2d53f 7045514: SPARC assembly code for JSR 292 ricochet frames Reviewed-by: kvn, jrose ! src/cpu/sparc/vm/assembler_sparc.cpp ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/cpu/sparc/vm/assembler_sparc.inline.hpp ! src/cpu/sparc/vm/frame_sparc.cpp ! src/cpu/sparc/vm/methodHandles_sparc.cpp + src/cpu/sparc/vm/methodHandles_sparc.hpp ! src/cpu/sparc/vm/registerMap_sparc.hpp ! src/cpu/sparc/vm/runtime_sparc.cpp ! src/cpu/sparc/vm/sharedRuntime_sparc.cpp ! src/cpu/sparc/vm/stubRoutines_sparc.hpp ! src/cpu/sparc/vm/templateInterpreter_sparc.cpp ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/cpu/x86/vm/methodHandles_x86.hpp ! src/cpu/x86/vm/runtime_x86_32.cpp ! src/cpu/x86/vm/sharedRuntime_x86_32.cpp ! src/cpu/x86/vm/sharedRuntime_x86_64.cpp ! src/cpu/x86/vm/stubRoutines_x86_32.hpp ! src/cpu/x86/vm/stubRoutines_x86_64.hpp ! src/share/vm/compiler/oopMap.cpp ! src/share/vm/opto/runtime.cpp ! src/share/vm/prims/methodHandleWalk.cpp ! src/share/vm/prims/methodHandleWalk.hpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/prims/methodHandles.hpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/sharedRuntime.hpp Changeset: 642c68c75db9 Author: kvn Date: 2011-06-04 10:36 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/hotspot/rev/642c68c75db9 7050280: assert(u->as_Unlock()->is_eliminated()) failed: sanity Summary: Mark all associated (same box and obj) lock and unlock nodes for elimination if some of them marked already. Reviewed-by: iveresov, never ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/macro.hpp Changeset: 5cf771a79037 Author: jrose Date: 2011-06-08 17:04 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/hotspot/rev/5cf771a79037 7047697: MethodHandle.invokeExact call for wrong method causes VM failure if run with -Xcomp Reviewed-by: never, twisti ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/frame_x86.inline.hpp ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/share/vm/code/pcDesc.cpp Changeset: c8f2186acf6d Author: twisti Date: 2011-06-14 12:25 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/hotspot/rev/c8f2186acf6d 7053520: JSR292: crash in invokedynamic with C1 using tiered and compressed oops Reviewed-by: iveresov, never ! src/share/vm/c1/c1_LIRGenerator.cpp Changeset: f8c9417e3571 Author: never Date: 2011-06-14 14:41 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/hotspot/rev/f8c9417e3571 7052219: JSR 292: Crash in ~BufferBlob::MethodHandles adapters Reviewed-by: twisti, kvn, jrose ! src/cpu/sparc/vm/methodHandles_sparc.cpp ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/share/vm/prims/methodHandleWalk.cpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/prims/methodHandles.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/stubCodeGenerator.cpp ! src/share/vm/runtime/stubCodeGenerator.hpp Changeset: e2ce15aa3daf Author: never Date: 2011-06-14 15:20 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/hotspot/rev/e2ce15aa3daf Merge Changeset: cfcf2ba8f3eb Author: never Date: 2011-06-15 10:20 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/hotspot/rev/cfcf2ba8f3eb Merge ! src/share/vm/prims/methodHandleWalk.cpp Changeset: e2af886d540b Author: trims Date: 2011-07-01 13:07 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/hotspot/rev/e2af886d540b 7061691: Fork HS21 to HS22 - renumber Minor and build numbers of JVM Summary: Update the Minor and Build numbers for HS22 fork Reviewed-by: jcoomes ! make/hotspot_version Changeset: 1e3493ac2d11 Author: ysr Date: 2011-05-27 10:23 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/hotspot/rev/1e3493ac2d11 7048342: CMS: eob == _limit || fc->isFree() failed: Only a free chunk should allow us to cross over the limit Summary: The freeness bit was being cleared in debug code when it shouldn't have been. Also removed unused FreeChunk methods linkAfterNonNull and clearPrev. Reviewed-by: brutisso ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/freeChunk.hpp Changeset: 5c0a3c1858b1 Author: ysr Date: 2011-06-02 10:23 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/hotspot/rev/5c0a3c1858b1 7048782: CMS: assert(last_chunk_index_to_check<= last_chunk_index) failed: parCardTableModRefBS.cpp:359 Summary: The LNC array is sized before the start of a scavenge, while the heap may expand during a scavenge. With CMS, the last block of an arbitrary suffice of the LNC array may expand due to coalition with the expansion delta. We now take care not to attempt access past the end of the LNC array. LNC array code will be cleaned up and suitably encapsulated as part of the forthcoming performance RFE 7043675. Reviewed-by: brutisso ! src/share/vm/gc_implementation/parNew/parCardTableModRefBS.cpp Changeset: e66f38dd58a9 Author: ysr Date: 2011-06-08 08:39 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/hotspot/rev/e66f38dd58a9 Merge Changeset: 053d84a76d3d Author: tonyp Date: 2011-06-08 15:31 -0400 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/hotspot/rev/053d84a76d3d 7032531: G1: enhance GC logging to include more accurate eden / survivor size transitions Summary: This changeset extends the logging information generated by +PrintGCDetails to also print out separate size transitions for the eden, survivors, and old regions. Reviewed-by: ysr, brutisso ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp Changeset: ae5b2f1dcf12 Author: tonyp Date: 2011-06-08 21:48 -0400 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/hotspot/rev/ae5b2f1dcf12 7045662: G1: OopsInHeapRegionClosure::set_region() should not be virtual Summary: make the method non-virtual, remove five unused closures, and fix a couple of copyright typos. Reviewed-by: stefank, johnc, poonam ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1OopClosures.hpp ! src/share/vm/gc_implementation/g1/g1OopClosures.inline.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/g1_specialized_oop_closures.hpp ! src/share/vm/gc_implementation/g1/heapRegionSet.hpp ! src/share/vm/gc_implementation/g1/heapRegionSets.hpp Changeset: c3f1170908be Author: tonyp Date: 2011-06-10 13:16 -0400 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/hotspot/rev/c3f1170908be 7045330: G1: Simplify/fix the HeapRegionSeq class 7042285: G1: native memory leak during humongous object allocation 6804436: G1: heap region indices should be size_t Summary: A series of fixes and improvements to the HeapRegionSeq class: a) replace the _regions growable array with a standard C array, b) avoid de-allocating / re-allocating HeapRegion instances when the heap shrinks / grows (fix for 7042285), c) introduce fast method to map address to HeapRegion via a "biased" array pointer, d) embed the _hrs object in G1CollectedHeap, instead of pointing to it via an indirection, e) assume that all the regions added to the HeapRegionSeq instance are contiguous, f) replace int's with size_t's for indexes (and expand that to HeapRegion as part of 6804436), g) remove unnecessary / unused methods, h) rename a couple of fields (_alloc_search_start and _seq_bottom), i) fix iterate_from() not to always start from index 0 irrespective of the region passed to it, j) add a verification method to check the HeapRegionSeq assumptions, k) always call the wrappers for _hrs.iterate(), _hrs_length(), and _hrs.at() from G1CollectedHeap, not those methods di rectly, and l) unify the code that expands the sequence (by either re-using or creating a new HeapRegion) and make it robust wrt to a HeapRegion allocation failing. Reviewed-by: stefank, johnc, brutisso ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.inline.hpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp ! src/share/vm/gc_implementation/g1/heapRegionSeq.cpp ! src/share/vm/gc_implementation/g1/heapRegionSeq.hpp ! src/share/vm/gc_implementation/g1/heapRegionSeq.inline.hpp ! src/share/vm/gc_implementation/g1/sparsePRT.cpp Changeset: 2a241e764894 Author: minqi Date: 2011-06-10 15:08 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/hotspot/rev/2a241e764894 6941923: RFE: Handling large log files produced by long running Java Applications Summary: supply optinal flags to realize gc log rotation Reviewed-by: ysr, jwilhelm ! src/share/vm/gc_implementation/shared/concurrentGCThread.cpp ! src/share/vm/gc_implementation/shared/concurrentGCThread.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/atomic.cpp ! src/share/vm/runtime/atomic.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/safepoint.cpp ! src/share/vm/utilities/ostream.cpp ! src/share/vm/utilities/ostream.hpp + test/gc/6941923/test6941923.sh Changeset: 42df21744b50 Author: minqi Date: 2011-06-10 15:44 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/hotspot/rev/42df21744b50 Merge Changeset: ef2d1b8f2dd4 Author: ysr Date: 2011-06-13 09:58 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/hotspot/rev/ef2d1b8f2dd4 7051430: CMS: ongoing CMS cycle should terminate abruptly to allow prompt JVM termination at exit Summary: It turns out that there is no need to explicitly stop CMS since the JVM is taken down at a terminal safepoint during which CMS threads are (terminally) inactive. This will need to be revised if and when we evolve in the future to a point where we allow JVM reincarnation in the same process, but those changes will be much more sweeping than just terminating CMS threads. The unused ::stop() methods will be removed in a separate CR. Also include in this CR is the fix for a small typo in the spelling of UseGCLogFileRotation in a message in arguments.cpp, brought to our attention by Rainer Jung and reviewed by minqi. Reviewed-by: johnc, jwilhelm ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/java.cpp ! src/share/vm/runtime/thread.cpp Changeset: 74cd10898bea Author: brutisso Date: 2011-06-13 13:48 +0200 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/hotspot/rev/74cd10898bea 6918185: Remove unused code for lost card-marking optimization in BacktraceBuilder Summary: Removed dead code Reviewed-by: ysr, coleenp, dholmes ! src/share/vm/classfile/javaClasses.cpp Changeset: 842b840e67db Author: tonyp Date: 2011-06-14 10:33 -0400 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/hotspot/rev/842b840e67db 7046558: G1: concurrent marking optimizations Summary: Some optimizations to improve the concurrent marking phase: specialize the main oop closure, make sure a few methods in the fast path are properly inlined, a few more bits and pieces, and some cosmetic fixes. Reviewed-by: stefank, johnc ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp + src/share/vm/gc_implementation/g1/concurrentMark.inline.hpp ! src/share/vm/gc_implementation/g1/g1OopClosures.hpp ! src/share/vm/gc_implementation/g1/g1OopClosures.inline.hpp ! src/share/vm/gc_implementation/g1/g1_specialized_oop_closures.hpp ! src/share/vm/utilities/bitMap.hpp Changeset: 6747fd0512e0 Author: johnc Date: 2011-06-14 11:01 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/hotspot/rev/6747fd0512e0 7004681: G1: Extend marking verification to Full GCs Summary: Perform a heap verification after the first phase of G1's full GC using objects' mark words to determine liveness. The third parameter of the heap verification routines, which was used in G1 to determine which marking bitmap to use in liveness calculations, has been changed from a boolean to an enum with values defined for using the mark word, and the 'prev' and 'next' bitmaps. Reviewed-by: tonyp, ysr ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1MarkSweep.cpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.cpp ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.hpp ! src/share/vm/gc_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 Changeset: 5130fa1b24f1 Author: johnc Date: 2011-06-15 10:18 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/hotspot/rev/5130fa1b24f1 7045751: G1: +ExplicitGCInvokesConcurrent causes excessive single region evacuation pauses Summary: When ExplicitGCInvokesConcurrent is enabled, do not perform an evacuation pause if a marking cycle is already in progress and block the requesting thread until the marking cycle completes. Reviewed-by: tonyp, ysr ! src/share/vm/gc_implementation/g1/vm_operations_g1.cpp Changeset: c9ca3f51cf41 Author: tonyp Date: 2011-06-16 15:51 -0400 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/hotspot/rev/c9ca3f51cf41 6994322: Remove the is_tlab and is_noref / is_large_noref parameters from the CollectedHeap Summary: Remove two unused parameters from the mem_allocate() method and update its uses accordingly. Reviewed-by: stefank, johnc ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.cpp ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.hpp ! src/share/vm/gc_implementation/parallelScavenge/psOldGen.cpp ! src/share/vm/gc_implementation/parallelScavenge/psOldGen.hpp ! src/share/vm/gc_implementation/parallelScavenge/psPermGen.cpp ! src/share/vm/gc_implementation/parallelScavenge/psYoungGen.hpp ! src/share/vm/gc_implementation/parallelScavenge/vmPSOperations.cpp ! src/share/vm/gc_implementation/parallelScavenge/vmPSOperations.hpp ! src/share/vm/gc_interface/collectedHeap.hpp ! src/share/vm/gc_interface/collectedHeap.inline.hpp ! src/share/vm/memory/collectorPolicy.cpp ! src/share/vm/memory/collectorPolicy.hpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/genCollectedHeap.hpp ! src/share/vm/oops/typeArrayKlass.cpp Changeset: f75137faa7fe Author: ysr Date: 2011-06-20 09:42 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/hotspot/rev/f75137faa7fe 6916968: CMS: freeList.cpp:304 assert(_allocation_stats.prevSweep() + ..., "Conservation Principle") Summary: Fix assert and adjust demand volume computation by adding missing factor. Reviewed-by: jmasa, tonyp ! src/share/vm/gc_implementation/concurrentMarkSweep/freeList.cpp ! src/share/vm/gc_implementation/shared/allocationStats.hpp Changeset: 23d434c6290d Author: tonyp Date: 2011-06-20 22:03 -0400 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/hotspot/rev/23d434c6290d 7055073: G1: code cleanup in the concurrentMark.* files Summary: Only cosmetic changes to make the concurrentMark.* more consistent, code-style-wise, with the rest of the codebase. Reviewed-by: johnc, ysr ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp ! src/share/vm/gc_implementation/g1/concurrentMark.inline.hpp Changeset: e8b0b0392037 Author: tonyp Date: 2011-06-21 15:23 -0400 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/hotspot/rev/e8b0b0392037 7046182: G1: remove unnecessary iterations over the collection set Summary: Remove two unnecessary iterations over the collection set which are supposed to prepare the RSet's of the CSet regions for parallel iterations (we'll make sure this is done incrementally). I'll piggyback on this CR the removal of the G1_REM_SET_LOGGING code. Reviewed-by: brutisso, johnc ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/g1RemSet.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.inline.hpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.hpp ! src/share/vm/gc_implementation/g1/heapRegionSets.cpp ! src/share/vm/gc_implementation/g1/heapRegionSets.hpp Changeset: 5f6f2615433a Author: tonyp Date: 2011-06-24 12:38 -0400 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/hotspot/rev/5f6f2615433a 7049999: G1: Make the G1PrintHeapRegions output consistent and complete Summary: Extend and make more consistent the output from the G1PrintHeapRegions flag. Reviewed-by: johnc, jmasa ! 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/g1HRPrinter.cpp + src/share/vm/gc_implementation/g1/g1HRPrinter.hpp Changeset: 04760e41b01e Author: brutisso Date: 2011-06-28 14:23 +0200 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/hotspot/rev/04760e41b01e 7016112: CMS: crash during promotion testing Summary: Also reviewed by mikael.gerdin at oracle.com; stdlib:qsort() does byte-by-byte swapping on Windows. This leads to pointer shearing. Fix is to implement a quicksort that does full pointer updates. Reviewed-by: never, coleenp, ysr ! src/share/vm/oops/methodOop.cpp ! src/share/vm/prims/jni.cpp ! src/share/vm/runtime/globals.hpp + src/share/vm/utilities/quickSort.cpp + src/share/vm/utilities/quickSort.hpp Changeset: 4bf3cbef0b3e Author: jcoomes Date: 2011-07-06 08:43 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/hotspot/rev/4bf3cbef0b3e Merge ! src/share/vm/oops/methodOop.cpp ! src/share/vm/runtime/globals.hpp Changeset: d83ac25d0304 Author: never Date: 2011-06-16 13:46 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/hotspot/rev/d83ac25d0304 7055355: JSR 292: crash while throwing WrongMethodTypeException Reviewed-by: jrose, twisti, bdelsart ! src/cpu/sparc/vm/methodHandles_sparc.cpp ! src/cpu/sparc/vm/stubGenerator_sparc.cpp ! src/cpu/sparc/vm/templateInterpreter_sparc.cpp ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp ! src/cpu/zero/vm/cppInterpreter_zero.cpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/interpreter/interpreterRuntime.hpp ! src/share/vm/interpreter/templateInterpreter.cpp ! src/share/vm/interpreter/templateInterpreterGenerator.hpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/sharedRuntime.hpp ! src/share/vm/runtime/stubRoutines.cpp ! src/share/vm/runtime/stubRoutines.hpp Changeset: aacaff365100 Author: kvn Date: 2011-06-20 16:45 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/hotspot/rev/aacaff365100 7052494: Eclipse test fails on JDK 7 b142 Summary: Keep 'ne' test in Counted loop when we can't guarantee during compilation that init < limit. Reviewed-by: never ! src/share/vm/opto/loopTransform.cpp ! src/share/vm/opto/loopnode.cpp + test/compiler/7052494/Test7052494.java Changeset: de6a837d75cf Author: never Date: 2011-06-21 09:04 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/hotspot/rev/de6a837d75cf 7056380: VM crashes with SIGSEGV in compiled code Summary: code was using andq reg, imm instead of addq addr, imm Reviewed-by: kvn, jrose, twisti ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/x86_64.ad Changeset: aabf25fa3f05 Author: never Date: 2011-06-22 14:45 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/hotspot/rev/aabf25fa3f05 7057587: JSR 292 - crash with jruby in test/test_respond_to.rb Summary: don't skip receiver when GC'ing compiled invokedynamic callsites Reviewed-by: twisti, kvn, jrose ! src/share/vm/code/nmethod.cpp ! src/share/vm/opto/bytecodeInfo.cpp ! src/share/vm/opto/doCall.cpp ! src/share/vm/opto/parse.hpp Changeset: ddd894528dbc Author: jrose Date: 2011-06-23 17:14 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/hotspot/rev/ddd894528dbc 7056328: JSR 292 invocation sometimes fails in adapters for types not on boot class path Reviewed-by: never ! src/cpu/sparc/vm/templateTable_sparc.cpp ! src/cpu/x86/vm/templateTable_x86_32.cpp ! src/cpu/x86/vm/templateTable_x86_64.cpp ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/ci/ciEnv.hpp ! src/share/vm/ci/ciField.cpp ! src/share/vm/ci/ciMethod.cpp ! src/share/vm/ci/ciMethodHandle.cpp ! src/share/vm/ci/ciObjArrayKlass.cpp ! src/share/vm/ci/ciSignature.cpp ! src/share/vm/ci/ciSignature.hpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/oops/constantPoolKlass.cpp ! src/share/vm/oops/constantPoolOop.cpp ! src/share/vm/oops/constantPoolOop.hpp ! src/share/vm/oops/cpCacheOop.cpp ! src/share/vm/oops/cpCacheOop.hpp ! src/share/vm/oops/methodOop.cpp ! src/share/vm/oops/methodOop.hpp ! src/share/vm/prims/methodHandleWalk.cpp ! src/share/vm/prims/methodHandleWalk.hpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/prims/methodHandles.hpp Changeset: 498c6cf70f7e Author: kvn Date: 2011-06-28 14:30 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/hotspot/rev/498c6cf70f7e 7058036: FieldsAllocationStyle=2 does not work in 32-bit VM Summary: parseClassFile() incorrectly uses nonstatic_oop_map_size() method instead of nonstatic_oop_map_count(). Reviewed-by: never Contributed-by: Krystal Mok ! src/share/vm/classfile/classFileParser.cpp Changeset: 6ae7a1561b53 Author: kvn Date: 2011-06-28 15:04 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/hotspot/rev/6ae7a1561b53 6990015: Incorrect Icache line size is used for 64 bit x86 Summary: correct Icache::line_size for x64 and add verification code into vm_version_x86. Reviewed-by: never, phh ! src/cpu/x86/vm/icache_x86.hpp ! src/cpu/x86/vm/vm_version_x86.cpp ! src/cpu/x86/vm/vm_version_x86.hpp Changeset: e3cbc9ddd434 Author: kvn Date: 2011-06-28 15:24 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/hotspot/rev/e3cbc9ddd434 7044738: Loop unroll optimization causes incorrect result Summary: take into account memory dependencies when clonning nodes in clone_up_backedge_goo(). Reviewed-by: never ! src/share/vm/opto/loopTransform.cpp ! src/share/vm/opto/loopnode.hpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/node.cpp ! src/share/vm/opto/node.hpp + test/compiler/7044738/Test7044738.java + test/compiler/7046096/Test7046096.java Changeset: 7889bbcc7f88 Author: kvn Date: 2011-06-28 15:50 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/hotspot/rev/7889bbcc7f88 7047954: VM crashes with assert(is_Mem()) failed Summary: cast constant array ptrs to bottom Reviewed-by: never ! src/share/vm/opto/compile.cpp Changeset: 6f6e91603a45 Author: iveresov Date: 2011-07-01 10:35 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/hotspot/rev/6f6e91603a45 7058689: Tiered: Reprofiling doesn't happen in presence of level 4 OSR methods Summary: Take into account current state of profiling before believing that existing higher level versions are valid Reviewed-by: kvn, never ! src/share/vm/runtime/advancedThresholdPolicy.cpp ! src/share/vm/runtime/simpleThresholdPolicy.cpp Changeset: 2c359f27615c Author: iveresov Date: 2011-07-01 10:37 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/hotspot/rev/2c359f27615c 7057120: Tiered: Allow C1 to inline methods with loops Summary: Recompile the enclosing methods without inlining of the method that has OSRed to level 4 or recompile the enclosing method at level 4. Reviewed-by: kvn, never ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_Runtime1.cpp ! src/share/vm/ci/ciMethod.cpp ! src/share/vm/ci/ciMethod.hpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/runtime/advancedThresholdPolicy.cpp ! src/share/vm/runtime/advancedThresholdPolicy.hpp ! src/share/vm/runtime/compilationPolicy.cpp ! src/share/vm/runtime/compilationPolicy.hpp ! src/share/vm/runtime/simpleThresholdPolicy.cpp ! src/share/vm/runtime/simpleThresholdPolicy.hpp Changeset: 15559220ce79 Author: never Date: 2011-07-05 16:07 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/hotspot/rev/15559220ce79 6478991: C1 NullCheckEliminator yields incorrect exceptions Reviewed-by: twisti, iveresov ! src/share/vm/c1/c1_Optimizer.cpp + test/compiler/6478991/NullCheckTest.java Changeset: fe240d87c6ec Author: never Date: 2011-07-06 09:27 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/hotspot/rev/fe240d87c6ec 7061101: adlc should complain about mixing block and expression forms of ins_encode Reviewed-by: kvn ! src/share/vm/adlc/adlparse.cpp Changeset: 3e23978ea0c3 Author: never Date: 2011-07-06 18:15 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/hotspot/rev/3e23978ea0c3 7062856: Disassembler needs to be smarter about finding hsdis after 1.7 launcher changes Summary: do explicit lookup emulating old LD_LIBRARY_PATH search Reviewed-by: kvn, jrose ! src/share/tools/hsdis/README ! src/share/vm/compiler/disassembler.cpp Changeset: b16582d6c7db Author: kvn Date: 2011-07-07 10:51 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/hotspot/rev/b16582d6c7db Merge ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/oops/methodOop.cpp Changeset: 7d9e451f5416 Author: jcoomes Date: 2011-07-06 12:03 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/hotspot/rev/7d9e451f5416 7061187: need some includes for arm/ppc Reviewed-by: dholmes, never, jwilhelm, kvn ! src/share/vm/opto/lcm.cpp ! src/share/vm/opto/matcher.cpp ! src/share/vm/runtime/atomic.cpp Changeset: eb94b7226b7a Author: jcoomes Date: 2011-07-06 12:17 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/hotspot/rev/eb94b7226b7a 7061192: option handling adjustments for oracle and embedded builds Reviewed-by: dholmes, never, jwilhelm, kvn ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp Changeset: 65dba8692db7 Author: jcoomes Date: 2011-07-06 12:22 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/hotspot/rev/65dba8692db7 7061197: ThreadLocalStorage sp map table should be optional Reviewed-by: dholmes, never, jwilhelm, kvn ! src/os_cpu/linux_x86/vm/assembler_linux_x86.cpp ! src/os_cpu/linux_x86/vm/threadLS_linux_x86.cpp ! src/os_cpu/linux_x86/vm/threadLS_linux_x86.hpp Changeset: 48048b59a551 Author: jcoomes Date: 2011-07-06 12:28 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/hotspot/rev/48048b59a551 7061204: clean the chunk table synchronously in embedded builds Reviewed-by: dholmes, never, jwilhelm, kvn ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/memory/defNewGeneration.cpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/thread.cpp Changeset: bf6481e5f96d Author: jcoomes Date: 2011-07-06 13:02 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/hotspot/rev/bf6481e5f96d 7061225: os::print_cpu_info() should support os-specific data Reviewed-by: dholmes, never, jwilhelm, kvn ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/windows/vm/os_windows.cpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/os.hpp Changeset: 8a4fc2990229 Author: jcoomes Date: 2011-07-07 15:44 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/hotspot/rev/8a4fc2990229 7053189: remove some unnecessary platform-dependent includes Reviewed-by: dholmes, never, jwilhelm, kvn ! src/share/vm/prims/jni.cpp ! src/share/vm/runtime/arguments.cpp Changeset: b0b8491925fe Author: jcoomes Date: 2011-07-11 14:15 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/hotspot/rev/b0b8491925fe 7061212: use o/s low memory notification in embedded builds Reviewed-by: dholmes, never, jwilhelm, kvn ! src/os/linux/vm/os_linux.cpp Changeset: 0defeba52583 Author: jcoomes Date: 2011-07-12 16:32 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/hotspot/rev/0defeba52583 Merge Changeset: faa472957b38 Author: kvn Date: 2011-07-08 09:38 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/hotspot/rev/faa472957b38 7059034: Use movxtod/movdtox on T4 Summary: Use new VIS3 mov instructions on T4 for move data between general and float registers. Reviewed-by: never, twisti ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/cpu/sparc/vm/sparc.ad ! src/cpu/sparc/vm/vm_version_sparc.cpp ! src/share/vm/runtime/globals.hpp Changeset: 263247c478c5 Author: iveresov Date: 2011-07-08 15:33 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/hotspot/rev/263247c478c5 7058510: multinewarray with 6 dimensions uncommon traps in server compiler Summary: Pass arguments to runtime via java array for arrays with > 5 dimensions Reviewed-by: never, kvn, jrose, pbk ! src/share/vm/opto/parse3.cpp ! src/share/vm/opto/runtime.cpp ! src/share/vm/opto/runtime.hpp Changeset: 1f4f4ae84625 Author: kvn Date: 2011-07-13 10:48 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/hotspot/rev/1f4f4ae84625 Merge ! src/share/vm/runtime/globals.hpp Changeset: e6e7d76b2bd3 Author: mr Date: 2011-05-24 15:28 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/hotspot/rev/e6e7d76b2bd3 7048009: Update .jcheck/conf files for JDK 8 Reviewed-by: jjh ! .jcheck/conf Changeset: 3fbb609d9e96 Author: kvn Date: 2011-07-14 15:39 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/hotspot/rev/3fbb609d9e96 7067288: compiler regression test Test7052494 timeouts with client VM Summary: Test is modified to reduce number of iterations in test5() and test6(). Reviewed-by: never, iveresov ! test/compiler/7052494/Test7052494.java Changeset: 341a57af9b0a Author: never Date: 2011-07-15 15:35 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/hotspot/rev/341a57af9b0a 6990212: JSR 292 JVMTI MethodEnter hook is not called for JSR 292 bootstrap and target methods Summary: check for single stepping when dispatching invokes from method handles Reviewed-by: coleenp, twisti, kvn, dsamersoff ! src/cpu/sparc/vm/methodHandles_sparc.cpp ! src/cpu/sparc/vm/methodHandles_sparc.hpp ! src/cpu/x86/vm/interp_masm_x86_32.cpp ! src/cpu/x86/vm/interp_masm_x86_64.cpp ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/cpu/x86/vm/methodHandles_x86.hpp + test/compiler/6990212/Test6990212.java Changeset: 968305b802ee Author: trims Date: 2011-07-23 01:56 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/hotspot/rev/968305b802ee Merge Changeset: 8e5d4aa73a8c Author: trims Date: 2011-07-22 23:47 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/hotspot/rev/8e5d4aa73a8c 7069176: Update the JDK version numbers in Hotspot for JDK 8 Summary: Change JDK_MINOR_VER and JDK_PREVIOUS_VERSION to reflect JDK8 values Reviewed-by: jcoomes ! make/hotspot_version Changeset: 0cc8a70952c3 Author: trims Date: 2011-07-22 23:42 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/hotspot/rev/0cc8a70952c3 7070061: Adjust Hotspot make/jprt.properties for new JDK8 settings Summary: Fix so the JPRT can build with -release jdk8 now Reviewed-by: ohair ! make/jprt.properties Changeset: 20cac004a4f9 Author: dsamersoff Date: 2011-06-09 01:06 +0400 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/hotspot/rev/20cac004a4f9 Merge Changeset: 1744e37e032b Author: dsamersoff Date: 2011-06-18 13:32 +0400 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/hotspot/rev/1744e37e032b Merge Changeset: d425748f2203 Author: dcubed Date: 2011-06-23 20:31 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/hotspot/rev/d425748f2203 7043987: 3/3 JVMTI FollowReferences is slow Summary: VM_HeapWalkOperation::doit() should only reset mark bits when necessary. Reviewed-by: dsamersoff, ysr, dholmes, dcubed Contributed-by: ashok.srinivasa.murthy at oracle.com ! src/share/vm/prims/jvmtiTagMap.cpp Changeset: 88dce6a60ac8 Author: dcubed Date: 2011-06-29 20:28 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/hotspot/rev/88dce6a60ac8 6951623: 3/3 possible performance problems in FollowReferences() and GetObjectsWithTags() Summary: Call collect_stack_roots() before collect_simple_roots() as an optimization. Reviewed-by: ysr, dsamersoff, dcubed Contributed-by: ashok.srinivasa.murthy at oracle.com ! src/share/vm/prims/jvmtiTagMap.cpp Changeset: 109d1d265924 Author: dholmes Date: 2011-07-02 04:17 -0400 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/hotspot/rev/109d1d265924 7052988: JPRT embedded builds don't set MINIMIZE_RAM_USAGE Reviewed-by: kamg, dsamersoff ! make/jprt.gmk Changeset: 5447b2c582ad Author: coleenp Date: 2011-07-07 22:34 -0400 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/hotspot/rev/5447b2c582ad Merge Changeset: bcc6475bc68f Author: coleenp Date: 2011-07-16 22:21 -0400 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/hotspot/rev/bcc6475bc68f Merge Changeset: 0b80db433fcb Author: dholmes Date: 2011-07-22 00:29 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/hotspot/rev/0b80db433fcb 7046490: Preallocated OOME objects should obey Throwable stack trace protocol Summary: Update the OOME stacktrace to contain Throwable.UNASSIGNED_STACK when the backtrace is filled in Reviewed-by: mchung, phh ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp Changeset: 8107273fd204 Author: coleenp Date: 2011-07-23 10:42 -0400 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/hotspot/rev/8107273fd204 Merge Changeset: ca1f1753c866 Author: andrew Date: 2011-07-28 14:10 -0400 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/hotspot/rev/ca1f1753c866 7072341: enable hotspot builds on Linux 3.0 Summary: Add "3" to list of allowable versions Reviewed-by: kamg, chrisphi ! make/linux/Makefile Changeset: 14a2fd14c0db Author: johnc Date: 2011-08-01 10:04 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/hotspot/rev/14a2fd14c0db 7068240: G1: Long "parallel other time" and "ext root scanning" when running specific benchmark Summary: In root processing, move the scanning of the reference processor's discovered lists to before RSet updating and scanning. When scanning the reference processor's discovered lists, use a buffering closure so that the time spent copying any reference object is correctly attributed. Also removed a couple of unused and irrelevant timers. Reviewed-by: ysr, jmasa ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp Changeset: 6aa4feb8a366 Author: johnc Date: 2011-08-02 12:13 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/hotspot/rev/6aa4feb8a366 7069863: G1: SIGSEGV running SPECjbb2011 and -UseBiasedLocking Summary: Align the reserved size of the heap and perm to the heap region size to get a preferred heap base that is aligned to the region size, and call the correct heap reservation constructor. Also add a check in the heap reservation code that the reserved space starts at the requested address (if any). Reviewed-by: kvn, ysr ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/runtime/virtualspace.cpp Changeset: a20e6e447d3d Author: iveresov Date: 2011-08-05 16:44 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/hotspot/rev/a20e6e447d3d 7060842: UseNUMA crash with UseHugreTLBFS running SPECjvm2008 Summary: Use mmap() instead of madvise(MADV_DONTNEED) to uncommit pages Reviewed-by: ysr ! src/os/linux/vm/os_linux.cpp Changeset: 7c2653aefc46 Author: iveresov Date: 2011-08-05 16:50 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/hotspot/rev/7c2653aefc46 7060836: RHEL 5.5 and 5.6 should support UseNUMA Summary: Add a wrapper for sched_getcpu() for systems where libc lacks it Reviewed-by: ysr Contributed-by: Andrew John Hughes ! src/os/linux/vm/os_linux.cpp ! src/os/linux/vm/os_linux.hpp Changeset: 41e6ee74f879 Author: kevinw Date: 2011-08-02 14:37 +0100 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/hotspot/rev/41e6ee74f879 7072527: CMS: JMM GC counters overcount in some cases Summary: Avoid overcounting when CMS has concurrent mode failure. Reviewed-by: ysr Contributed-by: rednaxelafx at gmail.com ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp + test/gc/7072527/TestFullGCCount.java Changeset: e9db47a083cc Author: kevinw Date: 2011-08-11 14:58 +0100 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/hotspot/rev/e9db47a083cc Merge Changeset: 87e40b34bc2b Author: johnc Date: 2011-08-11 11:36 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/hotspot/rev/87e40b34bc2b 7074579: G1: JVM crash with JDK7 running ATG CRMDemo Fusion App Summary: Handlize MemoryUsage klass oop in createGCInfo routine Reviewed-by: tonyp, fparain, ysr, jcoomes ! src/share/vm/services/gcNotifier.cpp Changeset: f44782f04dd4 Author: tonyp Date: 2011-08-12 11:31 -0400 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/hotspot/rev/f44782f04dd4 7039627: G1: avoid BOT updates for survivor allocations and dirty survivor regions incrementally Summary: Refactor the allocation code during GC to use the G1AllocRegion abstraction. Use separate subclasses of G1AllocRegion for survivor and old regions. Avoid BOT updates and dirty survivor cards incrementally for the former. Reviewed-by: brutisso, johnc, ysr ! src/share/vm/gc_implementation/g1/g1AllocRegion.cpp ! src/share/vm/gc_implementation/g1/g1AllocRegion.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.inline.hpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp Changeset: 76b1a9420e3d Author: ysr Date: 2011-08-16 08:02 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/hotspot/rev/76b1a9420e3d Merge Changeset: 46cb9a7b8b01 Author: dsamersoff Date: 2011-08-10 15:04 +0400 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/hotspot/rev/46cb9a7b8b01 7073913: The fix for 7017193 causes segfaults Summary: Buffer overflow in os::get_line_chars Reviewed-by: coleenp, dholmes, dcubed Contributed-by: aph at redhat.com ! src/share/vm/runtime/os.cpp Changeset: b1cbb0907b36 Author: zgu Date: 2011-04-15 09:34 -0400 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/hotspot/rev/b1cbb0907b36 7016797: Hotspot: securely/restrictive load dlls and new API for loading system dlls Summary: Created Windows Dll wrapped to handle jdk6 and jdk7 platform requirements, also provided more restictive Dll search orders for Windows system Dlls. Reviewed-by: acorn, dcubed, ohair, alanb ! make/windows/makefiles/compile.make ! src/os/windows/vm/decoder_windows.cpp ! src/os/windows/vm/jvm_windows.h ! src/os/windows/vm/os_windows.cpp ! src/os/windows/vm/os_windows.hpp Changeset: 279ef1916773 Author: zgu Date: 2011-07-12 21:13 -0400 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/hotspot/rev/279ef1916773 7065535: Mistyped function name that disabled UseLargePages on Windows Summary: Missing suffix "A" of Windows API LookupPrivilegeValue failed finding function pointer, caused VM to disable UseLargePages option Reviewed-by: coleenp, phh ! src/os/windows/vm/os_windows.cpp Changeset: a68e11dceb83 Author: zgu Date: 2011-08-16 09:18 -0400 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/hotspot/rev/a68e11dceb83 Merge Changeset: 00ed4ccfe642 Author: collins Date: 2011-08-17 07:05 -0400 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/hotspot/rev/00ed4ccfe642 Merge Changeset: 43f9d800f276 Author: iveresov Date: 2011-07-20 18:04 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/hotspot/rev/43f9d800f276 7066339: Tiered: policy should make consistent decisions about osr levels Summary: Added feedback disabling flag to common(), fixed handling of TieredStopAtLevel. Reviewed-by: kvn, never ! src/share/vm/classfile/classLoader.cpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/runtime/advancedThresholdPolicy.cpp ! src/share/vm/runtime/advancedThresholdPolicy.hpp ! src/share/vm/runtime/compilationPolicy.hpp ! src/share/vm/runtime/javaCalls.cpp ! src/share/vm/runtime/simpleThresholdPolicy.cpp ! src/share/vm/runtime/simpleThresholdPolicy.hpp Changeset: 6a991dcb52bb Author: never Date: 2011-07-21 08:38 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/hotspot/rev/6a991dcb52bb 7012081: JSR 292: SA-JDI can't read MH/MT/Indy ConstantPool entries Reviewed-by: kvn, twisti, jrose ! agent/src/share/classes/sun/jvm/hotspot/interpreter/Bytecode.java - agent/src/share/classes/sun/jvm/hotspot/interpreter/BytecodeFastAAccess0.java - agent/src/share/classes/sun/jvm/hotspot/interpreter/BytecodeFastIAccess0.java ! agent/src/share/classes/sun/jvm/hotspot/interpreter/BytecodeLoadConstant.java ! agent/src/share/classes/sun/jvm/hotspot/interpreter/BytecodeStream.java ! agent/src/share/classes/sun/jvm/hotspot/interpreter/BytecodeWideable.java ! agent/src/share/classes/sun/jvm/hotspot/interpreter/BytecodeWithCPIndex.java ! agent/src/share/classes/sun/jvm/hotspot/interpreter/Bytecodes.java ! agent/src/share/classes/sun/jvm/hotspot/oops/ConstMethod.java ! agent/src/share/classes/sun/jvm/hotspot/oops/ConstantPool.java ! agent/src/share/classes/sun/jvm/hotspot/oops/ConstantPoolCache.java ! agent/src/share/classes/sun/jvm/hotspot/oops/GenerateOopMap.java ! agent/src/share/classes/sun/jvm/hotspot/oops/Method.java ! agent/src/share/classes/sun/jvm/hotspot/oops/TypeArray.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/ConstantTag.java ! src/share/vm/oops/generateOopMap.cpp Changeset: 3d42f82cd811 Author: kvn Date: 2011-07-21 11:25 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/hotspot/rev/3d42f82cd811 7063628: Use cbcond on T4 Summary: Add new short branch instruction to Hotspot sparc assembler. Reviewed-by: never, twisti, jrose ! src/cpu/sparc/vm/assembler_sparc.cpp ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/cpu/sparc/vm/assembler_sparc.inline.hpp ! src/cpu/sparc/vm/c1_CodeStubs_sparc.cpp ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/sparc/vm/c1_MacroAssembler_sparc.cpp ! src/cpu/sparc/vm/c1_Runtime1_sparc.cpp ! src/cpu/sparc/vm/cppInterpreter_sparc.cpp ! src/cpu/sparc/vm/interp_masm_sparc.cpp ! src/cpu/sparc/vm/interpreter_sparc.cpp ! src/cpu/sparc/vm/methodHandles_sparc.cpp ! src/cpu/sparc/vm/sharedRuntime_sparc.cpp ! src/cpu/sparc/vm/sparc.ad ! src/cpu/sparc/vm/stubGenerator_sparc.cpp ! src/cpu/sparc/vm/templateInterpreter_sparc.cpp ! src/cpu/sparc/vm/templateTable_sparc.cpp ! src/cpu/sparc/vm/vm_version_sparc.cpp ! src/cpu/sparc/vm/vm_version_sparc.hpp ! src/cpu/sparc/vm/vtableStubs_sparc.cpp ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/os_cpu/solaris_sparc/vm/vm_version_solaris_sparc.cpp ! src/share/vm/adlc/formssel.cpp ! src/share/vm/adlc/output_c.cpp ! src/share/vm/adlc/output_h.cpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/machnode.cpp ! src/share/vm/opto/machnode.hpp ! src/share/vm/opto/output.cpp ! src/share/vm/runtime/globals.hpp Changeset: 4e761e7e6e12 Author: kvn Date: 2011-07-26 19:35 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/hotspot/rev/4e761e7e6e12 7070134: Hotspot crashes with sigsegv from PorterStemmer Summary: Do not move data nodes which are attached to a predicate test to a dominating test. Reviewed-by: never ! src/share/vm/opto/ifnode.cpp ! src/share/vm/opto/loopPredicate.cpp ! src/share/vm/opto/loopnode.hpp ! src/share/vm/opto/loopopts.cpp + test/compiler/7070134/Stemmer.java + test/compiler/7070134/Test7070134.sh + test/compiler/7070134/words Changeset: 0f34fdee809e Author: never Date: 2011-07-27 15:06 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/hotspot/rev/0f34fdee809e 7071427: AdapterFingerPrint can hold 8 entries per int Reviewed-by: kvn ! src/share/vm/runtime/java.cpp ! src/share/vm/runtime/sharedRuntime.cpp Changeset: c7b60b601eb4 Author: kvn Date: 2011-07-27 17:28 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/hotspot/rev/c7b60b601eb4 7069452: Cleanup NodeFlags Summary: Remove flags which duplicate information in Node::NodeClasses. 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/adlc/adlparse.cpp ! src/share/vm/adlc/archDesc.cpp ! src/share/vm/adlc/formssel.cpp ! src/share/vm/adlc/formssel.hpp ! src/share/vm/adlc/output_h.cpp ! src/share/vm/opto/block.cpp ! src/share/vm/opto/callnode.hpp ! src/share/vm/opto/cfgnode.hpp ! src/share/vm/opto/coalesce.cpp ! src/share/vm/opto/gcm.cpp ! src/share/vm/opto/idealGraphPrinter.cpp ! src/share/vm/opto/lcm.cpp ! src/share/vm/opto/machnode.hpp ! src/share/vm/opto/mulnode.cpp ! src/share/vm/opto/mulnode.hpp ! src/share/vm/opto/node.hpp ! src/share/vm/opto/output.cpp ! src/share/vm/opto/reg_split.cpp ! src/share/vm/opto/superword.cpp ! src/share/vm/opto/superword.hpp ! src/share/vm/opto/vectornode.cpp ! src/share/vm/opto/vectornode.hpp Changeset: d17bd0b18663 Author: twisti Date: 2011-07-28 02:14 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/hotspot/rev/d17bd0b18663 7066143: JSR 292: Zero support after regressions from 7009923 and 7009309 Reviewed-by: jrose, twisti Contributed-by: Xerxes Ranby ! src/cpu/zero/vm/stack_zero.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: ce3e1d4dc416 Author: never Date: 2011-07-28 13:03 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/hotspot/rev/ce3e1d4dc416 7060619: C1 should respect inline and dontinline directives from CompilerOracle Reviewed-by: kvn, iveresov ! src/share/vm/c1/c1_GraphBuilder.cpp Changeset: c96c3eb1efae Author: kvn Date: 2011-07-29 09:16 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/hotspot/rev/c96c3eb1efae 7068051: SIGSEGV in PhaseIdealLoop::build_loop_late_post Summary: Removed predicate cloning from loop peeling optimization and from split fall-in paths. Reviewed-by: never ! src/share/vm/opto/cfgnode.cpp ! src/share/vm/opto/ifnode.cpp ! src/share/vm/opto/loopPredicate.cpp ! src/share/vm/opto/loopTransform.cpp ! src/share/vm/opto/loopUnswitch.cpp ! src/share/vm/opto/loopnode.cpp ! src/share/vm/opto/loopnode.hpp ! src/share/vm/opto/phaseX.hpp Changeset: 4aa5974a06dd Author: kvn Date: 2011-08-06 08:28 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/hotspot/rev/4aa5974a06dd 7075559: JPRT windows_x64 build failure Summary: use SA_CLASSDIR variable instead of dirsctory saclasses. Reviewed-by: kamg, dcubed ! make/linux/makefiles/defs.make ! make/solaris/makefiles/defs.make ! make/solaris/makefiles/saproc.make ! make/windows/makefiles/defs.make ! make/windows/makefiles/sa.make Changeset: a3142bdb6707 Author: twisti Date: 2011-08-08 05:49 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/hotspot/rev/a3142bdb6707 7071823: Zero: zero/shark doesn't build after b147-fcs Reviewed-by: gbenson, twisti Contributed-by: Chris Phillips ! src/cpu/zero/vm/frame_zero.cpp + src/cpu/zero/vm/methodHandles_zero.hpp ! src/cpu/zero/vm/sharedRuntime_zero.cpp ! src/share/vm/shark/sharkContext.hpp Changeset: a19c671188cb Author: never Date: 2011-08-08 13:19 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/hotspot/rev/a19c671188cb 7075623: 6990212 broke raiseException in 64 bit Reviewed-by: kvn, twisti ! src/cpu/sparc/vm/methodHandles_sparc.cpp ! src/cpu/x86/vm/methodHandles_x86.cpp Changeset: f1c12354c3f7 Author: roland Date: 2011-08-02 18:36 +0200 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/hotspot/rev/f1c12354c3f7 7074017: Introduce MemBarAcquireLock/MemBarReleaseLock nodes for monitor enter/exit code paths Summary: replace MemBarAcquire/MemBarRelease nodes on the monitor enter/exit code paths with new MemBarAcquireLock/MemBarReleaseLock nodes Reviewed-by: kvn, twisti ! src/cpu/sparc/vm/sparc.ad ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/adlc/formssel.cpp ! src/share/vm/opto/classes.hpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/matcher.cpp ! src/share/vm/opto/matcher.hpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/memnode.hpp Changeset: 6987871cfb9b Author: kvn Date: 2011-08-10 14:06 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/hotspot/rev/6987871cfb9b 7077439: Possible reference through NULL in loopPredicate.cpp:726 Summary: Use cl->is_valid_counted_loop() check. Reviewed-by: never ! src/share/vm/opto/loopPredicate.cpp ! src/share/vm/opto/loopTransform.cpp ! src/share/vm/opto/loopnode.cpp ! src/share/vm/opto/superword.cpp Changeset: 95134e034042 Author: kvn Date: 2011-08-11 12:08 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/hotspot/rev/95134e034042 7063629: use cbcond in C2 generated code on T4 Summary: Use new short branch instruction in C2 generated code. Reviewed-by: never ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/cpu/sparc/vm/sparc.ad ! src/cpu/sparc/vm/vm_version_sparc.cpp ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/os_cpu/linux_x86/vm/linux_x86_32.ad ! src/os_cpu/linux_x86/vm/linux_x86_64.ad ! src/os_cpu/solaris_x86/vm/solaris_x86_32.ad ! src/os_cpu/solaris_x86/vm/solaris_x86_64.ad ! src/share/vm/adlc/formssel.cpp ! src/share/vm/adlc/output_h.cpp ! src/share/vm/opto/block.cpp ! src/share/vm/opto/block.hpp ! src/share/vm/opto/compile.hpp ! src/share/vm/opto/machnode.hpp ! src/share/vm/opto/matcher.hpp ! src/share/vm/opto/node.hpp ! src/share/vm/opto/output.cpp Changeset: fdb992d83a87 Author: twisti Date: 2011-08-16 04:14 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/hotspot/rev/fdb992d83a87 7071653: JSR 292: call site change notification should be pushed not pulled Reviewed-by: kvn, never, bdelsart ! src/cpu/sparc/vm/interp_masm_sparc.cpp ! src/cpu/sparc/vm/interp_masm_sparc.hpp ! src/cpu/sparc/vm/templateTable_sparc.cpp ! src/cpu/x86/vm/interp_masm_x86_32.cpp ! src/cpu/x86/vm/interp_masm_x86_32.hpp ! src/cpu/x86/vm/interp_masm_x86_64.cpp ! src/cpu/x86/vm/interp_masm_x86_64.hpp ! src/cpu/x86/vm/templateTable_x86_32.cpp ! src/cpu/x86/vm/templateTable_x86_64.cpp ! src/share/vm/ci/ciCallSite.cpp ! src/share/vm/ci/ciCallSite.hpp ! src/share/vm/ci/ciField.hpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/code/dependencies.cpp ! src/share/vm/code/dependencies.hpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/interpreter/templateTable.hpp ! src/share/vm/memory/universe.cpp ! src/share/vm/memory/universe.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/opto/callGenerator.cpp ! src/share/vm/opto/callGenerator.hpp ! src/share/vm/opto/doCall.cpp ! src/share/vm/opto/parse3.cpp Changeset: 11211f7cb5a0 Author: kvn Date: 2011-08-16 11:53 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/hotspot/rev/11211f7cb5a0 7079317: Incorrect branch's destination block in PrintoOptoAssembly output Summary: save/restore label and block in scratch_emit_size() Reviewed-by: never ! src/share/vm/adlc/archDesc.cpp ! src/share/vm/adlc/formssel.cpp ! src/share/vm/adlc/output_c.cpp ! src/share/vm/adlc/output_h.cpp ! src/share/vm/opto/block.cpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/idealGraphPrinter.cpp ! src/share/vm/opto/machnode.cpp ! src/share/vm/opto/machnode.hpp ! src/share/vm/opto/node.hpp ! src/share/vm/opto/output.cpp Changeset: 1af104d6cf99 Author: kvn Date: 2011-08-16 16:59 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/hotspot/rev/1af104d6cf99 7079329: Adjust allocation prefetching for T4 Summary: on T4 2 BIS instructions should be issued to prefetch 64 bytes Reviewed-by: iveresov, phh, twisti ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/cpu/sparc/vm/sparc.ad ! src/cpu/sparc/vm/vm_version_sparc.cpp ! src/cpu/sparc/vm/vm_version_sparc.hpp ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/vm_version_x86.cpp ! src/cpu/x86/vm/vm_version_x86.hpp ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/adlc/formssel.cpp ! src/share/vm/memory/threadLocalAllocBuffer.hpp ! src/share/vm/opto/classes.hpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/matcher.cpp ! src/share/vm/opto/memnode.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/vm_version.cpp ! src/share/vm/runtime/vm_version.hpp Changeset: 381bf869f784 Author: twisti Date: 2011-08-17 05:14 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/hotspot/rev/381bf869f784 7079626: x64 emits unnecessary REX prefix Reviewed-by: kvn, iveresov, never ! src/cpu/x86/vm/assembler_x86.cpp Changeset: bd87c0dcaba5 Author: twisti Date: 2011-08-17 11:52 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/hotspot/rev/bd87c0dcaba5 7079769: JSR 292: incorrect size() for CallStaticJavaHandle on sparc Reviewed-by: never, kvn ! src/cpu/sparc/vm/sparc.ad Changeset: 739a9abbbd4b Author: kvn Date: 2011-08-18 11:49 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/hotspot/rev/739a9abbbd4b 7080431: VM asserts if specified size(x) in .ad is larger than emitted size Summary: Move code from finalize_offsets_and_shorten() to fill_buffer() to restore previous behavior. Reviewed-by: never ! src/share/vm/opto/compile.hpp ! src/share/vm/opto/output.cpp Changeset: de147f62e695 Author: kvn Date: 2011-08-19 08:55 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/hotspot/rev/de147f62e695 Merge - agent/src/share/classes/sun/jvm/hotspot/interpreter/BytecodeFastAAccess0.java - agent/src/share/classes/sun/jvm/hotspot/interpreter/BytecodeFastIAccess0.java Changeset: 24cee90e9453 Author: jcoomes Date: 2011-08-17 10:32 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/hotspot/rev/24cee90e9453 6791672: enable 1G and larger pages on solaris Reviewed-by: ysr, iveresov, johnc ! src/os/solaris/vm/os_solaris.cpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/os.hpp Changeset: 3be7439273c5 Author: katleman Date: 2011-05-25 13:31 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/hotspot/rev/3be7439273c5 7044486: open jdk repos have files with incorrect copyright headers, which can end up in src bundles Reviewed-by: ohair, trims ! agent/src/share/classes/sun/jvm/hotspot/runtime/ServiceThread.java ! make/linux/README ! make/windows/projectfiles/kernel/Makefile ! src/cpu/x86/vm/vm_version_x86.cpp ! src/cpu/x86/vm/vm_version_x86.hpp ! src/os_cpu/solaris_sparc/vm/solaris_sparc.s ! src/share/tools/hsdis/README ! src/share/vm/gc_implementation/g1/heapRegionSet.inline.hpp ! src/share/vm/gc_implementation/parNew/parCardTableModRefBS.cpp ! src/share/vm/utilities/yieldingWorkgroup.cpp Changeset: 8b135e6129d6 Author: jeff Date: 2011-05-27 15:01 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/hotspot/rev/8b135e6129d6 7045697: JDK7 THIRD PARTY README update Reviewed-by: lana ! THIRD_PARTY_README Changeset: 52e4ba46751f Author: kamg Date: 2011-04-12 16:42 -0400 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/hotspot/rev/52e4ba46751f 7020373: JSR rewriting can overflow memory address size variables Summary: Abort if incoming classfile's parameters would cause overflows Reviewed-by: coleenp, dcubed, never ! src/share/vm/oops/generateOopMap.cpp + test/runtime/7020373/Test7020373.sh Changeset: bca686989d4b Author: asaha Date: 2011-06-15 14:59 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/hotspot/rev/bca686989d4b 7055247: Ignore test of # 7020373 Reviewed-by: dcubed ! test/runtime/7020373/Test7020373.sh Changeset: 337ffef74c37 Author: jeff Date: 2011-06-22 10:10 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/hotspot/rev/337ffef74c37 7057046: Add embedded license to THIRD PARTY README Reviewed-by: lana ! THIRD_PARTY_README Changeset: 9f12ede5571a Author: jcoomes Date: 2011-08-19 14:08 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/hotspot/rev/9f12ede5571a Merge ! src/cpu/x86/vm/vm_version_x86.cpp ! src/cpu/x86/vm/vm_version_x86.hpp ! src/share/vm/oops/generateOopMap.cpp ! src/share/vm/runtime/os.cpp Changeset: 7c29742c41b4 Author: jcoomes Date: 2011-08-19 14:22 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/hotspot/rev/7c29742c41b4 7081251: bump the hs22 build number to 02 Reviewed-by: johnc ! make/hotspot_version Changeset: 8580b4f22e29 Author: jcoomes Date: 2011-08-23 21:17 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/hotspot/rev/8580b4f22e29 Merge ! .jcheck/conf - agent/src/share/classes/sun/jvm/hotspot/interpreter/BytecodeFastAAccess0.java - agent/src/share/classes/sun/jvm/hotspot/interpreter/BytecodeFastIAccess0.java ! make/hotspot_version ! src/cpu/x86/vm/vm_version_x86.cpp ! src/cpu/x86/vm/vm_version_x86.hpp ! src/os/windows/vm/os_windows.cpp ! src/share/tools/hsdis/README ! src/share/vm/gc_implementation/parNew/parCardTableModRefBS.cpp ! src/share/vm/prims/methodHandleWalk.cpp From john.coomes at oracle.com Tue Aug 23 22:07:45 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Wed, 24 Aug 2011 05:07:45 +0000 Subject: hg: jdk7u/jdk7u/hotspot: 131 new changesets Message-ID: <20110824051144.5C04447081@hg.openjdk.java.net> Changeset: 303a4d63b484 Author: jcoomes Date: 2011-08-23 21:11 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/303a4d63b484 7082689: allow duplicate bug ids in jdk7u repos Reviewed-by: johnc ! .jcheck/conf Changeset: c7c81f18c834 Author: kvn Date: 2011-05-25 21:17 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/c7c81f18c834 7048332: Cadd_cmpLTMask doesn't handle 64-bit tmp register properly Summary: Use ins_encode %{ %} form to encode cadd_cmpLTMask() instruction and remove unused code. Reviewed-by: never ! src/cpu/x86/vm/x86_64.ad + test/compiler/7048332/Test7048332.java Changeset: 28263a73ebfb Author: iveresov Date: 2011-05-26 13:15 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/28263a73ebfb 7047491: C1: registers saved incorrectly when calling checkcast_arraycopy stub Summary: Save and restore the argument registers around the call to checkcast_arraycopy Reviewed-by: never, roland ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp Changeset: 5ac411b3b8fc Author: never Date: 2011-05-26 14:44 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/5ac411b3b8fc 7047961: JSR 292 MethodHandleWalk swap args doesn't handle T_LONG and T_DOUBLE properly Reviewed-by: kvn, jrose ! src/share/vm/prims/methodHandleWalk.cpp ! src/share/vm/prims/methodHandleWalk.hpp ! src/share/vm/prims/methodHandles.cpp Changeset: c76c13577460 Author: never Date: 2011-05-26 16:39 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/c76c13577460 Merge Changeset: b2cb497dec28 Author: kvn Date: 2011-05-27 12:47 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/b2cb497dec28 7047069: Array can dynamically change size when assigned to an object field Summary: Fix initialization of a newly-allocated array with arraycopy Reviewed-by: never ! src/share/vm/opto/library_call.cpp + test/compiler/7047069/Test7047069.java Changeset: 33e2b8f1d466 Author: kvn Date: 2011-05-31 10:05 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/33e2b8f1d466 6956668: misbehavior of XOR operator (^) with int Summary: optimize cmp_ne(xor(X,1),0) to cmp_eq(X,0) only for boolean values X. Reviewed-by: never ! src/share/vm/opto/subnode.cpp + test/compiler/6956668/Test6956668.java Changeset: 60b8287df30e Author: jrose Date: 2011-06-01 23:25 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/60b8287df30e 7049415: Failure of resolution of sym.reference to the c.s.s. should be wrapped in BootstrapMethodError Summary: Delegate invokedynamic linkage errors to MethodHandleNatives.raiseException. Reviewed-by: never ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/prims/methodHandles.hpp Changeset: a93146d0e4be Author: jrose Date: 2011-06-01 23:25 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/a93146d0e4be 7049410: JSR 292 old method name MethodHandle.invokeGeneric should not be accepted by the JVM Summary: change the default setting of the flag AllowInvokeGeneric to false Reviewed-by: never ! src/share/vm/runtime/globals.hpp Changeset: 537a4053b0f9 Author: ysr Date: 2011-05-23 16:42 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/537a4053b0f9 7042740: CMS: assert(n> q) failed: Looping at: ... blockOffsetTable.cpp:557 Summary: Do a one-step look-ahead, when sweeping free or garbage blocks, to avoid overstepping sweep limit, which may become a non-block-boundary because of a heap expansion delta coalescing with a previously co-terminal free block. Reviewed-by: brutisso, tonyp ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp ! src/share/vm/memory/blockOffsetTable.cpp Changeset: f153114134c8 Author: jcoomes Date: 2011-06-07 13:17 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/f153114134c8 Merge Changeset: d3b9f2be46ab Author: coleenp Date: 2011-05-21 15:39 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/d3b9f2be46ab 7033141: assert(has_cp_cache(i)) failed: oob Summary: Unrewrite bytecodes for OOM error allocating the constant pool cache. Reviewed-by: dcubed, acorn, never ! src/share/vm/interpreter/rewriter.cpp ! src/share/vm/interpreter/rewriter.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/methodOop.cpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/prims/methodHandleWalk.cpp Changeset: 9dd6c4ba364f Author: coleenp Date: 2011-06-02 14:17 -0400 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/9dd6c4ba364f 7049928: VM crashes with "assert(_adapter != NULL) failed: must have" at methodOop.cpp:63 Summary: Removed extra change from another bug fix that caused this regression Reviewed-by: phh, dcubed, kvn, kamg, never ! src/share/vm/oops/methodOop.cpp Changeset: 96c891ebe56a Author: coleenp Date: 2011-06-02 21:01 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/96c891ebe56a Merge ! src/share/vm/prims/methodHandleWalk.cpp Changeset: ae1d716e395c Author: dsamersoff Date: 2011-06-09 01:33 +0400 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/ae1d716e395c Merge Changeset: f918d6096e23 Author: never Date: 2011-06-02 13:36 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/f918d6096e23 7050554: JSR 292 - need optimization for selectAlternative Reviewed-by: kvn, jrose ! src/share/vm/ci/ciCallProfile.hpp ! src/share/vm/ci/ciMethodHandle.cpp ! src/share/vm/ci/ciMethodHandle.hpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/opto/callGenerator.cpp ! src/share/vm/opto/callGenerator.hpp ! src/share/vm/opto/doCall.cpp Changeset: cba7b5c2d53f Author: never Date: 2011-06-03 22:31 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/cba7b5c2d53f 7045514: SPARC assembly code for JSR 292 ricochet frames Reviewed-by: kvn, jrose ! src/cpu/sparc/vm/assembler_sparc.cpp ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/cpu/sparc/vm/assembler_sparc.inline.hpp ! src/cpu/sparc/vm/frame_sparc.cpp ! src/cpu/sparc/vm/methodHandles_sparc.cpp + src/cpu/sparc/vm/methodHandles_sparc.hpp ! src/cpu/sparc/vm/registerMap_sparc.hpp ! src/cpu/sparc/vm/runtime_sparc.cpp ! src/cpu/sparc/vm/sharedRuntime_sparc.cpp ! src/cpu/sparc/vm/stubRoutines_sparc.hpp ! src/cpu/sparc/vm/templateInterpreter_sparc.cpp ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/cpu/x86/vm/methodHandles_x86.hpp ! src/cpu/x86/vm/runtime_x86_32.cpp ! src/cpu/x86/vm/sharedRuntime_x86_32.cpp ! src/cpu/x86/vm/sharedRuntime_x86_64.cpp ! src/cpu/x86/vm/stubRoutines_x86_32.hpp ! src/cpu/x86/vm/stubRoutines_x86_64.hpp ! src/share/vm/compiler/oopMap.cpp ! src/share/vm/opto/runtime.cpp ! src/share/vm/prims/methodHandleWalk.cpp ! src/share/vm/prims/methodHandleWalk.hpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/prims/methodHandles.hpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/sharedRuntime.hpp Changeset: 642c68c75db9 Author: kvn Date: 2011-06-04 10:36 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/642c68c75db9 7050280: assert(u->as_Unlock()->is_eliminated()) failed: sanity Summary: Mark all associated (same box and obj) lock and unlock nodes for elimination if some of them marked already. Reviewed-by: iveresov, never ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/macro.hpp Changeset: 5cf771a79037 Author: jrose Date: 2011-06-08 17:04 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/5cf771a79037 7047697: MethodHandle.invokeExact call for wrong method causes VM failure if run with -Xcomp Reviewed-by: never, twisti ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/frame_x86.inline.hpp ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/share/vm/code/pcDesc.cpp Changeset: c8f2186acf6d Author: twisti Date: 2011-06-14 12:25 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/c8f2186acf6d 7053520: JSR292: crash in invokedynamic with C1 using tiered and compressed oops Reviewed-by: iveresov, never ! src/share/vm/c1/c1_LIRGenerator.cpp Changeset: f8c9417e3571 Author: never Date: 2011-06-14 14:41 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/f8c9417e3571 7052219: JSR 292: Crash in ~BufferBlob::MethodHandles adapters Reviewed-by: twisti, kvn, jrose ! src/cpu/sparc/vm/methodHandles_sparc.cpp ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/share/vm/prims/methodHandleWalk.cpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/prims/methodHandles.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/stubCodeGenerator.cpp ! src/share/vm/runtime/stubCodeGenerator.hpp Changeset: e2ce15aa3daf Author: never Date: 2011-06-14 15:20 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/e2ce15aa3daf Merge Changeset: cfcf2ba8f3eb Author: never Date: 2011-06-15 10:20 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/cfcf2ba8f3eb Merge ! src/share/vm/prims/methodHandleWalk.cpp Changeset: e2af886d540b Author: trims Date: 2011-07-01 13:07 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/e2af886d540b 7061691: Fork HS21 to HS22 - renumber Minor and build numbers of JVM Summary: Update the Minor and Build numbers for HS22 fork Reviewed-by: jcoomes ! make/hotspot_version Changeset: 1e3493ac2d11 Author: ysr Date: 2011-05-27 10:23 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/1e3493ac2d11 7048342: CMS: eob == _limit || fc->isFree() failed: Only a free chunk should allow us to cross over the limit Summary: The freeness bit was being cleared in debug code when it shouldn't have been. Also removed unused FreeChunk methods linkAfterNonNull and clearPrev. Reviewed-by: brutisso ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/freeChunk.hpp Changeset: 5c0a3c1858b1 Author: ysr Date: 2011-06-02 10:23 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/5c0a3c1858b1 7048782: CMS: assert(last_chunk_index_to_check<= last_chunk_index) failed: parCardTableModRefBS.cpp:359 Summary: The LNC array is sized before the start of a scavenge, while the heap may expand during a scavenge. With CMS, the last block of an arbitrary suffice of the LNC array may expand due to coalition with the expansion delta. We now take care not to attempt access past the end of the LNC array. LNC array code will be cleaned up and suitably encapsulated as part of the forthcoming performance RFE 7043675. Reviewed-by: brutisso ! src/share/vm/gc_implementation/parNew/parCardTableModRefBS.cpp Changeset: e66f38dd58a9 Author: ysr Date: 2011-06-08 08:39 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/e66f38dd58a9 Merge Changeset: 053d84a76d3d Author: tonyp Date: 2011-06-08 15:31 -0400 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/053d84a76d3d 7032531: G1: enhance GC logging to include more accurate eden / survivor size transitions Summary: This changeset extends the logging information generated by +PrintGCDetails to also print out separate size transitions for the eden, survivors, and old regions. Reviewed-by: ysr, brutisso ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp Changeset: ae5b2f1dcf12 Author: tonyp Date: 2011-06-08 21:48 -0400 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/ae5b2f1dcf12 7045662: G1: OopsInHeapRegionClosure::set_region() should not be virtual Summary: make the method non-virtual, remove five unused closures, and fix a couple of copyright typos. Reviewed-by: stefank, johnc, poonam ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1OopClosures.hpp ! src/share/vm/gc_implementation/g1/g1OopClosures.inline.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/g1_specialized_oop_closures.hpp ! src/share/vm/gc_implementation/g1/heapRegionSet.hpp ! src/share/vm/gc_implementation/g1/heapRegionSets.hpp Changeset: c3f1170908be Author: tonyp Date: 2011-06-10 13:16 -0400 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/c3f1170908be 7045330: G1: Simplify/fix the HeapRegionSeq class 7042285: G1: native memory leak during humongous object allocation 6804436: G1: heap region indices should be size_t Summary: A series of fixes and improvements to the HeapRegionSeq class: a) replace the _regions growable array with a standard C array, b) avoid de-allocating / re-allocating HeapRegion instances when the heap shrinks / grows (fix for 7042285), c) introduce fast method to map address to HeapRegion via a "biased" array pointer, d) embed the _hrs object in G1CollectedHeap, instead of pointing to it via an indirection, e) assume that all the regions added to the HeapRegionSeq instance are contiguous, f) replace int's with size_t's for indexes (and expand that to HeapRegion as part of 6804436), g) remove unnecessary / unused methods, h) rename a couple of fields (_alloc_search_start and _seq_bottom), i) fix iterate_from() not to always start from index 0 irrespective of the region passed to it, j) add a verification method to check the HeapRegionSeq assumptions, k) always call the wrappers for _hrs.iterate(), _hrs_length(), and _hrs.at() from G1CollectedHeap, not those methods di rectly, and l) unify the code that expands the sequence (by either re-using or creating a new HeapRegion) and make it robust wrt to a HeapRegion allocation failing. Reviewed-by: stefank, johnc, brutisso ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.inline.hpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp ! src/share/vm/gc_implementation/g1/heapRegionSeq.cpp ! src/share/vm/gc_implementation/g1/heapRegionSeq.hpp ! src/share/vm/gc_implementation/g1/heapRegionSeq.inline.hpp ! src/share/vm/gc_implementation/g1/sparsePRT.cpp Changeset: 2a241e764894 Author: minqi Date: 2011-06-10 15:08 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/2a241e764894 6941923: RFE: Handling large log files produced by long running Java Applications Summary: supply optinal flags to realize gc log rotation Reviewed-by: ysr, jwilhelm ! src/share/vm/gc_implementation/shared/concurrentGCThread.cpp ! src/share/vm/gc_implementation/shared/concurrentGCThread.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/atomic.cpp ! src/share/vm/runtime/atomic.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/safepoint.cpp ! src/share/vm/utilities/ostream.cpp ! src/share/vm/utilities/ostream.hpp + test/gc/6941923/test6941923.sh Changeset: 42df21744b50 Author: minqi Date: 2011-06-10 15:44 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/42df21744b50 Merge Changeset: ef2d1b8f2dd4 Author: ysr Date: 2011-06-13 09:58 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/ef2d1b8f2dd4 7051430: CMS: ongoing CMS cycle should terminate abruptly to allow prompt JVM termination at exit Summary: It turns out that there is no need to explicitly stop CMS since the JVM is taken down at a terminal safepoint during which CMS threads are (terminally) inactive. This will need to be revised if and when we evolve in the future to a point where we allow JVM reincarnation in the same process, but those changes will be much more sweeping than just terminating CMS threads. The unused ::stop() methods will be removed in a separate CR. Also include in this CR is the fix for a small typo in the spelling of UseGCLogFileRotation in a message in arguments.cpp, brought to our attention by Rainer Jung and reviewed by minqi. Reviewed-by: johnc, jwilhelm ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/java.cpp ! src/share/vm/runtime/thread.cpp Changeset: 74cd10898bea Author: brutisso Date: 2011-06-13 13:48 +0200 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/74cd10898bea 6918185: Remove unused code for lost card-marking optimization in BacktraceBuilder Summary: Removed dead code Reviewed-by: ysr, coleenp, dholmes ! src/share/vm/classfile/javaClasses.cpp Changeset: 842b840e67db Author: tonyp Date: 2011-06-14 10:33 -0400 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/842b840e67db 7046558: G1: concurrent marking optimizations Summary: Some optimizations to improve the concurrent marking phase: specialize the main oop closure, make sure a few methods in the fast path are properly inlined, a few more bits and pieces, and some cosmetic fixes. Reviewed-by: stefank, johnc ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp + src/share/vm/gc_implementation/g1/concurrentMark.inline.hpp ! src/share/vm/gc_implementation/g1/g1OopClosures.hpp ! src/share/vm/gc_implementation/g1/g1OopClosures.inline.hpp ! src/share/vm/gc_implementation/g1/g1_specialized_oop_closures.hpp ! src/share/vm/utilities/bitMap.hpp Changeset: 6747fd0512e0 Author: johnc Date: 2011-06-14 11:01 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/6747fd0512e0 7004681: G1: Extend marking verification to Full GCs Summary: Perform a heap verification after the first phase of G1's full GC using objects' mark words to determine liveness. The third parameter of the heap verification routines, which was used in G1 to determine which marking bitmap to use in liveness calculations, has been changed from a boolean to an enum with values defined for using the mark word, and the 'prev' and 'next' bitmaps. Reviewed-by: tonyp, ysr ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1MarkSweep.cpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.cpp ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.hpp ! src/share/vm/gc_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 Changeset: 5130fa1b24f1 Author: johnc Date: 2011-06-15 10:18 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/5130fa1b24f1 7045751: G1: +ExplicitGCInvokesConcurrent causes excessive single region evacuation pauses Summary: When ExplicitGCInvokesConcurrent is enabled, do not perform an evacuation pause if a marking cycle is already in progress and block the requesting thread until the marking cycle completes. Reviewed-by: tonyp, ysr ! src/share/vm/gc_implementation/g1/vm_operations_g1.cpp Changeset: c9ca3f51cf41 Author: tonyp Date: 2011-06-16 15:51 -0400 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/c9ca3f51cf41 6994322: Remove the is_tlab and is_noref / is_large_noref parameters from the CollectedHeap Summary: Remove two unused parameters from the mem_allocate() method and update its uses accordingly. Reviewed-by: stefank, johnc ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.cpp ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.hpp ! src/share/vm/gc_implementation/parallelScavenge/psOldGen.cpp ! src/share/vm/gc_implementation/parallelScavenge/psOldGen.hpp ! src/share/vm/gc_implementation/parallelScavenge/psPermGen.cpp ! src/share/vm/gc_implementation/parallelScavenge/psYoungGen.hpp ! src/share/vm/gc_implementation/parallelScavenge/vmPSOperations.cpp ! src/share/vm/gc_implementation/parallelScavenge/vmPSOperations.hpp ! src/share/vm/gc_interface/collectedHeap.hpp ! src/share/vm/gc_interface/collectedHeap.inline.hpp ! src/share/vm/memory/collectorPolicy.cpp ! src/share/vm/memory/collectorPolicy.hpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/genCollectedHeap.hpp ! src/share/vm/oops/typeArrayKlass.cpp Changeset: f75137faa7fe Author: ysr Date: 2011-06-20 09:42 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/f75137faa7fe 6916968: CMS: freeList.cpp:304 assert(_allocation_stats.prevSweep() + ..., "Conservation Principle") Summary: Fix assert and adjust demand volume computation by adding missing factor. Reviewed-by: jmasa, tonyp ! src/share/vm/gc_implementation/concurrentMarkSweep/freeList.cpp ! src/share/vm/gc_implementation/shared/allocationStats.hpp Changeset: 23d434c6290d Author: tonyp Date: 2011-06-20 22:03 -0400 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/23d434c6290d 7055073: G1: code cleanup in the concurrentMark.* files Summary: Only cosmetic changes to make the concurrentMark.* more consistent, code-style-wise, with the rest of the codebase. Reviewed-by: johnc, ysr ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp ! src/share/vm/gc_implementation/g1/concurrentMark.inline.hpp Changeset: e8b0b0392037 Author: tonyp Date: 2011-06-21 15:23 -0400 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/e8b0b0392037 7046182: G1: remove unnecessary iterations over the collection set Summary: Remove two unnecessary iterations over the collection set which are supposed to prepare the RSet's of the CSet regions for parallel iterations (we'll make sure this is done incrementally). I'll piggyback on this CR the removal of the G1_REM_SET_LOGGING code. Reviewed-by: brutisso, johnc ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/g1RemSet.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.inline.hpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.hpp ! src/share/vm/gc_implementation/g1/heapRegionSets.cpp ! src/share/vm/gc_implementation/g1/heapRegionSets.hpp Changeset: 5f6f2615433a Author: tonyp Date: 2011-06-24 12:38 -0400 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/5f6f2615433a 7049999: G1: Make the G1PrintHeapRegions output consistent and complete Summary: Extend and make more consistent the output from the G1PrintHeapRegions flag. Reviewed-by: johnc, jmasa ! 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/g1HRPrinter.cpp + src/share/vm/gc_implementation/g1/g1HRPrinter.hpp Changeset: 04760e41b01e Author: brutisso Date: 2011-06-28 14:23 +0200 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/04760e41b01e 7016112: CMS: crash during promotion testing Summary: Also reviewed by mikael.gerdin at oracle.com; stdlib:qsort() does byte-by-byte swapping on Windows. This leads to pointer shearing. Fix is to implement a quicksort that does full pointer updates. Reviewed-by: never, coleenp, ysr ! src/share/vm/oops/methodOop.cpp ! src/share/vm/prims/jni.cpp ! src/share/vm/runtime/globals.hpp + src/share/vm/utilities/quickSort.cpp + src/share/vm/utilities/quickSort.hpp Changeset: 4bf3cbef0b3e Author: jcoomes Date: 2011-07-06 08:43 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/4bf3cbef0b3e Merge ! src/share/vm/oops/methodOop.cpp ! src/share/vm/runtime/globals.hpp Changeset: d83ac25d0304 Author: never Date: 2011-06-16 13:46 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/d83ac25d0304 7055355: JSR 292: crash while throwing WrongMethodTypeException Reviewed-by: jrose, twisti, bdelsart ! src/cpu/sparc/vm/methodHandles_sparc.cpp ! src/cpu/sparc/vm/stubGenerator_sparc.cpp ! src/cpu/sparc/vm/templateInterpreter_sparc.cpp ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp ! src/cpu/zero/vm/cppInterpreter_zero.cpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/interpreter/interpreterRuntime.hpp ! src/share/vm/interpreter/templateInterpreter.cpp ! src/share/vm/interpreter/templateInterpreterGenerator.hpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/sharedRuntime.hpp ! src/share/vm/runtime/stubRoutines.cpp ! src/share/vm/runtime/stubRoutines.hpp Changeset: aacaff365100 Author: kvn Date: 2011-06-20 16:45 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/aacaff365100 7052494: Eclipse test fails on JDK 7 b142 Summary: Keep 'ne' test in Counted loop when we can't guarantee during compilation that init < limit. Reviewed-by: never ! src/share/vm/opto/loopTransform.cpp ! src/share/vm/opto/loopnode.cpp + test/compiler/7052494/Test7052494.java Changeset: de6a837d75cf Author: never Date: 2011-06-21 09:04 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/de6a837d75cf 7056380: VM crashes with SIGSEGV in compiled code Summary: code was using andq reg, imm instead of addq addr, imm Reviewed-by: kvn, jrose, twisti ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/x86_64.ad Changeset: aabf25fa3f05 Author: never Date: 2011-06-22 14:45 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/aabf25fa3f05 7057587: JSR 292 - crash with jruby in test/test_respond_to.rb Summary: don't skip receiver when GC'ing compiled invokedynamic callsites Reviewed-by: twisti, kvn, jrose ! src/share/vm/code/nmethod.cpp ! src/share/vm/opto/bytecodeInfo.cpp ! src/share/vm/opto/doCall.cpp ! src/share/vm/opto/parse.hpp Changeset: ddd894528dbc Author: jrose Date: 2011-06-23 17:14 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/ddd894528dbc 7056328: JSR 292 invocation sometimes fails in adapters for types not on boot class path Reviewed-by: never ! src/cpu/sparc/vm/templateTable_sparc.cpp ! src/cpu/x86/vm/templateTable_x86_32.cpp ! src/cpu/x86/vm/templateTable_x86_64.cpp ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/ci/ciEnv.hpp ! src/share/vm/ci/ciField.cpp ! src/share/vm/ci/ciMethod.cpp ! src/share/vm/ci/ciMethodHandle.cpp ! src/share/vm/ci/ciObjArrayKlass.cpp ! src/share/vm/ci/ciSignature.cpp ! src/share/vm/ci/ciSignature.hpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/oops/constantPoolKlass.cpp ! src/share/vm/oops/constantPoolOop.cpp ! src/share/vm/oops/constantPoolOop.hpp ! src/share/vm/oops/cpCacheOop.cpp ! src/share/vm/oops/cpCacheOop.hpp ! src/share/vm/oops/methodOop.cpp ! src/share/vm/oops/methodOop.hpp ! src/share/vm/prims/methodHandleWalk.cpp ! src/share/vm/prims/methodHandleWalk.hpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/prims/methodHandles.hpp Changeset: 498c6cf70f7e Author: kvn Date: 2011-06-28 14:30 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/498c6cf70f7e 7058036: FieldsAllocationStyle=2 does not work in 32-bit VM Summary: parseClassFile() incorrectly uses nonstatic_oop_map_size() method instead of nonstatic_oop_map_count(). Reviewed-by: never Contributed-by: Krystal Mok ! src/share/vm/classfile/classFileParser.cpp Changeset: 6ae7a1561b53 Author: kvn Date: 2011-06-28 15:04 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/6ae7a1561b53 6990015: Incorrect Icache line size is used for 64 bit x86 Summary: correct Icache::line_size for x64 and add verification code into vm_version_x86. Reviewed-by: never, phh ! src/cpu/x86/vm/icache_x86.hpp ! src/cpu/x86/vm/vm_version_x86.cpp ! src/cpu/x86/vm/vm_version_x86.hpp Changeset: e3cbc9ddd434 Author: kvn Date: 2011-06-28 15:24 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/e3cbc9ddd434 7044738: Loop unroll optimization causes incorrect result Summary: take into account memory dependencies when clonning nodes in clone_up_backedge_goo(). Reviewed-by: never ! src/share/vm/opto/loopTransform.cpp ! src/share/vm/opto/loopnode.hpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/node.cpp ! src/share/vm/opto/node.hpp + test/compiler/7044738/Test7044738.java + test/compiler/7046096/Test7046096.java Changeset: 7889bbcc7f88 Author: kvn Date: 2011-06-28 15:50 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/7889bbcc7f88 7047954: VM crashes with assert(is_Mem()) failed Summary: cast constant array ptrs to bottom Reviewed-by: never ! src/share/vm/opto/compile.cpp Changeset: 6f6e91603a45 Author: iveresov Date: 2011-07-01 10:35 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/6f6e91603a45 7058689: Tiered: Reprofiling doesn't happen in presence of level 4 OSR methods Summary: Take into account current state of profiling before believing that existing higher level versions are valid Reviewed-by: kvn, never ! src/share/vm/runtime/advancedThresholdPolicy.cpp ! src/share/vm/runtime/simpleThresholdPolicy.cpp Changeset: 2c359f27615c Author: iveresov Date: 2011-07-01 10:37 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/2c359f27615c 7057120: Tiered: Allow C1 to inline methods with loops Summary: Recompile the enclosing methods without inlining of the method that has OSRed to level 4 or recompile the enclosing method at level 4. Reviewed-by: kvn, never ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_Runtime1.cpp ! src/share/vm/ci/ciMethod.cpp ! src/share/vm/ci/ciMethod.hpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/runtime/advancedThresholdPolicy.cpp ! src/share/vm/runtime/advancedThresholdPolicy.hpp ! src/share/vm/runtime/compilationPolicy.cpp ! src/share/vm/runtime/compilationPolicy.hpp ! src/share/vm/runtime/simpleThresholdPolicy.cpp ! src/share/vm/runtime/simpleThresholdPolicy.hpp Changeset: 15559220ce79 Author: never Date: 2011-07-05 16:07 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/15559220ce79 6478991: C1 NullCheckEliminator yields incorrect exceptions Reviewed-by: twisti, iveresov ! src/share/vm/c1/c1_Optimizer.cpp + test/compiler/6478991/NullCheckTest.java Changeset: fe240d87c6ec Author: never Date: 2011-07-06 09:27 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/fe240d87c6ec 7061101: adlc should complain about mixing block and expression forms of ins_encode Reviewed-by: kvn ! src/share/vm/adlc/adlparse.cpp Changeset: 3e23978ea0c3 Author: never Date: 2011-07-06 18:15 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/3e23978ea0c3 7062856: Disassembler needs to be smarter about finding hsdis after 1.7 launcher changes Summary: do explicit lookup emulating old LD_LIBRARY_PATH search Reviewed-by: kvn, jrose ! src/share/tools/hsdis/README ! src/share/vm/compiler/disassembler.cpp Changeset: b16582d6c7db Author: kvn Date: 2011-07-07 10:51 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/b16582d6c7db Merge ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/oops/methodOop.cpp Changeset: 7d9e451f5416 Author: jcoomes Date: 2011-07-06 12:03 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/7d9e451f5416 7061187: need some includes for arm/ppc Reviewed-by: dholmes, never, jwilhelm, kvn ! src/share/vm/opto/lcm.cpp ! src/share/vm/opto/matcher.cpp ! src/share/vm/runtime/atomic.cpp Changeset: eb94b7226b7a Author: jcoomes Date: 2011-07-06 12:17 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/eb94b7226b7a 7061192: option handling adjustments for oracle and embedded builds Reviewed-by: dholmes, never, jwilhelm, kvn ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp Changeset: 65dba8692db7 Author: jcoomes Date: 2011-07-06 12:22 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/65dba8692db7 7061197: ThreadLocalStorage sp map table should be optional Reviewed-by: dholmes, never, jwilhelm, kvn ! src/os_cpu/linux_x86/vm/assembler_linux_x86.cpp ! src/os_cpu/linux_x86/vm/threadLS_linux_x86.cpp ! src/os_cpu/linux_x86/vm/threadLS_linux_x86.hpp Changeset: 48048b59a551 Author: jcoomes Date: 2011-07-06 12:28 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/48048b59a551 7061204: clean the chunk table synchronously in embedded builds Reviewed-by: dholmes, never, jwilhelm, kvn ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/memory/defNewGeneration.cpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/thread.cpp Changeset: bf6481e5f96d Author: jcoomes Date: 2011-07-06 13:02 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/bf6481e5f96d 7061225: os::print_cpu_info() should support os-specific data Reviewed-by: dholmes, never, jwilhelm, kvn ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/windows/vm/os_windows.cpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/os.hpp Changeset: 8a4fc2990229 Author: jcoomes Date: 2011-07-07 15:44 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/8a4fc2990229 7053189: remove some unnecessary platform-dependent includes Reviewed-by: dholmes, never, jwilhelm, kvn ! src/share/vm/prims/jni.cpp ! src/share/vm/runtime/arguments.cpp Changeset: b0b8491925fe Author: jcoomes Date: 2011-07-11 14:15 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/b0b8491925fe 7061212: use o/s low memory notification in embedded builds Reviewed-by: dholmes, never, jwilhelm, kvn ! src/os/linux/vm/os_linux.cpp Changeset: 0defeba52583 Author: jcoomes Date: 2011-07-12 16:32 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/0defeba52583 Merge Changeset: faa472957b38 Author: kvn Date: 2011-07-08 09:38 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/faa472957b38 7059034: Use movxtod/movdtox on T4 Summary: Use new VIS3 mov instructions on T4 for move data between general and float registers. Reviewed-by: never, twisti ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/cpu/sparc/vm/sparc.ad ! src/cpu/sparc/vm/vm_version_sparc.cpp ! src/share/vm/runtime/globals.hpp Changeset: 263247c478c5 Author: iveresov Date: 2011-07-08 15:33 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/263247c478c5 7058510: multinewarray with 6 dimensions uncommon traps in server compiler Summary: Pass arguments to runtime via java array for arrays with > 5 dimensions Reviewed-by: never, kvn, jrose, pbk ! src/share/vm/opto/parse3.cpp ! src/share/vm/opto/runtime.cpp ! src/share/vm/opto/runtime.hpp Changeset: 1f4f4ae84625 Author: kvn Date: 2011-07-13 10:48 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/1f4f4ae84625 Merge ! src/share/vm/runtime/globals.hpp Changeset: e6e7d76b2bd3 Author: mr Date: 2011-05-24 15:28 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/e6e7d76b2bd3 7048009: Update .jcheck/conf files for JDK 8 Reviewed-by: jjh ! .jcheck/conf Changeset: 3fbb609d9e96 Author: kvn Date: 2011-07-14 15:39 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/3fbb609d9e96 7067288: compiler regression test Test7052494 timeouts with client VM Summary: Test is modified to reduce number of iterations in test5() and test6(). Reviewed-by: never, iveresov ! test/compiler/7052494/Test7052494.java Changeset: 341a57af9b0a Author: never Date: 2011-07-15 15:35 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/341a57af9b0a 6990212: JSR 292 JVMTI MethodEnter hook is not called for JSR 292 bootstrap and target methods Summary: check for single stepping when dispatching invokes from method handles Reviewed-by: coleenp, twisti, kvn, dsamersoff ! src/cpu/sparc/vm/methodHandles_sparc.cpp ! src/cpu/sparc/vm/methodHandles_sparc.hpp ! src/cpu/x86/vm/interp_masm_x86_32.cpp ! src/cpu/x86/vm/interp_masm_x86_64.cpp ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/cpu/x86/vm/methodHandles_x86.hpp + test/compiler/6990212/Test6990212.java Changeset: 968305b802ee Author: trims Date: 2011-07-23 01:56 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/968305b802ee Merge Changeset: 8e5d4aa73a8c Author: trims Date: 2011-07-22 23:47 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/8e5d4aa73a8c 7069176: Update the JDK version numbers in Hotspot for JDK 8 Summary: Change JDK_MINOR_VER and JDK_PREVIOUS_VERSION to reflect JDK8 values Reviewed-by: jcoomes ! make/hotspot_version Changeset: 0cc8a70952c3 Author: trims Date: 2011-07-22 23:42 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/0cc8a70952c3 7070061: Adjust Hotspot make/jprt.properties for new JDK8 settings Summary: Fix so the JPRT can build with -release jdk8 now Reviewed-by: ohair ! make/jprt.properties Changeset: 20cac004a4f9 Author: dsamersoff Date: 2011-06-09 01:06 +0400 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/20cac004a4f9 Merge Changeset: 1744e37e032b Author: dsamersoff Date: 2011-06-18 13:32 +0400 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/1744e37e032b Merge Changeset: d425748f2203 Author: dcubed Date: 2011-06-23 20:31 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/d425748f2203 7043987: 3/3 JVMTI FollowReferences is slow Summary: VM_HeapWalkOperation::doit() should only reset mark bits when necessary. Reviewed-by: dsamersoff, ysr, dholmes, dcubed Contributed-by: ashok.srinivasa.murthy at oracle.com ! src/share/vm/prims/jvmtiTagMap.cpp Changeset: 88dce6a60ac8 Author: dcubed Date: 2011-06-29 20:28 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/88dce6a60ac8 6951623: 3/3 possible performance problems in FollowReferences() and GetObjectsWithTags() Summary: Call collect_stack_roots() before collect_simple_roots() as an optimization. Reviewed-by: ysr, dsamersoff, dcubed Contributed-by: ashok.srinivasa.murthy at oracle.com ! src/share/vm/prims/jvmtiTagMap.cpp Changeset: 109d1d265924 Author: dholmes Date: 2011-07-02 04:17 -0400 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/109d1d265924 7052988: JPRT embedded builds don't set MINIMIZE_RAM_USAGE Reviewed-by: kamg, dsamersoff ! make/jprt.gmk Changeset: 5447b2c582ad Author: coleenp Date: 2011-07-07 22:34 -0400 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/5447b2c582ad Merge Changeset: bcc6475bc68f Author: coleenp Date: 2011-07-16 22:21 -0400 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/bcc6475bc68f Merge Changeset: 0b80db433fcb Author: dholmes Date: 2011-07-22 00:29 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/0b80db433fcb 7046490: Preallocated OOME objects should obey Throwable stack trace protocol Summary: Update the OOME stacktrace to contain Throwable.UNASSIGNED_STACK when the backtrace is filled in Reviewed-by: mchung, phh ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp Changeset: 8107273fd204 Author: coleenp Date: 2011-07-23 10:42 -0400 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/8107273fd204 Merge Changeset: ca1f1753c866 Author: andrew Date: 2011-07-28 14:10 -0400 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/ca1f1753c866 7072341: enable hotspot builds on Linux 3.0 Summary: Add "3" to list of allowable versions Reviewed-by: kamg, chrisphi ! make/linux/Makefile Changeset: 14a2fd14c0db Author: johnc Date: 2011-08-01 10:04 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/14a2fd14c0db 7068240: G1: Long "parallel other time" and "ext root scanning" when running specific benchmark Summary: In root processing, move the scanning of the reference processor's discovered lists to before RSet updating and scanning. When scanning the reference processor's discovered lists, use a buffering closure so that the time spent copying any reference object is correctly attributed. Also removed a couple of unused and irrelevant timers. Reviewed-by: ysr, jmasa ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp Changeset: 6aa4feb8a366 Author: johnc Date: 2011-08-02 12:13 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/6aa4feb8a366 7069863: G1: SIGSEGV running SPECjbb2011 and -UseBiasedLocking Summary: Align the reserved size of the heap and perm to the heap region size to get a preferred heap base that is aligned to the region size, and call the correct heap reservation constructor. Also add a check in the heap reservation code that the reserved space starts at the requested address (if any). Reviewed-by: kvn, ysr ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/runtime/virtualspace.cpp Changeset: a20e6e447d3d Author: iveresov Date: 2011-08-05 16:44 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/a20e6e447d3d 7060842: UseNUMA crash with UseHugreTLBFS running SPECjvm2008 Summary: Use mmap() instead of madvise(MADV_DONTNEED) to uncommit pages Reviewed-by: ysr ! src/os/linux/vm/os_linux.cpp Changeset: 7c2653aefc46 Author: iveresov Date: 2011-08-05 16:50 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/7c2653aefc46 7060836: RHEL 5.5 and 5.6 should support UseNUMA Summary: Add a wrapper for sched_getcpu() for systems where libc lacks it Reviewed-by: ysr Contributed-by: Andrew John Hughes ! src/os/linux/vm/os_linux.cpp ! src/os/linux/vm/os_linux.hpp Changeset: 41e6ee74f879 Author: kevinw Date: 2011-08-02 14:37 +0100 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/41e6ee74f879 7072527: CMS: JMM GC counters overcount in some cases Summary: Avoid overcounting when CMS has concurrent mode failure. Reviewed-by: ysr Contributed-by: rednaxelafx at gmail.com ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp + test/gc/7072527/TestFullGCCount.java Changeset: e9db47a083cc Author: kevinw Date: 2011-08-11 14:58 +0100 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/e9db47a083cc Merge Changeset: 87e40b34bc2b Author: johnc Date: 2011-08-11 11:36 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/87e40b34bc2b 7074579: G1: JVM crash with JDK7 running ATG CRMDemo Fusion App Summary: Handlize MemoryUsage klass oop in createGCInfo routine Reviewed-by: tonyp, fparain, ysr, jcoomes ! src/share/vm/services/gcNotifier.cpp Changeset: f44782f04dd4 Author: tonyp Date: 2011-08-12 11:31 -0400 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/f44782f04dd4 7039627: G1: avoid BOT updates for survivor allocations and dirty survivor regions incrementally Summary: Refactor the allocation code during GC to use the G1AllocRegion abstraction. Use separate subclasses of G1AllocRegion for survivor and old regions. Avoid BOT updates and dirty survivor cards incrementally for the former. Reviewed-by: brutisso, johnc, ysr ! src/share/vm/gc_implementation/g1/g1AllocRegion.cpp ! src/share/vm/gc_implementation/g1/g1AllocRegion.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.inline.hpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp Changeset: 76b1a9420e3d Author: ysr Date: 2011-08-16 08:02 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/76b1a9420e3d Merge Changeset: 46cb9a7b8b01 Author: dsamersoff Date: 2011-08-10 15:04 +0400 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/46cb9a7b8b01 7073913: The fix for 7017193 causes segfaults Summary: Buffer overflow in os::get_line_chars Reviewed-by: coleenp, dholmes, dcubed Contributed-by: aph at redhat.com ! src/share/vm/runtime/os.cpp Changeset: b1cbb0907b36 Author: zgu Date: 2011-04-15 09:34 -0400 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/b1cbb0907b36 7016797: Hotspot: securely/restrictive load dlls and new API for loading system dlls Summary: Created Windows Dll wrapped to handle jdk6 and jdk7 platform requirements, also provided more restictive Dll search orders for Windows system Dlls. Reviewed-by: acorn, dcubed, ohair, alanb ! make/windows/makefiles/compile.make ! src/os/windows/vm/decoder_windows.cpp ! src/os/windows/vm/jvm_windows.h ! src/os/windows/vm/os_windows.cpp ! src/os/windows/vm/os_windows.hpp Changeset: 279ef1916773 Author: zgu Date: 2011-07-12 21:13 -0400 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/279ef1916773 7065535: Mistyped function name that disabled UseLargePages on Windows Summary: Missing suffix "A" of Windows API LookupPrivilegeValue failed finding function pointer, caused VM to disable UseLargePages option Reviewed-by: coleenp, phh ! src/os/windows/vm/os_windows.cpp Changeset: a68e11dceb83 Author: zgu Date: 2011-08-16 09:18 -0400 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/a68e11dceb83 Merge Changeset: 00ed4ccfe642 Author: collins Date: 2011-08-17 07:05 -0400 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/00ed4ccfe642 Merge Changeset: 43f9d800f276 Author: iveresov Date: 2011-07-20 18:04 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/43f9d800f276 7066339: Tiered: policy should make consistent decisions about osr levels Summary: Added feedback disabling flag to common(), fixed handling of TieredStopAtLevel. Reviewed-by: kvn, never ! src/share/vm/classfile/classLoader.cpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/runtime/advancedThresholdPolicy.cpp ! src/share/vm/runtime/advancedThresholdPolicy.hpp ! src/share/vm/runtime/compilationPolicy.hpp ! src/share/vm/runtime/javaCalls.cpp ! src/share/vm/runtime/simpleThresholdPolicy.cpp ! src/share/vm/runtime/simpleThresholdPolicy.hpp Changeset: 6a991dcb52bb Author: never Date: 2011-07-21 08:38 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/6a991dcb52bb 7012081: JSR 292: SA-JDI can't read MH/MT/Indy ConstantPool entries Reviewed-by: kvn, twisti, jrose ! agent/src/share/classes/sun/jvm/hotspot/interpreter/Bytecode.java - agent/src/share/classes/sun/jvm/hotspot/interpreter/BytecodeFastAAccess0.java - agent/src/share/classes/sun/jvm/hotspot/interpreter/BytecodeFastIAccess0.java ! agent/src/share/classes/sun/jvm/hotspot/interpreter/BytecodeLoadConstant.java ! agent/src/share/classes/sun/jvm/hotspot/interpreter/BytecodeStream.java ! agent/src/share/classes/sun/jvm/hotspot/interpreter/BytecodeWideable.java ! agent/src/share/classes/sun/jvm/hotspot/interpreter/BytecodeWithCPIndex.java ! agent/src/share/classes/sun/jvm/hotspot/interpreter/Bytecodes.java ! agent/src/share/classes/sun/jvm/hotspot/oops/ConstMethod.java ! agent/src/share/classes/sun/jvm/hotspot/oops/ConstantPool.java ! agent/src/share/classes/sun/jvm/hotspot/oops/ConstantPoolCache.java ! agent/src/share/classes/sun/jvm/hotspot/oops/GenerateOopMap.java ! agent/src/share/classes/sun/jvm/hotspot/oops/Method.java ! agent/src/share/classes/sun/jvm/hotspot/oops/TypeArray.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/ConstantTag.java ! src/share/vm/oops/generateOopMap.cpp Changeset: 3d42f82cd811 Author: kvn Date: 2011-07-21 11:25 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/3d42f82cd811 7063628: Use cbcond on T4 Summary: Add new short branch instruction to Hotspot sparc assembler. Reviewed-by: never, twisti, jrose ! src/cpu/sparc/vm/assembler_sparc.cpp ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/cpu/sparc/vm/assembler_sparc.inline.hpp ! src/cpu/sparc/vm/c1_CodeStubs_sparc.cpp ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/sparc/vm/c1_MacroAssembler_sparc.cpp ! src/cpu/sparc/vm/c1_Runtime1_sparc.cpp ! src/cpu/sparc/vm/cppInterpreter_sparc.cpp ! src/cpu/sparc/vm/interp_masm_sparc.cpp ! src/cpu/sparc/vm/interpreter_sparc.cpp ! src/cpu/sparc/vm/methodHandles_sparc.cpp ! src/cpu/sparc/vm/sharedRuntime_sparc.cpp ! src/cpu/sparc/vm/sparc.ad ! src/cpu/sparc/vm/stubGenerator_sparc.cpp ! src/cpu/sparc/vm/templateInterpreter_sparc.cpp ! src/cpu/sparc/vm/templateTable_sparc.cpp ! src/cpu/sparc/vm/vm_version_sparc.cpp ! src/cpu/sparc/vm/vm_version_sparc.hpp ! src/cpu/sparc/vm/vtableStubs_sparc.cpp ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/os_cpu/solaris_sparc/vm/vm_version_solaris_sparc.cpp ! src/share/vm/adlc/formssel.cpp ! src/share/vm/adlc/output_c.cpp ! src/share/vm/adlc/output_h.cpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/machnode.cpp ! src/share/vm/opto/machnode.hpp ! src/share/vm/opto/output.cpp ! src/share/vm/runtime/globals.hpp Changeset: 4e761e7e6e12 Author: kvn Date: 2011-07-26 19:35 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/4e761e7e6e12 7070134: Hotspot crashes with sigsegv from PorterStemmer Summary: Do not move data nodes which are attached to a predicate test to a dominating test. Reviewed-by: never ! src/share/vm/opto/ifnode.cpp ! src/share/vm/opto/loopPredicate.cpp ! src/share/vm/opto/loopnode.hpp ! src/share/vm/opto/loopopts.cpp + test/compiler/7070134/Stemmer.java + test/compiler/7070134/Test7070134.sh + test/compiler/7070134/words Changeset: 0f34fdee809e Author: never Date: 2011-07-27 15:06 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/0f34fdee809e 7071427: AdapterFingerPrint can hold 8 entries per int Reviewed-by: kvn ! src/share/vm/runtime/java.cpp ! src/share/vm/runtime/sharedRuntime.cpp Changeset: c7b60b601eb4 Author: kvn Date: 2011-07-27 17:28 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/c7b60b601eb4 7069452: Cleanup NodeFlags Summary: Remove flags which duplicate information in Node::NodeClasses. 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/adlc/adlparse.cpp ! src/share/vm/adlc/archDesc.cpp ! src/share/vm/adlc/formssel.cpp ! src/share/vm/adlc/formssel.hpp ! src/share/vm/adlc/output_h.cpp ! src/share/vm/opto/block.cpp ! src/share/vm/opto/callnode.hpp ! src/share/vm/opto/cfgnode.hpp ! src/share/vm/opto/coalesce.cpp ! src/share/vm/opto/gcm.cpp ! src/share/vm/opto/idealGraphPrinter.cpp ! src/share/vm/opto/lcm.cpp ! src/share/vm/opto/machnode.hpp ! src/share/vm/opto/mulnode.cpp ! src/share/vm/opto/mulnode.hpp ! src/share/vm/opto/node.hpp ! src/share/vm/opto/output.cpp ! src/share/vm/opto/reg_split.cpp ! src/share/vm/opto/superword.cpp ! src/share/vm/opto/superword.hpp ! src/share/vm/opto/vectornode.cpp ! src/share/vm/opto/vectornode.hpp Changeset: d17bd0b18663 Author: twisti Date: 2011-07-28 02:14 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/d17bd0b18663 7066143: JSR 292: Zero support after regressions from 7009923 and 7009309 Reviewed-by: jrose, twisti Contributed-by: Xerxes Ranby ! src/cpu/zero/vm/stack_zero.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: ce3e1d4dc416 Author: never Date: 2011-07-28 13:03 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/ce3e1d4dc416 7060619: C1 should respect inline and dontinline directives from CompilerOracle Reviewed-by: kvn, iveresov ! src/share/vm/c1/c1_GraphBuilder.cpp Changeset: c96c3eb1efae Author: kvn Date: 2011-07-29 09:16 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/c96c3eb1efae 7068051: SIGSEGV in PhaseIdealLoop::build_loop_late_post Summary: Removed predicate cloning from loop peeling optimization and from split fall-in paths. Reviewed-by: never ! src/share/vm/opto/cfgnode.cpp ! src/share/vm/opto/ifnode.cpp ! src/share/vm/opto/loopPredicate.cpp ! src/share/vm/opto/loopTransform.cpp ! src/share/vm/opto/loopUnswitch.cpp ! src/share/vm/opto/loopnode.cpp ! src/share/vm/opto/loopnode.hpp ! src/share/vm/opto/phaseX.hpp Changeset: 4aa5974a06dd Author: kvn Date: 2011-08-06 08:28 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/4aa5974a06dd 7075559: JPRT windows_x64 build failure Summary: use SA_CLASSDIR variable instead of dirsctory saclasses. Reviewed-by: kamg, dcubed ! make/linux/makefiles/defs.make ! make/solaris/makefiles/defs.make ! make/solaris/makefiles/saproc.make ! make/windows/makefiles/defs.make ! make/windows/makefiles/sa.make Changeset: a3142bdb6707 Author: twisti Date: 2011-08-08 05:49 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/a3142bdb6707 7071823: Zero: zero/shark doesn't build after b147-fcs Reviewed-by: gbenson, twisti Contributed-by: Chris Phillips ! src/cpu/zero/vm/frame_zero.cpp + src/cpu/zero/vm/methodHandles_zero.hpp ! src/cpu/zero/vm/sharedRuntime_zero.cpp ! src/share/vm/shark/sharkContext.hpp Changeset: a19c671188cb Author: never Date: 2011-08-08 13:19 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/a19c671188cb 7075623: 6990212 broke raiseException in 64 bit Reviewed-by: kvn, twisti ! src/cpu/sparc/vm/methodHandles_sparc.cpp ! src/cpu/x86/vm/methodHandles_x86.cpp Changeset: f1c12354c3f7 Author: roland Date: 2011-08-02 18:36 +0200 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/f1c12354c3f7 7074017: Introduce MemBarAcquireLock/MemBarReleaseLock nodes for monitor enter/exit code paths Summary: replace MemBarAcquire/MemBarRelease nodes on the monitor enter/exit code paths with new MemBarAcquireLock/MemBarReleaseLock nodes Reviewed-by: kvn, twisti ! src/cpu/sparc/vm/sparc.ad ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/adlc/formssel.cpp ! src/share/vm/opto/classes.hpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/matcher.cpp ! src/share/vm/opto/matcher.hpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/memnode.hpp Changeset: 6987871cfb9b Author: kvn Date: 2011-08-10 14:06 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/6987871cfb9b 7077439: Possible reference through NULL in loopPredicate.cpp:726 Summary: Use cl->is_valid_counted_loop() check. Reviewed-by: never ! src/share/vm/opto/loopPredicate.cpp ! src/share/vm/opto/loopTransform.cpp ! src/share/vm/opto/loopnode.cpp ! src/share/vm/opto/superword.cpp Changeset: 95134e034042 Author: kvn Date: 2011-08-11 12:08 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/95134e034042 7063629: use cbcond in C2 generated code on T4 Summary: Use new short branch instruction in C2 generated code. Reviewed-by: never ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/cpu/sparc/vm/sparc.ad ! src/cpu/sparc/vm/vm_version_sparc.cpp ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/os_cpu/linux_x86/vm/linux_x86_32.ad ! src/os_cpu/linux_x86/vm/linux_x86_64.ad ! src/os_cpu/solaris_x86/vm/solaris_x86_32.ad ! src/os_cpu/solaris_x86/vm/solaris_x86_64.ad ! src/share/vm/adlc/formssel.cpp ! src/share/vm/adlc/output_h.cpp ! src/share/vm/opto/block.cpp ! src/share/vm/opto/block.hpp ! src/share/vm/opto/compile.hpp ! src/share/vm/opto/machnode.hpp ! src/share/vm/opto/matcher.hpp ! src/share/vm/opto/node.hpp ! src/share/vm/opto/output.cpp Changeset: fdb992d83a87 Author: twisti Date: 2011-08-16 04:14 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/fdb992d83a87 7071653: JSR 292: call site change notification should be pushed not pulled Reviewed-by: kvn, never, bdelsart ! src/cpu/sparc/vm/interp_masm_sparc.cpp ! src/cpu/sparc/vm/interp_masm_sparc.hpp ! src/cpu/sparc/vm/templateTable_sparc.cpp ! src/cpu/x86/vm/interp_masm_x86_32.cpp ! src/cpu/x86/vm/interp_masm_x86_32.hpp ! src/cpu/x86/vm/interp_masm_x86_64.cpp ! src/cpu/x86/vm/interp_masm_x86_64.hpp ! src/cpu/x86/vm/templateTable_x86_32.cpp ! src/cpu/x86/vm/templateTable_x86_64.cpp ! src/share/vm/ci/ciCallSite.cpp ! src/share/vm/ci/ciCallSite.hpp ! src/share/vm/ci/ciField.hpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/code/dependencies.cpp ! src/share/vm/code/dependencies.hpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/interpreter/templateTable.hpp ! src/share/vm/memory/universe.cpp ! src/share/vm/memory/universe.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/opto/callGenerator.cpp ! src/share/vm/opto/callGenerator.hpp ! src/share/vm/opto/doCall.cpp ! src/share/vm/opto/parse3.cpp Changeset: 11211f7cb5a0 Author: kvn Date: 2011-08-16 11:53 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/11211f7cb5a0 7079317: Incorrect branch's destination block in PrintoOptoAssembly output Summary: save/restore label and block in scratch_emit_size() Reviewed-by: never ! src/share/vm/adlc/archDesc.cpp ! src/share/vm/adlc/formssel.cpp ! src/share/vm/adlc/output_c.cpp ! src/share/vm/adlc/output_h.cpp ! src/share/vm/opto/block.cpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/idealGraphPrinter.cpp ! src/share/vm/opto/machnode.cpp ! src/share/vm/opto/machnode.hpp ! src/share/vm/opto/node.hpp ! src/share/vm/opto/output.cpp Changeset: 1af104d6cf99 Author: kvn Date: 2011-08-16 16:59 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/1af104d6cf99 7079329: Adjust allocation prefetching for T4 Summary: on T4 2 BIS instructions should be issued to prefetch 64 bytes Reviewed-by: iveresov, phh, twisti ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/cpu/sparc/vm/sparc.ad ! src/cpu/sparc/vm/vm_version_sparc.cpp ! src/cpu/sparc/vm/vm_version_sparc.hpp ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/vm_version_x86.cpp ! src/cpu/x86/vm/vm_version_x86.hpp ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/adlc/formssel.cpp ! src/share/vm/memory/threadLocalAllocBuffer.hpp ! src/share/vm/opto/classes.hpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/matcher.cpp ! src/share/vm/opto/memnode.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/vm_version.cpp ! src/share/vm/runtime/vm_version.hpp Changeset: 381bf869f784 Author: twisti Date: 2011-08-17 05:14 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/381bf869f784 7079626: x64 emits unnecessary REX prefix Reviewed-by: kvn, iveresov, never ! src/cpu/x86/vm/assembler_x86.cpp Changeset: bd87c0dcaba5 Author: twisti Date: 2011-08-17 11:52 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/bd87c0dcaba5 7079769: JSR 292: incorrect size() for CallStaticJavaHandle on sparc Reviewed-by: never, kvn ! src/cpu/sparc/vm/sparc.ad Changeset: 739a9abbbd4b Author: kvn Date: 2011-08-18 11:49 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/739a9abbbd4b 7080431: VM asserts if specified size(x) in .ad is larger than emitted size Summary: Move code from finalize_offsets_and_shorten() to fill_buffer() to restore previous behavior. Reviewed-by: never ! src/share/vm/opto/compile.hpp ! src/share/vm/opto/output.cpp Changeset: de147f62e695 Author: kvn Date: 2011-08-19 08:55 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/de147f62e695 Merge - agent/src/share/classes/sun/jvm/hotspot/interpreter/BytecodeFastAAccess0.java - agent/src/share/classes/sun/jvm/hotspot/interpreter/BytecodeFastIAccess0.java Changeset: 24cee90e9453 Author: jcoomes Date: 2011-08-17 10:32 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/24cee90e9453 6791672: enable 1G and larger pages on solaris Reviewed-by: ysr, iveresov, johnc ! src/os/solaris/vm/os_solaris.cpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/os.hpp Changeset: 3be7439273c5 Author: katleman Date: 2011-05-25 13:31 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/3be7439273c5 7044486: open jdk repos have files with incorrect copyright headers, which can end up in src bundles Reviewed-by: ohair, trims ! agent/src/share/classes/sun/jvm/hotspot/runtime/ServiceThread.java ! make/linux/README ! make/windows/projectfiles/kernel/Makefile ! src/cpu/x86/vm/vm_version_x86.cpp ! src/cpu/x86/vm/vm_version_x86.hpp ! src/os_cpu/solaris_sparc/vm/solaris_sparc.s ! src/share/tools/hsdis/README ! src/share/vm/gc_implementation/g1/heapRegionSet.inline.hpp ! src/share/vm/gc_implementation/parNew/parCardTableModRefBS.cpp ! src/share/vm/utilities/yieldingWorkgroup.cpp Changeset: 8b135e6129d6 Author: jeff Date: 2011-05-27 15:01 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/8b135e6129d6 7045697: JDK7 THIRD PARTY README update Reviewed-by: lana ! THIRD_PARTY_README Changeset: 52e4ba46751f Author: kamg Date: 2011-04-12 16:42 -0400 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/52e4ba46751f 7020373: JSR rewriting can overflow memory address size variables Summary: Abort if incoming classfile's parameters would cause overflows Reviewed-by: coleenp, dcubed, never ! src/share/vm/oops/generateOopMap.cpp + test/runtime/7020373/Test7020373.sh Changeset: bca686989d4b Author: asaha Date: 2011-06-15 14:59 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/bca686989d4b 7055247: Ignore test of # 7020373 Reviewed-by: dcubed ! test/runtime/7020373/Test7020373.sh Changeset: 337ffef74c37 Author: jeff Date: 2011-06-22 10:10 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/337ffef74c37 7057046: Add embedded license to THIRD PARTY README Reviewed-by: lana ! THIRD_PARTY_README Changeset: 9f12ede5571a Author: jcoomes Date: 2011-08-19 14:08 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/9f12ede5571a Merge ! src/cpu/x86/vm/vm_version_x86.cpp ! src/cpu/x86/vm/vm_version_x86.hpp ! src/share/vm/oops/generateOopMap.cpp ! src/share/vm/runtime/os.cpp Changeset: 7c29742c41b4 Author: jcoomes Date: 2011-08-19 14:22 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/7c29742c41b4 7081251: bump the hs22 build number to 02 Reviewed-by: johnc ! make/hotspot_version Changeset: 8580b4f22e29 Author: jcoomes Date: 2011-08-23 21:17 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/8580b4f22e29 Merge ! .jcheck/conf - agent/src/share/classes/sun/jvm/hotspot/interpreter/BytecodeFastAAccess0.java - agent/src/share/classes/sun/jvm/hotspot/interpreter/BytecodeFastIAccess0.java ! make/hotspot_version ! src/cpu/x86/vm/vm_version_x86.cpp ! src/cpu/x86/vm/vm_version_x86.hpp ! src/os/windows/vm/os_windows.cpp ! src/share/tools/hsdis/README ! src/share/vm/gc_implementation/parNew/parCardTableModRefBS.cpp ! src/share/vm/prims/methodHandleWalk.cpp From John.Coomes at oracle.com Tue Aug 23 22:49:09 2011 From: John.Coomes at oracle.com (John Coomes) Date: Tue, 23 Aug 2011 22:49:09 -0700 Subject: jdk7u2-b03: HotSpot Message-ID: <20052.37077.987497.937454@oracle.com> http://hg.openjdk.java.net/jdk7u/jdk7u/rev/91954c06ba1e http://hg.openjdk.java.net/jdk7u/jdk7u/corba/rev/e1a1c0d72264 http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/8580b4f22e29 http://hg.openjdk.java.net/jdk7u/jdk7u/jaxp/rev/4b0c44f2f7f1 http://hg.openjdk.java.net/jdk7u/jdk7u/jaxws/rev/e94a8b7a9629 http://hg.openjdk.java.net/jdk7u/jdk7u/jdk/rev/449f7f1bb735 http://hg.openjdk.java.net/jdk7u/jdk7u/langtools/rev/d5d8654d8180 Component : VM Status : 0 major failures, 4 minor failures Date : 08/23/2011 at 09:34 Tested By : VM SQE and Nicolay.Haustov at oracle.com Cost(total man-days): 1 Workspace : N/A Bundles : JPRT: 2011-08-19-232819.jcoomes.hs22-b02-snapshot Platforms : Solaris x86 11(32), -client Solaris x86 11(32), -server Solaris x86 10(32), -client Solaris x86 10(32), -server WinXP Prof(32), -client WinXP Prof(32), -server WinXP Home(32), -client WinXP Home(32), -server Win Server 2003(32), -client Win Server 2003(32), -server Windows Vista 32 bit, -client Windows Vista 32 bit, -server RH AS4.0 (32), -client RH AS4.0 (32), -server SuSE SLES 8(32), -client SuSE SLES 8(32), -server Solaris AMD64(64jdk), -d64/-server Sol Sparc 10(64OS)(64jdk), -d64/-server win server2003 AMD(64OS)(64jdk), -d64/-server RH AS4.0 AMD(64OS)(64jdk), -d64/-server SuSE SLES8 AMD(64OS)(64jdk), -d64/-server Others Tests : /net/sqenfs-1.us.oracle.com/export1/comp/vm/testbase Browsers : NA Patches : NA Logs : http://sqeweb.us.oracle.com/nfs/results/vm/gtee/HSX/PIT/VM/hs22/b02/jdk7u2b03/ Number of Tests Executed : 329365 product tests, 0 unit tests, 0 tck tests Bug verification status: ====================================== Tested, Pass: 6791672: enable 1G and larger pages on solaris 6916968: CMS: freeList.cpp:304 assert(_allocation_stats.prevSweep() + ..., "Conservation Principle") 6941923: RFE: Handling large log files produced by long running Java Applications 7016112: CMS: crash during promotion testing 7032531: G1: enhance GC logging to include more accurate eden / survivor size transitions 7042285: G1: native memory leak during humongous object allocation 7044738: Loop unroll optimization causes incorrect result 7046490: Preallocated OOME objects should obey Throwable stack trace protocol 7047954: VM crashes with assert(is_Mem()) failed: invalid node class 7048342: CMS: eob == _limit || fc->isFree() failed: Only a free chunk should allow us to cross over the limit 7048782: CMS: assert(last_chunk_index_to_check<= last_chunk_index) failed: parCardTableModRefBS.cpp:359 7058036: FieldsAllocationStyle=2 does not work in 32-bit VM 7058510: multinewarray with 6 dimensions uncommon traps in server compiler 7061192: option handling adjustments for oracle and embedded builds 7061197: ThreadLocalStorage sp map table should be optional 7061204: clean the chunk table synchronously in embedded builds 7061212: use o/s low memory notification in embedded builds 7061225: os::print_cpu_info() should support os-specific data 7062856: Disassembler needs to be smarter about finding hsdis after 1.7 launcher changes 7067288: compiler regression test Test7052494 timeouts with client VM 7068051: SIGSEGV in PhaseIdealLoop::build_loop_late_post on T5440 7069863: G1: SIGSEGV running SPECjbb2011 and -UseBiasedLocking 7070134: Hotspot crashes with sigsegv from PorterStemmer 7072527: CMS: JMM GC counters overcount in some cases 7075623: 6990212 broke raiseException in 64 bit 7079317: Incorrect branch's destination block in PrintoOptoAssembly output 7079626: x64 emits unnecessary REX prefix Tested, Pass (partial fixes): Tested, Fail: Untested bug fixes: Setup is not available: 6478991: C1 NullCheckEliminator yields incorrect exceptions 6804436: G1: heap region indices should be size_t 6918185: Remove unused code for lost card-marking optimization in BacktraceBuilder 6990015: Incorrect Icache line size is used for 64 bit x86 6994322: Remove the is_tlab and is_noref / is_large_noref parameters from the CollectedHeap interface 7004681: G1: Extend marking verification to marking phase of Full GCs 7039627: G1: avoid BOT updates for survivor allocations and dirty survivor regions incrementally 7043987: JVMTI FollowReferences is slow 7045330: G1: Simplify/fix the HeapRegionSeq class 7045662: G1: OopsInHeapRegionClosure::set_region() should not be virtual 7045751: G1: +ExplicitGCInvokesConcurrent causes excessive single region evacuation pauses 7046182: G1: remove unnecessary iterations over the collection set 7046558: G1: concurrent marking optimizations 7049999: G1: Make the G1PrintHeapRegions output consistent and complete 7051430: CMS: ongoing CMS cycle should terminate abruptly to allow prompt JVM termination at exit 7057120: Tiered: Allow C1 to inline methods with loops 7058689: Tiered: Reprofiling doesn't happen in presence of level 4 OSR methods 7058870: C2/ARM: compiler/7048332/Test7048332.java 7059034: Use movxtod/movdtox on T4 7060619: C1 should respect inline and dontinline directives from CompilerOracle 7060836: RHEL 5.5 and 5.6 should support UseNUMA 7060842: UseNUMA crash with UseHugreTLBFS running SPECjvm2008 7061101: adlc should complain about mixing block and expression forms of ins_encode 7063628: Use cbcond on T4 7063629: use cbcond in C2 generated code on T4 7065535: Mistyped function name that disabled UseLargePages on Windows 7066143: JSR 292: Zero support after regressions from 7009923 and 7009309 7066339: Tiered: policy should make consistent decisions about osr levels 7068240: G1: Long "parallel other time" and "ext root scanning" when running specific benchmark 7069452: Cleanup NodeFlags 7071427: AdapterFingerPrint can hold 8 entries per int 7071653: JSR 292: call site change notification should be pushed not pulled 7073913: The fix for 7017193 causes segfaults 7074017: Introduce MemBarAcquireLock/MemBarReleaseLock nodes for monitor enter/exit code paths 7074579: G1: JVM crash with JDK7 running ATG CRMDemo Fusion App 7076673: C2: assert(false) failed: bad AD file in matcher.cpp:1497 7077242: c2/arm: Enable support of 32 fp registers when available 7077439: Possible reference through NULL in loopPrdicate.cpp:726 7079329: Adjust allocation prefetching for T4 7080431: VM asserts if specified size(x) in .ad is larger than emitted size Build change only: 6951623: possible performance problems in FollowReferences() and GetObjectsWithTags() 6990212: JSR 292 JVMTI MethodEnter hook is not called for JSR 292 bootstrap and target methods 7012081: JSR 292: SA-JDI can't read MH/MT/Indy ConstantPool entries 7048009: Update .jcheck/conf files for JDK 8 7052988: JPRT embedded builds don't set MINIMIZE_RAM_USAGE 7053189: remove some unnecessary platform-dependent includes 7055073: G1: code cleanup in the concurrentMark.* files 7061187: need some includes for arm/ppc 7061691: Fork HS21 to HS22 - renumber Major and build numbers of JVM 7069176: Update the JDK version numbers in Hotspot for JDK 8 7070061: Adjust Hotspot make/jprt.properties for new JDK8 settings 7071823: Zero: zero/shark doesn't build after b147-fcs 7072341: enable hotspot builds on Linux 3.0 7075559: JPRT windows_x64 build failure 7079769: JSR 292: incorrect size() for CallStaticJavaHandle on sparc 7081251: bump the hs22 build number to 02 New bugs filed: Bugs in PIT build: 7046355: C2/arm: Error: Unimplemented() at arm.ad:851 7081842: assert(Compile::current()->unique() < (uint)MaxNodeLimit) failed: Node limit exceeded 7082274: TEST BUG: JSR 292: vm/mlvm/meth/func/jdi//breakpointOtherStratum fails intermittently 7082294: nsk/regression/b4265661 crashes on windows Bugs in earlier promoted build: Number of PIT requested: 1 Integration target J2SE build number: 7u2-b03 Issues and Notes: This is HS 22 b02 PIT for JDK 7u2 b03. ------------------------------- >From VM SQE and Nicolay.Haustov at oracle.com From nils.loodin at oracle.com Wed Aug 24 06:04:43 2011 From: nils.loodin at oracle.com (Nils Loodin) Date: Wed, 24 Aug 2011 15:04:43 +0200 Subject: Request for review: Bug 7067811 Message-ID: <4E54F6EB.3080200@oracle.com> webrev here: http://cr.openjdk.java.net/~nloodin/7067811/webrev.03/ Bug states that we need a block of comments in each demo source file as well as top level read-me:s in the demo and samples dir stating that the code is unfit for production. From description: ------------- The documentation should include the following disclaimer: The source code provided with samples and demos for the JDK is meant to illustrate the usage of a given feature or technique and has been deliberately simplified. Additional steps required for a production-quality application, such as security checks, input validation, and proper error handling, might not be present in the sample code. Usage of sample code in production environments is strongly discouraged. On the actual source code a variation of the message should be included as a comment in the header: This source code is provided to illustrate the usage of a given feature or technique and has been deliberately simplified. Additional steps required for a production-quality application, such as security checks, input validation, and proper error handling, might not be present in this sample code. Finally on the documentation of applications, such as the lightweight HTTP server, that are shipped for testing/debugging, the following disclaimer should be added: Applications such as the lightweight HTTP server are shipped with the JDK to help developers deploy and test their code easily. They have not been developed in accordance to software development standards for production-quality applications. Usage of such test and/or support applications in production environments is strongly discouraged. -------------- Mostly comment changes, but also changes in samples and demos makefiles to copy the README. Regards Nisse From dalibor.topic at oracle.com Wed Aug 24 06:55:47 2011 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Wed, 24 Aug 2011 15:55:47 +0200 Subject: Request for review: Bug 7067811 In-Reply-To: <4E54F6EB.3080200@oracle.com> References: <4E54F6EB.3080200@oracle.com> Message-ID: <4E5502E3.9020806@oracle.com> On 8/24/11 3:04 PM, Nils Loodin wrote: > webrev here: http://cr.openjdk.java.net/~nloodin/7067811/webrev.03/ > > Bug states that we need a block of comments in each demo source file as well as top level read-me:s in the demo and samples dir stating that the code is unfit for production. From description: Hi Nisse, if I'm reading this right, this is the same patch as the one you're proposing for jdk8 over here: http://mail.openjdk.java.net/pipermail/serviceability-dev/2011-August/004450.html - correct? In that case, you don't need to request an additional review here - instead you will need to request approval (in a separate mail to this list) to push the change into jdk7u-dev once you have pushed it into jdk8. A template for that mail is here: Subject: Request for approval for CR $NR With the body containing a) a link to the publicly visible bug on the bugs.sun.com site (or its equivalent), or a description of the change in case no publicly visible bug is here b) a link to the publicly visible webrev or changeset (in case it's in JDK 8 already) c) if the review is taking place somewhere else, a link to the public review thread d) if the fix has already been reviewed for inclusion into jdk7u-dev, the list of reviewers e) once we branch off 7u2, you'll also need to add the forest the fix is targeted for I'd suggest waiting for the reviews for jdk8 to complete before you ask for approval, though, in case that the proposed changeset turns out to need to be modified before the actual push into jdk8. cheers, dalibor topic -- Oracle Dalibor Topic | Java F/OSS Ambassador Phone: +494023646738 | Mobile: +491772664192 Oracle Java Platform Group ORACLE Deutschland B.V. & Co. KG | Nagelsweg 55 | 20097 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: J?rgen Kunz, Marcel van de Molen, Alexander van der Ven Green Oracle Oracle is committed to developing practices and products that help protect the environment From denis.fokin at sun.com Wed Aug 24 08:51:36 2011 From: denis.fokin at sun.com (denis.fokin at sun.com) Date: Wed, 24 Aug 2011 15:51:36 +0000 Subject: hg: jdk7u/jdk7u-dev/jdk: 7072645: Toolkit.addPropertyChangeListener(name, pcl) throws NPE for null name Message-ID: <20110824155147.07E164709B@hg.openjdk.java.net> Changeset: 44141ce2c9ea Author: denis Date: 2011-08-24 19:49 +0400 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/jdk/rev/44141ce2c9ea 7072645: Toolkit.addPropertyChangeListener(name, pcl) throws NPE for null name Reviewed-by: art ! src/solaris/classes/sun/awt/X11/XToolkit.java ! src/windows/classes/sun/awt/windows/WToolkit.java From mandy.chung at oracle.com Wed Aug 24 10:11:25 2011 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 24 Aug 2011 10:11:25 -0700 Subject: Request for approval for 7068328 Message-ID: <4E5530BD.2050707@oracle.com> This is to request approval to backport the fix for 7068328 to jdk7u-dev/jdk: 7068328: BufferPoolMXBean and PlatformLoggingMXBean getObjectName may return null http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7068328 Changeset in jdk8 (and see [1] for the discussion): http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4e53fc6bcac0 The patch for jdk7u is the same as that in jdk8. Build and regression tests pass. Thanks Mandy [1] http://mail.openjdk.java.net/pipermail/serviceability-dev/2011-August/004441.html From xueming.shen at oracle.com Wed Aug 24 10:58:59 2011 From: xueming.shen at oracle.com (Xueming Shen) Date: Wed, 24 Aug 2011 10:58:59 -0700 Subject: Request for approval for: 7066490 Message-ID: <4E553BE3.7080103@oracle.com> /Hi, Could you please approve the fix for /7066490: @since 1.7 tag is missing for java.util.regex.Matcher.group(java.lang.String) This is a simple doc update (to add the missing @since1.7 tag). The same fix has been pushed in JDK8 already. / Bug description is at /http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7066490 /The webrev is at /http://cr.openjdk.java.net/~sherman/7066490/7u2/webrev The fix was mistakenly pushed into the 7u2 repository yesterday without going through this "request for approval" process. My apology for the mishandling. Thanks, Sherman From dalibor.topic at oracle.com Wed Aug 24 11:10:51 2011 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Wed, 24 Aug 2011 20:10:51 +0200 Subject: Request for approval for: 7066490 In-Reply-To: <4E553BE3.7080103@oracle.com> References: <4E553BE3.7080103@oracle.com> Message-ID: <4E553EAB.9000607@oracle.com> On 8/24/11 7:58 PM, Xueming Shen wrote: > /Hi, > > Could you please approve the fix for > > /7066490: @since 1.7 tag is missing for java.util.regex.Matcher.group(java.lang.String) > > This is a simple doc update (to add the missing @since1.7 tag). > The same fix has been pushed in JDK8 already. > / > Bug description is at > /http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7066490 > > /The webrev is at > /http://cr.openjdk.java.net/~sherman/7066490/7u2/webrev > > The fix was mistakenly pushed into the 7u2 repository yesterday without > going through this "request for approval" process. My apology for the > mishandling. > > Thanks, > Sherman > > Thanks, Sherman - retroactively approved. cheers, dalibor topic -- Oracle Dalibor Topic | Java F/OSS Ambassador Phone: +494023646738 | Mobile: +491772664192 Oracle Java Platform Group ORACLE Deutschland B.V. & Co. KG | Nagelsweg 55 | 20097 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: J?rgen Kunz, Marcel van de Molen, Alexander van der Ven Green Oracle Oracle is committed to developing practices and products that help protect the environment From dalibor.topic at oracle.com Wed Aug 24 11:13:13 2011 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Wed, 24 Aug 2011 20:13:13 +0200 Subject: Request for approval for 7068328 In-Reply-To: <4E5530BD.2050707@oracle.com> References: <4E5530BD.2050707@oracle.com> Message-ID: <4E553F39.1060704@oracle.com> Thanks, Mandy - approved! cheers, dalibor topic On 8/24/11 7:11 PM, Mandy Chung wrote: > This is to request approval to backport the fix for 7068328 to jdk7u-dev/jdk: > > 7068328: BufferPoolMXBean and PlatformLoggingMXBean getObjectName may return null > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7068328 > > Changeset in jdk8 (and see [1] for the discussion): > http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4e53fc6bcac0 > > The patch for jdk7u is the same as that in jdk8. Build and regression tests pass. > > Thanks > Mandy > [1] http://mail.openjdk.java.net/pipermail/serviceability-dev/2011-August/004441.html -- Oracle Dalibor Topic | Java F/OSS Ambassador Phone: +494023646738 | Mobile: +491772664192 Oracle Java Platform Group ORACLE Deutschland B.V. & Co. KG | Nagelsweg 55 | 20097 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: J?rgen Kunz, Marcel van de Molen, Alexander van der Ven Green Oracle Oracle is committed to developing practices and products that help protect the environment From dalibor.topic at oracle.com Wed Aug 24 11:19:54 2011 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Wed, 24 Aug 2011 20:19:54 +0200 Subject: Process proposal for Updating JDK 7u with Hotspot Express... In-Reply-To: <4E53EC57.2010207@netdemons.com> References: <1313029001.1843.242.camel@ghostbox> <20051.57077.708965.353840@oracle.com> <4E53EC57.2010207@netdemons.com> Message-ID: <4E5540CA.9030609@oracle.com> Thanks, Erik & thanks, John. I'd like to leave this thread open for a couple more days, until next Wednesday, to see if there is going to be any further feedback, in particular now that the first merge following this process has landed in the forest, and then turn this proposal with its amendments into a hotspot bulk integration process documented on this project's web site. cheers, dalibor topic On 8/23/11 8:07 PM, Erik Trimble wrote: > On 8/23/2011 10:10 AM, John Coomes wrote: > >> Since Erik has left Oracle, I'll be filling in until a permanent >> hotspot gatekeeper is able to take over. >> >> I have some corrections and recommendations below. >> > All of John's comments make sense to me. More importantly, his changes reflect reality > of what the current 7u and 8 situation is. > > My one comment is on the following section: > >> 2a.) In addition, there will never be a Hotspot->7u integration until >> AFTER the same Hotspot version has been promoted into the JDK 8 forest, >> and undergone a full Release promotion cycle. This will be to make sure >> that the Hotspot version in hsx/hsxN/hotspot is indeed stabilized and we >> have worked out any immediately apparent serious issues. This may very >> well mean that Hotspot will not immediately promote all Hotspot builds >> unto 7u. E.g. HS20 b01 may go to JDK 8 Build 01, but if there are >> problems detected, then HS22 will not be pushed into 7u until those >> issues are addressed in a new HS build. So, it is entirely possible that >> an integration into 7u will actually encompass several Hotspot build >> numbers. >> This restriction (2a) will have to be relaxed, at least somewhat. >> Since jdk8 builds are not yet happening regularly, requiring the >> hotspot snapshot to appear in a promoted jdk8 build before it can be >> integrated into 7u will delay 7u integrations for indefinite periods. >> So the requirement that a hotspot snapshot complete what Erik calls 'a >> full Release promotion cycle' in jdk8 before being integrated into 7u >> should be dropped. >> >> In addition, given that build schedules and release dates for 7u and 8 >> are not aligned, I can easily foresee the case when deadlines will >> necessitate integration into 7u before integration into the jdk8 >> master forest. >> >> So we should change the requirement that a hotspot snapshot be >> integrated into the jdk8 *master* before before being integrated into >> 7u. Instead, the presence of a fix in *hsx/hotspot-main* should be >> enough to meet the requirement that a fix be present in jdk8. The >> hsx/hotspot-main forest is used very much like the jdk8 integration >> forests used by other groups (e.g., jdk8/build/*, jdk8/tl/*, etc.), in >> that it is regularly pushed up to the jdk8 master. The only >> difference is that it also delivers into other releases. The process >> for approving individual fixes for 7u deems the presence of the fix in >> a jdk8 integration forest (e.g., jdk8/tl) as sufficient to meet the >> requirement that a fix be included in jdk8; the same should apply to >> hotspot. > I'd think that what I originally described for the 7u process (i.e. never integrate to 7u > until that change has been pushed into 8) is the goal process - that is, if all the QA > systems are up and running, and all JDK 8 and JDK 7u development work is going full steam, > then the we should adhere to the No 7u Before 8 restriction. > > I know that's not the case now, and that 7u is currently being given more priority than 8, > so John's proposal is a good one (and, reflects the facts on the ground). Maybe about the > time 7u2 gets pushed out, things will have settled down sufficiently, and we can look > forward to going back to requiring a tested 8 push before the equivalent 7u push. > >>> One specific point where I'm not sure how we want to proceed is this: >>> >>> Should #6 (the push of the Hotspot snapshot into 7u-dev/hotspot) happen >>> right after approval from the Technical Lead happen? If so, then it >>> likely will be BEFORE QA has finished on the snapshot. This would be in >>> line with the other JDK fixes, since they do not undergo QA before being >>> pushed to 7u-dev/*. However, Hotspot is "special", so do we care to be >>> extra sure that 7u-dev/hotspot is stable? >>> ... >> I think hotspot should complete both a PIT cycle and a control build >> of the JDK before we integrate into 7u-dev since (a) we're doing bulk >> integrations and the amount of change may be rather large, and (b) we >> want to ensure that the hotspot in 7u-dev can be used as a bootstrap >> for a JDK build. We currently don't test the latest hotspot as a >> bootstrap to build the JDK as part of our automated nightly or JPRT >> tests, so it should be done before integrating into 7u-dev. >> >> We'll follow this order (integrate into jdk7u/jdk7u-dev only after >> passing PIT, and into jdk7u/jdk7u shortly afterward) for the current >> integration of hs22 b02 into 7u2 b03, expected today. PIT results are >> still pending, but all other requirements have been met. >> >> -John > John's proposal here is the more conservative one, which is entirely acceptable. > I think the only salient notable result is that people will see the 7u-dev/hotspot > updated very shortly before the 7u/hotspot repository (likely only a few hours before, if that). > So, people should be aware that this happens, and not to expect a large amount of time to review and/or > look at things in the 7u-dev/hotspot repository before those changes hit 7u/hotspot. > > > Lastly, John is correct in that I'm no longer at Oracle. I've moved to a company in downtown San Francisco; > however, I'm going to be a heavy user of the JDK at my new employer (who's building something that will > hammer the living crap out of the JVM), and expect to continue participating in the OpenJDK project. > Email from me will use this (my personal email) account, until it becomes > appropriate for me to use my new employer's address. > > So, set your email filters appropriately. :-) > > -Erik > trims at netdemons.com > > -- Oracle Dalibor Topic | Java F/OSS Ambassador Phone: +494023646738 | Mobile: +491772664192 Oracle Java Platform Group ORACLE Deutschland B.V. & Co. KG | Nagelsweg 55 | 20097 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: J?rgen Kunz, Marcel van de Molen, Alexander van der Ven Green Oracle Oracle is committed to developing practices and products that help protect the environment From mandy.chung at oracle.com Wed Aug 24 11:25:14 2011 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Wed, 24 Aug 2011 18:25:14 +0000 Subject: hg: jdk7u/jdk7u-dev/jdk: 7068328: BufferPoolMXBean and PlatformLoggingMXBean getObjectName may return null Message-ID: <20110824182528.DCF1D470AB@hg.openjdk.java.net> Changeset: 55cd74a4d575 Author: mchung Date: 2011-08-23 10:35 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/jdk/rev/55cd74a4d575 7068328: BufferPoolMXBean and PlatformLoggingMXBean getObjectName may return null Reviewed-by: alanb Contributed-by: spoole at uk.ibm.com ! src/share/classes/sun/management/ManagementFactoryHelper.java + test/java/lang/management/ManagementFactory/GetObjectName.java From rob.mckenna at oracle.com Wed Aug 24 12:56:57 2011 From: rob.mckenna at oracle.com (Rob McKenna) Date: Wed, 24 Aug 2011 20:56:57 +0100 Subject: Request for approval for: 6670868 Message-ID: <4E555789.3070003@oracle.com> Hi folks, Looking for approval for : 6670868: StackOverFlow with authenticated Proxy tunnels This is a backport from jdk8, and is identical to that fix: http://cr.openjdk.java.net/~chegar/6670868/webrev.00/webrev/ http://hg.openjdk.java.net/jdk8/jdk8-gate/jdk/rev/a80562f7ea50 Description available at: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6670868 -Rob From rob.mckenna at oracle.com Wed Aug 24 12:59:34 2011 From: rob.mckenna at oracle.com (Rob McKenna) Date: Wed, 24 Aug 2011 20:59:34 +0100 Subject: Request for approval for: 7068416 Message-ID: <4E555826.3080101@oracle.com> Hi folks, Looking for approval for : 7068416: Lightweight HTTP Server should support TCP_NODELAY This is a backport from jdk8, and is identical to that fix: http://cr.openjdk.java.net/~chegar/7068416/webrev.01/webrev/ http://hg.openjdk.java.net/jdk8/jdk8-gate/jdk/rev/70ec3aa8e99a Description available at: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7068416 -Rob From dalibor.topic at oracle.com Wed Aug 24 15:07:57 2011 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Thu, 25 Aug 2011 00:07:57 +0200 Subject: Request for approval for: 6670868 In-Reply-To: <4E555789.3070003@oracle.com> References: <4E555789.3070003@oracle.com> Message-ID: <4E55763D.8060600@oracle.com> On 8/24/11 9:56 PM, Rob McKenna wrote: > Hi folks, > > Looking for approval for : > > 6670868: StackOverFlow with authenticated Proxy tunnels > > This is a backport from jdk8, and is identical to that fix: > > http://cr.openjdk.java.net/~chegar/6670868/webrev.00/webrev/ > http://hg.openjdk.java.net/jdk8/jdk8-gate/jdk/rev/a80562f7ea50 > > Description available at: > > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6670868 Thanks, Rob - approved! cheers, dalibor topic -- Oracle Dalibor Topic | Java F/OSS Ambassador Phone: +494023646738 | Mobile: +491772664192 Oracle Java Platform Group ORACLE Deutschland B.V. & Co. KG | Nagelsweg 55 | 20097 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: J?rgen Kunz, Marcel van de Molen, Alexander van der Ven Green Oracle Oracle is committed to developing practices and products that help protect the environment From dalibor.topic at oracle.com Wed Aug 24 23:24:44 2011 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Thu, 25 Aug 2011 08:24:44 +0200 Subject: Request for approval for: 7068416 In-Reply-To: <4E555826.3080101@oracle.com> References: <4E555826.3080101@oracle.com> Message-ID: <4E55EAAC.50205@oracle.com> On 8/24/11 9:59 PM, Rob McKenna wrote: > Hi folks, > > Looking for approval for : > > 7068416: Lightweight HTTP Server should support TCP_NODELAY > > This is a backport from jdk8, and is identical to that fix: > > http://cr.openjdk.java.net/~chegar/7068416/webrev.01/webrev/ > http://hg.openjdk.java.net/jdk8/jdk8-gate/jdk/rev/70ec3aa8e99a > > Description available at: > > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7068416 > > -Rob Hi Rob, this changeset adds a public property. Before I can approve it, I need to check if this is a case where a CCC is necessary for 7u. cheers, dalibor topic [1] http://openjdk.java.net/guide/changePlanning.html section 4. -- Oracle Dalibor Topic | Java F/OSS Ambassador Phone: +494023646738 | Mobile: +491772664192 Oracle Java Platform Group ORACLE Deutschland B.V. & Co. KG | Nagelsweg 55 | 20097 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: J?rgen Kunz, Marcel van de Molen, Alexander van der Ven Green Oracle Oracle is committed to developing practices and products that help protect the environment From maurizio.cimadamore at oracle.com Thu Aug 25 05:40:52 2011 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Thu, 25 Aug 2011 12:40:52 +0000 Subject: hg: jdk7u/jdk7u-dev/langtools: 3 new changesets Message-ID: <20110825124101.33286470E4@hg.openjdk.java.net> Changeset: e296280b4e77 Author: mcimadamore Date: 2011-07-27 19:00 +0100 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/langtools/rev/e296280b4e77 7062745: Regression: difference in overload resolution when two methods are maximally specific Summary: Fix most specific when two methods are maximally specific and only one has non-raw return type Reviewed-by: jjg, dlsmith ! src/share/classes/com/sun/tools/javac/comp/Resolve.java + test/tools/javac/generics/rawOverride/7062745/GenericOverrideTest.java + test/tools/javac/generics/rawOverride/7062745/T7062745neg.java + test/tools/javac/generics/rawOverride/7062745/T7062745neg.out + test/tools/javac/generics/rawOverride/7062745/T7062745pos.java Changeset: 2de6d1e52742 Author: mcimadamore Date: 2011-07-27 19:01 +0100 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/langtools/rev/2de6d1e52742 7046778: Project Coin: problem with diamond and member inner classes Summary: Diamond inference generates spurious error messages when target type is a member inner class Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Attr.java + test/tools/javac/generics/diamond/7046778/DiamondAndInnerClassTest.java ! test/tools/javac/generics/diamond/neg/Neg09.out Changeset: 8c9f07f9aa28 Author: mcimadamore Date: 2011-07-27 19:01 +0100 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/langtools/rev/8c9f07f9aa28 7057297: Project Coin: diamond erroneously accepts in array initializer expressions Summary: Diamond in array initializer expressions should be rejected Reviewed-by: jjg, dlsmith ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties + test/tools/javac/diags/examples/CannotCreateArrayWithDiamond.java + test/tools/javac/generics/diamond/7057297/T7057297.java + test/tools/javac/generics/diamond/7057297/T7057297.out From dalibor.topic at oracle.com Thu Aug 25 14:42:03 2011 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Thu, 25 Aug 2011 23:42:03 +0200 Subject: Request for approval for: 7068416 In-Reply-To: <4E55EAAC.50205@oracle.com> References: <4E555826.3080101@oracle.com> <4E55EAAC.50205@oracle.com> Message-ID: <4E56C1AB.4090601@oracle.com> On 8/25/11 8:24 AM, Dalibor Topic wrote: > On 8/24/11 9:59 PM, Rob McKenna wrote: >> Hi folks, >> >> Looking for approval for : >> >> 7068416: Lightweight HTTP Server should support TCP_NODELAY >> >> This is a backport from jdk8, and is identical to that fix: >> >> http://cr.openjdk.java.net/~chegar/7068416/webrev.01/webrev/ >> http://hg.openjdk.java.net/jdk8/jdk8-gate/jdk/rev/70ec3aa8e99a >> >> Description available at: >> >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7068416 >> >> -Rob > > Hi Rob, > > this changeset adds a public property. Before I can approve it, I need to > check if this is a case where a CCC is necessary for 7u. > > cheers, > dalibor topic > > [1] http://openjdk.java.net/guide/changePlanning.html section 4. > Yeah, it looks like this one will have to take a round with the CCC for JDK 7 first. Rob, please let us know on this list if & when it passes, and then we'll take another look at the request. cheers, dalibor topic -- Oracle Dalibor Topic | Java F/OSS Ambassador Phone: +494023646738 | Mobile: +491772664192 Oracle Java Platform Group ORACLE Deutschland B.V. & Co. KG | Nagelsweg 55 | 20097 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: J?rgen Kunz, Marcel van de Molen, Alexander van der Ven Green Oracle Oracle is committed to developing practices and products that help protect the environment From rob.mckenna at oracle.com Thu Aug 25 18:05:04 2011 From: rob.mckenna at oracle.com (Rob McKenna) Date: Fri, 26 Aug 2011 02:05:04 +0100 Subject: Request for approval for: 7068416 In-Reply-To: <4E56C1AB.4090601@oracle.com> References: <4E555826.3080101@oracle.com> <4E55EAAC.50205@oracle.com> <4E56C1AB.4090601@oracle.com> Message-ID: <4E56F140.5050104@oracle.com> Will do, apologies for the oversight. -Rob On 25/08/11 22:42, Dalibor Topic wrote: > On 8/25/11 8:24 AM, Dalibor Topic wrote: >> On 8/24/11 9:59 PM, Rob McKenna wrote: >>> Hi folks, >>> >>> Looking for approval for : >>> >>> 7068416: Lightweight HTTP Server should support TCP_NODELAY >>> >>> This is a backport from jdk8, and is identical to that fix: >>> >>> http://cr.openjdk.java.net/~chegar/7068416/webrev.01/webrev/ >>> http://hg.openjdk.java.net/jdk8/jdk8-gate/jdk/rev/70ec3aa8e99a >>> >>> Description available at: >>> >>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7068416 >>> >>> -Rob >> Hi Rob, >> >> this changeset adds a public property. Before I can approve it, I need to >> check if this is a case where a CCC is necessary for 7u. >> >> cheers, >> dalibor topic >> >> [1] http://openjdk.java.net/guide/changePlanning.html section 4. >> > Yeah, it looks like this one will have to take a round with the CCC for JDK 7 > first. Rob, please let us know on this list if& when it passes, and then we'll > take another look at the request. > > cheers, > dalibor topic > > From xueming.shen at oracle.com Fri Aug 26 10:36:49 2011 From: xueming.shen at oracle.com (Xueming Shen) Date: Fri, 26 Aug 2011 10:36:49 -0700 Subject: Request for approval for: 7077769 Message-ID: <4E57D9B1.5060507@oracle.com> /Hi, Could you please approve the fix for / 7077769: (zipfs) ZipFileSystem.writeCEN() writes wrong "data size" for ZIP64 extended information extra field http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7077769 The fix tries to address two issues in the ZipFileSystem class, which is newly introduced in JDK7. (1) The OutputStream used to write out the bits in sync() is not wrapped by a BufferedOutputStream. Without the BufferedOutputStream wrapper, we basically write all ZIP header tables (loc and cen) byte by byte. How big is the impact to the performance? With the BufferedOutputStream, the time we spend on sync/writing a Jar file in size of 64M (our rt.jar) improved from 3640 ms to 1315 ms on my local machine. (2) The writeCEN() incorrectly sets the data size of the ZIP64 extended information extra field block. The "data size" should be the size of the ZIP64 data block only, not include the 4-byte header (the ZFS.writeCEN() accidentally includes these extra 4 bytes). Webrev is at http://cr.openjdk.java.net/~sherman/7077769/7u2/webrev The fix will go into JDK8 first (which is being reviewed). Thanks, Sherman From edvard.wendelin at oracle.com Fri Aug 26 10:42:40 2011 From: edvard.wendelin at oracle.com (Edvard Wendelin) Date: Fri, 26 Aug 2011 10:42:40 -0700 Subject: Request for approval for: 7077769 In-Reply-To: <4E57D9B1.5060507@oracle.com> References: <4E57D9B1.5060507@oracle.com> Message-ID: <0F406E8A-F3A1-48BE-8F27-34D8F01EC5B7@oracle.com> Hi, I'll pre-approve the fix so that you can submit the change once it's in JDK 8. Cheers, Edvard On 26 aug 2011, at 10.36, Xueming Shen wrote: > /Hi, > > Could you please approve the fix for > / > > 7077769: (zipfs) ZipFileSystem.writeCEN() writes wrong "data size" > for ZIP64 extended information extra field > > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7077769 > > The fix tries to address two issues in the ZipFileSystem class, > which is newly introduced > in JDK7. > > (1) The OutputStream used to write out the bits in sync() is not > wrapped > by a BufferedOutputStream. Without the BufferedOutputStream wrapper, > we basically write all ZIP header tables (loc and cen) byte by byte. > How > big is the impact to the performance? With the BufferedOutputStream, > the > time we spend on sync/writing a Jar file in size of 64M (our rt.jar) > improved > from 3640 ms to 1315 ms on my local machine. > > (2) The writeCEN() incorrectly sets the data size of the ZIP64 > extended > information extra field block. The "data size" should be the size > of the > ZIP64 data block only, not include the 4-byte header (the > ZFS.writeCEN() > accidentally includes these extra 4 bytes). > > Webrev is at > > http://cr.openjdk.java.net/~sherman/7077769/7u2/webrev > > The fix will go into JDK8 first (which is being reviewed). > > Thanks, > Sherman From xueming.shen at oracle.com Fri Aug 26 19:01:31 2011 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Sat, 27 Aug 2011 02:01:31 +0000 Subject: hg: jdk7u/jdk7u-dev/jdk: 7077769: (zipfs) ZipFileSystem.writeCEN() writes wrong "data size" for ZIP64 extended information extra field Message-ID: <20110827020151.3212547154@hg.openjdk.java.net> Changeset: eabbc04b83bc Author: sherman Date: 2011-08-26 18:38 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/jdk/rev/eabbc04b83bc 7077769: (zipfs) ZipFileSystem.writeCEN() writes wrong "data size" for ZIP64 extended information extra field Summary: fixed the wrong size when writing out the cen table for ZIP64 Reviewed-by: alanb ! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipFileSystem.java ! test/java/util/zip/LargeZip.java From dalibor.topic at oracle.com Mon Aug 29 16:17:25 2011 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Mon, 29 Aug 2011 16:17:25 -0700 Subject: Request for approval for: 6670868 In-Reply-To: <4E55763D.8060600@oracle.com> References: <4E555789.3070003@oracle.com> <4E55763D.8060600@oracle.com> Message-ID: <4E5C1E05.8000703@oracle.com> On 8/24/11 3:07 PM, Dalibor Topic wrote: > On 8/24/11 9:56 PM, Rob McKenna wrote: >> Hi folks, >> >> Looking for approval for : >> >> 6670868: StackOverFlow with authenticated Proxy tunnels >> >> This is a backport from jdk8, and is identical to that fix: >> >> http://cr.openjdk.java.net/~chegar/6670868/webrev.00/webrev/ >> http://hg.openjdk.java.net/jdk8/jdk8-gate/jdk/rev/a80562f7ea50 >> >> Description available at: >> >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6670868 > > Thanks, Rob - approved! > I don't think I saw the changeset go into jdk7u-dev - Rob, is something holding this one up? cheers, dalibor topic -- Oracle Dalibor Topic | Java F/OSS Ambassador Phone: +494023646738 | Mobile: +491772664192 Oracle Java Platform Group ORACLE Deutschland B.V. & Co. KG | Nagelsweg 55 | 20097 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: J?rgen Kunz, Marcel van de Molen, Alexander van der Ven Green Oracle Oracle is committed to developing practices and products that help protect the environment From suchen.chien at oracle.com Tue Aug 30 10:25:09 2011 From: suchen.chien at oracle.com (suchen.chien at oracle.com) Date: Tue, 30 Aug 2011 17:25:09 +0000 Subject: hg: jdk7u/jdk7u: Added tag jdk7u2-b04 for changeset 91954c06ba1e Message-ID: <20110830172509.192BA4721E@hg.openjdk.java.net> Changeset: c8b409d5b8d1 Author: schien Date: 2011-08-30 10:20 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/rev/c8b409d5b8d1 Added tag jdk7u2-b04 for changeset 91954c06ba1e ! .hgtags From suchen.chien at oracle.com Tue Aug 30 10:25:17 2011 From: suchen.chien at oracle.com (suchen.chien at oracle.com) Date: Tue, 30 Aug 2011 17:25:17 +0000 Subject: hg: jdk7u/jdk7u/corba: Added tag jdk7u2-b04 for changeset e1a1c0d72264 Message-ID: <20110830172518.0729947220@hg.openjdk.java.net> Changeset: 391d8aa6f432 Author: schien Date: 2011-08-30 10:20 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/corba/rev/391d8aa6f432 Added tag jdk7u2-b04 for changeset e1a1c0d72264 ! .hgtags From suchen.chien at oracle.com Tue Aug 30 10:26:00 2011 From: suchen.chien at oracle.com (suchen.chien at oracle.com) Date: Tue, 30 Aug 2011 17:26:00 +0000 Subject: hg: jdk7u/jdk7u/hotspot: Added tag jdk7u2-b04 for changeset 8580b4f22e29 Message-ID: <20110830172602.4777447222@hg.openjdk.java.net> Changeset: 2c820a7d4f30 Author: schien Date: 2011-08-30 10:20 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/2c820a7d4f30 Added tag jdk7u2-b04 for changeset 8580b4f22e29 ! .hgtags From suchen.chien at oracle.com Tue Aug 30 10:27:24 2011 From: suchen.chien at oracle.com (suchen.chien at oracle.com) Date: Tue, 30 Aug 2011 17:27:24 +0000 Subject: hg: jdk7u/jdk7u/jaxp: Added tag jdk7u2-b04 for changeset 4b0c44f2f7f1 Message-ID: <20110830172724.CB97447224@hg.openjdk.java.net> Changeset: 06ec99824fc7 Author: schien Date: 2011-08-30 10:20 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/jaxp/rev/06ec99824fc7 Added tag jdk7u2-b04 for changeset 4b0c44f2f7f1 ! .hgtags From suchen.chien at oracle.com Tue Aug 30 10:27:33 2011 From: suchen.chien at oracle.com (suchen.chien at oracle.com) Date: Tue, 30 Aug 2011 17:27:33 +0000 Subject: hg: jdk7u/jdk7u/jaxws: Added tag jdk7u2-b04 for changeset e94a8b7a9629 Message-ID: <20110830172733.439EC47226@hg.openjdk.java.net> Changeset: aec267c02523 Author: schien Date: 2011-08-30 10:20 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/jaxws/rev/aec267c02523 Added tag jdk7u2-b04 for changeset e94a8b7a9629 ! .hgtags From suchen.chien at oracle.com Tue Aug 30 10:27:44 2011 From: suchen.chien at oracle.com (suchen.chien at oracle.com) Date: Tue, 30 Aug 2011 17:27:44 +0000 Subject: hg: jdk7u/jdk7u/jdk: Added tag jdk7u2-b04 for changeset 449f7f1bb735 Message-ID: <20110830172754.4B2E147229@hg.openjdk.java.net> Changeset: 775d67f1d144 Author: schien Date: 2011-08-30 10:20 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/jdk/rev/775d67f1d144 Added tag jdk7u2-b04 for changeset 449f7f1bb735 ! .hgtags From suchen.chien at oracle.com Tue Aug 30 10:29:50 2011 From: suchen.chien at oracle.com (suchen.chien at oracle.com) Date: Tue, 30 Aug 2011 17:29:50 +0000 Subject: hg: jdk7u/jdk7u/langtools: Added tag jdk7u2-b04 for changeset d5d8654d8180 Message-ID: <20110830172952.1BD4B4722B@hg.openjdk.java.net> Changeset: 1f1c1763ac31 Author: schien Date: 2011-08-30 10:20 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/langtools/rev/1f1c1763ac31 Added tag jdk7u2-b04 for changeset d5d8654d8180 ! .hgtags From rob.mckenna at oracle.com Wed Aug 31 09:39:59 2011 From: rob.mckenna at oracle.com (Rob McKenna) Date: Wed, 31 Aug 2011 17:39:59 +0100 Subject: Request for approval for: 6670868 In-Reply-To: <4E5C1E05.8000703@oracle.com> References: <4E555789.3070003@oracle.com> <4E55763D.8060600@oracle.com> <4E5C1E05.8000703@oracle.com> Message-ID: <4E5E63DF.1030107@oracle.com> Apologies for the delay. It'll be done tonight. Just running a triple check jtreg. -Rob On 30/08/11 00:17, Dalibor Topic wrote: > On 8/24/11 3:07 PM, Dalibor Topic wrote: >> On 8/24/11 9:56 PM, Rob McKenna wrote: >>> Hi folks, >>> >>> Looking for approval for : >>> >>> 6670868: StackOverFlow with authenticated Proxy tunnels >>> >>> This is a backport from jdk8, and is identical to that fix: >>> >>> http://cr.openjdk.java.net/~chegar/6670868/webrev.00/webrev/ >>> http://hg.openjdk.java.net/jdk8/jdk8-gate/jdk/rev/a80562f7ea50 >>> >>> Description available at: >>> >>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6670868 >> Thanks, Rob - approved! >> > I don't think I saw the changeset go into jdk7u-dev - Rob, is > something holding this one up? > > cheers, > dalibor topic > > From dalibor.topic at oracle.com Wed Aug 31 11:08:18 2011 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Wed, 31 Aug 2011 11:08:18 -0700 Subject: Request for approval for: 6670868 In-Reply-To: <4E5E63DF.1030107@oracle.com> References: <4E555789.3070003@oracle.com> <4E55763D.8060600@oracle.com> <4E5C1E05.8000703@oracle.com> <4E5E63DF.1030107@oracle.com> Message-ID: <4E5E7892.6090605@oracle.com> On 8/31/11 9:39 AM, Rob McKenna wrote: > Apologies for the delay. It'll be done tonight. Just running a triple check jtreg. > Great - thanks, Rob! cheers, dalibor topic > -Rob > > On 30/08/11 00:17, Dalibor Topic wrote: >> On 8/24/11 3:07 PM, Dalibor Topic wrote: >>> On 8/24/11 9:56 PM, Rob McKenna wrote: >>>> Hi folks, >>>> >>>> Looking for approval for : >>>> >>>> 6670868: StackOverFlow with authenticated Proxy tunnels >>>> >>>> This is a backport from jdk8, and is identical to that fix: >>>> >>>> http://cr.openjdk.java.net/~chegar/6670868/webrev.00/webrev/ >>>> http://hg.openjdk.java.net/jdk8/jdk8-gate/jdk/rev/a80562f7ea50 >>>> >>>> Description available at: >>>> >>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6670868 >>> Thanks, Rob - approved! >>> >> I don't think I saw the changeset go into jdk7u-dev - Rob, is >> something holding this one up? >> >> cheers, >> dalibor topic >> >> -- Oracle Dalibor Topic | Java F/OSS Ambassador Phone: +494023646738 | Mobile: +491772664192 Oracle Java Platform Group ORACLE Deutschland B.V. & Co. KG | Nagelsweg 55 | 20097 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: J?rgen Kunz, Marcel van de Molen, Alexander van der Ven Green Oracle Oracle is committed to developing practices and products that help protect the environment From suchen.chien at oracle.com Wed Aug 31 15:45:08 2011 From: suchen.chien at oracle.com (suchen.chien at oracle.com) Date: Wed, 31 Aug 2011 22:45:08 +0000 Subject: hg: jdk7u/jdk7u: Added tag jdk7u2-b05 for changeset c8b409d5b8d1 Message-ID: <20110831224508.1F34447277@hg.openjdk.java.net> Changeset: 4331602abe52 Author: schien Date: 2011-08-31 15:36 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/rev/4331602abe52 Added tag jdk7u2-b05 for changeset c8b409d5b8d1 ! .hgtags From suchen.chien at oracle.com Wed Aug 31 15:45:15 2011 From: suchen.chien at oracle.com (suchen.chien at oracle.com) Date: Wed, 31 Aug 2011 22:45:15 +0000 Subject: hg: jdk7u/jdk7u/corba: Added tag jdk7u2-b05 for changeset 391d8aa6f432 Message-ID: <20110831224517.057E347278@hg.openjdk.java.net> Changeset: e4907c890e42 Author: schien Date: 2011-08-31 15:36 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/corba/rev/e4907c890e42 Added tag jdk7u2-b05 for changeset 391d8aa6f432 ! .hgtags From suchen.chien at oracle.com Wed Aug 31 15:45:46 2011 From: suchen.chien at oracle.com (suchen.chien at oracle.com) Date: Wed, 31 Aug 2011 22:45:46 +0000 Subject: hg: jdk7u/jdk7u/hotspot: Added tag jdk7u2-b05 for changeset 2c820a7d4f30 Message-ID: <20110831224549.B7A9647279@hg.openjdk.java.net> Changeset: e012eb9e136d Author: schien Date: 2011-08-31 15:36 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/e012eb9e136d Added tag jdk7u2-b05 for changeset 2c820a7d4f30 ! .hgtags From suchen.chien at oracle.com Wed Aug 31 15:47:02 2011 From: suchen.chien at oracle.com (suchen.chien at oracle.com) Date: Wed, 31 Aug 2011 22:47:02 +0000 Subject: hg: jdk7u/jdk7u/jaxp: Added tag jdk7u2-b05 for changeset 06ec99824fc7 Message-ID: <20110831224702.3CAC04727A@hg.openjdk.java.net> Changeset: 5946b073c57a Author: schien Date: 2011-08-31 15:37 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/jaxp/rev/5946b073c57a Added tag jdk7u2-b05 for changeset 06ec99824fc7 ! .hgtags From suchen.chien at oracle.com Wed Aug 31 15:47:09 2011 From: suchen.chien at oracle.com (suchen.chien at oracle.com) Date: Wed, 31 Aug 2011 22:47:09 +0000 Subject: hg: jdk7u/jdk7u/jaxws: Added tag jdk7u2-b05 for changeset aec267c02523 Message-ID: <20110831224709.F04D94727B@hg.openjdk.java.net> Changeset: 286a65169fda Author: schien Date: 2011-08-31 15:37 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/jaxws/rev/286a65169fda Added tag jdk7u2-b05 for changeset aec267c02523 ! .hgtags From suchen.chien at oracle.com Wed Aug 31 15:47:20 2011 From: suchen.chien at oracle.com (suchen.chien at oracle.com) Date: Wed, 31 Aug 2011 22:47:20 +0000 Subject: hg: jdk7u/jdk7u/jdk: Added tag jdk7u2-b05 for changeset 775d67f1d144 Message-ID: <20110831224730.67A6E4727C@hg.openjdk.java.net> Changeset: 0f58ca394fb3 Author: schien Date: 2011-08-31 15:37 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/jdk/rev/0f58ca394fb3 Added tag jdk7u2-b05 for changeset 775d67f1d144 ! .hgtags From suchen.chien at oracle.com Wed Aug 31 15:48:34 2011 From: suchen.chien at oracle.com (suchen.chien at oracle.com) Date: Wed, 31 Aug 2011 22:48:34 +0000 Subject: hg: jdk7u/jdk7u/langtools: Added tag jdk7u2-b05 for changeset 1f1c1763ac31 Message-ID: <20110831224838.162514727D@hg.openjdk.java.net> Changeset: c364b317119b Author: schien Date: 2011-08-31 15:37 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/langtools/rev/c364b317119b Added tag jdk7u2-b05 for changeset 1f1c1763ac31 ! .hgtags From rob.mckenna at oracle.com Wed Aug 31 17:13:54 2011 From: rob.mckenna at oracle.com (rob.mckenna at oracle.com) Date: Thu, 01 Sep 2011 00:13:54 +0000 Subject: hg: jdk7u/jdk7u-dev/jdk: 6670868: StackOverFlow with authenticated Proxy tunnels Message-ID: <20110901001404.553A347281@hg.openjdk.java.net> Changeset: 85d7fc20baa5 Author: robm Date: 2011-09-01 00:09 +0100 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/jdk/rev/85d7fc20baa5 6670868: StackOverFlow with authenticated Proxy tunnels Reviewed-by: chegar, coffeys ! src/share/classes/sun/net/www/http/HttpClient.java ! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java + test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/HttpsProxyStackOverflow.java From dalibor.topic at oracle.com Wed Aug 31 18:30:22 2011 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Wed, 31 Aug 2011 18:30:22 -0700 Subject: Interaction with the CCC Process - Draft Message-ID: <4E5EE02E.6000607@oracle.com> Hi, here's a draft for discussion how the JDK 7 Updates Project should interact with the existing CCC process, in order to provide additional transparency around potential upcoming interface changes future releases. The draft is open for comments until Wednesday September 7th. cheers, dalibor topic Interaction with the CCC process: Preamble: JDK 7 exposes different kinds of interfaces to its users. See http://cr.openjdk.java.net/~darcy/OpenJdkDevGuide/OpenJdkDevelopersGuide.v0.777.html#kinds_of_interfaces for an introduction. Changes to those interfaces need to be carefully managed. That's done through the CCC process. This document describes how the JDK 7 Updates Project plugs into that existing process. Rule 0: If a changeset proposed for a JDK 7 Update forest requires a specification change, directly affects an external interface, or otherwise has a compatibility impact, a CCC request MUST be initiated. Unless special circumstances hold, a specification change to a java.* or javax.* API is out of bounds for a JDK 7 update release. Rule 1: Currently, if the developer is not employed by Oracle, the CCC request SHOULD be initiated by the Technical Lead. Otherwise, the CCC request MUST be initiated by the developer proposing the changeset. Rule 2: When a CCC request is initiated, the initiator MUST post that a request has been initiated on the jdk7u-dev at openjdk.java.net mailing list. Rule 3: While a CCC request is in progress, the initiator MUST keep the jdk7u-dev at openjdk.java.net mailing list up to date on its progress, in particular whether the request has been approved. Rule 4: As a special exception, CCC requests for changes not going into a public JDK 7 Update forest are not covered by Rule 2 and Rule 3. Rule 5: A changeset for which the CCC request has not been approved (yet), MUST not be committed into a JDK 7 Update forest. Rule 6: The maintainer MAY request a CCC request to be initiated for a changeset. -- Oracle Dalibor Topic | Java F/OSS Ambassador Phone: +494023646738 | Mobile: +491772664192 Oracle Java Platform Group ORACLE Deutschland B.V. & Co. KG | Nagelsweg 55 | 20097 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: J?rgen Kunz, Marcel van de Molen, Alexander van der Ven Green Oracle Oracle is committed to developing practices and products that help protect the environment From dalibor.topic at ORACLE.COM Wed Aug 31 19:59:26 2011 From: dalibor.topic at ORACLE.COM (Dalibor Topic) Date: Wed, 31 Aug 2011 19:59:26 -0700 Subject: Push Approval Request Template posted Message-ID: <4E5EF50E.20203@oracle.com> Hi, since we're now getting regular push approval requests, and they mostly follow the template from our prior mailing list discussions [0], I put it up on the Project web page: http://openjdk.java.net/projects/jdk7u/approval-template.html Please use this template for future push approval requests. There is one change from the discussion on the list - I added a $Synopsis to the subject line, meaning that push approval requests should include both the CR and the synopsis in the subject line to make it a bit easier to glance from the subject line what kind of a change a push approval request is about. cheers, dalibor topic [0] http://mail.openjdk.java.net/pipermail/jdk7u-dev/2011-August/000063.html -- Oracle Dalibor Topic | Java F/OSS Ambassador Phone: +494023646738 | Mobile: +491772664192 Oracle Java Platform Group ORACLE Deutschland B.V. & Co. KG | Nagelsweg 55 | 20097 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: J?rgen Kunz, Marcel van de Molen, Alexander van der Ven Green Oracle Oracle is committed to developing practices and products that help protect the environment From dalibor.topic at oracle.com Wed Aug 31 20:28:28 2011 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Wed, 31 Aug 2011 20:28:28 -0700 Subject: Draft Public Code Review Proposal In-Reply-To: <4E38EAA7.1030208@oracle.com> References: <4E1E4A41.1060101@oracle.com> <4E1E77DF.8050505@oracle.com> <4E38BA8F.3020103@oracle.com> <4E38EAA7.1030208@oracle.com> Message-ID: <4E5EFBDC.60207@oracle.com> On 8/2/11 11:28 PM, Poonam Bajaj wrote: > Hi Dalibor, > > On 8/3/2011 8:33 AM, Dalibor Topic wrote: >> On 7/14/11 7:00 AM, David Holmes wrote: >> >>> Hi Dalibor, >>> >>> On 14/07/2011 11:45 AM, Dalibor Topic wrote: >>> >>>> Next item on my draft list is code review. The proposal below is inspired by the developer guide section on code review, and in part inspired by the processes in OpenJDK 6. It tries to encourage transparency, and getting more eyes on the code, while at the same time allowing established practices, like asking component leads for additional reviews, to continue to work. >>>> >>>> Public code review: >>>> >>>> Preamble: The new infrastructure is not ready yet, so we won't switch to it for the next release in OpenJDK (i.e. 7u2, as 7u1 is a CPU) just yet. The process here may change for 7u4. >>>> >>>> Pre-requisite: Before asking for code review, make sure your fix is applied on the most recent revision of the code you intend to work on, that there are no build errors on the supported platforms for the release you're working on, and that any included or otherwise applicable tests pass without failures on all relevant platforms. If you're not able to build or test on all supported platforms, you MUST let the reviewers know which ones you were able to build and test on, as well as whether you anticipate any issues on the platforms you haven't been able to build and test on. >>>> >>>> Rule 0: Code reviews for public JDK 7 Update forests MUST be done publicly: Either through e-mail on jdk7u-dev at openjdk.java.net mailing list, or using some other suitable public mechanism. If a code review is not done on the jdk7u-dev at openjdk.java.net mailing list, as part of the approval request for inclusion of the fix into a public JDK 7 Updates forest, which you MUST send to the jdk7u-dev at openjdk.java.net mailing list, a URL for the public code review MUST be provided. >>>> >>> At present who comprises the set of authors, commiters and reviewers for the jdk7u project? >>> >> >> The initial set of committers is the set of individuals who have committed code into JDK 7, >> i.e. the output of >> >> for i in . corba/ hotspot/ jaxp jaxws/ jdk/ langtools/ ; do hg -R $i log --template "{author}\n" ; done | sort | uniq >> >> on jdk7. >> >> The initial set of reviewers is the set of individuals who have reviewed code committed into JDK 7, i.e. are mentioned in a Reviewed-by: line in a commit. >> I don't have a nice one liner for that yet, though. >> >> The initial set of authors is the set of individuals who have submitted code into JDK 7, without having committed it themselves, >> i.e. the individuals mentioned in Contributed-by lines who are not Committers. Again, no sweet one liner for that either, >> contributions welcome. >> >> The rationale for going with that broad set of individuals is that if you helped create or review changesets for JDK 7, you can now >> help in the same roles with the updates. >> >> > Can we have a page listing the names of authors, commiters and reviewers for jdk7u project ? http://openjdk.java.net/census/#jdk7u You'll note that this isn't quite what I described above, but it has the advantage of being a consistent transition step across all OpenJDK Projects, rather then having this Project be a special exception. Since I expect the vast majority of fixes for JDK 7 Updates to come from JDK 8, transitioning jdk7u and jdk8 in the same way makes it in particular a bit easier for fixes to continue to flow from there to here as quickly as they have so far. See http://openjdk.java.net/census/ for more information on the OpenJDK Census. I have updated the Project web page accordingly with a pointer to the Census. cheers, dalibor topic -- Oracle Dalibor Topic | Java F/OSS Ambassador Phone: +494023646738 | Mobile: +491772664192 Oracle Java Platform Group ORACLE Deutschland B.V. & Co. KG | Nagelsweg 55 | 20097 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: J?rgen Kunz, Marcel van de Molen, Alexander van der Ven Green Oracle Oracle is committed to developing practices and products that help protect the environment From chris.hegarty at oracle.com Wed Aug 31 23:01:55 2011 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 01 Sep 2011 07:01:55 +0100 Subject: Request for approval for CR 7051516 - ThreadLocalRandom seed is never initialized so all instances generate the same sequence Message-ID: <4E5F1FD3.7060609@oracle.com> This is a request for approval to backport the fix for 7051516 to jdk7u-dev/jdk: 7051516 - ThreadLocalRandom seed is never initialized so all instances generate the same sequence http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7051516 Changeset in jdk8 (and see [1] for the discussion): http://hg.openjdk.java.net/jdk8/tl/jdk/rev/411d02c13385 The patch for jdk7u is the same as that in jdk8. Thanks, Chris From chris.hegarty at oracle.com Wed Aug 31 23:03:45 2011 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 01 Sep 2011 07:03:45 +0100 Subject: Request for Approval for CR 7058828 - test/java/util/concurrent/Phaser/Arrive.java fails intermittently Message-ID: <4E5F2041.4030404@oracle.com> This is a request for approval to backport the fix for 7058828 to jdk7u-dev/jdk: 7058828 - test/java/util/concurrent/Phaser/Arrive.java fails intermittently http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7058828 Changeset in jdk8: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/549b7c3f0bdc The patch for jdk7u is the same as that in jdk8. Thanks, Chris