From Sergey.Bylokhov at oracle.com Sun Jun 1 13:05:48 2014 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Sun, 01 Jun 2014 17:05:48 +0400 Subject: CFV: New jdk9 Committer: Pete Brunet Message-ID: <538B252C.4030909@oracle.com> I hereby nominate Pete Brunet (OpenJDK user name: ptbrunet) to JDK9 Committer. Pete is currently a JDK9 Author and a member of Accessibility team at Oracle. Here is the list of fixes: http://hg.openjdk.java.net/jdk9/client/jdk/log?revcount=300&rev=peter.brunet%40oracle.com http://hg.openjdk.java.net/jdk9/client/jdk/search/?rev=ptbrunet&revcount=100 Votes are due by June 15, 2014. Only current JDK9 Committers [1] are eligible to vote on this nomination. For Lazy Consensus voting instructions, see [2]. [1] http://openjdk.java.net/census#jdk9 [2] http://openjdk.java.net/projects#committer-vote -- Best regards, Sergey. From petr.pchelko at oracle.com Mon Jun 2 06:27:53 2014 From: petr.pchelko at oracle.com (Petr Pchelko) Date: Mon, 2 Jun 2014 10:27:53 +0400 Subject: CFV: New jdk9 Committer: Pete Brunet In-Reply-To: <538B252C.4030909@oracle.com> References: <538B252C.4030909@oracle.com> Message-ID: Vote: YES. With best regards. Petr. On 01 ???? 2014 ?., at 17:05, Sergey Bylokhov wrote: > I hereby nominate Pete Brunet (OpenJDK user name: ptbrunet) to JDK9 Committer. > > Pete is currently a JDK9 Author and a member of Accessibility team at Oracle. > > Here is the list of fixes: > http://hg.openjdk.java.net/jdk9/client/jdk/log?revcount=300&rev=peter.brunet%40oracle.com > http://hg.openjdk.java.net/jdk9/client/jdk/search/?rev=ptbrunet&revcount=100 > > Votes are due by June 15, 2014. > > Only current JDK9 Committers [1] are eligible to vote on this nomination. > > For Lazy Consensus voting instructions, see [2]. > > [1] http://openjdk.java.net/census#jdk9 > [2] http://openjdk.java.net/projects#committer-vote > > -- > Best regards, Sergey. > From Abhi.Saha at Oracle.Com Mon Jun 2 14:25:09 2014 From: Abhi.Saha at Oracle.Com (Abhijit Saha) Date: Mon, 02 Jun 2014 07:25:09 -0700 Subject: CFV: New jdk9 Committer: Pete Brunet In-Reply-To: <538B252C.4030909@oracle.com> References: <538B252C.4030909@oracle.com> Message-ID: <538C8945.2070106@Oracle.Com> Vote : Yes. On 6/1/2014 6:05 AM, Sergey Bylokhov wrote: > I hereby nominate Pete Brunet (OpenJDK user name: ptbrunet) to JDK9 > Committer. > > Pete is currently a JDK9 Author and a member of Accessibility team at > Oracle. > > Here is the list of fixes: > http://hg.openjdk.java.net/jdk9/client/jdk/log?revcount=300&rev=peter.brunet%40oracle.com > > http://hg.openjdk.java.net/jdk9/client/jdk/search/?rev=ptbrunet&revcount=100 > > > Votes are due by June 15, 2014. > > Only current JDK9 Committers [1] are eligible to vote on this nomination. > > For Lazy Consensus voting instructions, see [2]. > > [1] http://openjdk.java.net/census#jdk9 > [2] http://openjdk.java.net/projects#committer-vote > -- Lead, Java SE Updates Java Platform Group Oracle Corporation. (408)276-7564 From eric.mccorkle at oracle.com Mon Jun 2 15:04:44 2014 From: eric.mccorkle at oracle.com (Eric McCorkle) Date: Mon, 02 Jun 2014 11:04:44 -0400 Subject: New jdk9 Committer: Paul Govereau Message-ID: <538C928C.9070706@oracle.com> Voting for Paul Govereau is now closed. Yes: 20 Veto: 0 Abstain: 0 According to the Bylaws definition of Three-Vote Consensus, this is sufficient to approve the nomination. Eric McCorkle From sergey.malenkov at oracle.com Mon Jun 2 15:55:20 2014 From: sergey.malenkov at oracle.com (sergey malenkov) Date: Mon, 02 Jun 2014 19:55:20 +0400 Subject: CFV: New jdk9 Committer: Pete Brunet In-Reply-To: <538B252C.4030909@oracle.com> References: <538B252C.4030909@oracle.com> Message-ID: <538C9E68.7090500@oracle.com> Vote: YES On 01.06.2014 17:05, Sergey Bylokhov wrote: > I hereby nominate Pete Brunet (OpenJDK user name: ptbrunet) to JDK9 > Committer. > > Pete is currently a JDK9 Author and a member of Accessibility team at > Oracle. > > Here is the list of fixes: > http://hg.openjdk.java.net/jdk9/client/jdk/log?revcount=300&rev=peter.brunet%40oracle.com > > http://hg.openjdk.java.net/jdk9/client/jdk/search/?rev=ptbrunet&revcount=100 > > > Votes are due by June 15, 2014. > > Only current JDK9 Committers [1] are eligible to vote on this nomination. > > For Lazy Consensus voting instructions, see [2]. > > [1] http://openjdk.java.net/census#jdk9 > [2] http://openjdk.java.net/projects#committer-vote > From mike.duigou at oracle.com Mon Jun 2 16:30:25 2014 From: mike.duigou at oracle.com (Mike Duigou) Date: Mon, 2 Jun 2014 09:30:25 -0700 Subject: CFV: New jdk9 Committer: Pete Brunet In-Reply-To: <538B252C.4030909@oracle.com> References: <538B252C.4030909@oracle.com> Message-ID: <5D774256-EFB1-4B6C-9A4E-8A1B3880A92A@oracle.com> Vote: YES On Jun 1 2014, at 06:05 , Sergey Bylokhov wrote: > I hereby nominate Pete Brunet (OpenJDK user name: ptbrunet) to JDK9 Committer. > > Pete is currently a JDK9 Author and a member of Accessibility team at Oracle. > > Here is the list of fixes: > http://hg.openjdk.java.net/jdk9/client/jdk/log?revcount=300&rev=peter.brunet%40oracle.com > http://hg.openjdk.java.net/jdk9/client/jdk/search/?rev=ptbrunet&revcount=100 > > Votes are due by June 15, 2014. > > Only current JDK9 Committers [1] are eligible to vote on this nomination. > > For Lazy Consensus voting instructions, see [2]. > > [1] http://openjdk.java.net/census#jdk9 > [2] http://openjdk.java.net/projects#committer-vote > > -- > Best regards, Sergey. > From jia-hong.chen at oracle.com Mon Jun 2 18:52:03 2014 From: jia-hong.chen at oracle.com (Johnny Chen) Date: Mon, 2 Jun 2014 11:52:03 -0700 Subject: CFV: New jdk9 Committer: Pete Brunet In-Reply-To: References: <538B252C.4030909@oracle.com> Message-ID: Vote: YES. Thanks, Johnny Chen From anthony.petrov at oracle.com Tue Jun 3 11:30:05 2014 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 03 Jun 2014 15:30:05 +0400 Subject: Result: New jdk9 Committer: David DeHaven Message-ID: <538DB1BD.2010508@oracle.com> Voting for David DeHaven [1] is now closed. Yes: 22 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. [1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2014-May/000728.html -- best regards, Anthony From alejandro.murillo at oracle.com Tue Jun 3 19:15:18 2014 From: alejandro.murillo at oracle.com (Alejandro E Murillo) Date: Tue, 03 Jun 2014 13:15:18 -0600 Subject: jdk9-dev: HotSpot Message-ID: <538E1EC6.4030505@oracle.com> jdk9-hs-2014-05-30 has been integrated into jdk9-dev. http://hg.openjdk.java.net/jdk9/dev/rev/cf22a728521f http://hg.openjdk.java.net/jdk9/dev/corba/rev/422ef9d29d84 http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/4a0965f52d4d http://hg.openjdk.java.net/jdk9/dev/jaxp/rev/a1461221b05d http://hg.openjdk.java.net/jdk9/dev/jaxws/rev/1e1a3b2215b7 http://hg.openjdk.java.net/jdk9/dev/jdk/rev/b84aa47bbe0e http://hg.openjdk.java.net/jdk9/dev/langtools/rev/62e5d13e3383 http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/21f799bc2254 Component : VM Status : 0 major failures, 0 minor failures Date : 05/27/2014 at 22:00 MSK Tested By : VM SQE &dmitry.fazunenko at oracle.com Cost(total man-days): 0 Workspace : 2014-05-30-205120.amurillo.jdk9-hs-2014-05-30-jdk9-dev-control Bundles : 2014-05-30-205120.amurillo.jdk9-hs-2014-05-30-jdk9-dev-control Platforms : Others Tests :/net/sqenfs-1.sfbay/export1/comp/vm/testbase/ Log :http://surl.us.oracle.com/pit_jdk9_b15_summary Browsers : NA Patches : NA Number of Tests Executed: 398248 passed tests, 4928 failed tests (797 new failures) Bug verification status: ====================================== Tested, Pass: Tested, Pass (partial fixes): Tested, Fail: Untested bug fixes: Setup is not available: Bugs in PIT build: Number of PIT requested: 1 Integration target J2SE build number: Issues and Notes: There was no detailed analysis for this PIT. I look through the failures quickly. No showstoppers have been detected Go for integration -- Alejandro From lana.steuck at oracle.com Wed Jun 4 17:38:04 2014 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 4 Jun 2014 10:38:04 -0700 (PDT) Subject: jdk9-b16: dev Message-ID: <201406041738.s54Hc44g014162@jano-app.us.oracle.com> http://hg.openjdk.java.net/jdk9/jdk9/rev/cf22a728521f http://hg.openjdk.java.net/jdk9/jdk9/nashorn/rev/fed8c83dfba4 http://hg.openjdk.java.net/jdk9/jdk9/langtools/rev/7d67ebd3e35c http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/ab7d2c565b0d http://hg.openjdk.java.net/jdk9/jdk9/jaxws/rev/1e1a3b2215b7 http://hg.openjdk.java.net/jdk9/jdk9/jaxp/rev/a1461221b05d http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/b14e7c0b7d3e http://hg.openjdk.java.net/jdk9/jdk9/corba/rev/422ef9d29d84 --- All the fixes will be tested during promotion (no PIT testing at this point): List of all fixes: =================== JDK-8024832 core-libs (so) ServerSocketChannel.socket().accept() throws IllegalBlockingModeException if not bound JDK-8043916 core-libs Fix fallthrough lint warnings in java/lang/UNIXProcess.java JDK-8044415 core-libs ant makefile should have a target to generate javadoc only for jdk.nashorn.api and sub-packages JDK-8042370 core-libs closed/java/net/DatagramPacket/CheckInetAddress.java failed intermittently with Teredo Pseudo-Interface JDK-8035186 core-libs j2se_jdk/jdk/test/java/lang/invoke/lambda/LogGeneratedClassesTest.java - assertion error JDK-8043953 core-svc Add closed/sun/management/snmp/generic/GenericTest.sh to problemlist JDK-8044418 core-svc Add com/sun/jdi/JdbReadTwiceTest.sh to ProblemList.txt JDK-8040290 other-libs Update Java DB in JDK 9 to 10.10.2.0 . JDK-7047033 security-libs (smartcardio) Card.disconnect(boolean reset) does not reset when reset is true JDK-8039319 security-libs (smartcardio) Card.transmitControlCommand() does not work on Mac OS X JDK-8043720 security-libs (smartcardio) Native memory should be handled more accurately JDK-8044027 security-libs Remove unused XML Signature schema and dtd files from source JDK-8044038 security-libs Security tests fail on 32 bit linux platform JDK-8044342 security-libs build failure on Windows noticed with recent smartcardio fix. JDK-8036779 security-libs sun.security.krb5.KdcComm interprets kdc_timeout as msec instead of sec JDK-8031967 tools For some sources compiler compiles for ever JDK-8036709 tools Java 7 jarsigner displays warning about cert policy tree JDK-8037934 tools Javac generates invalid signatures for local types JDK-8037937 tools javac: AssertionError during LVT generation, wrong variable ranges JDK-8043592 xml The basic XML parser based on UKit fails to read XML files encoded in UTF-16BE or LE From henry.jen at oracle.com Wed Jun 4 17:52:08 2014 From: henry.jen at oracle.com (Henry Jen) Date: Wed, 04 Jun 2014 10:52:08 -0700 Subject: RFR: 8044740: Convert all JDK versions used in @since tag to 1.n[.n] in jdk repo In-Reply-To: <538E74B8.20603@oracle.com> References: <538E74B8.20603@oracle.com> Message-ID: <538F5CC8.3050702@oracle.com> Thanks for all reviewing and feedbacks on core-libs-dev[1], I tried to respond to feedbacks with this email and send off to other mailing lists. I am wondering if jdk9-dev is the appropriate list for such a trivious but broad change, so that we can have one instead of many lists, and we still probably miss another. Lets follow up this thread on jdk9-dev. Regarding to whether we should keep JDK, the later convention is 1.#, and as David pointed out the document also list @since that way, I think we should settle on that. For other standards such as SAX or JCE, I propose to convert them to the version of JDK those APIs are included. To retain that information, we can introduce a custom tag, perhaps @standard or @conformingTo? @conformingTo [, ]* For example, @conformingTo SAX 2.0. Repo wise, I think it's best if I can commit to jdk9/dev as a single commit instead of scattering to dev and client. But I can cope if this is absolutely necessary. Some changes to implementation classes, as I mentioned, only when it is straightforward. Essentially, I did a s/(@since *)JDK(.*)/\1\2 against all files. Some changes not obvious are simply remove tailing space, a (positive) side effect of the tools I use so I kept them. Cheers, Henry [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-June/027113.html On 06/03/2014 06:22 PM, Henry Jen wrote: > Hi, > > In an effort to determine APIs availability in a given version, it > became obvious that a consistent way to express @since tag would be > beneficial. > > So started with the most obvious ones, where we have various expression > for JDK version, this webrev make sure we use @since 1.n[.n] for JDK > versions. > > The main focus is on public APIs, private ones are taken care if it is > straightforward, otherwise, we try to keep the information. > > Some public APIs are using @since format, > they are also preserved for now, but I think it worth discussion whether > we want to change to the version as included in J2SE. > > There are APIs without @since information, separate webrevs will be > coming to complete those information. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8044740 > The webrev can be found at > http://cr.openjdk.java.net/~henryjen/jdk9/8044740/0/webrev > > but it's probably easier just look into the raw diff, > http://cr.openjdk.java.net/~henryjen/jdk9/8044740/0/webrev/jdk.changeset > > Cheers, > Henry From Sergey.Bylokhov at oracle.com Thu Jun 5 10:57:36 2014 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 05 Jun 2014 14:57:36 +0400 Subject: Result: New JDK 9 Committer: Alexander Zvegintsev Message-ID: <53904D20.1080407@oracle.com> Voting for Alexander Zvegintsev [1] is now closed. Yes: 11 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. [1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2014-May/000758.html -- Best regards, Sergey. From tim.bell at oracle.com Thu Jun 5 21:46:18 2014 From: tim.bell at oracle.com (Tim Bell) Date: Thu, 05 Jun 2014 21:46:18 +0000 Subject: Coming soon: JDK 9 Platform/Compiler upgrades at Oracle Message-ID: <5390E52A.10308@oracle.com> All- For JDK 9 we will upgrade the build platforms and compilers used at Oracle to build the JDK. In this cycle, our target combinations are: - Linux - Oracle Linux 6.4 64-bit / GCC 4.8.2 - Mac OS X - 10.9.2 (Mavericks) 64-bit / XCode 5.1.1 / clang - Solaris X86 - 11.1 / Oracle Solaris Studio 12.3 - Solaris SPARC - 11.1 / Oracle Solaris Studio 12.3 - Windows - Windows Server 2012 R2 64-bit / Microsoft Visual Studio 2013 For Linux and Windows, the 64-bit platform will also build 32-bit binaries. The Mac OS X and Solaris builds are already 64-bit only. Status of the project: At this point, both the Solaris and Linux platforms build using the new platforms and tools. They also passed an initial round of testing. Performance testing is still in progress. For Windows and Mac OS X, we are working on a few stopper bugs. We will need to integrate a set of fixes as part of doing the compiler upgrades in order for us to be able to build the JDK using the new compilers. Upgrades are currently planned for Linux and Solaris platforms next week (June 9). A JDK 9 build will be promoted containing only these changes. Mac OS X and Windows will follow when the stopper bugs are fixed and we are ready. At this point, we are estimating the end of June. We will send an email to this list with confirmation of the dates for these two platforms once the blockers have been resolved. We will send an update to the list when we start the upgrade. It is important to keep as few things as possible moving during the special promotion cycle. We will work with the integrators to ensure no changes apart from those needed for the compiler upgrades are integrated into the master. We will notify you when the upgrade has been completed and will also let you know where to find the build that was done after the compiler upgrades. Feedback is welcome. Please send to jdk9-dev at openjdk.java.net Tim From fweimer at redhat.com Sat Jun 7 19:26:30 2014 From: fweimer at redhat.com (Florian Weimer) Date: Sat, 07 Jun 2014 21:26:30 +0200 Subject: Coming soon: JDK 9 Platform/Compiler upgrades at Oracle In-Reply-To: <5390E52A.10308@oracle.com> References: <5390E52A.10308@oracle.com> Message-ID: <53936766.60002@redhat.com> On 06/05/2014 11:46 PM, Tim Bell wrote: > - Linux - Oracle Linux 6.4 64-bit / GCC 4.8.2 Are you sure the GCC version is correct? -- Florian Weimer / Red Hat Product Security Team From erik.joelsson at oracle.com Mon Jun 9 08:37:50 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 09 Jun 2014 10:37:50 +0200 Subject: Coming soon: JDK 9 Platform/Compiler upgrades at Oracle In-Reply-To: <53936766.60002@redhat.com> References: <5390E52A.10308@oracle.com> <53936766.60002@redhat.com> Message-ID: <5395725E.8000502@oracle.com> On 2014-06-07 21:26, Florian Weimer wrote: > On 06/05/2014 11:46 PM, Tim Bell wrote: > >> - Linux - Oracle Linux 6.4 64-bit / GCC 4.8.2 > > Are you sure the GCC version is correct? > Yes, we are not using the GCC bundled with the Linux distribution, but have instead opted to create our own compiler package from source. The compiler packages are actually based on Oracle Linux 5 so that the built JDK bits will be compatible with older Linux versions without forcing us to run the builds on older OS versions. The scripts used to generate these packages can be found in make/devkit/ in the root repo. /Erik From doug.simon at oracle.com Mon Jun 9 09:06:01 2014 From: doug.simon at oracle.com (Doug Simon) Date: Mon, 9 Jun 2014 11:06:01 +0200 Subject: Coming soon: JDK 9 Platform/Compiler upgrades at Oracle In-Reply-To: <5395725E.8000502@oracle.com> References: <5390E52A.10308@oracle.com> <53936766.60002@redhat.com> <5395725E.8000502@oracle.com> Message-ID: <53E6A5DC-621B-4CA4-B043-8C92505A9CF3@oracle.com> On Jun 9, 2014, at 10:37 AM, Erik Joelsson wrote: > > On 2014-06-07 21:26, Florian Weimer wrote: >> On 06/05/2014 11:46 PM, Tim Bell wrote: >> >>> - Linux - Oracle Linux 6.4 64-bit / GCC 4.8.2 >> >> Are you sure the GCC version is correct? >> > Yes, we are not using the GCC bundled with the Linux distribution, but have instead opted to create our own compiler package from source. The compiler packages are actually based on Oracle Linux 5 so that the built JDK bits will be compatible with older Linux versions without forcing us to run the builds on older OS versions. The scripts used to generate these packages can be found in make/devkit/ in the root repo. An alternative approach to this that we experimented with while working out how to build GraalVM images[1] that support older Linux versions was to use Docker[2]. It?s fairly straight forward and avoided the need for a completely separate VM in our case (or a from source GCC toolchain). -Doug [1] http://lafo.ssw.uni-linz.ac.at/builds/ [2] http://www.docker.com From mark.reinhold at oracle.com Mon Jun 9 15:14:42 2014 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Mon, 09 Jun 2014 08:14:42 -0700 Subject: RFR: 8044740: Convert all JDK versions used in @since tag to 1.n[.n] in jdk repo In-Reply-To: <538F5CC8.3050702@oracle.com> References: <538E74B8.20603@oracle.com>,<538F5CC8.3050702@oracle.com> Message-ID: <20140609081442.401946@eggemoggin.niobe.net> Henry -- Thanks for taking on this huge cleanup task! A couple of comments below. 2014/6/4 3:52 -0700, henry.jen at oracle.com: > ... > > Regarding to whether we should keep JDK, the later convention is 1.#, > and as David pointed out the document also list @since that way, I think > we should settle on that. I agree. A "JDK" prefix on every version number would be redundant. > For other standards such as SAX or JCE, I propose to convert them to the > version of JDK those APIs are included. To retain that information, we > can introduce a custom tag, perhaps @standard or @conformingTo? These secondary version numbers aren't always for standards as such, and in some cases they no longer have any real meaning. JCE, e.g., was a standlone technology which was folded into the JDK many releases ago and hasn't really had its own version number since. So to do this right you'd need to figure out what's a "standard" and what's not, which could take a fair bit of time, and it's not worth introducing new custom tags if we aren't going to do it right. I suggest you just retain the secondary version numbers and list them after the primary, e.g., * @since 1.6, SAX 2.0 > ... > > Some changes not obvious are simply remove tailing space, a (positive) > side effect of the tools I use so I kept them. I suggest you limit your patch only to change the @since tags. That will make it easier to review and easier to comprehend later on. The whitespace cleanup can be done separately. - Mark From henry.jen at oracle.com Mon Jun 9 18:55:12 2014 From: henry.jen at oracle.com (Henry Jen) Date: Mon, 09 Jun 2014 11:55:12 -0700 Subject: [UPDATED] RFR: 8044740: Convert all JDK versions used in @since tag to 1.n[.n] in jdk repo In-Reply-To: <20140609081442.401946@eggemoggin.niobe.net> References: <538E74B8.20603@oracle.com>, <538F5CC8.3050702@oracle.com> <20140609081442.401946@eggemoggin.niobe.net> Message-ID: <53960310.5050305@oracle.com> On 06/09/2014 08:14 AM, mark.reinhold at oracle.com wrote: > Henry -- Thanks for taking on this huge cleanup task! A couple of > comments below. > > 2014/6/4 3:52 -0700, henry.jen at oracle.com: >> ... >> >> Regarding to whether we should keep JDK, the later convention is 1.#, >> and as David pointed out the document also list @since that way, I think >> we should settle on that. > > I agree. A "JDK" prefix on every version number would be redundant. > Consider settled, thanks. >> For other standards such as SAX or JCE, I propose to convert them to the >> version of JDK those APIs are included. To retain that information, we >> can introduce a custom tag, perhaps @standard or @conformingTo? > > These secondary version numbers aren't always for standards as such, and > in some cases they no longer have any real meaning. JCE, e.g., was a > standlone technology which was folded into the JDK many releases ago and > hasn't really had its own version number since. So to do this right > you'd need to figure out what's a "standard" and what's not, which could > take a fair bit of time, and it's not worth introducing new custom tags > if we aren't going to do it right. > > I suggest you just retain the secondary version numbers and list them > after the primary, e.g., > > * @since 1.6, SAX 2.0 This webrev doesn't involve any changes on this proposal, just wants to start the discussion to figure what we should do. I think as long as the first is the JDK version, and convention is established, i.e, developer knows how to read it, this is fine. I am not sure if that extra information is worth to preserve or not, custom tag allows we retain the information in code, but not disclose them in javadoc until we are ready. There are a couple tags I found in existing javadoc seems relevant, like @spec and @revised. > >> ... >> >> Some changes not obvious are simply remove tailing space, a (positive) >> side effect of the tools I use so I kept them. > > I suggest you limit your patch only to change the @since tags. That > will make it easier to review and easier to comprehend later on. The > whitespace cleanup can be done separately. > I strip out those changes, so the updated webrev is essentially normalize JDK version format. Since this is just change format, not actually change any version values, I think current review received is sufficient. I will commit this to jdk9/dev 12:00PM 6/10 PDT with current reviewers unless explicit veto was received by then. Cheers, Henry From martinrb at google.com Mon Jun 9 22:27:15 2014 From: martinrb at google.com (Martin Buchholz) Date: Mon, 9 Jun 2014 15:27:15 -0700 Subject: Coming soon: JDK 9 Platform/Compiler upgrades at Oracle In-Reply-To: <5395725E.8000502@oracle.com> References: <5390E52A.10308@oracle.com> <53936766.60002@redhat.com> <5395725E.8000502@oracle.com> Message-ID: AFAIK there is no way to build with a newer compiler and remain compatible with older runtimes. Are you actually using gcc 4.8 built in some magic backward-compatible way or are you using an older gcc? If you have magic spells, please share. On Mon, Jun 9, 2014 at 1:37 AM, Erik Joelsson wrote: > > On 2014-06-07 21:26, Florian Weimer wrote: > >> On 06/05/2014 11:46 PM, Tim Bell wrote: >> >> - Linux - Oracle Linux 6.4 64-bit / GCC 4.8.2 >>> >> >> Are you sure the GCC version is correct? >> >> Yes, we are not using the GCC bundled with the Linux distribution, but > have instead opted to create our own compiler package from source. The > compiler packages are actually based on Oracle Linux 5 so that the built > JDK bits will be compatible with older Linux versions without forcing us to > run the builds on older OS versions. The scripts used to generate these > packages can be found in make/devkit/ in the root repo. > > /Erik > From david.holmes at oracle.com Tue Jun 10 06:38:31 2014 From: david.holmes at oracle.com (David Holmes) Date: Tue, 10 Jun 2014 16:38:31 +1000 Subject: Coming soon: JDK 9 Platform/Compiler upgrades at Oracle In-Reply-To: References: <5390E52A.10308@oracle.com> <53936766.60002@redhat.com> <5395725E.8000502@oracle.com> Message-ID: <5396A7E7.9020201@oracle.com> On 10/06/2014 8:27 AM, Martin Buchholz wrote: > AFAIK there is no way to build with a newer compiler and remain compatible > with older runtimes. Wouldn't you just build the compiler on the oldest system you want to support? Isn't that effectively what the existing "old compilers" are? David > Are you actually using gcc 4.8 built in some magic backward-compatible way > or are you using an older gcc? > If you have magic spells, please share. > > > On Mon, Jun 9, 2014 at 1:37 AM, Erik Joelsson > wrote: > >> >> On 2014-06-07 21:26, Florian Weimer wrote: >> >>> On 06/05/2014 11:46 PM, Tim Bell wrote: >>> >>> - Linux - Oracle Linux 6.4 64-bit / GCC 4.8.2 >>>> >>> >>> Are you sure the GCC version is correct? >>> >>> Yes, we are not using the GCC bundled with the Linux distribution, but >> have instead opted to create our own compiler package from source. The >> compiler packages are actually based on Oracle Linux 5 so that the built >> JDK bits will be compatible with older Linux versions without forcing us to >> run the builds on older OS versions. The scripts used to generate these >> packages can be found in make/devkit/ in the root repo. >> >> /Erik >> From erik.joelsson at oracle.com Tue Jun 10 07:29:24 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 10 Jun 2014 09:29:24 +0200 Subject: Coming soon: JDK 9 Platform/Compiler upgrades at Oracle In-Reply-To: References: <5390E52A.10308@oracle.com> <53936766.60002@redhat.com> <5395725E.8000502@oracle.com> Message-ID: <5396B3D4.3050008@oracle.com> On 2014-06-10 00:27, Martin Buchholz wrote: > AFAIK there is no way to build with a newer compiler and remain > compatible with older runtimes. > > Are you actually using gcc 4.8 built in some magic backward-compatible > way or are you using an older gcc? > If you have magic spells, please share. > It depends on what you mean by "runtime". It's true that the version of libstdc++ a binary requires depends only on the version of GCC used to compile it. When building OracleJDK, Hotspot is already statically linking libstdc++ to avoid these kinds of problems. For glibc, it's like David Holmes says, we only provide an old glibc so the compiler and linker accepts it. No magic unfortunately. /Erik > > On Mon, Jun 9, 2014 at 1:37 AM, Erik Joelsson > > wrote: > > > On 2014-06-07 21:26, Florian Weimer wrote: > > On 06/05/2014 11:46 PM, Tim Bell wrote: > > - Linux - Oracle Linux 6.4 64-bit / GCC 4.8.2 > > > Are you sure the GCC version is correct? > > Yes, we are not using the GCC bundled with the Linux distribution, > but have instead opted to create our own compiler package from > source. The compiler packages are actually based on Oracle Linux 5 > so that the built JDK bits will be compatible with older Linux > versions without forcing us to run the builds on older OS > versions. The scripts used to generate these packages can be found > in make/devkit/ in the root repo. > > /Erik > > From martinrb at google.com Tue Jun 10 16:33:59 2014 From: martinrb at google.com (Martin Buchholz) Date: Tue, 10 Jun 2014 09:33:59 -0700 Subject: Coming soon: JDK 9 Platform/Compiler upgrades at Oracle In-Reply-To: <5396A7E7.9020201@oracle.com> References: <5390E52A.10308@oracle.com> <53936766.60002@redhat.com> <5395725E.8000502@oracle.com> <5396A7E7.9020201@oracle.com> Message-ID: On Mon, Jun 9, 2014 at 11:38 PM, David Holmes wrote: > On 10/06/2014 8:27 AM, Martin Buchholz wrote: > >> AFAIK there is no way to build with a newer compiler and remain compatible >> with older runtimes. >> > > Wouldn't you just build the compiler on the oldest system you want to > support? Isn't that effectively what the existing "old compilers" are? > > I don't think the way the compiler itself is built makes much difference, except as to whether the compiler itself can be run. The compilation environment includes the compiler itself, the header files and (static and shared) libraries, all of which can create version skew incompatibilities. Added complications come from the compiler coming with some "system" libraries, libstdc++ and libgcc_s. From martinrb at google.com Tue Jun 10 16:34:08 2014 From: martinrb at google.com (Martin Buchholz) Date: Tue, 10 Jun 2014 09:34:08 -0700 Subject: Coming soon: JDK 9 Platform/Compiler upgrades at Oracle In-Reply-To: <5396B3D4.3050008@oracle.com> References: <5390E52A.10308@oracle.com> <53936766.60002@redhat.com> <5395725E.8000502@oracle.com> <5396B3D4.3050008@oracle.com> Message-ID: On Tue, Jun 10, 2014 at 12:29 AM, Erik Joelsson wrote: > > On 2014-06-10 00:27, Martin Buchholz wrote: > > AFAIK there is no way to build with a newer compiler and remain compatible > with older runtimes. > > Are you actually using gcc 4.8 built in some magic backward-compatible way > or are you using an older gcc? > If you have magic spells, please share. > > It depends on what you mean by "runtime". It's true that the version of > libstdc++ a binary requires depends only on the version of GCC used to > compile it. When building OracleJDK, Hotspot is already statically linking > libstdc++ to avoid these kinds of problems. For glibc, it's like David > Holmes says, we only provide an old glibc so the compiler and linker > accepts it. No magic unfortunately. > The greatest compatibility comes from old versions of all aspects of the compilation environment. It's safest to actually build on an old OS, else it's easy for things in /usr/include and /usr/lib to creep into the build process (although --sysroot helps - I assume that's what you're using to point to an old glibc and other system libs?). From fweimer at redhat.com Tue Jun 10 16:41:56 2014 From: fweimer at redhat.com (Florian Weimer) Date: Tue, 10 Jun 2014 18:41:56 +0200 Subject: Coming soon: JDK 9 Platform/Compiler upgrades at Oracle In-Reply-To: References: <5390E52A.10308@oracle.com> <53936766.60002@redhat.com> <5395725E.8000502@oracle.com> <5396B3D4.3050008@oracle.com> Message-ID: <53973554.9070709@redhat.com> On 06/10/2014 06:34 PM, Martin Buchholz wrote: > The greatest compatibility comes from old versions of all aspects of the > compilation environment. Agreed, it's perfectly possible that even binutils results in backwards compatibility concerns. The downside is that it precludes the use of newer language features, but I'm not sure if that matters for Hotspot because even if all the official baseline compilers support a reasonable subset of C++11, OpenJDK as a whole is still expected to build with older compilers, right? -- Florian Weimer / Red Hat Product Security Team From alejandro.murillo at oracle.com Tue Jun 10 19:25:54 2014 From: alejandro.murillo at oracle.com (Alejandro E Murillo) Date: Tue, 10 Jun 2014 13:25:54 -0600 Subject: jdk9-dev: HotSpot Message-ID: <53975BC2.1070302@oracle.com> jdk9-hs-2014-06-06 has been integrated into jdk9-dev. http://hg.openjdk.java.net/jdk9/dev/rev/24152ee0ee1a http://hg.openjdk.java.net/jdk9/dev/corba/rev/4c75c2ca7cf3 http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/41be7ddc01b2 http://hg.openjdk.java.net/jdk9/dev/jaxp/rev/6f923fcbe512 http://hg.openjdk.java.net/jdk9/dev/jaxws/rev/6b159e727dac http://hg.openjdk.java.net/jdk9/dev/jdk/rev/7b404a7be697 http://hg.openjdk.java.net/jdk9/dev/langtools/rev/f7be68b3bd2e http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/96f475bfb917 Component : VM Status : 0 major failures, 0 minor failures Date : 05/27/2014 at 22:00 MSK Tested By : VM SQE &dmitry.fazunenko at oracle.com Cost(total man-days): 0 Workspace : 2014-06-06-172345.amurillo.jdk9-hs-2014-06-06-jdk9-dev-control Bundles : 2014-06-06-172345.amurillo.jdk9-hs-2014-06-06-jdk9-dev-control Platforms : Others Tests : Log : Browsers : NA Patches : NA Number of Tests Executed: 388166 passed tests, 2963 failed tests (488 new failures) Bug verification status: ====================================== Tested, Pass: Tested, Pass (partial fixes): Tested, Fail: Untested bug fixes: Setup is not available: Bugs in PIT build: Number of PIT requested: 1 Integration target J2SE build number: Issues and Notes: There was no detailed analysis for this PIT. I look through the failures quickly. The majority of failures are caused by configuration problems. There four crashes which will be analyzed. No showstoppers have been detected Go for integration -- Alejandro From erik.joelsson at oracle.com Wed Jun 11 07:21:31 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 11 Jun 2014 09:21:31 +0200 Subject: Coming soon: JDK 9 Platform/Compiler upgrades at Oracle In-Reply-To: References: <5390E52A.10308@oracle.com> <53936766.60002@redhat.com> <5395725E.8000502@oracle.com> <5396B3D4.3050008@oracle.com> Message-ID: <5398037B.2090004@oracle.com> On 2014-06-10 18:34, Martin Buchholz wrote: > > > > On Tue, Jun 10, 2014 at 12:29 AM, Erik Joelsson > > wrote: > > > On 2014-06-10 00:27, Martin Buchholz wrote: >> AFAIK there is no way to build with a newer compiler and remain >> compatible with older runtimes. >> >> Are you actually using gcc 4.8 built in some magic >> backward-compatible way or are you using an older gcc? >> If you have magic spells, please share. >> > It depends on what you mean by "runtime". It's true that the > version of libstdc++ a binary requires depends only on the version > of GCC used to compile it. When building OracleJDK, Hotspot is > already statically linking libstdc++ to avoid these kinds of > problems. For glibc, it's like David Holmes says, we only provide > an old glibc so the compiler and linker accepts it. No magic > unfortunately. > > > The greatest compatibility comes from old versions of all aspects of > the compilation environment. > It's safest to actually build on an old OS, else it's easy for things > in /usr/include and /usr/lib to creep into the build process (although > --sysroot helps - I assume that's what you're using to point to an old > glibc and other system libs?). I agree it's safer to build on the old OS. It does however also bring a cost for maintenance that we would like to avoid. Keeping Fedora 9 around for the lifetime of JDK 8 is not something we are looking forward to. Yes, we use sysroot so the compilation process is only using headers and linking to libraries from the old OS. As for other possible incompatibilities, for OracleJDK, we have a set of platforms that we officially support, and we test on them. If we discover issues we will certainly have to fix them. OpenJDK should still work with older compilers until a decision is made to use newer features from a newer compiler, but as with any open source project, it's the responsibility of the users of those older compilers to keep it working. /Erik From chris.hegarty at oracle.com Wed Jun 11 10:58:22 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 11 Jun 2014 11:58:22 +0100 Subject: CFV: New JDK 9 Committer: Pavel Rappo Message-ID: <5398364E.2090409@oracle.com> I hereby nominate Pavel Rappo (prappo) to JDK 9 Committer. Pavel is a member of the Core Libraries team at Oracle. Most recently, he has been fixing issues in the Networking and NIO area. His JDK 9 contributions, to date, can be seen below. Votes are due by 25th June 2014 23:59 GMT Only current JDK 9 Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [2]. -Chris.. [1] http://openjdk.java.net/census [2] http://openjdk.java.net/projects/#committer-vote http://hg.openjdk.java.net/jdk9/dev/jdk/rev/b39e23ebc008 http://hg.openjdk.java.net/jdk9/dev/jdk/rev/eb6f07ec4509 http://hg.openjdk.java.net/jdk9/dev/jdk/rev/cda85444cad2 http://hg.openjdk.java.net/jdk9/dev/jdk/rev/4aa94c6a7257 http://hg.openjdk.java.net/jdk9/dev/jdk/rev/8cef08d9eacf http://hg.openjdk.java.net/jdk9/dev/jdk/rev/db75bd98d8fd http://hg.openjdk.java.net/jdk9/dev/jdk/rev/50a749f2cade http://hg.openjdk.java.net/jdk9/dev/jdk/rev/9a58ff1e27a6 http://hg.openjdk.java.net/jdk9/dev/jdk/rev/e6d4d07dee4c http://hg.openjdk.java.net/jdk9/dev/jdk/rev/acda974a4986 http://hg.openjdk.java.net/jdk9/dev/jdk/rev/476d56ab6377 From xuelei.fan at oracle.com Wed Jun 11 11:15:22 2014 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 11 Jun 2014 19:15:22 +0800 Subject: CFV: New JDK 9 Committer: Pavel Rappo In-Reply-To: <5398364E.2090409@oracle.com> References: <5398364E.2090409@oracle.com> Message-ID: <53983A4A.2020606@oracle.com> Vote: yes. Xuelei On 6/11/2014 6:58 PM, Chris Hegarty wrote: > I hereby nominate Pavel Rappo (prappo) to JDK 9 Committer. > > Pavel is a member of the Core Libraries team at Oracle. Most recently, > he has been fixing issues in the Networking and NIO area. His JDK 9 > contributions, to date, can be seen below. > > Votes are due by 25th June 2014 23:59 GMT > > Only current JDK 9 Committers [1] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Lazy Consensus voting instructions, see [2]. > > -Chris.. > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/b39e23ebc008 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/eb6f07ec4509 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/cda85444cad2 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/4aa94c6a7257 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/8cef08d9eacf > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/db75bd98d8fd > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/50a749f2cade > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/9a58ff1e27a6 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/e6d4d07dee4c > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/acda974a4986 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/476d56ab6377 From vincent.x.ryan at oracle.com Wed Jun 11 12:18:08 2014 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Wed, 11 Jun 2014 13:18:08 +0100 Subject: CFV: New JDK 9 Committer: Pavel Rappo In-Reply-To: <5398364E.2090409@oracle.com> References: <5398364E.2090409@oracle.com> Message-ID: <29A766F8-9FAA-48AD-933F-D0922F97E070@oracle.com> Vote: yes On 11 Jun 2014, at 11:58, Chris Hegarty wrote: > I hereby nominate Pavel Rappo (prappo) to JDK 9 Committer. > > Pavel is a member of the Core Libraries team at Oracle. Most recently, he has been fixing issues in the Networking and NIO area. His JDK 9 contributions, to date, can be seen below. > > Votes are due by 25th June 2014 23:59 GMT > > Only current JDK 9 Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > -Chris.. > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/b39e23ebc008 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/eb6f07ec4509 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/cda85444cad2 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/4aa94c6a7257 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/8cef08d9eacf > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/db75bd98d8fd > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/50a749f2cade > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/9a58ff1e27a6 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/e6d4d07dee4c > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/acda974a4986 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/476d56ab6377 From mike.duigou at oracle.com Wed Jun 11 13:19:18 2014 From: mike.duigou at oracle.com (Mike Duigou) Date: Wed, 11 Jun 2014 06:19:18 -0700 Subject: CFV: New JDK 9 Committer: Pavel Rappo In-Reply-To: <5398364E.2090409@oracle.com> References: <5398364E.2090409@oracle.com> Message-ID: <21543848-3CBE-422E-A61F-EB0C403660B7@oracle.com> Vote: YES On Jun 11 2014, at 03:58 , Chris Hegarty wrote: > I hereby nominate Pavel Rappo (prappo) to JDK 9 Committer. > > Pavel is a member of the Core Libraries team at Oracle. Most recently, he has been fixing issues in the Networking and NIO area. His JDK 9 contributions, to date, can be seen below. > > Votes are due by 25th June 2014 23:59 GMT > > Only current JDK 9 Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > -Chris.. > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/b39e23ebc008 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/eb6f07ec4509 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/cda85444cad2 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/4aa94c6a7257 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/8cef08d9eacf > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/db75bd98d8fd > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/50a749f2cade > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/9a58ff1e27a6 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/e6d4d07dee4c > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/acda974a4986 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/476d56ab6377 From Abhi.Saha at Oracle.Com Wed Jun 11 13:31:47 2014 From: Abhi.Saha at Oracle.Com (Abhijit Saha) Date: Wed, 11 Jun 2014 06:31:47 -0700 Subject: CFV: New JDK 9 Committer: Pavel Rappo In-Reply-To: <5398364E.2090409@oracle.com> References: <5398364E.2090409@oracle.com> Message-ID: <53985A43.7090402@Oracle.Com> Vote: yes On 6/11/2014 3:58 AM, Chris Hegarty wrote: > I hereby nominate Pavel Rappo (prappo) to JDK 9 Committer. > > Pavel is a member of the Core Libraries team at Oracle. Most recently, > he has been fixing issues in the Networking and NIO area. His JDK 9 > contributions, to date, can be seen below. > > Votes are due by 25th June 2014 23:59 GMT > > Only current JDK 9 Committers [1] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Lazy Consensus voting instructions, see [2]. > > -Chris.. > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/b39e23ebc008 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/eb6f07ec4509 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/cda85444cad2 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/4aa94c6a7257 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/8cef08d9eacf > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/db75bd98d8fd > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/50a749f2cade > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/9a58ff1e27a6 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/e6d4d07dee4c > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/acda974a4986 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/476d56ab6377 -- Lead, Java SE Updates Java Platform Group Oracle Corporation. (408)276-7564 From vicente.romero at oracle.com Wed Jun 11 13:55:11 2014 From: vicente.romero at oracle.com (Vicente-Arturo Romero-Zaldivar) Date: Wed, 11 Jun 2014 14:55:11 +0100 Subject: CFV: New JDK 9 Committer: Pavel Rappo In-Reply-To: <5398364E.2090409@oracle.com> References: <5398364E.2090409@oracle.com> Message-ID: <53985FBF.7010002@oracle.com> Vote: yes Vicente On 11/06/14 11:58, Chris Hegarty wrote: > I hereby nominate Pavel Rappo (prappo) to JDK 9 Committer. > > Pavel is a member of the Core Libraries team at Oracle. Most recently, > he has been fixing issues in the Networking and NIO area. His JDK 9 > contributions, to date, can be seen below. > > Votes are due by 25th June 2014 23:59 GMT > > Only current JDK 9 Committers [1] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Lazy Consensus voting instructions, see [2]. > > -Chris.. > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/b39e23ebc008 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/eb6f07ec4509 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/cda85444cad2 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/4aa94c6a7257 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/8cef08d9eacf > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/db75bd98d8fd > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/50a749f2cade > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/9a58ff1e27a6 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/e6d4d07dee4c > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/acda974a4986 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/476d56ab6377 From michael.x.mcmahon at oracle.com Wed Jun 11 14:38:39 2014 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Wed, 11 Jun 2014 15:38:39 +0100 Subject: CFV: New JDK 9 Committer: Pavel Rappo In-Reply-To: <5398364E.2090409@oracle.com> References: <5398364E.2090409@oracle.com> Message-ID: <539869EF.7030309@oracle.com> Vote: Yes On 11/06/14 11:58, Chris Hegarty wrote: > I hereby nominate Pavel Rappo (prappo) to JDK 9 Committer. > > Pavel is a member of the Core Libraries team at Oracle. Most recently, > he has been fixing issues in the Networking and NIO area. His JDK 9 > contributions, to date, can be seen below. > > Votes are due by 25th June 2014 23:59 GMT > > Only current JDK 9 Committers [1] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Lazy Consensus voting instructions, see [2]. > > -Chris.. > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/b39e23ebc008 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/eb6f07ec4509 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/cda85444cad2 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/4aa94c6a7257 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/8cef08d9eacf > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/db75bd98d8fd > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/50a749f2cade > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/9a58ff1e27a6 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/e6d4d07dee4c > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/acda974a4986 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/476d56ab6377 From sean.coffey at oracle.com Wed Jun 11 15:22:36 2014 From: sean.coffey at oracle.com (=?ISO-8859-1?Q?Se=E1n_Coffey?=) Date: Wed, 11 Jun 2014 16:22:36 +0100 Subject: CFV: New JDK 9 Committer: Pavel Rappo In-Reply-To: <5398364E.2090409@oracle.com> References: <5398364E.2090409@oracle.com> Message-ID: <5398743C.5080109@oracle.com> Vote: Yes regards, Sean. On 11/06/14 11:58, Chris Hegarty wrote: > I hereby nominate Pavel Rappo (prappo) to JDK 9 Committer. > > Pavel is a member of the Core Libraries team at Oracle. Most recently, > he has been fixing issues in the Networking and NIO area. His JDK 9 > contributions, to date, can be seen below. > > Votes are due by 25th June 2014 23:59 GMT > > Only current JDK 9 Committers [1] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Lazy Consensus voting instructions, see [2]. > > -Chris.. > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/b39e23ebc008 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/eb6f07ec4509 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/cda85444cad2 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/4aa94c6a7257 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/8cef08d9eacf > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/db75bd98d8fd > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/50a749f2cade > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/9a58ff1e27a6 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/e6d4d07dee4c > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/acda974a4986 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/476d56ab6377 From roger.riggs at oracle.com Wed Jun 11 15:27:11 2014 From: roger.riggs at oracle.com (roger riggs) Date: Wed, 11 Jun 2014 11:27:11 -0400 Subject: CFV: New JDK 9 Committer: Pavel Rappo In-Reply-To: <5398364E.2090409@oracle.com> References: <5398364E.2090409@oracle.com> Message-ID: <5398754F.4020204@oracle.com> Vote: yes On 6/11/2014 6:58 AM, Chris Hegarty wrote: > I hereby nominate Pavel Rappo (prappo) to JDK 9 Committer. From henry.jen at oracle.com Wed Jun 11 15:47:32 2014 From: henry.jen at oracle.com (Henry Jen) Date: Wed, 11 Jun 2014 08:47:32 -0700 Subject: CFV: New JDK 9 Committer: Pavel Rappo In-Reply-To: <5398364E.2090409@oracle.com> References: <5398364E.2090409@oracle.com> Message-ID: <53987A14.20200@oracle.com> Vote: Yes Cheers, Henry On 06/11/2014 03:58 AM, Chris Hegarty wrote: > I hereby nominate Pavel Rappo (prappo) to JDK 9 Committer. > > Pavel is a member of the Core Libraries team at Oracle. Most recently, > he has been fixing issues in the Networking and NIO area. His JDK 9 > contributions, to date, can be seen below. > > Votes are due by 25th June 2014 23:59 GMT > > Only current JDK 9 Committers [1] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Lazy Consensus voting instructions, see [2]. > > -Chris.. > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/b39e23ebc008 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/eb6f07ec4509 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/cda85444cad2 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/4aa94c6a7257 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/8cef08d9eacf > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/db75bd98d8fd > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/50a749f2cade > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/9a58ff1e27a6 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/e6d4d07dee4c > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/acda974a4986 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/476d56ab6377 From daniel.fuchs at oracle.com Wed Jun 11 16:20:05 2014 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 11 Jun 2014 18:20:05 +0200 Subject: CFV: New JDK 9 Committer: Pavel Rappo In-Reply-To: <5398364E.2090409@oracle.com> References: <5398364E.2090409@oracle.com> Message-ID: <539881B5.9010308@oracle.com> Vote: yes On 6/11/14 12:58 PM, Chris Hegarty wrote: > I hereby nominate Pavel Rappo (prappo) to JDK 9 Committer. > > Pavel is a member of the Core Libraries team at Oracle. Most recently, > he has been fixing issues in the Networking and NIO area. His JDK 9 > contributions, to date, can be seen below. > > Votes are due by 25th June 2014 23:59 GMT > > Only current JDK 9 Committers [1] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Lazy Consensus voting instructions, see [2]. > > -Chris.. > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/b39e23ebc008 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/eb6f07ec4509 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/cda85444cad2 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/4aa94c6a7257 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/8cef08d9eacf > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/db75bd98d8fd > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/50a749f2cade > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/9a58ff1e27a6 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/e6d4d07dee4c > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/acda974a4986 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/476d56ab6377 From brent.christian at oracle.com Wed Jun 11 18:04:04 2014 From: brent.christian at oracle.com (Brent Christian) Date: Wed, 11 Jun 2014 11:04:04 -0700 Subject: CFV: New JDK 9 Committer: Pavel Rappo In-Reply-To: <5398364E.2090409@oracle.com> References: <5398364E.2090409@oracle.com> Message-ID: <53989A14.9060202@oracle.com> Vote: Yes On 6/11/14 3:58 AM, Chris Hegarty wrote: > I hereby nominate Pavel Rappo (prappo) to JDK 9 Committer. From lana.steuck at oracle.com Wed Jun 11 18:32:59 2014 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 11 Jun 2014 11:32:59 -0700 (PDT) Subject: jdk9-b17: dev Message-ID: <201406111832.s5BIWxEb002512@jano-app.us.oracle.com> http://hg.openjdk.java.net/jdk9/jdk9/rev/24152ee0ee1a http://hg.openjdk.java.net/jdk9/jdk9/nashorn/rev/4a47b7cfecdf http://hg.openjdk.java.net/jdk9/jdk9/langtools/rev/b64f8d5b97fa http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/fd8e675f141b http://hg.openjdk.java.net/jdk9/jdk9/jaxws/rev/6b159e727dac http://hg.openjdk.java.net/jdk9/jdk9/jaxp/rev/6f923fcbe512 http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/14b656df31c2 http://hg.openjdk.java.net/jdk9/jdk9/corba/rev/4c75c2ca7cf3 --- All the fixes will be tested during promotion (no PIT testing at this point): List of all fixes: =================== JDK-8044469 client-libs Fix fallthrough lint warning in accessibility JDK-8043160 client-libs JDK 9 Build failure in accessbridge JDK-8040081 client-libs Tidy warnings cleanup for java.applet JDK-8032527 client-libs fix a couple doclint errors in java/awt/geom/Path2D JDK-8043611 core-libs test/script/basic/apply_to_call/apply_to_call_bench.js fails on staging repo with AssertionError JDK-8038396 core-libs 8037534 breaks richards Octane benchmark JDK-8038416 core-libs Access to undefined scoped variables deoptimized too much JDK-8037572 core-libs Add more test cases to check static types JDK-8039916 core-libs AnnotatedType.getType() of a Executable parameters may return wrong type JDK-8040089 core-libs Apply to call transform broke raytrace JDK-8040024 core-libs BranchOptimizer produces bad code for NaN FP comparison JDK-8044590 core-libs Broken links in jre.api.net.socketoptions JDK-8044725 core-libs Bug in zlib 1.2.5 prevents inflation of some gzipped files JDK-8037967 core-libs Build broken by proto depth patch JDK-8043633 core-libs Change -Dnashorn.time to a log option --time with different granularity levels. Also get rid of static state that survives over contexts JDK-8037086 core-libs Check that deoptimizing recompilations are correct JDK-8044461 core-libs Cleanup new Boolean and single character strings JDK-8043137 core-libs Collapse long sequences of NOP in Nashorn bytecode output JDK-8044534 core-libs Constant folding for unary + should produce int for boolean literals JDK-8044533 core-libs Deoptimizing negation produces wrong result for zero JDK-8043605 core-libs Enable history for empty property maps JDK-8044102 core-libs Ensure benchmark exclude list for octane benchmarks is only in one place, project.properties, and fix benchmark harness JDK-8044518 core-libs Ensure exceptions related to optimistic recompilation are not serializable JDK-8039044 core-libs Expand undefined intrinsic to handle all commutative combinations of undefined JDK-8040655 core-libs Fix RewriteException debug object return value JDK-8043133 core-libs Fix corner cases of JDK-8041995 JDK-8044858 core-libs Fix raw and unchecked lint warnings in socket direct protocol JDK-8043431 core-libs Fix yet another corner case of JDK-8041995 JDK-8044502 core-libs Get rid of global optimistic flag JDK-8038426 core-libs Get the DebugLoggers out of the process wide scope and into the global scope JDK-8043002 core-libs Improve performance of Nashorn equality operators JDK-8044012 core-libs Integrate the latest best known performance flags in ant octane jobs, make sure there is a single run that can be done with one ant command line to compare nashorn vs v8 JDK-8044206 core-libs LambdaMetafactory.altMetafactory javadoc refers to wrong method JDK-8037177 core-libs Make -Dnashorn.optimistic enabled by default JDK-8043608 core-libs Make equality tests inline better JDK-8038406 core-libs Make log events storable as introspectable objects in the Debug context JDK-8044171 core-libs Make optimistic exception handlers smaller JDK-8033105 core-libs Make sure Nashorn can run the zlib octane benchmark JDK-8035836 core-libs Make sure all array and typed array operations are optimistic and perform well JDK-8046014 core-libs MultiGlobalCompiledScript used to cache method handle and strict mode - not anymore JDK-8038413 core-libs NPE in unboxInteger JDK-8044154 core-libs Nashorn : all tests failed with java.security.AccessControlException JDK-8044520 core-libs Nashorn cannot execute node.js's express module JDK-8027043 core-libs Nashorn performance umbrella CR JDK-8044766 core-libs New jdk.net classes have @since 1.9 tags in 8u20 JDK-8036986 core-libs New tests need to be written for optimistic typing feature JDK-8043504 core-libs Octane test harness in Nashorn is missing an argument for print_always JDK-8044816 core-libs On-demand compiled top-level program doesn't need :createProgramFunction JDK-8035820 core-libs Optimistic recompilation JDK-8038398 core-libs OptimisticRecompilationTest fails on staging repo nashorn/jdk9/nashorn due to test framework JDK-8043632 core-libs Parallelize class installation JDK-8044727 core-libs Problem reading the contents of some zip files JDK-8043004 core-libs Reduce variability at JavaAdapter call sites JDK-8040102 core-libs Remove all references to Unsafe and defineAnonymousClass from the code JDK-8037866 core-libs Replace the Fun class in tests with lambdas JDK-8042118 core-libs Separate types from symbols JDK-8038945 core-libs Simplify undefined checks if undefined has not been scope overridden JDK-8044612 core-libs StringIndexOutOfBoundException in NativeRegExp.appendReplacement JDK-8038223 core-libs Symbol trace debug output takes time JDK-8041995 core-libs The entire property node value in an object creation process needs to be inspected for the failing program point JDK-8036127 core-libs The proto filter needs to be applied to the guard as well JDK-8044638 core-libs Tidy up Nashorn codebase for code standards JDK-8043235 core-libs Type-based optimizations interfere with continuation methods JDK-8039746 core-libs Unbox apply specialisations and turn them into calls JDK-8044803 core-libs Unnecessary restOf check in CodeGenerator.undefinedCheck JDK-8038799 core-libs Until all optimistic compilation is in place, unbox boxed objects on property setters to avoid unnecessarily exploding objects and causing megamorphisism JDK-8037534 core-libs Use scope types to determine optimistic types JDK-8043003 core-libs Use strongly referenced generic invokers JDK-8041434 core-libs Various synchronization issues in GlobalConstants creates non-deterministic errors in ant test262parallel JDK-8034206 core-libs Warmup regression: Warmup/Compile time: Streamline deoptimizing compilation pipeline JDK-8033334 core-libs We need to maintain a map of outside definitions for a RecompilableScriptFunctionData or fastScope won't work in the optimistic world (and this would enable fast non-conservative lazy compilation) JDK-8044695 core-libs __stack__ becomes visible in Error properties JDK-8041905 core-libs apply2call bug prevents avatar.js test suite from completing JDK-8042486 core-libs closed/tools/pack200/MemoryAllocatorTest.java fails on linux-32 JDK-8044750 core-libs megamorphic getter for scope objects does not call __noSuchProperty__ hook JDK-8041625 core-libs test/script/external/test262/test/suite/ch12/12.10/12.10-0-3.js is broken in optimistic JDK-8044633 core-svc Add closed/sun/usagetracker/UsageTracker.sh to ProblemList JDK-8027230 core-svc Overflow in java.lang.instrument.Instrumentation.getObjectSize() method JDK-8044495 core-svc Remove test demo/jvmti/mtrace/TraceJFrame.java JDK-8032901 core-svc WaitForMultipleObjects() return value not handled appropriately JDK-8043635 embedded Embedded test suite co-location: JDK_ARCH tests JDK-8043136 embedded NEED_TEST JDK-8000688 JDK-8032970 hotspot Add stack size check methods to WhiteBox API JDK-8044090 hotspot C1: Old value instead of new one is passed to post-barrier in UnsafeGetAndSetObject JDK-8038422 hotspot CDS test failed: assert((size % os::vm_allocation_granularity()) == 0) failed when limiting SharedMiscDataSize JDK-8043301 hotspot Duplicate definitions in vm/runtime/sharedRuntimeTrans.cpp versus math.h in VS2013 JDK-8043206 hotspot Fix signed vs. unsigned comparison warning in copy_sparc.hpp JDK-8043925 hotspot Fix typo in verifier.cpp JDK-8005873 hotspot JRuby test_respond_to.rb asserts with: MT-unsafe modification of inline cache JDK-8034935 hotspot JSR 292 support for PopFrame has a fragile coupling with DirectMethodHandle JDK-8031475 hotspot Missing oopmap in patching stubs JDK-8043638 hotspot Multiple compilation attempts break LogCompilation, lead to confusing PrintInlining output JDK-8038924 hotspot Test bit-instructions fails with unexpected exit value on sparc JDK-8040250 hotspot The test test/gc/parallelScavenge/TestDynShrinkHeap.java fails with OOME JDK-8042155 hotspot [TESTBUG] Tests for stack guard pages have to be cleaned up JDK-8043899 hotspot compiler/5091921/Test7005594.java fails if specified -Xmx is less than 1600m JDK-8042557 hotspot compiler/uncommontrap/TestSpecTrapClassUnloading.java fails with: GC triggered before VM initialization completed JDK-8043723 hotspot max_heap_for_compressed_oops() declared with size_t, but defined with uintx JDK-8042727 hotspot nsk/jdb/unwatch/unwatch001 crash in InstanceKlass::methods_do(void (*)(Method*)) JDK-8043917 infrastructure ALT_BUNDLE_DATE does not work in jdk8u and 9 build JDK-8039865 infrastructure Add fallthrough lint warning to build of jdk repository JDK-8044395 infrastructure JDK 9 platform and compiler upgrade failed on linux-i586 platform with deploy/make/plugin/plugin2/npjp2 error JDK-8044480 infrastructure JDK image target overwrites lib/server/libjsig.dylib symlink with a copy of lib/libjsig.dylib JDK-8044363 infrastructure Remove special build options for unpack200 executable JDK-8044733 infrastructure common/autoconf/configure script doesn't properly detect missing tools JDK-8044235 infrastructure src.zip should include all sources JDK-8043753 other-libs Drop javax.transaction from compact2 and compact3 JDK-8044477 other-libs Fix fallthrough lint warning in ASM JDK-8044046 other-libs [asm] refresh internal ASM version to v5.0.3 JDK-8044755 security-libs Add a test for algorithm constraints check in jarsigner JDK-8044771 security-libs PKIXValidator indent cleanup JDK-8041142 security-libs Re-enabling CBC_PAD PKCS11 mechanisms for Solaris JDK-8037742 security-libs Re-enabling PKCS11 HMAC mechanisms in Solaris JDK-8036841 security-libs Reuse no-perms AccessControlContext object when performing isAuthorized check JDK-8044487 tools Fix for 8042785 causes regression tests to fail with java.lang.VerifyError JDK-8044064 tools Group 1: create .out files for cast and capture negative tests in tools/javac dir JDK-8044072 tools Group 2: create .out files for OverrideChecks tests in tools/javac dir JDK-8043893 tools Inference doesn't report error on incompatible upper bounds JDK-8041713 tools Type inference of non-existent method references crashes the compiler JDK-8036006 tools [TESTBUG] sun/tools/native2ascii/NativeErrors.java fails: Process exit code was 0, but error was expected. JDK-8042785 tools javac, bridge methods are not getting the flags from the original method JDK-8044647 tools sun/tools/jrunscript/jrunscriptTest.sh start failing: Output of jrunscript -l nashorn differ from expected output JDK-8046067 tools test/tools/javac/api/6410643/T6410643.java is broken From serguei.spitsyn at oracle.com Wed Jun 11 22:19:17 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 11 Jun 2014 15:19:17 -0700 Subject: CFV: New JDK 9 Committer: Pavel Rappo In-Reply-To: <5398364E.2090409@oracle.com> References: <5398364E.2090409@oracle.com> Message-ID: <5398D5E5.6010805@oracle.com> Vote: yes On 6/11/14 3:58 AM, Chris Hegarty wrote: > I hereby nominate Pavel Rappo (prappo) to JDK 9 Committer. > > Pavel is a member of the Core Libraries team at Oracle. Most recently, > he has been fixing issues in the Networking and NIO area. His JDK 9 > contributions, to date, can be seen below. > > Votes are due by 25th June 2014 23:59 GMT > > Only current JDK 9 Committers [1] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Lazy Consensus voting instructions, see [2]. > > -Chris.. > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/b39e23ebc008 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/eb6f07ec4509 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/cda85444cad2 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/4aa94c6a7257 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/8cef08d9eacf > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/db75bd98d8fd > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/50a749f2cade > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/9a58ff1e27a6 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/e6d4d07dee4c > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/acda974a4986 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/476d56ab6377 From coleen.phillimore at oracle.com Thu Jun 12 04:05:51 2014 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 12 Jun 2014 00:05:51 -0400 Subject: CFV: New jdk9 Reviewer: Harold Seigel Message-ID: <5399271F.9060500@oracle.com> I hereby nominate Harold Seigel (hseigel) to jdk9 Reviewer. Harold is a member of the Hotspot Runtime group and is a Committer for the jdk8 and jdk9 projects. He has contributed 55 changesets so far, notably in the areas of bytecode verification and classfile verification, class data sharing, compressed oops and numerous bug fixes and cleanups. He has been a key contributor to the Hotspot side of the Lambda project and provided several bug fixes and code reviews to changes in default method resolution for jdk8. Votes are due by 12:00 AM ET, Thursday June 26, 2014. Only current jdk9 Reviewers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Three-Vote Consensus voting instructions, see [2]. Coleen Phillimore [1] http://openjdk.java.net/census [2] http://openjdk.java.net/projects/#reviewer-vote From vladimir.kozlov at oracle.com Thu Jun 12 04:25:51 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 11 Jun 2014 21:25:51 -0700 Subject: CFV: New jdk9 Reviewer: Harold Seigel In-Reply-To: <5399271F.9060500@oracle.com> References: <5399271F.9060500@oracle.com> Message-ID: <53992BCF.5050702@oracle.com> Vote: yes On 6/11/14 9:05 PM, Coleen Phillimore wrote: > > I hereby nominate Harold Seigel (hseigel) to jdk9 Reviewer. > > Harold is a member of the Hotspot Runtime group and is a Committer for the jdk8 and jdk9 projects. He has contributed > 55 changesets so far, notably in the areas of bytecode verification and classfile verification, class data sharing, > compressed oops and numerous bug fixes and cleanups. He has been a key contributor to the Hotspot side of the Lambda > project and provided several bug fixes and code reviews to changes in default method resolution for jdk8. > > Votes are due by 12:00 AM ET, Thursday June 26, 2014. > > Only current jdk9 Reviewers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to > this mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Coleen Phillimore > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > From yumin.qi at oracle.com Thu Jun 12 04:47:39 2014 From: yumin.qi at oracle.com (Yumin Qi) Date: Wed, 11 Jun 2014 21:47:39 -0700 Subject: CFV: New jdk9 Reviewer: Harold Seigel In-Reply-To: <5399271F.9060500@oracle.com> References: <5399271F.9060500@oracle.com> Message-ID: <539930EB.2050801@oracle.com> Vote: Yes On 6/11/2014 9:05 PM, Coleen Phillimore wrote: > > I hereby nominate Harold Seigel (hseigel) to jdk9 Reviewer. > > Harold is a member of the Hotspot Runtime group and is a Committer for > the jdk8 and jdk9 projects. He has contributed 55 changesets so far, > notably in the areas of bytecode verification and classfile > verification, class data sharing, compressed oops and numerous bug > fixes and cleanups. He has been a key contributor to the Hotspot > side of the Lambda project and provided several bug fixes and code > reviews to changes in default method resolution for jdk8. > > Votes are due by 12:00 AM ET, Thursday June 26, 2014. > > Only current jdk9 Reviewers [1] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this > mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Coleen Phillimore > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > From Abhi.Saha at Oracle.Com Thu Jun 12 05:00:18 2014 From: Abhi.Saha at Oracle.Com (Abhijit Saha) Date: Wed, 11 Jun 2014 22:00:18 -0700 Subject: CFV: New jdk9 Reviewer: Harold Seigel In-Reply-To: <5399271F.9060500@oracle.com> References: <5399271F.9060500@oracle.com> Message-ID: <539933E2.8000303@Oracle.Com> Vote: Yes On 6/11/2014 9:05 PM, Coleen Phillimore wrote: > > I hereby nominate Harold Seigel (hseigel) to jdk9 Reviewer. -- Lead, Java SE Updates Java Platform Group Oracle Corporation. (408)276-7564 From david.holmes at oracle.com Thu Jun 12 05:09:53 2014 From: david.holmes at oracle.com (David Holmes) Date: Thu, 12 Jun 2014 15:09:53 +1000 Subject: CFV: New jdk9 Reviewer: Harold Seigel In-Reply-To: <5399271F.9060500@oracle.com> References: <5399271F.9060500@oracle.com> Message-ID: <53993621.7040809@oracle.com> Folks, only JDK 9 Project _Reviewers_ can vote on this. David On 12/06/2014 2:05 PM, Coleen Phillimore wrote: > > I hereby nominate Harold Seigel (hseigel) to jdk9 Reviewer. > > Harold is a member of the Hotspot Runtime group and is a Committer for > the jdk8 and jdk9 projects. He has contributed 55 changesets so far, > notably in the areas of bytecode verification and classfile > verification, class data sharing, compressed oops and numerous bug fixes > and cleanups. He has been a key contributor to the Hotspot side of the > Lambda project and provided several bug fixes and code reviews to > changes in default method resolution for jdk8. > > Votes are due by 12:00 AM ET, Thursday June 26, 2014. > > Only current jdk9 Reviewers [1] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Three-Vote Consensus voting instructions, see [2]. > > Coleen Phillimore > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > From Alan.Bateman at oracle.com Thu Jun 12 05:30:05 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 12 Jun 2014 06:30:05 +0100 Subject: CFV: New jdk9 Reviewer: Harold Seigel In-Reply-To: <5399271F.9060500@oracle.com> References: <5399271F.9060500@oracle.com> Message-ID: <53993ADD.6030909@oracle.com> Vote: yes From martinrb at google.com Thu Jun 12 06:32:18 2014 From: martinrb at google.com (Martin Buchholz) Date: Wed, 11 Jun 2014 23:32:18 -0700 Subject: Coming soon: JDK 9 Platform/Compiler upgrades at Oracle In-Reply-To: <5398037B.2090004@oracle.com> References: <5390E52A.10308@oracle.com> <53936766.60002@redhat.com> <5395725E.8000502@oracle.com> <5396B3D4.3050008@oracle.com> <5398037B.2090004@oracle.com> Message-ID: Erik, At Google we struggle with the same kinds of issues and come up with similar solutions, using fixed libraries and headers to compile against and using --sysroot. On Wed, Jun 11, 2014 at 12:21 AM, Erik Joelsson wrote: > > On 2014-06-10 18:34, Martin Buchholz wrote: > > > > > On Tue, Jun 10, 2014 at 12:29 AM, Erik Joelsson > wrote: > >> >> On 2014-06-10 00:27, Martin Buchholz wrote: >> >> AFAIK there is no way to build with a newer compiler and remain >> compatible with older runtimes. >> >> Are you actually using gcc 4.8 built in some magic backward-compatible >> way or are you using an older gcc? >> If you have magic spells, please share. >> >> It depends on what you mean by "runtime". It's true that the version >> of libstdc++ a binary requires depends only on the version of GCC used to >> compile it. When building OracleJDK, Hotspot is already statically linking >> libstdc++ to avoid these kinds of problems. For glibc, it's like David >> Holmes says, we only provide an old glibc so the compiler and linker >> accepts it. No magic unfortunately. >> > > > The greatest compatibility comes from old versions of all aspects of the > compilation environment. > It's safest to actually build on an old OS, else it's easy for things in > /usr/include and /usr/lib to creep into the build process (although > --sysroot helps - I assume that's what you're using to point to an old > glibc and other system libs?). > > I agree it's safer to build on the old OS. It does however also bring a > cost for maintenance that we would like to avoid. Keeping Fedora 9 around > for the lifetime of JDK 8 is not something we are looking forward to. > > Yes, we use sysroot so the compilation process is only using headers and > linking to libraries from the old OS. > > As for other possible incompatibilities, for OracleJDK, we have a set of > platforms that we officially support, and we test on them. If we discover > issues we will certainly have to fix them. > > OpenJDK should still work with older compilers until a decision is made to > use newer features from a newer compiler, but as with any open source > project, it's the responsibility of the users of those older compilers to > keep it working. > > /Erik > From staffan.larsen at oracle.com Thu Jun 12 06:32:38 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 12 Jun 2014 08:32:38 +0200 Subject: CFV: New jdk9 Reviewer: Harold Seigel In-Reply-To: <5399271F.9060500@oracle.com> References: <5399271F.9060500@oracle.com> Message-ID: <073A338E-7525-426B-8106-59D234F09227@oracle.com> Vote: yes On 12 jun 2014, at 06:05, Coleen Phillimore wrote: > > I hereby nominate Harold Seigel (hseigel) to jdk9 Reviewer. > > Harold is a member of the Hotspot Runtime group and is a Committer for the jdk8 and jdk9 projects. He has contributed 55 changesets so far, notably in the areas of bytecode verification and classfile verification, class data sharing, compressed oops and numerous bug fixes and cleanups. He has been a key contributor to the Hotspot side of the Lambda project and provided several bug fixes and code reviews to changes in default method resolution for jdk8. > > Votes are due by 12:00 AM ET, Thursday June 26, 2014. > > Only current jdk9 Reviewers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Coleen Phillimore > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > From bengt.rutisson at oracle.com Thu Jun 12 06:15:13 2014 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Thu, 12 Jun 2014 08:15:13 +0200 Subject: CFV: New jdk9 Reviewer: Harold Seigel In-Reply-To: <5399271F.9060500@oracle.com> References: <5399271F.9060500@oracle.com> Message-ID: <53994571.3010701@oracle.com> Vote: yes Bengt On 6/12/14 6:05 AM, Coleen Phillimore wrote: > > I hereby nominate Harold Seigel (hseigel) to jdk9 Reviewer. > > Harold is a member of the Hotspot Runtime group and is a Committer for > the jdk8 and jdk9 projects. He has contributed 55 changesets so far, > notably in the areas of bytecode verification and classfile > verification, class data sharing, compressed oops and numerous bug > fixes and cleanups. He has been a key contributor to the Hotspot > side of the Lambda project and provided several bug fixes and code > reviews to changes in default method resolution for jdk8. > > Votes are due by 12:00 AM ET, Thursday June 26, 2014. > > Only current jdk9 Reviewers [1] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this > mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Coleen Phillimore > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > From zhengyu.gu at oracle.com Thu Jun 12 11:59:12 2014 From: zhengyu.gu at oracle.com (Zhengyu Gu) Date: Thu, 12 Jun 2014 07:59:12 -0400 Subject: CFV: New jdk9 Reviewer: Harold Seigel In-Reply-To: <5399271F.9060500@oracle.com> References: <5399271F.9060500@oracle.com> Message-ID: <53999610.6000009@oracle.com> Vote: yes -Zhengyu On 6/12/2014 12:05 AM, Coleen Phillimore wrote: > > I hereby nominate Harold Seigel (hseigel) to jdk9 Reviewer. > > Harold is a member of the Hotspot Runtime group and is a Committer for > the jdk8 and jdk9 projects. He has contributed 55 changesets so far, > notably in the areas of bytecode verification and classfile > verification, class data sharing, compressed oops and numerous bug > fixes and cleanups. He has been a key contributor to the Hotspot > side of the Lambda project and provided several bug fixes and code > reviews to changes in default method resolution for jdk8. > > Votes are due by 12:00 AM ET, Thursday June 26, 2014. > > Only current jdk9 Reviewers [1] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this > mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Coleen Phillimore > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > From roger.riggs at oracle.com Thu Jun 12 13:06:07 2014 From: roger.riggs at oracle.com (roger riggs) Date: Thu, 12 Jun 2014 09:06:07 -0400 Subject: CFV: New jdk9 Reviewer: Harold Seigel In-Reply-To: <5399271F.9060500@oracle.com> References: <5399271F.9060500@oracle.com> Message-ID: <5399A5BF.6030004@oracle.com> Vote: Yes On 6/12/2014 12:05 AM, Coleen Phillimore wrote: > > I hereby nominate Harold Seigel (hseigel) to jdk9 Reviewer. From joel.franck at oracle.com Thu Jun 12 13:37:26 2014 From: joel.franck at oracle.com (Joel Borggren-Franck) Date: Thu, 12 Jun 2014 15:37:26 +0200 Subject: CFV: New JDK 9 Committer: Pavel Rappo In-Reply-To: <5398364E.2090409@oracle.com> References: <5398364E.2090409@oracle.com> Message-ID: <20140612133726.GA20482@oracle.com> Vote: yes cheers /Joel On 2014-06-11, Chris Hegarty wrote: > I hereby nominate Pavel Rappo (prappo) to JDK 9 Committer. > > Pavel is a member of the Core Libraries team at Oracle. Most > recently, he has been fixing issues in the Networking and NIO area. > His JDK 9 contributions, to date, can be seen below. > > Votes are due by 25th June 2014 23:59 GMT > > Only current JDK 9 Committers [1] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [2]. > > -Chris.. > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/b39e23ebc008 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/eb6f07ec4509 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/cda85444cad2 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/4aa94c6a7257 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/8cef08d9eacf > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/db75bd98d8fd > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/50a749f2cade > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/9a58ff1e27a6 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/e6d4d07dee4c > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/acda974a4986 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/476d56ab6377 From karen.kinnear at oracle.com Thu Jun 12 13:32:39 2014 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Thu, 12 Jun 2014 09:32:39 -0400 Subject: CFV: New jdk9 Reviewer: Harold Seigel In-Reply-To: <5399271F.9060500@oracle.com> References: <5399271F.9060500@oracle.com> Message-ID: <5447561D-92C7-48CE-B0AD-67206EF6438B@oracle.com> vote: yes On Jun 12, 2014, at 12:05 AM, Coleen Phillimore wrote: > > I hereby nominate Harold Seigel (hseigel) to jdk9 Reviewer. > > Harold is a member of the Hotspot Runtime group and is a Committer for the jdk8 and jdk9 projects. He has contributed 55 changesets so far, notably in the areas of bytecode verification and classfile verification, class data sharing, compressed oops and numerous bug fixes and cleanups. He has been a key contributor to the Hotspot side of the Lambda project and provided several bug fixes and code reviews to changes in default method resolution for jdk8. > > Votes are due by 12:00 AM ET, Thursday June 26, 2014. > > Only current jdk9 Reviewers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Coleen Phillimore > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > From daniel.daugherty at oracle.com Thu Jun 12 13:46:29 2014 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 12 Jun 2014 07:46:29 -0600 Subject: CFV: New jdk9 Reviewer: Harold Seigel In-Reply-To: <5399271F.9060500@oracle.com> References: <5399271F.9060500@oracle.com> Message-ID: <5399AF35.3000102@oracle.com> Vote: YES Dan On 6/11/14 10:05 PM, Coleen Phillimore wrote: > > I hereby nominate Harold Seigel (hseigel) to jdk9 Reviewer. > > Harold is a member of the Hotspot Runtime group and is a Committer for > the jdk8 and jdk9 projects. He has contributed 55 changesets so far, > notably in the areas of bytecode verification and classfile > verification, class data sharing, compressed oops and numerous bug > fixes and cleanups. He has been a key contributor to the Hotspot > side of the Lambda project and provided several bug fixes and code > reviews to changes in default method resolution for jdk8. > > Votes are due by 12:00 AM ET, Thursday June 26, 2014. > > Only current jdk9 Reviewers [1] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this > mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Coleen Phillimore > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > > > From mike.duigou at oracle.com Thu Jun 12 16:54:08 2014 From: mike.duigou at oracle.com (Mike Duigou) Date: Thu, 12 Jun 2014 09:54:08 -0700 Subject: CFV: New jdk9 Reviewer: Harold Seigel In-Reply-To: <5399271F.9060500@oracle.com> References: <5399271F.9060500@oracle.com> Message-ID: <431609D9-722C-416B-ADF6-11A64EFABF58@oracle.com> Vote: YES On Jun 11 2014, at 21:05 , Coleen Phillimore wrote: > > I hereby nominate Harold Seigel (hseigel) to jdk9 Reviewer. > > Harold is a member of the Hotspot Runtime group and is a Committer for the jdk8 and jdk9 projects. He has contributed 55 changesets so far, notably in the areas of bytecode verification and classfile verification, class data sharing, compressed oops and numerous bug fixes and cleanups. He has been a key contributor to the Hotspot side of the Lambda project and provided several bug fixes and code reviews to changes in default method resolution for jdk8. > > Votes are due by 12:00 AM ET, Thursday June 26, 2014. > > Only current jdk9 Reviewers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Coleen Phillimore > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > From coleen.phillimore at oracle.com Thu Jun 12 17:22:45 2014 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 12 Jun 2014 13:22:45 -0400 Subject: CFV: New jdk9 Reviewer: Harold Seigel In-Reply-To: <5399271F.9060500@oracle.com> References: <5399271F.9060500@oracle.com> Message-ID: <5399E1E5.7050102@oracle.com> Vote: yes On 6/12/14, 12:05 AM, Coleen Phillimore wrote: > > I hereby nominate Harold Seigel (hseigel) to jdk9 Reviewer. > > Harold is a member of the Hotspot Runtime group and is a Committer for > the jdk8 and jdk9 projects. He has contributed 55 changesets so far, > notably in the areas of bytecode verification and classfile > verification, class data sharing, compressed oops and numerous bug > fixes and cleanups. He has been a key contributor to the Hotspot > side of the Lambda project and provided several bug fixes and code > reviews to changes in default method resolution for jdk8. > > Votes are due by 12:00 AM ET, Thursday June 26, 2014. > > Only current jdk9 Reviewers [1] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this > mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Coleen Phillimore > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > From mike.duigou at oracle.com Thu Jun 12 22:25:20 2014 From: mike.duigou at oracle.com (Mike Duigou) Date: Thu, 12 Jun 2014 15:25:20 -0700 Subject: RFR : JDK-8032045 : (m/l) Enable compiler and linker safety switches for debug builds Message-ID: <405FD050-2A45-4076-A4EE-B80D3E22F05A@oracle.com> Hello all; After some additional work this changeset appears to finally complete. This is your very last chance to review and further extend the saga! jbsbug: https://bugs.openjdk.java.net/browse/JDK-8032045 webrev:http://cr.openjdk.java.net/~mduigou/JDK-8032045/9/webrev/ The changes since the last version remove some bash4.0-isms, backout an unnecessary change to the optimization level of HIGHEST and backout a change that was causing problems on MacOS. The later has been moved to a separate issue, 8046397. I've completed product and fastdebug builds and test on all supported platforms including embedded and slowdebug builds on linux and macos with no apparent regressions. Cheers, Mike From vladimir.kozlov at oracle.com Thu Jun 12 23:02:31 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 12 Jun 2014 16:02:31 -0700 Subject: RFR : JDK-8032045 : (m/l) Enable compiler and linker safety switches for debug builds In-Reply-To: <405FD050-2A45-4076-A4EE-B80D3E22F05A@oracle.com> References: <405FD050-2A45-4076-A4EE-B80D3E22F05A@oracle.com> Message-ID: <539A3187.8050205@oracle.com> Looks good. Vladimir On 6/12/14 3:25 PM, Mike Duigou wrote: > Hello all; > > After some additional work this changeset appears to finally complete. This is your very last chance to review and further extend the saga! > > jbsbug: https://bugs.openjdk.java.net/browse/JDK-8032045 > webrev:http://cr.openjdk.java.net/~mduigou/JDK-8032045/9/webrev/ > > The changes since the last version remove some bash4.0-isms, backout an unnecessary change to the optimization level of HIGHEST and backout a change that was causing problems on MacOS. The later has been moved to a separate issue, 8046397. > > I've completed product and fastdebug builds and test on all supported platforms including embedded and slowdebug builds on linux and macos with no apparent regressions. > > Cheers, > > Mike > From ivan.gerasimov at oracle.com Mon Jun 16 05:40:21 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Mon, 16 Jun 2014 09:40:21 +0400 Subject: CFV: New JDK 9 Committer: Pavel Rappo In-Reply-To: <5398364E.2090409@oracle.com> References: <5398364E.2090409@oracle.com> Message-ID: <539E8345.7030002@oracle.com> Vote: Yes On 11.06.2014 14:58, Chris Hegarty wrote: > I hereby nominate Pavel Rappo (prappo) to JDK 9 Committer. > > Pavel is a member of the Core Libraries team at Oracle. Most recently, > he has been fixing issues in the Networking and NIO area. His JDK 9 > contributions, to date, can be seen below. > > Votes are due by 25th June 2014 23:59 GMT > > Only current JDK 9 Committers [1] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Lazy Consensus voting instructions, see [2]. > > -Chris.. > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/b39e23ebc008 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/eb6f07ec4509 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/cda85444cad2 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/4aa94c6a7257 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/8cef08d9eacf > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/db75bd98d8fd > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/50a749f2cade > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/9a58ff1e27a6 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/e6d4d07dee4c > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/acda974a4986 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/476d56ab6377 > > From luchsh at linux.vnet.ibm.com Mon Jun 16 05:57:22 2014 From: luchsh at linux.vnet.ibm.com (Jonathan Lu) Date: Mon, 16 Jun 2014 13:57:22 +0800 Subject: CFV: New JDK 9 Committer: Pavel Rappo In-Reply-To: <539E8345.7030002@oracle.com> References: <5398364E.2090409@oracle.com> <539E8345.7030002@oracle.com> Message-ID: Vote: yes cheers On Mon, Jun 16, 2014 at 1:40 PM, Ivan Gerasimov wrote: > Vote: Yes > > > On 11.06.2014 14:58, Chris Hegarty wrote: > >> I hereby nominate Pavel Rappo (prappo) to JDK 9 Committer. >> >> Pavel is a member of the Core Libraries team at Oracle. Most recently, he >> has been fixing issues in the Networking and NIO area. His JDK 9 >> contributions, to date, can be seen below. >> >> Votes are due by 25th June 2014 23:59 GMT >> >> Only current JDK 9 Committers [1] are eligible to vote on this >> nomination. Votes must be cast in the open by replying to this mailing list. >> >> For Lazy Consensus voting instructions, see [2]. >> >> -Chris.. >> >> [1] http://openjdk.java.net/census >> [2] http://openjdk.java.net/projects/#committer-vote >> >> http://hg.openjdk.java.net/jdk9/dev/jdk/rev/b39e23ebc008 >> http://hg.openjdk.java.net/jdk9/dev/jdk/rev/eb6f07ec4509 >> http://hg.openjdk.java.net/jdk9/dev/jdk/rev/cda85444cad2 >> http://hg.openjdk.java.net/jdk9/dev/jdk/rev/4aa94c6a7257 >> http://hg.openjdk.java.net/jdk9/dev/jdk/rev/8cef08d9eacf >> http://hg.openjdk.java.net/jdk9/dev/jdk/rev/db75bd98d8fd >> http://hg.openjdk.java.net/jdk9/dev/jdk/rev/50a749f2cade >> http://hg.openjdk.java.net/jdk9/dev/jdk/rev/9a58ff1e27a6 >> http://hg.openjdk.java.net/jdk9/dev/jdk/rev/e6d4d07dee4c >> http://hg.openjdk.java.net/jdk9/dev/jdk/rev/acda974a4986 >> http://hg.openjdk.java.net/jdk9/dev/jdk/rev/476d56ab6377 >> >> >> > From thomas.schatzl at oracle.com Mon Jun 16 07:40:07 2014 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Mon, 16 Jun 2014 09:40:07 +0200 Subject: CFV: New jdk9 Reviewer: Harold Seigel In-Reply-To: <5399271F.9060500@oracle.com> References: <5399271F.9060500@oracle.com> Message-ID: <1402904407.2614.0.camel@cirrus> Vote: yes On Thu, 2014-06-12 at 00:05 -0400, Coleen Phillimore wrote: > I hereby nominate Harold Seigel (hseigel) to jdk9 Reviewer. > > Harold is a member of the Hotspot Runtime group and is a Committer for > the jdk8 and jdk9 projects. He has contributed 55 changesets so far, > notably in the areas of bytecode verification and classfile > verification, class data sharing, compressed oops and numerous bug fixes > and cleanups. He has been a key contributor to the Hotspot side of the > Lambda project and provided several bug fixes and code reviews to > changes in default method resolution for jdk8. > > Votes are due by 12:00 AM ET, Thursday June 26, 2014. > > Only current jdk9 Reviewers [1] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Three-Vote Consensus voting instructions, see [2]. > > Coleen Phillimore > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > From vladimir.x.ivanov at oracle.com Mon Jun 16 08:22:59 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Mon, 16 Jun 2014 12:22:59 +0400 Subject: CFV: New jdk9 Reviewer: Harold Seigel In-Reply-To: <5399271F.9060500@oracle.com> References: <5399271F.9060500@oracle.com> Message-ID: <539EA963.6090504@oracle.com> Vote: yes Best regards, Vladimir Ivanov On 6/12/14 8:05 AM, Coleen Phillimore wrote: > > I hereby nominate Harold Seigel (hseigel) to jdk9 Reviewer. > > Harold is a member of the Hotspot Runtime group and is a Committer for > the jdk8 and jdk9 projects. He has contributed 55 changesets so far, > notably in the areas of bytecode verification and classfile > verification, class data sharing, compressed oops and numerous bug fixes > and cleanups. He has been a key contributor to the Hotspot side of the > Lambda project and provided several bug fixes and code reviews to > changes in default method resolution for jdk8. > > Votes are due by 12:00 AM ET, Thursday June 26, 2014. > > Only current jdk9 Reviewers [1] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Three-Vote Consensus voting instructions, see [2]. > > Coleen Phillimore > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > From paul.sandoz at oracle.com Mon Jun 16 10:04:08 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 16 Jun 2014 11:04:08 +0100 Subject: CFV: New JDK 9 Committer: Pavel Rappo In-Reply-To: <5398364E.2090409@oracle.com> References: <5398364E.2090409@oracle.com> Message-ID: <113DFFDB-2222-4161-8CE3-05E561EED6F4@oracle.com> Vote: yes. Paul. From paul.sandoz at oracle.com Mon Jun 16 10:04:48 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 16 Jun 2014 11:04:48 +0100 Subject: CFV: New jdk9 Reviewer: Harold Seigel In-Reply-To: <5399271F.9060500@oracle.com> References: <5399271F.9060500@oracle.com> Message-ID: <4A40EA77-F7DC-4DAE-8759-32146BE9CD37@oracle.com> Vote: yes. Paul. From coleen.phillimore at oracle.com Mon Jun 16 15:42:30 2014 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 16 Jun 2014 11:42:30 -0400 Subject: RFR 6642881: Improve performance of Class.getClassLoader() Message-ID: <539F1066.8080302@oracle.com> Summary: Add classLoader to java/lang/Class instance for fast access In order to improve performance of Class.getClassLoader() in a way to allow the compilers to automatically optimize this call, I added the classLoader to the instance of java/lang/Class. For microbenchmarks, this results in a 98% improvement, which was expected. For Oracle internal applications, this results in a 10-12% improvement on solaris/sparc. The increase in size of java/lang/Class can be offset by other changes (removing constant pool lock, or removing signers). See bug link https://bugs.openjdk.java.net/browse/JDK-6642881 and associated linked bugs for more details. open webrev at http://cr.openjdk.java.net/~coleenp/6642881_hotspot/ open webrev at http://cr.openjdk.java.net/~coleenp/6642881_jdk/ There is both hotspot and jdk changes for this change. The hotspot changes can work without the jdk changes (check for optional field), but not vice-versa. I'll file another bug (and compatibility request) to remove JVM_GetClassLoader from hotspot. Tested with jck lang, vm, api/java_lang tests with/without jdk change, nsk vm.quick.testlist and hotspot jtreg tests, and jprt. Thanks, Coleen From lois.foltan at oracle.com Mon Jun 16 17:45:37 2014 From: lois.foltan at oracle.com (Lois Foltan) Date: Mon, 16 Jun 2014 13:45:37 -0400 Subject: RFR 6642881: Improve performance of Class.getClassLoader() In-Reply-To: <539F1066.8080302@oracle.com> References: <539F1066.8080302@oracle.com> Message-ID: <539F2D41.7040901@oracle.com> Hi Coleen, This looks good. Lois On 6/16/2014 11:42 AM, Coleen Phillimore wrote: > Summary: Add classLoader to java/lang/Class instance for fast access > > In order to improve performance of Class.getClassLoader() in a way to > allow the compilers to automatically optimize this call, I added the > classLoader to the instance of java/lang/Class. For microbenchmarks, > this results in a 98% improvement, which was expected. For Oracle > internal applications, this results in a 10-12% improvement on > solaris/sparc. The increase in size of java/lang/Class can be offset > by other changes (removing constant pool lock, or removing signers). > > See bug link https://bugs.openjdk.java.net/browse/JDK-6642881 and > associated linked bugs for more details. > > open webrev at http://cr.openjdk.java.net/~coleenp/6642881_hotspot/ > open webrev at http://cr.openjdk.java.net/~coleenp/6642881_jdk/ > > There is both hotspot and jdk changes for this change. The hotspot > changes can work without the jdk changes (check for optional field), > but not vice-versa. I'll file another bug (and compatibility request) > to remove JVM_GetClassLoader from hotspot. > > Tested with jck lang, vm, api/java_lang tests with/without jdk change, > nsk vm.quick.testlist and hotspot jtreg tests, and jprt. > > Thanks, > Coleen > > From roger.riggs at oracle.com Mon Jun 16 17:50:45 2014 From: roger.riggs at oracle.com (roger riggs) Date: Mon, 16 Jun 2014 13:50:45 -0400 Subject: RFR 6642881: Improve performance of Class.getClassLoader() In-Reply-To: <539F2D41.7040901@oracle.com> References: <539F1066.8080302@oracle.com> <539F2D41.7040901@oracle.com> Message-ID: <539F2E75.1050301@oracle.com> Hi Colleen, In Class.java, if only the VM creates Class objects (comment at line 681), and it does not use the constructor then the code (line 136) in the constructor to set classloader is misleading and deserves a comment. Roger On 6/16/2014 1:45 PM, Lois Foltan wrote: > Hi Coleen, > This looks good. > Lois > > On 6/16/2014 11:42 AM, Coleen Phillimore wrote: >> Summary: Add classLoader to java/lang/Class instance for fast access >> >> In order to improve performance of Class.getClassLoader() in a way to >> allow the compilers to automatically optimize this call, I added the >> classLoader to the instance of java/lang/Class. For microbenchmarks, >> this results in a 98% improvement, which was expected. For Oracle >> internal applications, this results in a 10-12% improvement on >> solaris/sparc. The increase in size of java/lang/Class can be >> offset by other changes (removing constant pool lock, or removing >> signers). >> >> See bug link https://bugs.openjdk.java.net/browse/JDK-6642881 and >> associated linked bugs for more details. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/6642881_hotspot/ >> open webrev at http://cr.openjdk.java.net/~coleenp/6642881_jdk/ >> >> There is both hotspot and jdk changes for this change. The hotspot >> changes can work without the jdk changes (check for optional field), >> but not vice-versa. I'll file another bug (and compatibility >> request) to remove JVM_GetClassLoader from hotspot. >> >> Tested with jck lang, vm, api/java_lang tests with/without jdk >> change, nsk vm.quick.testlist and hotspot jtreg tests, and jprt. >> >> Thanks, >> Coleen >> >> > From Alan.Bateman at oracle.com Mon Jun 16 18:06:21 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 16 Jun 2014 19:06:21 +0100 Subject: RFR 6642881: Improve performance of Class.getClassLoader() In-Reply-To: <539F1066.8080302@oracle.com> References: <539F1066.8080302@oracle.com> Message-ID: <539F321D.80200@oracle.com> On 16/06/2014 16:42, Coleen Phillimore wrote: > Summary: Add classLoader to java/lang/Class instance for fast access > > In order to improve performance of Class.getClassLoader() in a way to > allow the compilers to automatically optimize this call, I added the > classLoader to the instance of java/lang/Class. For microbenchmarks, > this results in a 98% improvement, which was expected. For Oracle > internal applications, this results in a 10-12% improvement on > solaris/sparc. The increase in size of java/lang/Class can be offset > by other changes (removing constant pool lock, or removing signers). > > See bug link https://bugs.openjdk.java.net/browse/JDK-6642881 and > associated linked bugs for more details. > > open webrev at http://cr.openjdk.java.net/~coleenp/6642881_hotspot/ > open webrev at http://cr.openjdk.java.net/~coleenp/6642881_jdk/ > > There is both hotspot and jdk changes for this change. The hotspot > changes can work without the jdk changes (check for optional field), > but not vice-versa. I'll file another bug (and compatibility request) > to remove JVM_GetClassLoader from hotspot. > The jdk changes look okay to me. One thing that I mentioned to Coleen off-list is that we have some dead code in the old verifier that uses JVM_GetClassLoader - I don't know the history to that but it should be checked and probably removed. -Alan From vladimir.x.ivanov at oracle.com Mon Jun 16 18:09:00 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Mon, 16 Jun 2014 22:09:00 +0400 Subject: RFR 6642881: Improve performance of Class.getClassLoader() In-Reply-To: <539F1066.8080302@oracle.com> References: <539F1066.8080302@oracle.com> Message-ID: <539F32BC.2010104@oracle.com> Looks good. Best regards, Vladimir Ivanov On 6/16/14 7:42 PM, Coleen Phillimore wrote: > Summary: Add classLoader to java/lang/Class instance for fast access > > In order to improve performance of Class.getClassLoader() in a way to > allow the compilers to automatically optimize this call, I added the > classLoader to the instance of java/lang/Class. For microbenchmarks, > this results in a 98% improvement, which was expected. For Oracle > internal applications, this results in a 10-12% improvement on > solaris/sparc. The increase in size of java/lang/Class can be offset > by other changes (removing constant pool lock, or removing signers). > > See bug link https://bugs.openjdk.java.net/browse/JDK-6642881 and > associated linked bugs for more details. > > open webrev at http://cr.openjdk.java.net/~coleenp/6642881_hotspot/ > open webrev at http://cr.openjdk.java.net/~coleenp/6642881_jdk/ > > There is both hotspot and jdk changes for this change. The hotspot > changes can work without the jdk changes (check for optional field), but > not vice-versa. I'll file another bug (and compatibility request) to > remove JVM_GetClassLoader from hotspot. > > Tested with jck lang, vm, api/java_lang tests with/without jdk change, > nsk vm.quick.testlist and hotspot jtreg tests, and jprt. > > Thanks, > Coleen > > From Alan.Bateman at oracle.com Mon Jun 16 20:04:35 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 16 Jun 2014 21:04:35 +0100 Subject: CFV: New JDK 9 Committer: Pavel Rappo In-Reply-To: <5398364E.2090409@oracle.com> References: <5398364E.2090409@oracle.com> Message-ID: <539F4DD3.5040408@oracle.com> Vote: yes From coleen.phillimore at oracle.com Mon Jun 16 20:43:21 2014 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 16 Jun 2014 16:43:21 -0400 Subject: RFR 6642881: Improve performance of Class.getClassLoader() In-Reply-To: <539F2E75.1050301@oracle.com> References: <539F1066.8080302@oracle.com> <539F2D41.7040901@oracle.com> <539F2E75.1050301@oracle.com> Message-ID: <539F56E9.3060705@oracle.com> On 6/16/14, 1:50 PM, roger riggs wrote: > Hi Colleen, > > In Class.java, if only the VM creates Class objects (comment at line > 681), > and it does not use the constructor then the code (line 136) in the > constructor > to set classloader is misleading and deserves a comment. Thanks, Roger. How about this comment? /* * Constructor. Only the Java Virtual Machine creates Class * objects, but this constructor prevents a warning that classLoader is not * initialized. */ private Class(ClassLoader loader) { classLoader = loader; } Coleen > > Roger > > On 6/16/2014 1:45 PM, Lois Foltan wrote: >> Hi Coleen, >> This looks good. >> Lois >> >> On 6/16/2014 11:42 AM, Coleen Phillimore wrote: >>> Summary: Add classLoader to java/lang/Class instance for fast access >>> >>> In order to improve performance of Class.getClassLoader() in a way >>> to allow the compilers to automatically optimize this call, I added >>> the classLoader to the instance of java/lang/Class. For >>> microbenchmarks, this results in a 98% improvement, which was >>> expected. For Oracle internal applications, this results in a >>> 10-12% improvement on solaris/sparc. The increase in size of >>> java/lang/Class can be offset by other changes (removing constant >>> pool lock, or removing signers). >>> >>> See bug link https://bugs.openjdk.java.net/browse/JDK-6642881 and >>> associated linked bugs for more details. >>> >>> open webrev at http://cr.openjdk.java.net/~coleenp/6642881_hotspot/ >>> open webrev at http://cr.openjdk.java.net/~coleenp/6642881_jdk/ >>> >>> There is both hotspot and jdk changes for this change. The hotspot >>> changes can work without the jdk changes (check for optional field), >>> but not vice-versa. I'll file another bug (and compatibility >>> request) to remove JVM_GetClassLoader from hotspot. >>> >>> Tested with jck lang, vm, api/java_lang tests with/without jdk >>> change, nsk vm.quick.testlist and hotspot jtreg tests, and jprt. >>> >>> Thanks, >>> Coleen >>> >>> >> > From christian.thalinger at oracle.com Mon Jun 16 22:33:07 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 16 Jun 2014 15:33:07 -0700 Subject: RFR 6642881: Improve performance of Class.getClassLoader() In-Reply-To: <539F1066.8080302@oracle.com> References: <539F1066.8080302@oracle.com> Message-ID: + template(classClassLoader_name, "classLoader") \ This should be classLoader_name. Otherwise this looks good. On Jun 16, 2014, at 8:42 AM, Coleen Phillimore wrote: > Summary: Add classLoader to java/lang/Class instance for fast access > > In order to improve performance of Class.getClassLoader() in a way to allow the compilers to automatically optimize this call, I added the classLoader to the instance of java/lang/Class. For microbenchmarks, this results in a 98% improvement, which was expected. For Oracle internal applications, this results in a 10-12% improvement on solaris/sparc. The increase in size of java/lang/Class can be offset by other changes (removing constant pool lock, or removing signers). > > See bug link https://bugs.openjdk.java.net/browse/JDK-6642881 and associated linked bugs for more details. > > open webrev at http://cr.openjdk.java.net/~coleenp/6642881_hotspot/ > open webrev at http://cr.openjdk.java.net/~coleenp/6642881_jdk/ > > There is both hotspot and jdk changes for this change. The hotspot changes can work without the jdk changes (check for optional field), but not vice-versa. I'll file another bug (and compatibility request) to remove JVM_GetClassLoader from hotspot. > > Tested with jck lang, vm, api/java_lang tests with/without jdk change, nsk vm.quick.testlist and hotspot jtreg tests, and jprt. > > Thanks, > Coleen > > From coleen.phillimore at oracle.com Mon Jun 16 22:44:02 2014 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 16 Jun 2014 18:44:02 -0400 Subject: RFR 6642881: Improve performance of Class.getClassLoader() In-Reply-To: References: <539F1066.8080302@oracle.com> Message-ID: <539F7332.8050207@oracle.com> On 6/16/14, 6:33 PM, Christian Thalinger wrote: > + template(classClassLoader_name, "classLoader") \ > > This should be classLoader_name. Thanks, you're right, I thought there was some sort of namespace convention (ie to say this is a field of j.l.class) from following classRedefinedCount example but there isn't this convention. Thanks, Coleen > > Otherwise this looks good. > > On Jun 16, 2014, at 8:42 AM, Coleen Phillimore > > > wrote: > >> Summary: Add classLoader to java/lang/Class instance for fast access >> >> In order to improve performance of Class.getClassLoader() in a way to >> allow the compilers to automatically optimize this call, I added the >> classLoader to the instance of java/lang/Class. For microbenchmarks, >> this results in a 98% improvement, which was expected. For Oracle >> internal applications, this results in a 10-12% improvement on >> solaris/sparc. The increase in size of java/lang/Class can be >> offset by other changes (removing constant pool lock, or removing >> signers). >> >> See bug link https://bugs.openjdk.java.net/browse/JDK-6642881 and >> associated linked bugs for more details. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/6642881_hotspot/ >> >> open webrev at http://cr.openjdk.java.net/~coleenp/6642881_jdk/ >> >> >> There is both hotspot and jdk changes for this change. The hotspot >> changes can work without the jdk changes (check for optional field), >> but not vice-versa. I'll file another bug (and compatibility >> request) to remove JVM_GetClassLoader from hotspot. >> >> Tested with jck lang, vm, api/java_lang tests with/without jdk >> change, nsk vm.quick.testlist and hotspot jtreg tests, and jprt. >> >> Thanks, >> Coleen >> >> > From coleen.phillimore at oracle.com Mon Jun 16 22:45:56 2014 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 16 Jun 2014 18:45:56 -0400 Subject: RFR 6642881: Improve performance of Class.getClassLoader() In-Reply-To: <539F32BC.2010104@oracle.com> References: <539F1066.8080302@oracle.com> <539F32BC.2010104@oracle.com> Message-ID: <539F73A4.40100@oracle.com> Thanks Vladimir, Lois and Alan. Coleen On 6/16/14, 2:09 PM, Vladimir Ivanov wrote: > Looks good. > > Best regards, > Vladimir Ivanov > > On 6/16/14 7:42 PM, Coleen Phillimore wrote: >> Summary: Add classLoader to java/lang/Class instance for fast access >> >> In order to improve performance of Class.getClassLoader() in a way to >> allow the compilers to automatically optimize this call, I added the >> classLoader to the instance of java/lang/Class. For microbenchmarks, >> this results in a 98% improvement, which was expected. For Oracle >> internal applications, this results in a 10-12% improvement on >> solaris/sparc. The increase in size of java/lang/Class can be offset >> by other changes (removing constant pool lock, or removing signers). >> >> See bug link https://bugs.openjdk.java.net/browse/JDK-6642881 and >> associated linked bugs for more details. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/6642881_hotspot/ >> open webrev at http://cr.openjdk.java.net/~coleenp/6642881_jdk/ >> >> There is both hotspot and jdk changes for this change. The hotspot >> changes can work without the jdk changes (check for optional field), but >> not vice-versa. I'll file another bug (and compatibility request) to >> remove JVM_GetClassLoader from hotspot. >> >> Tested with jck lang, vm, api/java_lang tests with/without jdk change, >> nsk vm.quick.testlist and hotspot jtreg tests, and jprt. >> >> Thanks, >> Coleen >> >> From mandy.chung at oracle.com Mon Jun 16 23:02:20 2014 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 16 Jun 2014 16:02:20 -0700 Subject: CFV: New JDK 9 Committer: Pavel Rappo In-Reply-To: <5398364E.2090409@oracle.com> References: <5398364E.2090409@oracle.com> Message-ID: <539F777C.5090606@oracle.com> Vote: yes Mandy From mandy.chung at oracle.com Mon Jun 16 23:02:49 2014 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 16 Jun 2014 16:02:49 -0700 Subject: CFV: New jdk9 Reviewer: Harold Seigel In-Reply-To: <5399271F.9060500@oracle.com> References: <5399271F.9060500@oracle.com> Message-ID: <539F7799.10008@oracle.com> Vote: yes Mandy From joel.franck at oracle.com Tue Jun 17 04:38:14 2014 From: joel.franck at oracle.com (=?windows-1252?Q?Joel_Borggr=E9n-Franck?=) Date: Tue, 17 Jun 2014 06:38:14 +0200 Subject: RFR 6642881: Improve performance of Class.getClassLoader() In-Reply-To: <539F1066.8080302@oracle.com> References: <539F1066.8080302@oracle.com> Message-ID: <6C677BF2-E257-48C9-B589-A668A8D939CC@oracle.com> Hi Coleen, On 16 jun 2014, at 17:42, Coleen Phillimore wrote: > Summary: Add classLoader to java/lang/Class instance for fast access > > In order to improve performance of Class.getClassLoader() in a way to allow the compilers to automatically optimize this call, I added the classLoader to the instance of java/lang/Class. For microbenchmarks, this results in a 98% improvement, which was expected. For Oracle internal applications, this results in a 10-12% improvement on solaris/sparc. The increase in size of java/lang/Class can be offset by other changes (removing constant pool lock, or removing signers). > > See bug link https://bugs.openjdk.java.net/browse/JDK-6642881 and associated linked bugs for more details. > > open webrev at http://cr.openjdk.java.net/~coleenp/6642881_hotspot/ > open webrev at http://cr.openjdk.java.net/~coleenp/6642881_jdk/ > > There is both hotspot and jdk changes for this change. The hotspot changes can work without the jdk changes (check for optional field), but not vice-versa. I'll file another bug (and compatibility request) to remove JVM_GetClassLoader from hotspot. > > Tested with jck lang, vm, api/java_lang tests with/without jdk change, nsk vm.quick.testlist and hotspot jtreg tests, and jprt. > Have you considered hiding the Class.classLoader field from reflection? I?m not sure it is necessary but I?m not to keen on the idea of people poking at this field with Unsafe (which should go away in 9 but ?). Otherwise looks good. cheers /Joel From david.holmes at oracle.com Tue Jun 17 05:30:51 2014 From: david.holmes at oracle.com (David Holmes) Date: Tue, 17 Jun 2014 15:30:51 +1000 Subject: RFR 6642881: Improve performance of Class.getClassLoader() In-Reply-To: <539F56E9.3060705@oracle.com> References: <539F1066.8080302@oracle.com> <539F2D41.7040901@oracle.com> <539F2E75.1050301@oracle.com> <539F56E9.3060705@oracle.com> Message-ID: <539FD28B.7000201@oracle.com> On 17/06/2014 6:43 AM, Coleen Phillimore wrote: > > On 6/16/14, 1:50 PM, roger riggs wrote: >> Hi Colleen, >> >> In Class.java, if only the VM creates Class objects (comment at line >> 681), >> and it does not use the constructor then the code (line 136) in the >> constructor >> to set classloader is misleading and deserves a comment. > > Thanks, Roger. How about this comment? > > /* > * Constructor. Only the Java Virtual Machine creates Class > * objects, but this constructor prevents a warning that > classLoader is not > * initialized. > */ > private Class(ClassLoader loader) { > classLoader = loader; > } Why not just initialize classloader to null when it is declared and leave the constructor alone? The constructor exists to prevent javac from creating a default constructor, and thus ensuring Class instances can not be created (which is what the original comment should, but doesn't quite, say). David > Coleen >> >> Roger >> >> On 6/16/2014 1:45 PM, Lois Foltan wrote: >>> Hi Coleen, >>> This looks good. >>> Lois >>> >>> On 6/16/2014 11:42 AM, Coleen Phillimore wrote: >>>> Summary: Add classLoader to java/lang/Class instance for fast access >>>> >>>> In order to improve performance of Class.getClassLoader() in a way >>>> to allow the compilers to automatically optimize this call, I added >>>> the classLoader to the instance of java/lang/Class. For >>>> microbenchmarks, this results in a 98% improvement, which was >>>> expected. For Oracle internal applications, this results in a >>>> 10-12% improvement on solaris/sparc. The increase in size of >>>> java/lang/Class can be offset by other changes (removing constant >>>> pool lock, or removing signers). >>>> >>>> See bug link https://bugs.openjdk.java.net/browse/JDK-6642881 and >>>> associated linked bugs for more details. >>>> >>>> open webrev at http://cr.openjdk.java.net/~coleenp/6642881_hotspot/ >>>> open webrev at http://cr.openjdk.java.net/~coleenp/6642881_jdk/ >>>> >>>> There is both hotspot and jdk changes for this change. The hotspot >>>> changes can work without the jdk changes (check for optional field), >>>> but not vice-versa. I'll file another bug (and compatibility >>>> request) to remove JVM_GetClassLoader from hotspot. >>>> >>>> Tested with jck lang, vm, api/java_lang tests with/without jdk >>>> change, nsk vm.quick.testlist and hotspot jtreg tests, and jprt. >>>> >>>> Thanks, >>>> Coleen >>>> >>>> >>> >> > From marcus.lagergren at oracle.com Tue Jun 17 07:40:55 2014 From: marcus.lagergren at oracle.com (Marcus Lagergren) Date: Tue, 17 Jun 2014 09:40:55 +0200 Subject: CFV: New JDK 9 Committer: Pavel Rappo In-Reply-To: <5398364E.2090409@oracle.com> References: <5398364E.2090409@oracle.com> Message-ID: <3EF26BF5-E0B3-46C2-9723-A6AEF41BCEA0@oracle.com> Vote: Yes /Marcus On 11 Jun 2014, at 12:58, Chris Hegarty wrote: > I hereby nominate Pavel Rappo (prappo) to JDK 9 Committer. > > Pavel is a member of the Core Libraries team at Oracle. Most recently, he has been fixing issues in the Networking and NIO area. His JDK 9 contributions, to date, can be seen below. > > Votes are due by 25th June 2014 23:59 GMT > > Only current JDK 9 Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > -Chris.. > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/b39e23ebc008 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/eb6f07ec4509 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/cda85444cad2 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/4aa94c6a7257 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/8cef08d9eacf > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/db75bd98d8fd > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/50a749f2cade > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/9a58ff1e27a6 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/e6d4d07dee4c > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/acda974a4986 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/476d56ab6377 From roger.riggs at oracle.com Tue Jun 17 14:08:34 2014 From: roger.riggs at oracle.com (roger riggs) Date: Tue, 17 Jun 2014 10:08:34 -0400 Subject: RFR 6642881: Improve performance of Class.getClassLoader() In-Reply-To: <539FD28B.7000201@oracle.com> References: <539F1066.8080302@oracle.com> <539F2D41.7040901@oracle.com> <539F2E75.1050301@oracle.com> <539F56E9.3060705@oracle.com> <539FD28B.7000201@oracle.com> Message-ID: <53A04BE2.90202@oracle.com> Hi, I'd favor David's suggestion also, omitting the constructor and initializing to null. Roger On 6/17/2014 1:30 AM, David Holmes wrote: > On 17/06/2014 6:43 AM, Coleen Phillimore wrote: >> >> On 6/16/14, 1:50 PM, roger riggs wrote: >>> Hi Colleen, >>> >>> In Class.java, if only the VM creates Class objects (comment at line >>> 681), >>> and it does not use the constructor then the code (line 136) in the >>> constructor >>> to set classloader is misleading and deserves a comment. >> >> Thanks, Roger. How about this comment? >> >> /* >> * Constructor. Only the Java Virtual Machine creates Class >> * objects, but this constructor prevents a warning that >> classLoader is not >> * initialized. >> */ >> private Class(ClassLoader loader) { >> classLoader = loader; >> } > > Why not just initialize classloader to null when it is declared and > leave the constructor alone? The constructor exists to prevent javac > from creating a default constructor, and thus ensuring Class instances > can not be created (which is what the original comment should, but > doesn't quite, say). > > David > >> Coleen >>> >>> Roger >>> >>> On 6/16/2014 1:45 PM, Lois Foltan wrote: >>>> Hi Coleen, >>>> This looks good. >>>> Lois >>>> >>>> On 6/16/2014 11:42 AM, Coleen Phillimore wrote: >>>>> Summary: Add classLoader to java/lang/Class instance for fast access >>>>> >>>>> In order to improve performance of Class.getClassLoader() in a way >>>>> to allow the compilers to automatically optimize this call, I added >>>>> the classLoader to the instance of java/lang/Class. For >>>>> microbenchmarks, this results in a 98% improvement, which was >>>>> expected. For Oracle internal applications, this results in a >>>>> 10-12% improvement on solaris/sparc. The increase in size of >>>>> java/lang/Class can be offset by other changes (removing constant >>>>> pool lock, or removing signers). >>>>> >>>>> See bug link https://bugs.openjdk.java.net/browse/JDK-6642881 and >>>>> associated linked bugs for more details. >>>>> >>>>> open webrev at http://cr.openjdk.java.net/~coleenp/6642881_hotspot/ >>>>> open webrev at http://cr.openjdk.java.net/~coleenp/6642881_jdk/ >>>>> >>>>> There is both hotspot and jdk changes for this change. The hotspot >>>>> changes can work without the jdk changes (check for optional field), >>>>> but not vice-versa. I'll file another bug (and compatibility >>>>> request) to remove JVM_GetClassLoader from hotspot. >>>>> >>>>> Tested with jck lang, vm, api/java_lang tests with/without jdk >>>>> change, nsk vm.quick.testlist and hotspot jtreg tests, and jprt. >>>>> >>>>> Thanks, >>>>> Coleen >>>>> >>>>> >>>> >>> >> From coleen.phillimore at oracle.com Tue Jun 17 14:52:02 2014 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 17 Jun 2014 10:52:02 -0400 Subject: RFR 6642881: Improve performance of Class.getClassLoader() In-Reply-To: <53A04BE2.90202@oracle.com> References: <539F1066.8080302@oracle.com> <539F2D41.7040901@oracle.com> <539F2E75.1050301@oracle.com> <539F56E9.3060705@oracle.com> <539FD28B.7000201@oracle.com> <53A04BE2.90202@oracle.com> Message-ID: <53A05612.90406@oracle.com> On 6/17/14, 10:08 AM, roger riggs wrote: > Hi, > > I'd favor David's suggestion also, omitting the constructor and > initializing to null. I think I can't actually do this because as a final field, won't the JIT optimize it to always be null? Coleen > > Roger > > On 6/17/2014 1:30 AM, David Holmes wrote: >> On 17/06/2014 6:43 AM, Coleen Phillimore wrote: >>> >>> On 6/16/14, 1:50 PM, roger riggs wrote: >>>> Hi Colleen, >>>> >>>> In Class.java, if only the VM creates Class objects (comment at line >>>> 681), >>>> and it does not use the constructor then the code (line 136) in the >>>> constructor >>>> to set classloader is misleading and deserves a comment. >>> >>> Thanks, Roger. How about this comment? >>> >>> /* >>> * Constructor. Only the Java Virtual Machine creates Class >>> * objects, but this constructor prevents a warning that >>> classLoader is not >>> * initialized. >>> */ >>> private Class(ClassLoader loader) { >>> classLoader = loader; >>> } >> >> Why not just initialize classloader to null when it is declared and >> leave the constructor alone? The constructor exists to prevent javac >> from creating a default constructor, and thus ensuring Class >> instances can not be created (which is what the original comment >> should, but doesn't quite, say). >> >> David >> >>> Coleen >>>> >>>> Roger >>>> >>>> On 6/16/2014 1:45 PM, Lois Foltan wrote: >>>>> Hi Coleen, >>>>> This looks good. >>>>> Lois >>>>> >>>>> On 6/16/2014 11:42 AM, Coleen Phillimore wrote: >>>>>> Summary: Add classLoader to java/lang/Class instance for fast access >>>>>> >>>>>> In order to improve performance of Class.getClassLoader() in a way >>>>>> to allow the compilers to automatically optimize this call, I added >>>>>> the classLoader to the instance of java/lang/Class. For >>>>>> microbenchmarks, this results in a 98% improvement, which was >>>>>> expected. For Oracle internal applications, this results in a >>>>>> 10-12% improvement on solaris/sparc. The increase in size of >>>>>> java/lang/Class can be offset by other changes (removing constant >>>>>> pool lock, or removing signers). >>>>>> >>>>>> See bug link https://bugs.openjdk.java.net/browse/JDK-6642881 and >>>>>> associated linked bugs for more details. >>>>>> >>>>>> open webrev at http://cr.openjdk.java.net/~coleenp/6642881_hotspot/ >>>>>> open webrev at http://cr.openjdk.java.net/~coleenp/6642881_jdk/ >>>>>> >>>>>> There is both hotspot and jdk changes for this change. The hotspot >>>>>> changes can work without the jdk changes (check for optional field), >>>>>> but not vice-versa. I'll file another bug (and compatibility >>>>>> request) to remove JVM_GetClassLoader from hotspot. >>>>>> >>>>>> Tested with jck lang, vm, api/java_lang tests with/without jdk >>>>>> change, nsk vm.quick.testlist and hotspot jtreg tests, and jprt. >>>>>> >>>>>> Thanks, >>>>>> Coleen >>>>>> >>>>>> >>>>> >>>> >>> > From christian.thalinger at oracle.com Tue Jun 17 15:30:57 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 17 Jun 2014 08:30:57 -0700 Subject: CFV: New jdk9 Reviewer: Harold Seigel In-Reply-To: <5399271F.9060500@oracle.com> References: <5399271F.9060500@oracle.com> Message-ID: <0F289AB4-6F10-4B8E-8765-AAE36E9719AC@oracle.com> Vote: yes On Jun 11, 2014, at 9:05 PM, Coleen Phillimore wrote: > > I hereby nominate Harold Seigel (hseigel) to jdk9 Reviewer. > > Harold is a member of the Hotspot Runtime group and is a Committer for the jdk8 and jdk9 projects. He has contributed 55 changesets so far, notably in the areas of bytecode verification and classfile verification, class data sharing, compressed oops and numerous bug fixes and cleanups. He has been a key contributor to the Hotspot side of the Lambda project and provided several bug fixes and code reviews to changes in default method resolution for jdk8. > > Votes are due by 12:00 AM ET, Thursday June 26, 2014. > > Only current jdk9 Reviewers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Coleen Phillimore > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > From christian.thalinger at oracle.com Tue Jun 17 15:33:28 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 17 Jun 2014 08:33:28 -0700 Subject: RFR 6642881: Improve performance of Class.getClassLoader() In-Reply-To: <53A05612.90406@oracle.com> References: <539F1066.8080302@oracle.com> <539F2D41.7040901@oracle.com> <539F2E75.1050301@oracle.com> <539F56E9.3060705@oracle.com> <539FD28B.7000201@oracle.com> <53A04BE2.90202@oracle.com> <53A05612.90406@oracle.com> Message-ID: <37561C6A-4AB5-4EB5-AF66-A6B37D3F6871@oracle.com> On Jun 17, 2014, at 7:52 AM, Coleen Phillimore wrote: > > On 6/17/14, 10:08 AM, roger riggs wrote: >> Hi, >> >> I'd favor David's suggestion also, omitting the constructor and initializing to null. > > I think I can't actually do this because as a final field, won't the JIT optimize it to always be null? Coleen and I talked about this. Currently, AFAIK, our JITs don?t do this but we might in the future (or someone else when we are all not around anymore). I suggested this solution to be future-proof. > > Coleen > >> >> Roger >> >> On 6/17/2014 1:30 AM, David Holmes wrote: >>> On 17/06/2014 6:43 AM, Coleen Phillimore wrote: >>>> >>>> On 6/16/14, 1:50 PM, roger riggs wrote: >>>>> Hi Colleen, >>>>> >>>>> In Class.java, if only the VM creates Class objects (comment at line >>>>> 681), >>>>> and it does not use the constructor then the code (line 136) in the >>>>> constructor >>>>> to set classloader is misleading and deserves a comment. >>>> >>>> Thanks, Roger. How about this comment? >>>> >>>> /* >>>> * Constructor. Only the Java Virtual Machine creates Class >>>> * objects, but this constructor prevents a warning that >>>> classLoader is not >>>> * initialized. >>>> */ >>>> private Class(ClassLoader loader) { >>>> classLoader = loader; >>>> } >>> >>> Why not just initialize classloader to null when it is declared and leave the constructor alone? The constructor exists to prevent javac from creating a default constructor, and thus ensuring Class instances can not be created (which is what the original comment should, but doesn't quite, say). >>> >>> David >>> >>>> Coleen >>>>> >>>>> Roger >>>>> >>>>> On 6/16/2014 1:45 PM, Lois Foltan wrote: >>>>>> Hi Coleen, >>>>>> This looks good. >>>>>> Lois >>>>>> >>>>>> On 6/16/2014 11:42 AM, Coleen Phillimore wrote: >>>>>>> Summary: Add classLoader to java/lang/Class instance for fast access >>>>>>> >>>>>>> In order to improve performance of Class.getClassLoader() in a way >>>>>>> to allow the compilers to automatically optimize this call, I added >>>>>>> the classLoader to the instance of java/lang/Class. For >>>>>>> microbenchmarks, this results in a 98% improvement, which was >>>>>>> expected. For Oracle internal applications, this results in a >>>>>>> 10-12% improvement on solaris/sparc. The increase in size of >>>>>>> java/lang/Class can be offset by other changes (removing constant >>>>>>> pool lock, or removing signers). >>>>>>> >>>>>>> See bug link https://bugs.openjdk.java.net/browse/JDK-6642881 and >>>>>>> associated linked bugs for more details. >>>>>>> >>>>>>> open webrev at http://cr.openjdk.java.net/~coleenp/6642881_hotspot/ >>>>>>> open webrev at http://cr.openjdk.java.net/~coleenp/6642881_jdk/ >>>>>>> >>>>>>> There is both hotspot and jdk changes for this change. The hotspot >>>>>>> changes can work without the jdk changes (check for optional field), >>>>>>> but not vice-versa. I'll file another bug (and compatibility >>>>>>> request) to remove JVM_GetClassLoader from hotspot. >>>>>>> >>>>>>> Tested with jck lang, vm, api/java_lang tests with/without jdk >>>>>>> change, nsk vm.quick.testlist and hotspot jtreg tests, and jprt. >>>>>>> >>>>>>> Thanks, >>>>>>> Coleen >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >> > From alejandro.murillo at oracle.com Tue Jun 17 18:57:22 2014 From: alejandro.murillo at oracle.com (Alejandro E Murillo) Date: Tue, 17 Jun 2014 12:57:22 -0600 Subject: jdk9-dev: HotSpot Message-ID: <53A08F92.9060903@oracle.com> jdk9-hs-2014-06-13 has been integrated into jdk9-dev. http://hg.openjdk.java.net/jdk9/dev/rev/ee2c182bef63 http://hg.openjdk.java.net/jdk9/dev/corba/rev/77565aaaa2bb http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/fedc61f9456a http://hg.openjdk.java.net/jdk9/dev/jaxp/rev/96e08eda44ce http://hg.openjdk.java.net/jdk9/dev/jaxws/rev/275f2385aed8 http://hg.openjdk.java.net/jdk9/dev/jdk/rev/34722d62436d http://hg.openjdk.java.net/jdk9/dev/langtools/rev/b4d1f317b2cc http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/1a9340351629 Component : VM Status : 0 major failures, 0 minor failures Date : 05/27/2014 at 22:00 MSK Tested By : VM SQE &dmitry.fazunenko at oracle.com Cost(total man-days): 0 Workspace : 2014-06-13-193550.amurillo.jdk9-hs-2014-06-13-jdk9-dev-control Bundles : 2014-06-13-193550.amurillo.jdk9-hs-2014-06-13-jdk9-dev-control Platforms : Others Tests : link Log : link Browsers : NA Patches : NA Number of Tests Executed: 266472 passed tests, 2584 failed tests (339 new failures) Bug verification status: ====================================== Tested, Pass: Tested, Pass (partial fixes): Tested, Fail: Untested bug fixes: Setup is not available: Bugs in PIT build: Number of PIT requested: 1 Integration target J2SE build number: Issues and Notes: There was no detailed analysis for this PIT. I look through the failures quickly. Go for integration -- Alejandro From brent.christian at oracle.com Tue Jun 17 23:43:31 2014 From: brent.christian at oracle.com (Brent Christian) Date: Tue, 17 Jun 2014 16:43:31 -0700 Subject: CFV: New JDK 9 Committer: Pavel Rappo In-Reply-To: <5398364E.2090409@oracle.com> References: <5398364E.2090409@oracle.com> Message-ID: <53A0D2A3.5050305@oracle.com> Vote: yes On 6/11/14 3:58 AM, Chris Hegarty wrote: > I hereby nominate Pavel Rappo (prappo) to JDK 9 Committer. From david.holmes at oracle.com Wed Jun 18 01:49:15 2014 From: david.holmes at oracle.com (David Holmes) Date: Wed, 18 Jun 2014 11:49:15 +1000 Subject: RFR 6642881: Improve performance of Class.getClassLoader() In-Reply-To: <37561C6A-4AB5-4EB5-AF66-A6B37D3F6871@oracle.com> References: <539F1066.8080302@oracle.com> <539F2D41.7040901@oracle.com> <539F2E75.1050301@oracle.com> <539F56E9.3060705@oracle.com> <539FD28B.7000201@oracle.com> <53A04BE2.90202@oracle.com> <53A05612.90406@oracle.com> <37561C6A-4AB5-4EB5-AF66-A6B37D3F6871@oracle.com> Message-ID: <53A0F01B.8030702@oracle.com> On 18/06/2014 1:33 AM, Christian Thalinger wrote: > > On Jun 17, 2014, at 7:52 AM, Coleen Phillimore wrote: > >> >> On 6/17/14, 10:08 AM, roger riggs wrote: >>> Hi, >>> >>> I'd favor David's suggestion also, omitting the constructor and initializing to null. First I didn't suggest ommitting the constructor, but leaving the existing constructor alone. There must be a private constructor present to stop javac from generating one. >> I think I can't actually do this because as a final field, won't the JIT optimize it to always be null? > > Coleen and I talked about this. Currently, AFAIK, our JITs don?t do this but we might in the future (or someone else when we are all not around anymore). I suggested this solution to be future-proof. I can't quite envisage how the JIT would go and look at the bytecode for the initializer to see that it was null, but ... David >> >> Coleen >> >>> >>> Roger >>> >>> On 6/17/2014 1:30 AM, David Holmes wrote: >>>> On 17/06/2014 6:43 AM, Coleen Phillimore wrote: >>>>> >>>>> On 6/16/14, 1:50 PM, roger riggs wrote: >>>>>> Hi Colleen, >>>>>> >>>>>> In Class.java, if only the VM creates Class objects (comment at line >>>>>> 681), >>>>>> and it does not use the constructor then the code (line 136) in the >>>>>> constructor >>>>>> to set classloader is misleading and deserves a comment. >>>>> >>>>> Thanks, Roger. How about this comment? >>>>> >>>>> /* >>>>> * Constructor. Only the Java Virtual Machine creates Class >>>>> * objects, but this constructor prevents a warning that >>>>> classLoader is not >>>>> * initialized. >>>>> */ >>>>> private Class(ClassLoader loader) { >>>>> classLoader = loader; >>>>> } >>>> >>>> Why not just initialize classloader to null when it is declared and leave the constructor alone? The constructor exists to prevent javac from creating a default constructor, and thus ensuring Class instances can not be created (which is what the original comment should, but doesn't quite, say). >>>> >>>> David >>>> >>>>> Coleen >>>>>> >>>>>> Roger >>>>>> >>>>>> On 6/16/2014 1:45 PM, Lois Foltan wrote: >>>>>>> Hi Coleen, >>>>>>> This looks good. >>>>>>> Lois >>>>>>> >>>>>>> On 6/16/2014 11:42 AM, Coleen Phillimore wrote: >>>>>>>> Summary: Add classLoader to java/lang/Class instance for fast access >>>>>>>> >>>>>>>> In order to improve performance of Class.getClassLoader() in a way >>>>>>>> to allow the compilers to automatically optimize this call, I added >>>>>>>> the classLoader to the instance of java/lang/Class. For >>>>>>>> microbenchmarks, this results in a 98% improvement, which was >>>>>>>> expected. For Oracle internal applications, this results in a >>>>>>>> 10-12% improvement on solaris/sparc. The increase in size of >>>>>>>> java/lang/Class can be offset by other changes (removing constant >>>>>>>> pool lock, or removing signers). >>>>>>>> >>>>>>>> See bug link https://bugs.openjdk.java.net/browse/JDK-6642881 and >>>>>>>> associated linked bugs for more details. >>>>>>>> >>>>>>>> open webrev at http://cr.openjdk.java.net/~coleenp/6642881_hotspot/ >>>>>>>> open webrev at http://cr.openjdk.java.net/~coleenp/6642881_jdk/ >>>>>>>> >>>>>>>> There is both hotspot and jdk changes for this change. The hotspot >>>>>>>> changes can work without the jdk changes (check for optional field), >>>>>>>> but not vice-versa. I'll file another bug (and compatibility >>>>>>>> request) to remove JVM_GetClassLoader from hotspot. >>>>>>>> >>>>>>>> Tested with jck lang, vm, api/java_lang tests with/without jdk >>>>>>>> change, nsk vm.quick.testlist and hotspot jtreg tests, and jprt. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Coleen >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>> >> > From alejandro.murillo at oracle.com Wed Jun 18 02:23:53 2014 From: alejandro.murillo at oracle.com (Alejandro E Murillo) Date: Tue, 17 Jun 2014 20:23:53 -0600 Subject: CFV: New JDK 9 Committer: Pavel Rappo In-Reply-To: <5398364E.2090409@oracle.com> References: <5398364E.2090409@oracle.com> Message-ID: <53A0F839.5050707@oracle.com> vote: yes On 6/11/2014 4:58 AM, Chris Hegarty wrote: > I hereby nominate Pavel Rappo (prappo) to JDK 9 Committer. -- Alejandro From simone.bordet at gmail.com Wed Jun 18 06:54:13 2014 From: simone.bordet at gmail.com (Simone Bordet) Date: Wed, 18 Jun 2014 08:54:13 +0200 Subject: TLS extensions API, ALPN and HTTP 2.0 Message-ID: Hi, I would like to reboot a discussion around an improved TLS extensions API in order to support ALPN (see http://tools.ietf.org/html/draft-ietf-tls-applayerprotoneg), which is the mechanism required by HTTP 2.0 to negotiate the new version of the HTTP protocol. I sent a previous message hoping that such work would have been included in JDK 8, but it was too late, see http://mail.openjdk.java.net/pipermail/jdk8-dev/2013-March/002197.html. I think this needs to be addressed so that a future version of the Servlet specification can be implemented without requiring the hacks described below. Under the Jetty project, we have implemented ALPN as a set of patches to JDK classes, producing a jar that must be prepended to the boot classpath in order for ALPN to work, see https://www.eclipse.org/jetty/documentation/current/alpn-chapter.html. The downside of this is that for every JDK release the ALPN jar may need to be rebuilt incorporating JDK changes. While this solution works, it would be great to have a clear API in the JDK that would allow to do add the required TLS extension without requiring patched classes and boot classpath jars. I apologize if this is not the right list to ask these questions, and I'll be glad to be redirected to the proper list. A) Is there any plan to add a generic TLS extensions API to JDK 9 ? B) Is there a plan, perhaps in concert with the Servlet EG, to prepare to support ALPN in order to support HTTP 2.0 ? C) What would be the process to start the effort to add a TLS extensions API to the JDK ? Start a new JEP ? Thanks ! -- Simone Bordet http://bordet.blogspot.com --- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal performance and reliability, the implementation technique must be flawless. Victoria Livschitz From xuelei.fan at oracle.com Wed Jun 18 07:52:26 2014 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 18 Jun 2014 15:52:26 +0800 Subject: TLS extensions API, ALPN and HTTP 2.0 In-Reply-To: References: Message-ID: <53A1453A.4070406@oracle.com> Hi, Thank you very much for the enhancement proposal. It is on the radar of us for JDK 9. However, because this specification is still in draft status, I may not consider it as a priority unless it is accepted as the position of IEFT. Contributions are welcome to OpenJDK community. If the enhancement is small (less than 2 weeks of engineering effort), it can be contributed as a patch[1]. Otherwise, better to submit as a JEP[2]. I think the best place to address this proposal is in JSSE component. security-dev at openjdk.java.net is the alias to talk about JSSE related issues. Regards, Xuelei [1]: http://openjdk.java.net/contribute/ [2]: http://openjdk.java.net/jeps/0 On 6/18/2014 2:54 PM, Simone Bordet wrote: > Hi, > > I would like to reboot a discussion around an improved TLS extensions > API in order to support ALPN (see > http://tools.ietf.org/html/draft-ietf-tls-applayerprotoneg), which is > the mechanism required by HTTP 2.0 to negotiate the new version of the > HTTP protocol. > > I sent a previous message hoping that such work would have been > included in JDK 8, but it was too late, see > http://mail.openjdk.java.net/pipermail/jdk8-dev/2013-March/002197.html. > > I think this needs to be addressed so that a future version of the > Servlet specification can be implemented without requiring the hacks > described below. > > Under the Jetty project, we have implemented ALPN as a set of patches > to JDK classes, producing a jar that must be prepended to the boot > classpath in order for ALPN to work, see > https://www.eclipse.org/jetty/documentation/current/alpn-chapter.html. > The downside of this is that for every JDK release the ALPN jar may > need to be rebuilt incorporating JDK changes. > > While this solution works, it would be great to have a clear API in > the JDK that would allow to do add the required TLS extension without > requiring patched classes and boot classpath jars. > > I apologize if this is not the right list to ask these questions, and > I'll be glad to be redirected to the proper list. > > A) Is there any plan to add a generic TLS extensions API to JDK 9 ? > B) Is there a plan, perhaps in concert with the Servlet EG, to prepare > to support ALPN in order to support HTTP 2.0 ? > C) What would be the process to start the effort to add a TLS > extensions API to the JDK ? Start a new JEP ? > > Thanks ! > From lana.steuck at oracle.com Wed Jun 18 17:36:06 2014 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 18 Jun 2014 10:36:06 -0700 (PDT) Subject: jdk9-b19: dev Message-ID: <201406181736.s5IHa69N008254@jano-app.us.oracle.com> http://hg.openjdk.java.net/jdk9/jdk9/rev/75a08df650eb http://hg.openjdk.java.net/jdk9/jdk9/nashorn/rev/46e36a92e37c http://hg.openjdk.java.net/jdk9/jdk9/langtools/rev/a9accd7c4415 http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/27561aede285 http://hg.openjdk.java.net/jdk9/jdk9/jaxws/rev/7f922a73e8a2 http://hg.openjdk.java.net/jdk9/jdk9/jaxp/rev/f9c82769a6bc http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/d4cffb3ae621 http://hg.openjdk.java.net/jdk9/jdk9/corba/rev/eecc1b6adc7e --- All the fixes will be tested during promotion (no PIT testing at this point): List of all fixes: =================== JDK-8029674 core-libs (reflect) getMethods returns default methods that are not members of the class JDK-8044798 core-libs API for debugging Nashorn JDK-8046025 core-libs AccessorProperty.getGetter is not threadsafe JDK-8043954 core-libs Behavior difference when connect() is interrupted by signal on AIX JDK-8044740 core-libs Convert all JDK versions used in @since tag to 1.n[.n] in jdk repo JDK-8046234 core-libs Exclude closed/java/text/Format/DateFormat/DateFormatTest.java from the test run JDK-8046085 core-libs HashMap.put with null key may throw NullPointerException JDK-8027308 core-libs HttpURLConnection should better handle URLs with literal IPv6 addresses JDK-8032400 core-libs JSR292: invokeSpecial: InternalError attempting to lookup a method JDK-8038864 core-libs Remove com.oracle.util.Checksums JDK-8044517 core-libs Run & debug single Nashorn test JDK-8046215 core-libs Running uncompilable scripts throws NullPointerException JDK-8004807 core-libs TEST_BUG: java/util/Timer/Args.java failing intermittently in HS testing JDK-8042451 core-libs Write tests for all possible kinds of type annotation JDK-8045998 core-libs closed/java/text/Format/DateFormat/DateFormatTest.java failing since June 4, 2014 JDK-8044135 core-svc Add API to start JMX agent from attach framework JDK-8044865 core-svc Fix raw and unchecked lint warnings in management-related code JDK-8043613 globalization Update .properties files for serialver tool JDK-8044398 hotspot Attach code should propagate errors in Diagnostic Commands as errors JDK-8044768 hotspot Backout fix for JDK-8040807 JDK-8043896 hotspot Error reporting for insufficient shared region size is incorrect JDK-8044531 hotspot Event based tracing locks to rank as leafs where possible JDK-8044838 hotspot Fix raw warnings in oracle.jrockit.jfr.* JDK-8040807 hotspot G1: Enable G1CollectedHeap::stop() JDK-8043239 hotspot G1: Missing post barrier in processing of j.l.ref.Reference objects JDK-8043086 hotspot Hotspot is expected to report OOM which is occurred String.intern(), but crashes in JDK8u5 JDK-8044132 hotspot Quarantine unstable/broken GC tests JDK-8041623 hotspot Solaris Studio 12.4 C++ 5.13, CHECK_UNHANDLED_OOPS use of class oop's copy constructor definitions causing error level diagnostic JDK-8036823 hotspot Stack trace sometimes shows 'locked' instead of 'waiting to lock' JDK-8022236 hotspot Test closed/com/oracle/jfr/compiler/TestAllocObjectInNewTLABEvent.java fails with G1 JDK-8042310 hotspot TestStringDeduplicationMemoryUsage test failing JDK-8043915 hotspot Tests get ClassNotFoundException: com.oracle.java.testlibrary.StreamPumper JDK-8038587 hotspot [TESTBUG] Create CDS tests to exercise region sizes and base address JDK-8026153 hotspot [TESTBUG] closed/runtime/4805573/X.java fails with OOME JDK-8043786 hotspot [TESTBUG] runtime/CommandLine/TestHexArguments.java test fails in nightly JDK-8044364 hotspot [TESTBUG] runtime/RedefineFinalizer test fails on windows JDK-8037513 hotspot [TESTBUG] runtime/negAttrLength/NegativeAttributeLength.java should be more strict JDK-8042933 hotspot assert(capacity_until_gc >= committed_bytes) failed JDK-6904403 hotspot assert(f == k->has_finalizer(),"inconsistent has_finalizer") with debug VM JDK-8038132 hotspot jprt bundles have libjsig.dylib in different place on OSX JDK-8046368 security-libs Code cleanup in SeedGenerator.java JDK-8023197 security-libs Pre-configured command line options for keytool and jarsigner JDK-8039212 security-libs SecretKeyBasic.sh needs to avoid NSS libnss3 and libsoftokn3 version mismatches JDK-8040812 security-libs Uninitialised memory in jdk/src/share/native/sun/security/ec/impl/mpi.c JDK-8044747 security-libs [TESTBUG] Test sun/security/tools/policytool/i18n.sh fails after clicking 'Done' button in test frame JDK-8046702 security-libs default_options.sh test failure on Solaris JDK-8046499 security-libs nativecache.c prints to stdout in debug build JDK-7026941 tools 199: path options ignored when reusing filemanager across tasks JDK-8015101 tools Covariance of return type implied by upper bounding on type parameter is ignored JDK-8043484 tools DPrinter does not compile JDK-8027262 tools Determine location for type annotations earlier in compiler pipeline JDK-8043669 tools Few of the ANNOT tests in JCK9 test suite fail with an AssertionError for exception_index JDK-8027182 tools Incorrect annotation attributes for type annotations on constructor type parameters JDK-8027258 tools Permit a single source annotation to generate multiple bytecode annotations JDK-8029042 tools Receiver parameter not supported on local class constructor JDK-8037348 tools RuntimeInvisibleAnnotations should not be generated for type annotation on anonymous innerclass creation JDK-8027261 tools Single codepath for attaching annotations to symbols JDK-8046296 tools TEST java/util/concurrent/BlockingQueue/PollMemoryLeak.java fails in nightly on all platform due to compiler issue JDK-8042060 tools Type parameter annotations don't work with multiple type parameters JDK-8043974 tools TypeAnnotation attribute is not generated for repeatable annotation in lambda JDK-8044009 tools TypeAnnotation attribute is not generated for repeatable annotation in nested types. JDK-8044010 tools TypeAnnotation attribute is not generated for repeatable annotation in type argument JDK-8037385 tools constant pool errors with -target 1.7 and static default methods JDK-8033414 tools javac Plugin to receive notification (before and) after the compilation. JDK-8027886 tools javac allows illegal receiver parameters JDK-8043725 tools javac fails with StackOverflowException JDK-8046443 xml A few typos in JAXP JavaDoc JDK-8041523 xml Xerces Update: Serializer improvements from Xalan From mandy.chung at oracle.com Wed Jun 18 18:16:33 2014 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 18 Jun 2014 11:16:33 -0700 Subject: RFR 6642881: Improve performance of Class.getClassLoader() In-Reply-To: <539FD28B.7000201@oracle.com> References: <539F1066.8080302@oracle.com> <539F2D41.7040901@oracle.com> <539F2E75.1050301@oracle.com> <539F56E9.3060705@oracle.com> <539FD28B.7000201@oracle.com> Message-ID: <53A1D781.7070704@oracle.com> Hi Coleen, I'm glad to see this change to go in. Thanks for doing this. The jdk change looks good. Minor comment: 684 // Initialized in JVM not by fake constructor 685 private final ClassLoader classLoader; I prefer to say "Initialized in JVM not by the private constructor" and the comment of the private constructor perhaps can say: /* * Private constructor.Only the Java Virtual Machine creates Class * objects. This constructor is not used and JVM directly injects * value of the instance fields. */ private Class(ClassLoader loader) { classLoader = loader; } And It may be worth to mention that the classLoader field is initialized to the given loader parameter instead of null to prepare for possible future JIT optimization. I didn't review the hotspot change. The new classLoader field is not in CLASS_INJECTED_FIELDS - is it just temporary to avoid the synchronized jdk/hotspot change? What if you push both changes through the same forest jdk9/hs-rt? A side note - Christian has a patch attached in this bug that can improve the performance when running with SecurityManager on the classloader related check for permission. Can you create a new bug to track that so that it won't get lost once this bug is resolved? thanks Mandy On 6/16/2014 10:30 PM, David Holmes wrote: > On 17/06/2014 6:43 AM, Coleen Phillimore wrote: >> >> >> /* >> * Constructor. Only the Java Virtual Machine creates Class >> * objects, but this constructor prevents a warning that >> classLoader is not >> * initialized. >> */ >> private Class(ClassLoader loader) { >> classLoader = loader; >> } > > Why not just initialize classloader to null when it is declared and > leave the constructor alone? The constructor exists to prevent javac > from creating a default constructor, and thus ensuring Class instances > can not be created (which is what the original comment should, but > doesn't quite, say). > > David > >> Coleen >>> >>> Roger >>> >>> On 6/16/2014 1:45 PM, Lois Foltan wrote: >>>> Hi Coleen, >>>> This looks good. >>>> Lois >>>> >>>> On 6/16/2014 11:42 AM, Coleen Phillimore wrote: >>>>> Summary: Add classLoader to java/lang/Class instance for fast access >>>>> >>>>> In order to improve performance of Class.getClassLoader() in a way >>>>> to allow the compilers to automatically optimize this call, I added >>>>> the classLoader to the instance of java/lang/Class. For >>>>> microbenchmarks, this results in a 98% improvement, which was >>>>> expected. For Oracle internal applications, this results in a >>>>> 10-12% improvement on solaris/sparc. The increase in size of >>>>> java/lang/Class can be offset by other changes (removing constant >>>>> pool lock, or removing signers). >>>>> >>>>> See bug link https://bugs.openjdk.java.net/browse/JDK-6642881 and >>>>> associated linked bugs for more details. >>>>> >>>>> open webrev at http://cr.openjdk.java.net/~coleenp/6642881_hotspot/ >>>>> open webrev at http://cr.openjdk.java.net/~coleenp/6642881_jdk/ >>>>> >>>>> There is both hotspot and jdk changes for this change. The hotspot >>>>> changes can work without the jdk changes (check for optional field), >>>>> but not vice-versa. I'll file another bug (and compatibility >>>>> request) to remove JVM_GetClassLoader from hotspot. >>>>> >>>>> Tested with jck lang, vm, api/java_lang tests with/without jdk >>>>> change, nsk vm.quick.testlist and hotspot jtreg tests, and jprt. >>>>> >>>>> Thanks, >>>>> Coleen >>>>> >>>>> >>>> >>> >> From coleen.phillimore at oracle.com Wed Jun 18 18:35:33 2014 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 18 Jun 2014 14:35:33 -0400 Subject: RFR 6642881: Improve performance of Class.getClassLoader() In-Reply-To: <53A1D781.7070704@oracle.com> References: <539F1066.8080302@oracle.com> <539F2D41.7040901@oracle.com> <539F2E75.1050301@oracle.com> <539F56E9.3060705@oracle.com> <539FD28B.7000201@oracle.com> <53A1D781.7070704@oracle.com> Message-ID: <53A1DBF5.2090607@oracle.com> Mandy, Thanks for looking at this. On 6/18/14, 2:16 PM, Mandy Chung wrote: > Hi Coleen, > > I'm glad to see this change to go in. Thanks for doing this. The jdk > change looks good. Minor comment: > > 684 // Initialized in JVM not by fake constructor > 685 private final ClassLoader classLoader; > > I prefer to say "Initialized in JVM not by the private constructor" Okay. I made this change. > and the comment of the private constructor perhaps can say: > > /* > * Private constructor.Only the Java Virtual Machine creates Class > * objects. This constructor is not used and JVM directly injects > * value of the instance fields. > */ > private Class(ClassLoader loader) { > classLoader = loader; > } > > And It may be worth to mention that the classLoader field is > initialized to > the given loader parameter instead of null to prepare for possible > future JIT optimization. How about (see below about injected fields): /* * Private constructor. Only the Java Virtual Machine creates Class * objects. This constructor is not used but prevents a warning that * classLoader is not initialized. The initialization value of non-null * prevents future JIT optimizations from assuming this final field is null. */ > > I didn't review the hotspot change. The new classLoader field is not > in CLASS_INJECTED_FIELDS - is it just temporary to avoid the synchronized > jdk/hotspot change? What if you push both changes through the same > forest jdk9/hs-rt? The new field classLoader is explicit and not injected by the jvm. The jvm looks up the offset of the field when it lays out the class Class and initializes it directly in the instance of java.lang.Class. So it isn't added to the injected fields. > > A side note - Christian has a patch attached in this bug that can > improve the performance when running with SecurityManager on the > classloader related check for permission. Can you create a new > bug to track that so that it won't get lost once this bug is > resolved? I didn't completely follow the relationship between Chris's patch and this bug. Yes, I'll file a new bug or ask someone who knows more about it to do so. Thanks! Coleen > > thanks > Mandy > > On 6/16/2014 10:30 PM, David Holmes wrote: >> On 17/06/2014 6:43 AM, Coleen Phillimore wrote: >>> >>> >>> /* >>> * Constructor. Only the Java Virtual Machine creates Class >>> * objects, but this constructor prevents a warning that >>> classLoader is not >>> * initialized. >>> */ >>> private Class(ClassLoader loader) { >>> classLoader = loader; >>> } >> >> Why not just initialize classloader to null when it is declared and >> leave the constructor alone? The constructor exists to prevent javac >> from creating a default constructor, and thus ensuring Class >> instances can not be created (which is what the original comment >> should, but doesn't quite, say). >> >> David >> >>> Coleen >>>> >>>> Roger >>>> >>>> On 6/16/2014 1:45 PM, Lois Foltan wrote: >>>>> Hi Coleen, >>>>> This looks good. >>>>> Lois >>>>> >>>>> On 6/16/2014 11:42 AM, Coleen Phillimore wrote: >>>>>> Summary: Add classLoader to java/lang/Class instance for fast access >>>>>> >>>>>> In order to improve performance of Class.getClassLoader() in a way >>>>>> to allow the compilers to automatically optimize this call, I added >>>>>> the classLoader to the instance of java/lang/Class. For >>>>>> microbenchmarks, this results in a 98% improvement, which was >>>>>> expected. For Oracle internal applications, this results in a >>>>>> 10-12% improvement on solaris/sparc. The increase in size of >>>>>> java/lang/Class can be offset by other changes (removing constant >>>>>> pool lock, or removing signers). >>>>>> >>>>>> See bug link https://bugs.openjdk.java.net/browse/JDK-6642881 and >>>>>> associated linked bugs for more details. >>>>>> >>>>>> open webrev at http://cr.openjdk.java.net/~coleenp/6642881_hotspot/ >>>>>> open webrev at http://cr.openjdk.java.net/~coleenp/6642881_jdk/ >>>>>> >>>>>> There is both hotspot and jdk changes for this change. The hotspot >>>>>> changes can work without the jdk changes (check for optional field), >>>>>> but not vice-versa. I'll file another bug (and compatibility >>>>>> request) to remove JVM_GetClassLoader from hotspot. >>>>>> >>>>>> Tested with jck lang, vm, api/java_lang tests with/without jdk >>>>>> change, nsk vm.quick.testlist and hotspot jtreg tests, and jprt. >>>>>> >>>>>> Thanks, >>>>>> Coleen >>>>>> >>>>>> >>>>> >>>> >>> > From coleen.phillimore at oracle.com Wed Jun 18 18:37:25 2014 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 18 Jun 2014 14:37:25 -0400 Subject: RFR 6642881: Improve performance of Class.getClassLoader() In-Reply-To: <53A1D781.7070704@oracle.com> References: <539F1066.8080302@oracle.com> <539F2D41.7040901@oracle.com> <539F2E75.1050301@oracle.com> <539F56E9.3060705@oracle.com> <539FD28B.7000201@oracle.com> <53A1D781.7070704@oracle.com> Message-ID: <53A1DC65.1020304@oracle.com> Hi, I missed a question. On 6/18/14, 2:16 PM, Mandy Chung wrote: > Hi Coleen, > > I'm glad to see this change to go in. Thanks for doing this. The jdk > change looks good. Minor comment: > > 684 // Initialized in JVM not by fake constructor > 685 private final ClassLoader classLoader; > > I prefer to say "Initialized in JVM not by the private constructor" > and the comment of the private constructor perhaps can say: > > /* > * Private constructor.Only the Java Virtual Machine creates Class > * objects. This constructor is not used and JVM directly injects > * value of the instance fields. > */ > private Class(ClassLoader loader) { > classLoader = loader; > } > > And It may be worth to mention that the classLoader field is > initialized to > the given loader parameter instead of null to prepare for possible > future JIT optimization. > > I didn't review the hotspot change. The new classLoader field is not > in CLASS_INJECTED_FIELDS - is it just temporary to avoid the synchronized > jdk/hotspot change? What if you push both changes through the same > forest jdk9/hs-rt? The plan is to push both through hs-rt. The jdk changes don't work without the jvm changes but I think that's fine because both will hit jdk9/dev at the same time. I've prewarned the gatekeepers and Alejandro. The hotspot change works without the jdk change because most people on hotspot don't build full jdks during development (yet). Thanks, Coleen > > A side note - Christian has a patch attached in this bug that can > improve the performance when running with SecurityManager on the > classloader related check for permission. Can you create a new > bug to track that so that it won't get lost once this bug is > resolved? > > thanks > Mandy > > On 6/16/2014 10:30 PM, David Holmes wrote: >> On 17/06/2014 6:43 AM, Coleen Phillimore wrote: >>> >>> >>> /* >>> * Constructor. Only the Java Virtual Machine creates Class >>> * objects, but this constructor prevents a warning that >>> classLoader is not >>> * initialized. >>> */ >>> private Class(ClassLoader loader) { >>> classLoader = loader; >>> } >> >> Why not just initialize classloader to null when it is declared and >> leave the constructor alone? The constructor exists to prevent javac >> from creating a default constructor, and thus ensuring Class >> instances can not be created (which is what the original comment >> should, but doesn't quite, say). >> >> David >> >>> Coleen >>>> >>>> Roger >>>> >>>> On 6/16/2014 1:45 PM, Lois Foltan wrote: >>>>> Hi Coleen, >>>>> This looks good. >>>>> Lois >>>>> >>>>> On 6/16/2014 11:42 AM, Coleen Phillimore wrote: >>>>>> Summary: Add classLoader to java/lang/Class instance for fast access >>>>>> >>>>>> In order to improve performance of Class.getClassLoader() in a way >>>>>> to allow the compilers to automatically optimize this call, I added >>>>>> the classLoader to the instance of java/lang/Class. For >>>>>> microbenchmarks, this results in a 98% improvement, which was >>>>>> expected. For Oracle internal applications, this results in a >>>>>> 10-12% improvement on solaris/sparc. The increase in size of >>>>>> java/lang/Class can be offset by other changes (removing constant >>>>>> pool lock, or removing signers). >>>>>> >>>>>> See bug link https://bugs.openjdk.java.net/browse/JDK-6642881 and >>>>>> associated linked bugs for more details. >>>>>> >>>>>> open webrev at http://cr.openjdk.java.net/~coleenp/6642881_hotspot/ >>>>>> open webrev at http://cr.openjdk.java.net/~coleenp/6642881_jdk/ >>>>>> >>>>>> There is both hotspot and jdk changes for this change. The hotspot >>>>>> changes can work without the jdk changes (check for optional field), >>>>>> but not vice-versa. I'll file another bug (and compatibility >>>>>> request) to remove JVM_GetClassLoader from hotspot. >>>>>> >>>>>> Tested with jck lang, vm, api/java_lang tests with/without jdk >>>>>> change, nsk vm.quick.testlist and hotspot jtreg tests, and jprt. >>>>>> >>>>>> Thanks, >>>>>> Coleen >>>>>> >>>>>> >>>>> >>>> >>> > From karen.kinnear at oracle.com Wed Jun 18 19:09:54 2014 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Wed, 18 Jun 2014 15:09:54 -0400 Subject: RFR 6642881: Improve performance of Class.getClassLoader() In-Reply-To: <53A1DC65.1020304@oracle.com> References: <539F1066.8080302@oracle.com> <539F2D41.7040901@oracle.com> <539F2E75.1050301@oracle.com> <539F56E9.3060705@oracle.com> <539FD28B.7000201@oracle.com> <53A1D781.7070704@oracle.com> <53A1DC65.1020304@oracle.com> Message-ID: <1F34CCB0-0DE6-4998-84BD-BD773BA6584A@oracle.com> What happens if folks do a full jdk build during development? Can you send a warning? There are folks doing that. thanks, Karen On Jun 18, 2014, at 2:37 PM, Coleen Phillimore wrote: > > Hi, I missed a question. > > On 6/18/14, 2:16 PM, Mandy Chung wrote: >> Hi Coleen, >> >> I'm glad to see this change to go in. Thanks for doing this. The jdk change looks good. Minor comment: >> >> 684 // Initialized in JVM not by fake constructor >> 685 private final ClassLoader classLoader; >> >> I prefer to say "Initialized in JVM not by the private constructor" >> and the comment of the private constructor perhaps can say: >> >> /* >> * Private constructor.Only the Java Virtual Machine creates Class >> * objects. This constructor is not used and JVM directly injects >> * value of the instance fields. >> */ >> private Class(ClassLoader loader) { >> classLoader = loader; >> } >> >> And It may be worth to mention that the classLoader field is initialized to >> the given loader parameter instead of null to prepare for possible future JIT optimization. >> >> I didn't review the hotspot change. The new classLoader field is not >> in CLASS_INJECTED_FIELDS - is it just temporary to avoid the synchronized >> jdk/hotspot change? What if you push both changes through the same forest jdk9/hs-rt? > > The plan is to push both through hs-rt. The jdk changes don't work without the jvm changes but I think that's fine because both will hit jdk9/dev at the same time. I've prewarned the gatekeepers and Alejandro. The hotspot change works without the jdk change because most people on hotspot don't build full jdks during development (yet). > > Thanks, > Coleen >> >> A side note - Christian has a patch attached in this bug that can >> improve the performance when running with SecurityManager on the >> classloader related check for permission. Can you create a new >> bug to track that so that it won't get lost once this bug is >> resolved? >> >> thanks >> Mandy >> >> On 6/16/2014 10:30 PM, David Holmes wrote: >>> On 17/06/2014 6:43 AM, Coleen Phillimore wrote: >>>> >>>> >>>> /* >>>> * Constructor. Only the Java Virtual Machine creates Class >>>> * objects, but this constructor prevents a warning that >>>> classLoader is not >>>> * initialized. >>>> */ >>>> private Class(ClassLoader loader) { >>>> classLoader = loader; >>>> } >>> >>> Why not just initialize classloader to null when it is declared and leave the constructor alone? The constructor exists to prevent javac from creating a default constructor, and thus ensuring Class instances can not be created (which is what the original comment should, but doesn't quite, say). >>> >>> David >>> >>>> Coleen >>>>> >>>>> Roger >>>>> >>>>> On 6/16/2014 1:45 PM, Lois Foltan wrote: >>>>>> Hi Coleen, >>>>>> This looks good. >>>>>> Lois >>>>>> >>>>>> On 6/16/2014 11:42 AM, Coleen Phillimore wrote: >>>>>>> Summary: Add classLoader to java/lang/Class instance for fast access >>>>>>> >>>>>>> In order to improve performance of Class.getClassLoader() in a way >>>>>>> to allow the compilers to automatically optimize this call, I added >>>>>>> the classLoader to the instance of java/lang/Class. For >>>>>>> microbenchmarks, this results in a 98% improvement, which was >>>>>>> expected. For Oracle internal applications, this results in a >>>>>>> 10-12% improvement on solaris/sparc. The increase in size of >>>>>>> java/lang/Class can be offset by other changes (removing constant >>>>>>> pool lock, or removing signers). >>>>>>> >>>>>>> See bug link https://bugs.openjdk.java.net/browse/JDK-6642881 and >>>>>>> associated linked bugs for more details. >>>>>>> >>>>>>> open webrev at http://cr.openjdk.java.net/~coleenp/6642881_hotspot/ >>>>>>> open webrev at http://cr.openjdk.java.net/~coleenp/6642881_jdk/ >>>>>>> >>>>>>> There is both hotspot and jdk changes for this change. The hotspot >>>>>>> changes can work without the jdk changes (check for optional field), >>>>>>> but not vice-versa. I'll file another bug (and compatibility >>>>>>> request) to remove JVM_GetClassLoader from hotspot. >>>>>>> >>>>>>> Tested with jck lang, vm, api/java_lang tests with/without jdk >>>>>>> change, nsk vm.quick.testlist and hotspot jtreg tests, and jprt. >>>>>>> >>>>>>> Thanks, >>>>>>> Coleen >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >> > From coleen.phillimore at oracle.com Wed Jun 18 19:17:36 2014 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 18 Jun 2014 15:17:36 -0400 Subject: RFR 6642881: Improve performance of Class.getClassLoader() In-Reply-To: <1F34CCB0-0DE6-4998-84BD-BD773BA6584A@oracle.com> References: <539F1066.8080302@oracle.com> <539F2D41.7040901@oracle.com> <539F2E75.1050301@oracle.com> <539F56E9.3060705@oracle.com> <539FD28B.7000201@oracle.com> <53A1D781.7070704@oracle.com> <53A1DC65.1020304@oracle.com> <1F34CCB0-0DE6-4998-84BD-BD773BA6584A@oracle.com> Message-ID: <53A1E5D0.3040203@oracle.com> On 6/18/14, 3:09 PM, Karen Kinnear wrote: > What happens if folks do a full jdk build during development? Can you send a warning? There > are folks doing that. They will get the right thing because the jdk/jvm changes will always be in the same repository. It's just the hotspot-only build people this is accommodating. Coleen > > thanks, > Karen > > On Jun 18, 2014, at 2:37 PM, Coleen Phillimore wrote: > >> Hi, I missed a question. >> >> On 6/18/14, 2:16 PM, Mandy Chung wrote: >>> Hi Coleen, >>> >>> I'm glad to see this change to go in. Thanks for doing this. The jdk change looks good. Minor comment: >>> >>> 684 // Initialized in JVM not by fake constructor >>> 685 private final ClassLoader classLoader; >>> >>> I prefer to say "Initialized in JVM not by the private constructor" >>> and the comment of the private constructor perhaps can say: >>> >>> /* >>> * Private constructor.Only the Java Virtual Machine creates Class >>> * objects. This constructor is not used and JVM directly injects >>> * value of the instance fields. >>> */ >>> private Class(ClassLoader loader) { >>> classLoader = loader; >>> } >>> >>> And It may be worth to mention that the classLoader field is initialized to >>> the given loader parameter instead of null to prepare for possible future JIT optimization. >>> >>> I didn't review the hotspot change. The new classLoader field is not >>> in CLASS_INJECTED_FIELDS - is it just temporary to avoid the synchronized >>> jdk/hotspot change? What if you push both changes through the same forest jdk9/hs-rt? >> The plan is to push both through hs-rt. The jdk changes don't work without the jvm changes but I think that's fine because both will hit jdk9/dev at the same time. I've prewarned the gatekeepers and Alejandro. The hotspot change works without the jdk change because most people on hotspot don't build full jdks during development (yet). >> >> Thanks, >> Coleen >>> A side note - Christian has a patch attached in this bug that can >>> improve the performance when running with SecurityManager on the >>> classloader related check for permission. Can you create a new >>> bug to track that so that it won't get lost once this bug is >>> resolved? >>> >>> thanks >>> Mandy >>> >>> On 6/16/2014 10:30 PM, David Holmes wrote: >>>> On 17/06/2014 6:43 AM, Coleen Phillimore wrote: >>>>> >>>>> /* >>>>> * Constructor. Only the Java Virtual Machine creates Class >>>>> * objects, but this constructor prevents a warning that >>>>> classLoader is not >>>>> * initialized. >>>>> */ >>>>> private Class(ClassLoader loader) { >>>>> classLoader = loader; >>>>> } >>>> Why not just initialize classloader to null when it is declared and leave the constructor alone? The constructor exists to prevent javac from creating a default constructor, and thus ensuring Class instances can not be created (which is what the original comment should, but doesn't quite, say). >>>> >>>> David >>>> >>>>> Coleen >>>>>> Roger >>>>>> >>>>>> On 6/16/2014 1:45 PM, Lois Foltan wrote: >>>>>>> Hi Coleen, >>>>>>> This looks good. >>>>>>> Lois >>>>>>> >>>>>>> On 6/16/2014 11:42 AM, Coleen Phillimore wrote: >>>>>>>> Summary: Add classLoader to java/lang/Class instance for fast access >>>>>>>> >>>>>>>> In order to improve performance of Class.getClassLoader() in a way >>>>>>>> to allow the compilers to automatically optimize this call, I added >>>>>>>> the classLoader to the instance of java/lang/Class. For >>>>>>>> microbenchmarks, this results in a 98% improvement, which was >>>>>>>> expected. For Oracle internal applications, this results in a >>>>>>>> 10-12% improvement on solaris/sparc. The increase in size of >>>>>>>> java/lang/Class can be offset by other changes (removing constant >>>>>>>> pool lock, or removing signers). >>>>>>>> >>>>>>>> See bug link https://bugs.openjdk.java.net/browse/JDK-6642881 and >>>>>>>> associated linked bugs for more details. >>>>>>>> >>>>>>>> open webrev at http://cr.openjdk.java.net/~coleenp/6642881_hotspot/ >>>>>>>> open webrev at http://cr.openjdk.java.net/~coleenp/6642881_jdk/ >>>>>>>> >>>>>>>> There is both hotspot and jdk changes for this change. The hotspot >>>>>>>> changes can work without the jdk changes (check for optional field), >>>>>>>> but not vice-versa. I'll file another bug (and compatibility >>>>>>>> request) to remove JVM_GetClassLoader from hotspot. >>>>>>>> >>>>>>>> Tested with jck lang, vm, api/java_lang tests with/without jdk >>>>>>>> change, nsk vm.quick.testlist and hotspot jtreg tests, and jprt. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Coleen >>>>>>>> >>>>>>>> From mandy.chung at oracle.com Wed Jun 18 19:27:39 2014 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 18 Jun 2014 12:27:39 -0700 Subject: RFR 6642881: Improve performance of Class.getClassLoader() In-Reply-To: <53A1DBF5.2090607@oracle.com> References: <539F1066.8080302@oracle.com> <539F2D41.7040901@oracle.com> <539F2E75.1050301@oracle.com> <539F56E9.3060705@oracle.com> <539FD28B.7000201@oracle.com> <53A1D781.7070704@oracle.com> <53A1DBF5.2090607@oracle.com> Message-ID: <53A1E82B.60109@oracle.com> On 6/18/2014 11:35 AM, Coleen Phillimore wrote: > > /* > * Private constructor. Only the Java Virtual Machine creates Class > * objects. This constructor is not used but prevents a warning that > * classLoader is not initialized. The initialization value of > non-null > * prevents future JIT optimizations from assuming this final > field is null. > */ > As David points out, the private constructor is to avoid the default constructor being generated. Your change to initialize the final classloader field is a second reason. The second statement reads to me like the reason for this private constructor is for the warning reason. Perhaps "but prevents... " gets me confused and maybe that part is not really needed? Your change looks good anyway. >> >> I didn't review the hotspot change. The new classLoader field is not >> in CLASS_INJECTED_FIELDS - is it just temporary to avoid the >> synchronized >> jdk/hotspot change? What if you push both changes through the same >> forest jdk9/hs-rt? > > The new field classLoader is explicit and not injected by the jvm. The > jvm looks up the offset of the field when it lays out the class Class > and initializes it directly in the instance of java.lang.Class. So it > isn't added to the injected fields. Right... I missed that obvious one. >> >> A side note - Christian has a patch attached in this bug that can >> improve the performance when running with SecurityManager on the >> classloader related check for permission. Can you create a new >> bug to track that so that it won't get lost once this bug is >> resolved? > > I didn't completely follow the relationship between Chris's patch and > this bug. Yes, I'll file a new bug or ask someone who knows more > about it to do so. > Thanks. The patch requires more investigation in the bootstrapping side of thing. > The plan is to push both through hs-rt. Great. That's what I wanted to know. Mandy From coleen.phillimore at oracle.com Wed Jun 18 19:38:43 2014 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 18 Jun 2014 15:38:43 -0400 Subject: RFR 6642881: Improve performance of Class.getClassLoader() In-Reply-To: <53A1E82B.60109@oracle.com> References: <539F1066.8080302@oracle.com> <539F2D41.7040901@oracle.com> <539F2E75.1050301@oracle.com> <539F56E9.3060705@oracle.com> <539FD28B.7000201@oracle.com> <53A1D781.7070704@oracle.com> <53A1DBF5.2090607@oracle.com> <53A1E82B.60109@oracle.com> Message-ID: <53A1EAC3.6030102@oracle.com> On 6/18/14, 3:27 PM, Mandy Chung wrote: > > On 6/18/2014 11:35 AM, Coleen Phillimore wrote: >> >> /* >> * Private constructor. Only the Java Virtual Machine creates Class >> * objects. This constructor is not used but prevents a warning >> that >> * classLoader is not initialized. The initialization value of >> non-null >> * prevents future JIT optimizations from assuming this final >> field is null. >> */ >> > > As David points out, the private constructor is to avoid the default > constructor being generated. Your change to initialize the final > classloader field is a second reason. The second statement reads to > me like the reason for this private constructor is for the warning > reason. Perhaps "but prevents... " gets me confused and maybe that > part is not really needed? Your change looks good anyway. How about this? I separated out the two concerns. /* * Private constructor. Only the Java Virtual Machine creates Class objects. * This constructor is not used and prevents the default constructor being * generated. */ private Class(ClassLoader loader) { // Initialize final field for classLoader. The initialization value of non-null // prevents future JIT optimizations from assuming this final field is null. classLoader = loader; } Thanks! Coleen > >>> >>> I didn't review the hotspot change. The new classLoader field is not >>> in CLASS_INJECTED_FIELDS - is it just temporary to avoid the >>> synchronized >>> jdk/hotspot change? What if you push both changes through the same >>> forest jdk9/hs-rt? >> >> The new field classLoader is explicit and not injected by the jvm. >> The jvm looks up the offset of the field when it lays out the class >> Class and initializes it directly in the instance of >> java.lang.Class. So it isn't added to the injected fields. > > Right... I missed that obvious one. > >>> >>> A side note - Christian has a patch attached in this bug that can >>> improve the performance when running with SecurityManager on the >>> classloader related check for permission. Can you create a new >>> bug to track that so that it won't get lost once this bug is >>> resolved? >> >> I didn't completely follow the relationship between Chris's patch and >> this bug. Yes, I'll file a new bug or ask someone who knows more >> about it to do so. >> > > Thanks. The patch requires more investigation in the bootstrapping > side of thing. > >> The plan is to push both through hs-rt. > > Great. That's what I wanted to know. > > Mandy > > From mandy.chung at oracle.com Wed Jun 18 19:42:11 2014 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 18 Jun 2014 12:42:11 -0700 Subject: RFR 6642881: Improve performance of Class.getClassLoader() In-Reply-To: <53A1EAC3.6030102@oracle.com> References: <539F1066.8080302@oracle.com> <539F2D41.7040901@oracle.com> <539F2E75.1050301@oracle.com> <539F56E9.3060705@oracle.com> <539FD28B.7000201@oracle.com> <53A1D781.7070704@oracle.com> <53A1DBF5.2090607@oracle.com> <53A1E82B.60109@oracle.com> <53A1EAC3.6030102@oracle.com> Message-ID: <53A1EB93.8070004@oracle.com> On 6/18/2014 12:38 PM, Coleen Phillimore wrote: > > On 6/18/14, 3:27 PM, Mandy Chung wrote: >> >> On 6/18/2014 11:35 AM, Coleen Phillimore wrote: >>> >>> /* >>> * Private constructor. Only the Java Virtual Machine creates Class >>> * objects. This constructor is not used but prevents a warning >>> that >>> * classLoader is not initialized. The initialization value of >>> non-null >>> * prevents future JIT optimizations from assuming this final >>> field is null. >>> */ >>> >> >> As David points out, the private constructor is to avoid the default >> constructor being generated. Your change to initialize the final >> classloader field is a second reason. The second statement reads to >> me like the reason for this private constructor is for the warning >> reason. Perhaps "but prevents... " gets me confused and maybe that >> part is not really needed? Your change looks good anyway. > > How about this? I separated out the two concerns. > > /* > * Private constructor. Only the Java Virtual Machine creates > Class objects. > * This constructor is not used and prevents the default > constructor being > * generated. > */ > private Class(ClassLoader loader) { > // Initialize final field for classLoader. The initialization > value of non-null > // prevents future JIT optimizations from assuming this final > field is null. > classLoader = loader; > } > Looks okay with me. Mandy From joe.darcy at oracle.com Thu Jun 19 06:03:30 2014 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 18 Jun 2014 23:03:30 -0700 Subject: Next up: rawtype and unchecked lint warning cleanup In-Reply-To: <533F415D.4030903@oracle.com> References: <533F415D.4030903@oracle.com> Message-ID: <53A27D32.6030309@oracle.com> An update, besides raw types and unchecked warnings, there were two other lint warning categories remaining in the jdk repo, finally warnings (for finally clauses that cannot complete normally) and overrides warnings (for overriding equals without also overriding hashcode). There were only a few occurrences of these finally and overrides warnings. The finally warnings have been resolved and enabled in the build: 8044715: Add finally lint warning to build of jdk repository http://hg.openjdk.java.net/jdk9/dev/jdk/rev/3b602ffe5fe5 The overrides warnings should be next. Progress also has been made on the raw types and unchecked front; fewer than 2,000 of those warnings remain. Cheers, -Joe On 4/4/2014 4:33 PM, Joseph Darcy wrote: > Hello, > > With the serial javac lint warnings in the jdk repo resolved [1], the > largest remaining category of lint warnings are for rawtypes and > unchecked conversions. Both of these kind of warnings are related to > incomplete generification and so they need to be addressed together. > > At the end of JDK 8, the jdk repo has approximately 4150 raw and > unchecked warnings; in contrast, the JDK 9 dev jdk repo only has about > 2800 raw and unchecked warnings. > > Clearing those remaining 2800 warnings will be tracked using subtasks of > > JDK-8039096 Fix raw and unchecked lint warnings in jdk libraries > https://bugs.openjdk.java.net/browse/JDK-8039096 > > Cheers, > > -Joe > > [1] > http://mail.openjdk.java.net/pipermail/jdk9-dev/2014-April/000580.html From coleen.phillimore at oracle.com Thu Jun 19 18:46:51 2014 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 19 Jun 2014 14:46:51 -0400 Subject: RFR 6642881: Improve performance of Class.getClassLoader() In-Reply-To: <6C677BF2-E257-48C9-B589-A668A8D939CC@oracle.com> References: <539F1066.8080302@oracle.com> <6C677BF2-E257-48C9-B589-A668A8D939CC@oracle.com> Message-ID: <53A3301B.7070405@oracle.com> Hi Joel, See below. On 6/17/14, 12:38 AM, Joel Borggr?n-Franck wrote: > Hi Coleen, > > On 16 jun 2014, at 17:42, Coleen Phillimore wrote: > >> Summary: Add classLoader to java/lang/Class instance for fast access >> >> In order to improve performance of Class.getClassLoader() in a way to allow the compilers to automatically optimize this call, I added the classLoader to the instance of java/lang/Class. For microbenchmarks, this results in a 98% improvement, which was expected. For Oracle internal applications, this results in a 10-12% improvement on solaris/sparc. The increase in size of java/lang/Class can be offset by other changes (removing constant pool lock, or removing signers). >> >> See bug link https://bugs.openjdk.java.net/browse/JDK-6642881 and associated linked bugs for more details. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/6642881_hotspot/ >> open webrev at http://cr.openjdk.java.net/~coleenp/6642881_jdk/ >> >> There is both hotspot and jdk changes for this change. The hotspot changes can work without the jdk changes (check for optional field), but not vice-versa. I'll file another bug (and compatibility request) to remove JVM_GetClassLoader from hotspot. >> >> Tested with jck lang, vm, api/java_lang tests with/without jdk change, nsk vm.quick.testlist and hotspot jtreg tests, and jprt. >> > Have you considered hiding the Class.classLoader field from reflection? I?m not sure it is necessary but I?m not to keen on the idea of people poking at this field with Unsafe (which should go away in 9 but ?). I don't know how to hide the field from reflection. It's a private final field so you need to get priviledges to make it setAccessible. If you mean injecting it on the JVM side, the reason for this change is so that the JIT compilers can inline this call and not have to call into the JVM to get the class loader. Thanks, Coleen > > Otherwise looks good. > > cheers > /Joel From joel.franck at oracle.com Thu Jun 19 19:34:38 2014 From: joel.franck at oracle.com (=?windows-1252?Q?Joel_Borggr=E9n-Franck?=) Date: Thu, 19 Jun 2014 21:34:38 +0200 Subject: RFR 6642881: Improve performance of Class.getClassLoader() In-Reply-To: <53A3301B.7070405@oracle.com> References: <539F1066.8080302@oracle.com> <6C677BF2-E257-48C9-B589-A668A8D939CC@oracle.com> <53A3301B.7070405@oracle.com> Message-ID: <92581C73-CE4D-44E0-B5D4-70300FF4100E@oracle.com> Hi, On 19 jun 2014, at 20:46, Coleen Phillimore wrote: > On 6/17/14, 12:38 AM, Joel Borggr?n-Franck wrote: >>> >> Have you considered hiding the Class.classLoader field from reflection? I?m not sure it is necessary but I?m not to keen on the idea of people poking at this field with Unsafe (which should go away in 9 but ?). > > I don't know how to hide the field from reflection. It's a private final field so you need to get priviledges to make it setAccessible. If you mean injecting it on the JVM side, the reason for this change is so that the JIT compilers can inline this call and not have to call into the JVM to get the class loader. > There is sun.reflect.Reflection.registerFieldsToFilter() that hides a field from being found using reflection. It might very well be the case that private and final is enough, I haven?t thought this through 100%. On the other hand, is there a reason to give users access through the field instead of having to use Class.getClassLoader()? cheers /Joel From mandy.chung at oracle.com Thu Jun 19 20:34:17 2014 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 19 Jun 2014 13:34:17 -0700 Subject: RFR 6642881: Improve performance of Class.getClassLoader() In-Reply-To: <92581C73-CE4D-44E0-B5D4-70300FF4100E@oracle.com> References: <539F1066.8080302@oracle.com> <6C677BF2-E257-48C9-B589-A668A8D939CC@oracle.com> <53A3301B.7070405@oracle.com> <92581C73-CE4D-44E0-B5D4-70300FF4100E@oracle.com> Message-ID: <53A34949.6040607@oracle.com> On 6/19/14 12:34 PM, Joel Borggr?n-Franck wrote: > Hi, > > On 19 jun 2014, at 20:46, Coleen Phillimore wrote: >> On 6/17/14, 12:38 AM, Joel Borggr?n-Franck wrote: >>> Have you considered hiding the Class.classLoader field from reflection? I?m not sure it is necessary but I?m not to keen on the idea of people poking at this field with Unsafe (which should go away in 9 but ?). >> I don't know how to hide the field from reflection. It's a private final field so you need to get priviledges to make it setAccessible. If you mean injecting it on the JVM side, the reason for this change is so that the JIT compilers can inline this call and not have to call into the JVM to get the class loader. >> > There is sun.reflect.Reflection.registerFieldsToFilter() that hides a field from being found using reflection. It might very well be the case that private and final is enough, I haven?t thought this through 100%. On the other hand, is there a reason to give users access through the field instead of having to use Class.getClassLoader()? > There are many getter methods that returns a private final field. I'm not sure if hiding the field is necessary nor a good precedence to set. Accessing a private field requires "accessDeclaredMember" permission although it's a different security check (vs "getClassLoader" permission). Arguably before this new classLoader field, one could call Class.getClassLoader0() via reflection to get a hold of class loader. Perhaps you are concerned that the "accessDeclaredMember" permission is too coarse-grained? I think the security team is looking into the improvement in that regards. Mandy From joel.franck at oracle.com Thu Jun 19 20:53:34 2014 From: joel.franck at oracle.com (=?windows-1252?Q?Joel_Borggr=E9n-Franck?=) Date: Thu, 19 Jun 2014 22:53:34 +0200 Subject: RFR 6642881: Improve performance of Class.getClassLoader() In-Reply-To: <53A34949.6040607@oracle.com> References: <539F1066.8080302@oracle.com> <6C677BF2-E257-48C9-B589-A668A8D939CC@oracle.com> <53A3301B.7070405@oracle.com> <92581C73-CE4D-44E0-B5D4-70300FF4100E@oracle.com> <53A34949.6040607@oracle.com> Message-ID: <105F29DA-7744-4D53-8AB5-36EE669ED417@oracle.com> Hi Mandy, On 19 jun 2014, at 22:34, Mandy Chung wrote: > On 6/19/14 12:34 PM, Joel Borggr?n-Franck wrote: >> Hi, >> >> On 19 jun 2014, at 20:46, Coleen Phillimore wrote: >>> On 6/17/14, 12:38 AM, Joel Borggr?n-Franck wrote: >>>> Have you considered hiding the Class.classLoader field from reflection? I?m not sure it is necessary but I?m not to keen on the idea of people poking at this field with Unsafe (which should go away in 9 but ?). >>> I don't know how to hide the field from reflection. It's a private final field so you need to get priviledges to make it setAccessible. If you mean injecting it on the JVM side, the reason for this change is so that the JIT compilers can inline this call and not have to call into the JVM to get the class loader. >>> >> There is sun.reflect.Reflection.registerFieldsToFilter() that hides a field from being found using reflection. It might very well be the case that private and final is enough, I haven?t thought this through 100%. On the other hand, is there a reason to give users access through the field instead of having to use Class.getClassLoader()? >> > There are many getter methods that returns a private final field. > I'm not sure if hiding the field is necessary nor a good precedence > to set. Accessing a private field requires "accessDeclaredMember" > permission although it's a different security check (vs "getClassLoader" > permission). Arguably before this new classLoader field, one could > call Class.getClassLoader0() via reflection to get a hold of class > loader. > > Perhaps you are concerned that the "accessDeclaredMember" permission > is too coarse-grained? I think the security team is looking into > the improvement in that regards. I think I?m a bit worried about two things, first as you wrote, ?accessDeclaredMember? isn?t the same as ?getClassLoader?, but since you could get the class loader through getClassLoader0() that shouldn?t be a new issue. The second thing is that IIRC there are ways to set a final field after initialization. I?m not sure we need to care about that either if you need Unsafe to do it. cheers /Joel From coleen.phillimore at oracle.com Thu Jun 19 20:54:49 2014 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 19 Jun 2014 16:54:49 -0400 Subject: RFR 6642881: Improve performance of Class.getClassLoader() In-Reply-To: <53A34949.6040607@oracle.com> References: <539F1066.8080302@oracle.com> <6C677BF2-E257-48C9-B589-A668A8D939CC@oracle.com> <53A3301B.7070405@oracle.com> <92581C73-CE4D-44E0-B5D4-70300FF4100E@oracle.com> <53A34949.6040607@oracle.com> Message-ID: <53A34E19.4030707@oracle.com> On 6/19/14, 4:34 PM, Mandy Chung wrote: > On 6/19/14 12:34 PM, Joel Borggr?n-Franck wrote: >> Hi, >> >> On 19 jun 2014, at 20:46, Coleen Phillimore >> wrote: >>> On 6/17/14, 12:38 AM, Joel Borggr?n-Franck wrote: >>>> Have you considered hiding the Class.classLoader field from >>>> reflection? I?m not sure it is necessary but I?m not to keen on the >>>> idea of people poking at this field with Unsafe (which should go >>>> away in 9 but ?). >>> I don't know how to hide the field from reflection. It's a private >>> final field so you need to get priviledges to make it >>> setAccessible. If you mean injecting it on the JVM side, the reason >>> for this change is so that the JIT compilers can inline this call >>> and not have to call into the JVM to get the class loader. >>> >> There is sun.reflect.Reflection.registerFieldsToFilter() that hides a >> field from being found using reflection. It might very well be the >> case that private and final is enough, I haven?t thought this through >> 100%. On the other hand, is there a reason to give users access >> through the field instead of having to use Class.getClassLoader()? >> > There are many getter methods that returns a private final field. > I'm not sure if hiding the field is necessary nor a good precedence > to set. Accessing a private field requires "accessDeclaredMember" > permission although it's a different security check (vs "getClassLoader" > permission). Arguably before this new classLoader field, one could > call Class.getClassLoader0() via reflection to get a hold of class > loader. Yes, thank you Mandy. Coleen > > Perhaps you are concerned that the "accessDeclaredMember" permission > is too coarse-grained? I think the security team is looking into > the improvement in that regards. > > Mandy > From coleen.phillimore at oracle.com Thu Jun 19 21:09:57 2014 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 19 Jun 2014 17:09:57 -0400 Subject: RFR 6642881: Improve performance of Class.getClassLoader() In-Reply-To: <105F29DA-7744-4D53-8AB5-36EE669ED417@oracle.com> References: <539F1066.8080302@oracle.com> <6C677BF2-E257-48C9-B589-A668A8D939CC@oracle.com> <53A3301B.7070405@oracle.com> <92581C73-CE4D-44E0-B5D4-70300FF4100E@oracle.com> <53A34949.6040607@oracle.com> <105F29DA-7744-4D53-8AB5-36EE669ED417@oracle.com> Message-ID: <53A351A5.8000109@oracle.com> On 6/19/14, 4:53 PM, Joel Borggr?n-Franck wrote: > Hi Mandy, > > On 19 jun 2014, at 22:34, Mandy Chung wrote: > >> On 6/19/14 12:34 PM, Joel Borggr?n-Franck wrote: >>> Hi, >>> >>> On 19 jun 2014, at 20:46, Coleen Phillimore wrote: >>>> On 6/17/14, 12:38 AM, Joel Borggr?n-Franck wrote: >>>>> Have you considered hiding the Class.classLoader field from reflection? I?m not sure it is necessary but I?m not to keen on the idea of people poking at this field with Unsafe (which should go away in 9 but ?). >>>> I don't know how to hide the field from reflection. It's a private final field so you need to get priviledges to make it setAccessible. If you mean injecting it on the JVM side, the reason for this change is so that the JIT compilers can inline this call and not have to call into the JVM to get the class loader. >>>> >>> There is sun.reflect.Reflection.registerFieldsToFilter() that hides a field from being found using reflection. It might very well be the case that private and final is enough, I haven?t thought this through 100%. On the other hand, is there a reason to give users access through the field instead of having to use Class.getClassLoader()? >>> >> There are many getter methods that returns a private final field. >> I'm not sure if hiding the field is necessary nor a good precedence >> to set. Accessing a private field requires "accessDeclaredMember" >> permission although it's a different security check (vs "getClassLoader" >> permission). Arguably before this new classLoader field, one could >> call Class.getClassLoader0() via reflection to get a hold of class >> loader. >> >> Perhaps you are concerned that the "accessDeclaredMember" permission >> is too coarse-grained? I think the security team is looking into >> the improvement in that regards. > I think I?m a bit worried about two things, first as you wrote, ?accessDeclaredMember? isn?t the same as ?getClassLoader?, but since you could get the class loader through getClassLoader0() that shouldn?t be a new issue. > > The second thing is that IIRC there are ways to set a final field after initialization. I?m not sure we need to care about that either if you need Unsafe to do it. > > cheers > /Joel So hiding this field from reflection and Unsafe doesn't seem like something we would need to do. If the field is the protectionDomain associated with this class, would that be different? Coleen From david.holmes at oracle.com Fri Jun 20 03:01:22 2014 From: david.holmes at oracle.com (David Holmes) Date: Fri, 20 Jun 2014 13:01:22 +1000 Subject: RFR 6642881: Improve performance of Class.getClassLoader() In-Reply-To: <105F29DA-7744-4D53-8AB5-36EE669ED417@oracle.com> References: <539F1066.8080302@oracle.com> <6C677BF2-E257-48C9-B589-A668A8D939CC@oracle.com> <53A3301B.7070405@oracle.com> <92581C73-CE4D-44E0-B5D4-70300FF4100E@oracle.com> <53A34949.6040607@oracle.com> <105F29DA-7744-4D53-8AB5-36EE669ED417@oracle.com> Message-ID: <53A3A402.2060501@oracle.com> On 20/06/2014 6:53 AM, Joel Borggr?n-Franck wrote: > Hi Mandy, > > On 19 jun 2014, at 22:34, Mandy Chung wrote: > >> On 6/19/14 12:34 PM, Joel Borggr?n-Franck wrote: >>> Hi, >>> >>> On 19 jun 2014, at 20:46, Coleen Phillimore wrote: >>>> On 6/17/14, 12:38 AM, Joel Borggr?n-Franck wrote: >>>>> Have you considered hiding the Class.classLoader field from reflection? I?m not sure it is necessary but I?m not to keen on the idea of people poking at this field with Unsafe (which should go away in 9 but ?). >>>> I don't know how to hide the field from reflection. It's a private final field so you need to get priviledges to make it setAccessible. If you mean injecting it on the JVM side, the reason for this change is so that the JIT compilers can inline this call and not have to call into the JVM to get the class loader. >>>> >>> There is sun.reflect.Reflection.registerFieldsToFilter() that hides a field from being found using reflection. It might very well be the case that private and final is enough, I haven?t thought this through 100%. On the other hand, is there a reason to give users access through the field instead of having to use Class.getClassLoader()? >>> >> There are many getter methods that returns a private final field. >> I'm not sure if hiding the field is necessary nor a good precedence >> to set. Accessing a private field requires "accessDeclaredMember" >> permission although it's a different security check (vs "getClassLoader" >> permission). Arguably before this new classLoader field, one could >> call Class.getClassLoader0() via reflection to get a hold of class >> loader. >> >> Perhaps you are concerned that the "accessDeclaredMember" permission >> is too coarse-grained? I think the security team is looking into >> the improvement in that regards. > > I think I?m a bit worried about two things, first as you wrote, ?accessDeclaredMember? isn?t the same as ?getClassLoader?, but since you could get the class loader through getClassLoader0() that shouldn?t be a new issue. > > The second thing is that IIRC there are ways to set a final field after initialization. I?m not sure we need to care about that either if you need Unsafe to do it. Normal reflection can set a final field if you can successfully call setAccessible(true) on the Field object. David ----- > cheers > /Joel > From patrick.zhang at oracle.com Fri Jun 20 08:42:51 2014 From: patrick.zhang at oracle.com (Patrick Zhang) Date: Fri, 20 Jun 2014 16:42:51 +0800 Subject: RFR 8035490: move xml jaxp unit tests in bugxxx dir into jaxp repo In-Reply-To: <53A3301B.7070405@oracle.com> References: <539F1066.8080302@oracle.com> <6C677BF2-E257-48C9-B589-A668A8D939CC@oracle.com> <53A3301B.7070405@oracle.com> Message-ID: <53A3F40B.1040108@oracle.com> Hi Team, 8035490 is one task used to track xml code colocation from sqe repo into jaxp repo. As one initial change set, it includes below materials: 1. TEST.ROOT to declare test code location. 2. ProblemList.txt to exclude 6 tests which have been discussed on past. 3. One Makefile to support future jprt/aurora execution. 4. test code located in bugxxx dir. All are based on testNG. webrev: http://cr.openjdk.java.net/~pzhang/xml_colocation/8035490/webrev/ test result. The failure has been proved as machine issue and fixed. full platform test result Regards Patrick From lana.steuck at oracle.com Fri Jun 20 18:23:25 2014 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 20 Jun 2014 11:23:25 -0700 (PDT) Subject: jdk9-b20: dev Message-ID: <201406201823.s5KINPiv014608@jano-app.us.oracle.com> http://hg.openjdk.java.net/jdk9/jdk9/rev/ee4fd72b2ec3 http://hg.openjdk.java.net/jdk9/jdk9/nashorn/rev/d703c59c556f http://hg.openjdk.java.net/jdk9/jdk9/langtools/rev/31acbc476a52 http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/f87c5be90e01 http://hg.openjdk.java.net/jdk9/jdk9/jaxws/rev/6a9f8ff45c04 http://hg.openjdk.java.net/jdk9/jdk9/jaxp/rev/94fd4d9d3a75 http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/c1af79d122ec http://hg.openjdk.java.net/jdk9/jdk9/corba/rev/87f36eecb166 --- All the fixes will be tested during promotion (no PIT testing at this point): List of all fixes: =================== JDK-8046595 client-libs fix doclint issues in swing classes, part 2 of 4 JDK-8046596 client-libs fix doclint issues in swing classes, part 3 of 4 JDK-8047035 core-libs (function() "hello")() crashes in Lexer with jdk9 JDK-8047057 core-libs Add a regression test for the passing test cases from JDK-8042304 JDK-8046389 core-libs Add missing @since tag under javax.sql.** JDK-8046898 core-libs Make sure that there is no difference in test exercise behavior between lazy and non lazy JDK-8046707 core-libs Performance of java.time could be better JDK-8041679 core-libs Replace uses of StringBuffer with StringBuilder within core library classes JDK-8046416 core-libs Unable to parse an Instant from fields JDK-8046903 core-libs VM anonymous class members can't be statically invocable JDK-8044730 core-libs small errors in ConcurrentHashMap and LongAdder docs JDK-8046588 core-libs test for SO_FLOW_SLA availability does not check for EACCESS JDK-8046778 core-svc Better error messages when starting JMX agent via attach or jcmd JDK-8043939 core-svc Remove management-agent.jar JDK-8041498 core-svc Remove npt library JDK-6545295 core-svc TEST BUG: The test HatHeapDump1Test uses wrong path in exec call. JDK-6622468 core-svc TEST_BUG: Time to retire the @debuggeeVMOptions mechanism used in the com.sun.jdi infrastructure JDK-8046348 core-svc com/sun/jdi/OptionTest.java should be quarantined JDK-8044762 core-svc com/sun/jdi/OptionTest.java test time out JDK-8046351 core-svc com/sun/management/GarbageCollectorMXBean/GarbageCollectionNotification[Content]Test.java should be quarantined JDK-8046355 core-svc sun/tools/jstatd/TestJstatdExternalRegistry.java should be quarantined JDK-8044496 hotspot 8034812 broke build with clang JDK-8035968 hotspot C2 support for SHA on SPARC JDK-8044673 hotspot Create jtreg groups to list GC specific tests JDK-8035605 hotspot Expand functionality of PredictedIntrinsicGenerator JDK-8046275 hotspot Fastdebug build failing on jdk9/hs/ control jobs after pulling some hs-comp changes JDK-8026796 hotspot Make replace_in_map() on parent maps generic JDK-8031389 hotspot On x86 C1 emits two relocations for polls JDK-8044071 hotspot Print format/argument warnings JDK-8043413 hotspot REGRESSION: Hotspot causes segmentation fault in jdk8ux, but not in jdk7ux JDK-8044242 hotspot Remove dead NativeMovRegMemPatching class JDK-8026396 hotspot Remove information duplication in the collector policy JDK-8042298 hotspot Remove the names gen0 and gen1 from the GC code JDK-8033145 hotspot Runtime1::arraycopy_count_address uses wrong _oop_arraycopy_cnt variable JDK-8011646 hotspot SEGV in compiled code with loop predication JDK-8046516 hotspot Segmentation fault in JVM (easily reproducible) JDK-8030976 hotspot Untaken paths should be more vigorously pruned at highest optimization level JDK-8044339 hotspot Update FilterSpuriousWakeups documentation. Review "Solaris only" vm options descriptions JDK-8041503 hotspot [TESTBUG] test/closed/compiler/4477197/AVTest.java runs for an hour JDK-8046226 hotspot assert(_thread == Thread::current()) failed: thread must be current w/ -XX:+TraceDeoptimization -XX:+Verbose JDK-8033626 hotspot assert(ex_map->jvms()->same_calls_as(_exceptions->jvms())) failed: all collected exceptions must come from the same place JDK-8029381 hotspot assert(is_method_type()) failed: bad cast JDK-8044538 hotspot assert(which != imm_operand) failed: instruction is not a movq reg, imm64 JDK-8046352 hotspot com/sun/tools/attach/TempDirTest.java should be quarantined JDK-8021775 hotspot compiler/8009761/Test8009761.java "Failed: init recursive calls: 51. After deopt 50" JDK-8040244 hotspot compiler/whitebox/IsMethodCompilableTest.java fails with 'private int SimpleTestCase$Helper.method() is still compilable after 3 iterations' JDK-8031994 hotspot java/lang/Character/CheckProp test times out JDK-8038756 hotspot new WB API :: get/setVMFlag JDK-8034812 hotspot remove IDX_INIT macro hack in Node class JDK-8044575 hotspot testlibrary_tests/whitebox/vm_flags/UintxTest.java failed: assert(!res || TypeEntriesAtCall::arguments_profiling_enabled()) failed: no profiling of arguments JDK-8047068 infrastructure Configure --with-java-devtools should set up new devkits JDK-8032045 infrastructure Enable compiler and linker safety switches for debug builds JDK-8046902 other-libs Remove sun.misc.Timer JDK-8046044 security-libs Fix raw and unchecked lint warnings in XML Signature Impl JDK-7176176 security-libs Need to make improvement to access temporary dir JDK-8047085 security-libs PKCS11/NSS tests failing intermittently on Windows JDK-8036613 security-libs [parfait] JNI exception pending in jdk/src/windows/native/sun/security/provider/WinCAPISeedGenerator.c JDK-8042830 tools A recently added Xprefer test fails on Windows JDK-8038975 tools Access control in enhanced for JDK-8036953 tools Fix timing of varargs access check, per JDK-8016205 JDK-8043062 tools JDK 9 platform and compiler upgrade failed on Solaris-sparcv9 with Javadoc.gmk:360: recipe for target docs/api/index.html JDK-8043253 tools Slow javac compile times in JDK 8 JDK-8046916 tools Type parameter annotations don't work with multiple type parameters JDK-8042829 tools [javadoc] index-file output is not sorted correctly JDK-8046369 tools sjavac should not use javac internal API for starting javac JDK-8044735 Print format/argument warnings From mike.duigou at oracle.com Tue Jun 24 22:47:13 2014 From: mike.duigou at oracle.com (Mike Duigou) Date: Tue, 24 Jun 2014 15:47:13 -0700 Subject: get_source.sh update Message-ID: <35BD9B5C-B187-411B-A303-F361C408C683@oracle.com> Hello all; I've pushed an update to the get_source.sh script which checks the version of the Mercurial client being used and rejects clients older than version 1.5. Version 1.5 was chosen as a cut-off because the reports of spuriously aborted transactions or stalled connections appear to be much higher with 1.4.1 and earlier. Version 1.1 and earlier don't appear to work at all with the current OpenJDK Mercurial server. Version 2.6.3 or later is recommended for best performance and reliability. The script will be updated when the required or recommended version changes. This will probably happen very infrequently. Mike From alejandro.murillo at oracle.com Tue Jun 24 22:50:13 2014 From: alejandro.murillo at oracle.com (Alejandro E Murillo) Date: Tue, 24 Jun 2014 16:50:13 -0600 Subject: jdk9-dev: HotSpot Message-ID: <53AA00A5.2050501@oracle.com> jdk9-hs-2014-06-20 has been integrated into jdk9-dev. http://hg.openjdk.java.net/jdk9/dev/rev/e533bd64ec46 http://hg.openjdk.java.net/jdk9/dev/corba/rev/eecc1b6adc7e http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/b70485f2a5b9 http://hg.openjdk.java.net/jdk9/dev/jaxp/rev/01c25780f33f http://hg.openjdk.java.net/jdk9/dev/jaxws/rev/7f922a73e8a2 http://hg.openjdk.java.net/jdk9/dev/jdk/rev/c84527dd35be http://hg.openjdk.java.net/jdk9/dev/langtools/rev/65ad8ee1ff0f http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/cf90d5f11b98 Component : VM Status : 0 major failures, 0 minor failures Date : 06/24/2014 at 22:00 MSK Tested By : VM SQE &leonid.mesnik at oracle.com Cost(total man-days): 0 Workspace : 2014-06-20-181706.amurillo.jdk9-hs-2014-06-20-jdk9-dev-control Bundles : 2014-06-20-181706.amurillo.jdk9-hs-2014-06-20-jdk9-dev-control Platforms : all Tests : Log : link Browsers : NA Patches : NA Number of Tests Executed: 319696 passed tests, 2985 failed tests (209 new failures) Bug verification status: ====================================== Tested, Pass: Tested, Pass (partial fixes): Tested, Fail: Untested bug fixes: 6311046: -Xcheck:jni should support checking of GetPrimitiveArrayCritical. 6961433: Revisit need to disable Windows C++ compiler optimisation of sharedRuntimeTrig.cpp. 8031819: Remove legacy jdk checks and code 8038392: Generating prelink cache breaks JAVA 'jinfo' utility normal behaviour 8039150: host_klass invariant fails when verifying newly loaded JSR-292 anonymous classes 8043224: -Xcheck:jni improvements to exception checking and excessive local refs 8043340: [macosx] Fix hard-wired paths to JavaVM.framework 8043492: ad_x86_64_misc.obj : error LNK2011: precompiled object not linked in; image may not run 8043722: Swapped usage of idx_t and bm_word_t types in parMarkBitMap.cpp 8044107: Add Diagnostic Command to list all ClassLoaders 8044540: serviceability/sa/jmap-hashcode/Test8028623.java should be quarantined 8044738: Check attribute_length of EnclosingMethod attribute 8044742: testlibrary_tests/whitebox/vm_flags/BooleanTest.java NoClassDefFoundError: com/oracle/java/testlibrary/JDKToolFinder 8044796: G1: Enable G1CollectedHeap::stop() 8044797: Building with clang gives: fatal error: file '...' has been modified since the precompiled header was built 8046287: [TESTBUG] runtime/Thread/TestThreadDumpMonitorContention.java failed error_cnt=12 8046408: Build failure from multiple ptrace.h 8046662: Check JNI ReleaseStringChars / ReleaseStringUTFChars verify_guards test inverted 8046684: sharedRuntime.cpp...assert(((nmethod*)cb)->is_at_poll_or_poll_return(pc)) failed: safepoint polling: type must be poll 8046715: Add a way to verify an extended set of command line options 8046758: cleanup non-indent white space issues prior to Contended Locking cleanup bucket 8046769: Set T family feature bit on Niagara systems 8047156: cleanup more non-indent white space issues prior to Contended Locking cleanup bucket Bugs in PIT build: Number of PIT requested: 1 Integration target J2SE build number: Issues and Notes: There was no detailed analysis for this PIT. I look through the failures quickly. Go for integration -- Alejandro From chris.hegarty at oracle.com Wed Jun 25 23:14:04 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 26 Jun 2014 00:14:04 +0100 Subject: Result: New JDK 9 Committer: Pavel Rappo In-Reply-To: <5398364E.2090409@oracle.com> References: <5398364E.2090409@oracle.com> Message-ID: <8A8DDEAB-EEB2-4820-A085-E8E7F008DDBC@oracle.com> Voting for Pavel Rappo [1] is now closed. Yes: 21 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. -Chris. [1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2014-June/000816.html From stuart.marks at oracle.com Thu Jun 26 04:34:54 2014 From: stuart.marks at oracle.com (Stuart Marks) Date: Wed, 25 Jun 2014 21:34:54 -0700 Subject: CFV: New JDK 9 Committer: Pavel Rappo In-Reply-To: <5398364E.2090409@oracle.com> References: <5398364E.2090409@oracle.com> Message-ID: <53ABA2EE.6080905@oracle.com> Vote: yes On 6/11/14 3:58 AM, Chris Hegarty wrote: > I hereby nominate Pavel Rappo (prappo) to JDK 9 Committer. > > Pavel is a member of the Core Libraries team at Oracle. Most recently, he has > been fixing issues in the Networking and NIO area. His JDK 9 contributions, to > date, can be seen below. > > Votes are due by 25th June 2014 23:59 GMT > > Only current JDK 9 Committers [1] are eligible to vote on this nomination. Votes > must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > -Chris.. > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/b39e23ebc008 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/eb6f07ec4509 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/cda85444cad2 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/4aa94c6a7257 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/8cef08d9eacf > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/db75bd98d8fd > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/50a749f2cade > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/9a58ff1e27a6 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/e6d4d07dee4c > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/acda974a4986 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/476d56ab6377 From coleen.phillimore at oracle.com Fri Jun 27 12:15:19 2014 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 27 Jun 2014 08:15:19 -0400 Subject: Result: New jdk9 Reviewer: Harold Seigel Message-ID: <53AD6057.3000408@oracle.com> Voting for Harold Seigel [1] is now closed. Yes: 15 Veto: 0 Abstain: 0 According to the Bylaws definition of Three-Vote Consensus, this is sufficient to approve the nomination. Coleen Phillimore [1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2014-June/000830.html