From david.holmes at oracle.com Wed Feb 1 03:42:38 2017 From: david.holmes at oracle.com (David Holmes) Date: Wed, 1 Feb 2017 13:42:38 +1000 Subject: JDK 10 forests open for bug fixes and small enhancements In-Reply-To: <20170125233400.ECB2E55A6D@eggemoggin.niobe.net> References: <20170125233400.ECB2E55A6D@eggemoggin.niobe.net> Message-ID: On 26/01/2017 9:34 AM, mark.reinhold at oracle.com wrote: > The Mercurial forests for JDK 10 are now available: > > http://hg.openjdk.java.net/jdk10/jdk10 -- Master + dev (combined) > http://hg.openjdk.java.net/jdk10/hs -- HotSpot > http://hg.openjdk.java.net/jdk10/sandbox -- Sandbox > http://hg.openjdk.java.net/jdk10/client -- Client libraries > > Corresponding -changes mailing lists have also been created. Note that you need to add yourself to the desired "changes" lists. David ----- > The main differences from the forests for JDK 9 are that there are fewer > of them, and that the "dev" and master forests have been combined. Most > committers should push directly into jdk10/jdk10 except when working on > HotSpot, a branch in the sandbox forest, or the client libraries. > > As of today these forests are open for bug fixes and small enhancements. > > Many committers will continue to focus mainly on JDK 9 for the next few > months so, for now, we'll semi-automatically pull changes from JDK 9 and > merge them into JDK 10. This means that if you make a change in JDK 9 > then you needn't do any extra work to get it into JDK 10, though if a > merge conflict arises then you might be asked to help resolve it. > > For work that's new in JDK 10, please try to keep destabilizing changes > to a minimum, for now, in order to reduce the overhead of the continuous > merges from JDK 9. If you want to work on a destabilizing change for > JDK 10 then consider starting that work in a sandbox branch. > > Once JDK 9 is closer to being done we'll use the JEP 2.0 process [2], as > usual, to target significant features. > > The JDK 10 forests have the same structure as the JDK 9 forests. The > repository consolidation proposed in JEP 296 [1] might be implemented > later in the release. > > In the (hopefully infrequent) event that a change in JDK 10 needs to be > back-ported to JDK 9 we'll have to figure out how to handle the duplicate > bug ids that will arise when a back-ported change is later merged forward > into JDK 10. One solution may just be to disable the unique bug-id test > in jcheck, on the assumption that existing social conventions adequately > protect us from the pathological scenarios that are prevented by this > test. Thoughts welcome ... > > - Mark > > > [1] http://openjdk.java.net/jeps/296 > [2] http://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html > From joe.darcy at oracle.com Fri Feb 10 18:28:45 2017 From: joe.darcy at oracle.com (joe darcy) Date: Fri, 10 Feb 2017 10:28:45 -0800 Subject: First pull of JDK 9 fixes into JDK 10 Message-ID: <12714e2f-c06e-c1f4-b306-db9fa2eee522@oracle.com> Hello, FYI, yesterday Lana did the first pull of changes from JDK 9 into JDK 10 as part of the the new model we're trying [1]. Over 400 changes were involved and the merges went smoothly. This brings JDK 10 up to date with changes up to JDK 9 build 156. Regression test results look good. Cheers, -Joe [1] http://mail.openjdk.java.net/pipermail/jdk10-dev/2016-December/000037.html From martinrb at google.com Fri Feb 10 20:48:42 2017 From: martinrb at google.com (Martin Buchholz) Date: Fri, 10 Feb 2017 12:48:42 -0800 Subject: First pull of JDK 9 fixes into JDK 10 In-Reply-To: <12714e2f-c06e-c1f4-b306-db9fa2eee522@oracle.com> References: <12714e2f-c06e-c1f4-b306-db9fa2eee522@oracle.com> Message-ID: Thanks. I'd like to see jdk10 have the same weekly cadence as jdk9 does, which seems to work well. Integration of fixes from jdk9 to jdk10, publishing of pre-release binaries and javadoc (etc... testing ...?) are all things that jdk9 and jdk10 can do in parallel until 9 is released. And it should not be too much of a burden for our heroic release engineer; just run the same scripts twice. On Fri, Feb 10, 2017 at 10:28 AM, joe darcy wrote: > Hello, > > FYI, yesterday Lana did the first pull of changes from JDK 9 into JDK 10 > as part of the the new model we're trying [1]. Over 400 changes were > involved and the merges went smoothly. This brings JDK 10 up to date with > changes up to JDK 9 build 156. Regression test results look good. > > Cheers, > > -Joe > > [1] http://mail.openjdk.java.net/pipermail/jdk10-dev/2016-Decemb > er/000037.html > > From joe.darcy at oracle.com Mon Feb 13 22:54:27 2017 From: joe.darcy at oracle.com (joe darcy) Date: Mon, 13 Feb 2017 14:54:27 -0800 Subject: How to handle future backports from JDK 10 into JDK 9? Message-ID: <49f8daf7-6c15-dec9-92e3-ef76dc6f2afb@oracle.com> Hello, An open question in Mark's announcement that the JDK 10 forests are open [1] concerned how to manage backports from JDK 10 to JDK 9: "In the (hopefully infrequent) event that a change in JDK 10 needs to be back-ported to JDK 9 we'll have to figure out how to handle the duplicate bug ids that will arise when a back-ported change is later merged forward into JDK 10. One solution may just be to disable the unique bug-id test in jcheck, on the assumption that existing social conventions adequately protect us from the pathological scenarios that are prevented by this test. Thoughts welcome ..." As a reminder, the overall model (for now) is that all fixes from JDK 9 will be synced into JDK 10; the first sync of several hundred bugs happened recently and went smoothly. [2] The potentially problematic situation would occur if * Bug JDK-8181818 is first fixed in JDK 10 * Bug JDK-8181818 is then backported to JDK 9 * The next sync of JDK 9 into JDK 10 would fail on the duplicate bug id JDK-8181818 even though the code may be identical One way to avoid this problem would be to do the push to JDK 9 under an explicit backport bug id rather than the main bug id JDK-8181818. This approach has a number of drawback. First, long-standing social convention has been to "always use the main bug id." Second, tooling like Hg updater has been written on the assumption that the main bug id will always be used to conceptually refer to an issue. The purpose of the jcheck unique bug id check stems from preventing sloppy bug handling where multiple changesets partially and incrementally address a bug and it is not clear whether or not an issue is fully fixed or not. However, even without programmatic enforcement of unique bug id, I don't think JDK development practices would devolve in that way. As supporting evidence, the unique bug id check is disabled in the 8 update forests to allow fixes from multiple releases to come back together in the always-open forest and the pathologies around partial fixes have not occurred. Therefore, I think the better option is to also disable the unique bug id check for the JDK 10 forests to allow easier syncing between 9 and 10. Comments? Cheers, -Joe [1] http://mail.openjdk.java.net/pipermail/jdk10-dev/2017-January/000041.html [2] http://mail.openjdk.java.net/pipermail/jdk10-dev/2017-February/000054.html From philip.race at oracle.com Mon Feb 13 23:31:59 2017 From: philip.race at oracle.com (Phil Race) Date: Mon, 13 Feb 2017 15:31:59 -0800 Subject: How to handle future backports from JDK 10 into JDK 9? In-Reply-To: <49f8daf7-6c15-dec9-92e3-ef76dc6f2afb@oracle.com> References: <49f8daf7-6c15-dec9-92e3-ef76dc6f2afb@oracle.com> Message-ID: <94d8612e-c3c4-5206-a860-5140233d1416@oracle.com> > on the assumption that existing social conventions adequately > protect us from the pathological scenarios that are prevented by this test. Well .. maybe .. it could also be that we got stopped at the commit stage from making an mistake and have learned this convention through the enforcement. Future developers not exposed to it may not learn the lesson so well and would also not benefit from the enforcement. As is the case for "don't use the backport ID when backporting", which is not enforced anywhere and I've made that mistake a few times as a result. -phil. On 02/13/2017 02:54 PM, joe darcy wrote: > Hello, > > An open question in Mark's announcement that the JDK 10 forests are > open [1] concerned how to manage backports from JDK 10 to JDK 9: > > "In the (hopefully infrequent) event that a change in JDK 10 needs to be > back-ported to JDK 9 we'll have to figure out how to handle the duplicate > bug ids that will arise when a back-ported change is later merged forward > into JDK 10. One solution may just be to disable the unique bug-id test > in jcheck, on the assumption that existing social conventions adequately > protect us from the pathological scenarios that are prevented by this > test. Thoughts welcome ..." > > As a reminder, the overall model (for now) is that all fixes from JDK > 9 will be synced into JDK 10; the first sync of several hundred bugs > happened recently and went smoothly. [2] > > The potentially problematic situation would occur if > > * Bug JDK-8181818 is first fixed in JDK 10 > * Bug JDK-8181818 is then backported to JDK 9 > * The next sync of JDK 9 into JDK 10 would fail on the duplicate bug > id JDK-8181818 even though the code may be identical > > One way to avoid this problem would be to do the push to JDK 9 under > an explicit backport bug id rather than the main bug id JDK-8181818. > This approach has a number of drawback. First, long-standing social > convention has been to "always use the main bug id." Second, tooling > like Hg updater has been written on the assumption that the main bug > id will always be used to conceptually refer to an issue. > > The purpose of the jcheck unique bug id check stems from preventing > sloppy bug handling where multiple changesets partially and > incrementally address a bug and it is not clear whether or not an > issue is fully fixed or not. > > However, even without programmatic enforcement of unique bug id, I > don't think JDK development practices would devolve in that way. As > supporting evidence, the unique bug id check is disabled in the 8 > update forests to allow fixes from multiple releases to come back > together in the always-open forest and the pathologies around partial > fixes have not occurred. > > Therefore, I think the better option is to also disable the unique bug > id check for the JDK 10 forests to allow easier syncing between 9 and 10. > > Comments? > > Cheers, > > -Joe > > [1] > http://mail.openjdk.java.net/pipermail/jdk10-dev/2017-January/000041.html > > [2] > http://mail.openjdk.java.net/pipermail/jdk10-dev/2017-February/000054.html > From kevin.rushforth at oracle.com Tue Feb 14 01:16:00 2017 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 13 Feb 2017 17:16:00 -0800 Subject: How to handle future backports from JDK 10 into JDK 9? In-Reply-To: <49f8daf7-6c15-dec9-92e3-ef76dc6f2afb@oracle.com> References: <49f8daf7-6c15-dec9-92e3-ef76dc6f2afb@oracle.com> Message-ID: <58A25A50.3030307@oracle.com> > Therefore, I think the better option is to also disable the unique bug id check for the JDK 10 forests to allow easier syncing between 9 and 10. This seems good to me. We haven't noticed a big problem with this in the JDK update releases where the unique Bug ID check is turned off. We also haven't seen problems in JavaFX (where we currently don't have jcheck enabled at all, but are working towards it, with the unique bug ID check disabled). I note that disabling the unique bug ID check will also help with the bug ID collision that will otherwise occur in the proposed repo consolidation, and which would otherwise need a solution. -- Kevin joe darcy wrote: > Hello, > > An open question in Mark's announcement that the JDK 10 forests are > open [1] concerned how to manage backports from JDK 10 to JDK 9: > > "In the (hopefully infrequent) event that a change in JDK 10 needs to be > back-ported to JDK 9 we'll have to figure out how to handle the duplicate > bug ids that will arise when a back-ported change is later merged forward > into JDK 10. One solution may just be to disable the unique bug-id test > in jcheck, on the assumption that existing social conventions adequately > protect us from the pathological scenarios that are prevented by this > test. Thoughts welcome ..." > > As a reminder, the overall model (for now) is that all fixes from JDK > 9 will be synced into JDK 10; the first sync of several hundred bugs > happened recently and went smoothly. [2] > > The potentially problematic situation would occur if > > * Bug JDK-8181818 is first fixed in JDK 10 > * Bug JDK-8181818 is then backported to JDK 9 > * The next sync of JDK 9 into JDK 10 would fail on the duplicate bug > id JDK-8181818 even though the code may be identical > > One way to avoid this problem would be to do the push to JDK 9 under > an explicit backport bug id rather than the main bug id JDK-8181818. > This approach has a number of drawback. First, long-standing social > convention has been to "always use the main bug id." Second, tooling > like Hg updater has been written on the assumption that the main bug > id will always be used to conceptually refer to an issue. > > The purpose of the jcheck unique bug id check stems from preventing > sloppy bug handling where multiple changesets partially and > incrementally address a bug and it is not clear whether or not an > issue is fully fixed or not. > > However, even without programmatic enforcement of unique bug id, I > don't think JDK development practices would devolve in that way. As > supporting evidence, the unique bug id check is disabled in the 8 > update forests to allow fixes from multiple releases to come back > together in the always-open forest and the pathologies around partial > fixes have not occurred. > > Therefore, I think the better option is to also disable the unique bug > id check for the JDK 10 forests to allow easier syncing between 9 and 10. > > Comments? > > Cheers, > > -Joe > > [1] > http://mail.openjdk.java.net/pipermail/jdk10-dev/2017-January/000041.html > > [2] > http://mail.openjdk.java.net/pipermail/jdk10-dev/2017-February/000054.html > > From joe.darcy at oracle.com Tue Feb 14 02:10:31 2017 From: joe.darcy at oracle.com (joe darcy) Date: Mon, 13 Feb 2017 18:10:31 -0800 Subject: Proposal to use hgupdate-sync label on bugs synced from JDK 9 to JDK 10 Message-ID: <66b26b47-4546-5b67-0d17-cda481685019@oracle.com> Hello, With the policy of fixes in JDK 9 being periodically synced into JDK 10 [1], the set of bugs in JBS and set of changesets in the JDK 10 forests will include both fixes unique and newly introduced to JDK 10 as well as hundreds of fixes "just" forward-ported from JDK 9. A similar situation occurs in the update release train when fixes from the stabilization forest are pulled into the always-open forest. The bug tracking in the update releases is assisted by use of the "hgupdate-sync" label: "The 'hgupdate-sync' label is used to denote bug records which are already fixed in a previous release. When code lines are synced a new backport record will be created with the hgupdate-sync label to capture the sync activity. For the most part, such records can be ignored since they indicate that the issue was resolved in an earlier update release." [2] For a particular example, the bug JDK-6515172: "Runtime.availableProcessors() ignores Linux taskset command" has several backports into the 8 update family. The earliest 8 update release with a backport is 8u121; there is no hgupdate-sync label in that case. However, when the fix was subsequently applied to 8u131 and 8u152, the backports created for those releases have the hgupdate-sync label: 8u121: https://bugs.openjdk.java.net/browse/JDK-8173345 8u131: https://bugs.openjdk.java.net/browse/JDK-8174019 hgupdate-sync 8u152: https://bugs.openjdk.java.net/browse/JDK-8166105 hgupdate-sync When the pushes/syncs into 8u131 and 8u152 occurred, Hg-updater saw that the bug was already fixed in an earlier 8uX release and thus added the hgupdate-sync label to the newly-created backports. The fixes unique to a release are (roughly) all the fixes with that fixVersion minus the fixes with the hgupdate-sync label. The same convention may be helpful to follow for the bugs synced from JDK 9 into JDK 10. Some small changes to Hg-updater would be necessary to implement this policy since currently hgupdate-sync will only be applied to fixes within the same update release family. A bulk edit could be done to add the label retroactively to the JDK 9 changes recently synced into JDK 10. Comments? Thanks, -Joe [1] http://mail.openjdk.java.net/pipermail/jdk10-dev/2017-February/000054.html [2] https://wiki.openjdk.java.net/display/general/JBS+Overview From david.holmes at oracle.com Tue Feb 14 02:15:36 2017 From: david.holmes at oracle.com (David Holmes) Date: Tue, 14 Feb 2017 12:15:36 +1000 Subject: How to handle future backports from JDK 10 into JDK 9? In-Reply-To: <49f8daf7-6c15-dec9-92e3-ef76dc6f2afb@oracle.com> References: <49f8daf7-6c15-dec9-92e3-ef76dc6f2afb@oracle.com> Message-ID: <58db6d43-3457-8bd9-bb04-3ab01aeb64e7@oracle.com> On 14/02/2017 8:54 AM, joe darcy wrote: > Hello, > > An open question in Mark's announcement that the JDK 10 forests are open > [1] concerned how to manage backports from JDK 10 to JDK 9: > > "In the (hopefully infrequent) event that a change in JDK 10 needs to be > back-ported to JDK 9 we'll have to figure out how to handle the duplicate > bug ids that will arise when a back-ported change is later merged forward > into JDK 10. One solution may just be to disable the unique bug-id test > in jcheck, on the assumption that existing social conventions adequately > protect us from the pathological scenarios that are prevented by this > test. Thoughts welcome ..." > > As a reminder, the overall model (for now) is that all fixes from JDK 9 > will be synced into JDK 10; the first sync of several hundred bugs > happened recently and went smoothly. [2] > > The potentially problematic situation would occur if > > * Bug JDK-8181818 is first fixed in JDK 10 > * Bug JDK-8181818 is then backported to JDK 9 > * The next sync of JDK 9 into JDK 10 would fail on the duplicate bug id > JDK-8181818 even though the code may be identical > > One way to avoid this problem would be to do the push to JDK 9 under an > explicit backport bug id rather than the main bug id JDK-8181818. This > approach has a number of drawback. First, long-standing social > convention has been to "always use the main bug id." Second, tooling > like Hg updater has been written on the assumption that the main bug id > will always be used to conceptually refer to an issue. > > The purpose of the jcheck unique bug id check stems from preventing > sloppy bug handling where multiple changesets partially and > incrementally address a bug and it is not clear whether or not an issue > is fully fixed or not. > > However, even without programmatic enforcement of unique bug id, I don't > think JDK development practices would devolve in that way. As supporting > evidence, the unique bug id check is disabled in the 8 update forests to > allow fixes from multiple releases to come back together in the > always-open forest and the pathologies around partial fixes have not > occurred. > > Therefore, I think the better option is to also disable the unique bug > id check for the JDK 10 forests to allow easier syncing between 9 and 10. I think that check has helped avoid pushes with mis-typed bug numbers. Unless we have a stronger "does this bug id match the bug synopsis" check I would not want to see this bug id check relaxed. I would not expect there to be many cases where something is deferred to 10, fixed, and then re-considered for 9. But if that does happen I think the simplest thing may be to do the backport under a new bug id (as already happens at time in the update releases when the backport is not clean). Thanks, David ----- > Comments? > > Cheers, > > -Joe > > [1] > http://mail.openjdk.java.net/pipermail/jdk10-dev/2017-January/000041.html > > [2] > http://mail.openjdk.java.net/pipermail/jdk10-dev/2017-February/000054.html > From jesper.wilhelmsson at oracle.com Wed Feb 15 15:03:54 2017 From: jesper.wilhelmsson at oracle.com (jesper.wilhelmsson at oracle.com) Date: Wed, 15 Feb 2017 16:03:54 +0100 Subject: CFV: New JDK 9/10 Committer: Jini George Message-ID: <854DE5D9-F54A-446C-A98E-8714121E072A@oracle.com> I hereby nominate Jini George (jgeorge) to JDK 9 and JDK 10 Committer. Jini is part of the Monitoring and Management team and has contributed 15 changesets to JDK 9 [3]. Votes are due by Mars 1, 2017. Only current JDK 9/10 Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. Since we are in the borderland between JDK 9 and JDK 10 now, and the JDK 10 project has already been created, I'm not sure if we need a vote per project so I'm sending this CFV to both the JDK 9 and JDK 10 lists. Unless someone can verify that it is enough to vote for one of these projects I suggest that those of you that are in both lists replies to both mails and treat this as two separate votes. For Lazy Consensus voting instructions, see [2]. Thanks, /Jesper [1] http://openjdk.java.net/census [2] http://openjdk.java.net/bylaws#lazy-consensus [3] List of changes: (1) 8173896: SA: BasicLauncherTest.java (printmdo) fails for Client VM and Server VM with emulated-client http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/3bd7f52ecae6 http://hg.openjdk.java.net/jdk9/hs/jdk/rev/615d771202e8 (2) 8171084: heapdump/JMapHeapCore fails with java.lang.RuntimeException: Heap segment size overflow http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/2c44cff993b8 (3) 8159127: hprof heap dumps broken for lambda classdata http://hg.openjdk.java.net/jdk9/hs/./rev/e5605f29b00e http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/e5e4011e9c30 (4) 8169232: SA: TestCpoolForInvokeDynamic.java fails with sun.jvm.hotspot.debugger.DebuggerException: binary search bug: should have found entry 1 http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/13e6043fcdcb (5) 8169638: serviceability/sa/TestInstanceKlassSize.java and serviceability/sa/TestInstanceKlassSizeForInterface.java fail compilation http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/ae23c7acb99a (6) 8169344: Potential open file descriptor in exists() of hotspot/agent/src/os/bsd/ps_core.c http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/a71b53580d07 (7) 7107018: sun.jvm.hotspot.utilities.soql.JSJavaHeap.forEachClass incorrect test http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/a169535aff9d (8) 8164783: SA: jhsdb clhsdb 'printall' often throws "Corrupted constant pool" assertion failure http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/8c2f220c759c (9) 8164383: jhsdb dumps core on Solaris 12 when loading dumped core http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/ce3eaa22b582 (10) 8166552: SA: Missed testcase for add default methods to InstanceKlass http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/0ff97dc32114 (11) 8027920: SA: Add default methods to InstanceKlass http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/c8b3f8e5423b (12) 8163150: SA: CLHSDB printmdo throws an exception with "java.lang.InternalError: missing reason for 22" http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/3652a2a22916 http://hg.openjdk.java.net/jdk9/hs/jdk/rev/8a0a818c3f28 (13) 8164562: serviceability/sa/TestInstanceKlassSizeForInterface.java: fails with NPE http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/1357a160e4f2 (14) 8163143: illegal bci error with interpreted frames in SA due to mirror being stored in interpreted frames http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/b84f097dc4c5 http://hg.openjdk.java.net/jdk9/hs/jdk/rev/481ac1e59664 (15) 8145627: sun.jvm.hotspot.oops.InstanceKlass::getSize() returns the incorrect size and has no test http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/ca241ed18db8 From zoltan.majo at oracle.com Wed Feb 15 15:10:50 2017 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Wed, 15 Feb 2017 16:10:50 +0100 Subject: CFV: New JDK 9/10 Committer: Jini George In-Reply-To: <854DE5D9-F54A-446C-A98E-8714121E072A@oracle.com> References: <854DE5D9-F54A-446C-A98E-8714121E072A@oracle.com> Message-ID: Vote: yes. Best regards, Zoltan On 02/15/2017 04:03 PM, jesper.wilhelmsson at oracle.com wrote: > I hereby nominate Jini George (jgeorge) to JDK 9 and JDK 10 Committer. > > Jini is part of the Monitoring and Management team and has contributed 15 changesets to JDK 9 [3]. > > Votes are due by Mars 1, 2017. > > Only current JDK 9/10 Committers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. Since we are in the borderland between JDK 9 and JDK 10 now, and the JDK 10 project has already been created, I'm not sure if we need a vote per project so I'm sending this CFV to both the JDK 9 and JDK 10 lists. Unless someone can verify that it is enough to vote for one of these projects I suggest that those of you that are in both lists replies to both mails and treat this as two separate votes. > > For Lazy Consensus voting instructions, see [2]. > > Thanks, > /Jesper > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/bylaws#lazy-consensus > [3] List of changes: > > (1) 8173896: SA: BasicLauncherTest.java (printmdo) fails for Client VM and Server VM with emulated-client > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/3bd7f52ecae6 > http://hg.openjdk.java.net/jdk9/hs/jdk/rev/615d771202e8 > > (2) 8171084: heapdump/JMapHeapCore fails with java.lang.RuntimeException: Heap segment size overflow > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/2c44cff993b8 > > (3) 8159127: hprof heap dumps broken for lambda classdata > http://hg.openjdk.java.net/jdk9/hs/./rev/e5605f29b00e > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/e5e4011e9c30 > > (4) 8169232: SA: TestCpoolForInvokeDynamic.java fails with sun.jvm.hotspot.debugger.DebuggerException: binary search bug: should have found entry 1 > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/13e6043fcdcb > > (5) 8169638: serviceability/sa/TestInstanceKlassSize.java and serviceability/sa/TestInstanceKlassSizeForInterface.java fail compilation > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/ae23c7acb99a > > (6) 8169344: Potential open file descriptor in exists() of hotspot/agent/src/os/bsd/ps_core.c > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/a71b53580d07 > > (7) 7107018: sun.jvm.hotspot.utilities.soql.JSJavaHeap.forEachClass incorrect test > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/a169535aff9d > > (8) 8164783: SA: jhsdb clhsdb 'printall' often throws "Corrupted constant pool" assertion failure > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/8c2f220c759c > > (9) 8164383: jhsdb dumps core on Solaris 12 when loading dumped core > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/ce3eaa22b582 > > (10) 8166552: SA: Missed testcase for add default methods to InstanceKlass > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/0ff97dc32114 > > (11) 8027920: SA: Add default methods to InstanceKlass > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/c8b3f8e5423b > > (12) 8163150: SA: CLHSDB printmdo throws an exception with "java.lang.InternalError: missing reason for 22" > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/3652a2a22916 > http://hg.openjdk.java.net/jdk9/hs/jdk/rev/8a0a818c3f28 > > (13) 8164562: serviceability/sa/TestInstanceKlassSizeForInterface.java: fails with NPE > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/1357a160e4f2 > > (14) 8163143: illegal bci error with interpreted frames in SA due to mirror being stored in interpreted frames > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/b84f097dc4c5 > http://hg.openjdk.java.net/jdk9/hs/jdk/rev/481ac1e59664 > > (15) 8145627: sun.jvm.hotspot.oops.InstanceKlass::getSize() returns the incorrect size and has no test > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/ca241ed18db8 > From eric.caspole at oracle.com Wed Feb 15 15:11:55 2017 From: eric.caspole at oracle.com (Eric Caspole) Date: Wed, 15 Feb 2017 10:11:55 -0500 Subject: CFV: New JDK 9/10 Committer: Jini George In-Reply-To: <854DE5D9-F54A-446C-A98E-8714121E072A@oracle.com> References: <854DE5D9-F54A-446C-A98E-8714121E072A@oracle.com> Message-ID: Vote: yes Eric On 02/15/2017 10:03 AM, jesper.wilhelmsson at oracle.com wrote: > I hereby nominate Jini George (jgeorge) to JDK 9 and JDK 10 Committer. > > Jini is part of the Monitoring and Management team and has contributed 15 changesets to JDK 9 [3]. > > Votes are due by Mars 1, 2017. > > Only current JDK 9/10 Committers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. Since we are in the borderland between JDK 9 and JDK 10 now, and the JDK 10 project has already been created, I'm not sure if we need a vote per project so I'm sending this CFV to both the JDK 9 and JDK 10 lists. Unless someone can verify that it is enough to vote for one of these projects I suggest that those of you that are in both lists replies to both mails and treat this as two separate votes. > > For Lazy Consensus voting instructions, see [2]. > > Thanks, > /Jesper > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/bylaws#lazy-consensus > [3] List of changes: > > (1) 8173896: SA: BasicLauncherTest.java (printmdo) fails for Client VM and Server VM with emulated-client > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/3bd7f52ecae6 > http://hg.openjdk.java.net/jdk9/hs/jdk/rev/615d771202e8 > > (2) 8171084: heapdump/JMapHeapCore fails with java.lang.RuntimeException: Heap segment size overflow > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/2c44cff993b8 > > (3) 8159127: hprof heap dumps broken for lambda classdata > http://hg.openjdk.java.net/jdk9/hs/./rev/e5605f29b00e > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/e5e4011e9c30 > > (4) 8169232: SA: TestCpoolForInvokeDynamic.java fails with sun.jvm.hotspot.debugger.DebuggerException: binary search bug: should have found entry 1 > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/13e6043fcdcb > > (5) 8169638: serviceability/sa/TestInstanceKlassSize.java and serviceability/sa/TestInstanceKlassSizeForInterface.java fail compilation > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/ae23c7acb99a > > (6) 8169344: Potential open file descriptor in exists() of hotspot/agent/src/os/bsd/ps_core.c > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/a71b53580d07 > > (7) 7107018: sun.jvm.hotspot.utilities.soql.JSJavaHeap.forEachClass incorrect test > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/a169535aff9d > > (8) 8164783: SA: jhsdb clhsdb 'printall' often throws "Corrupted constant pool" assertion failure > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/8c2f220c759c > > (9) 8164383: jhsdb dumps core on Solaris 12 when loading dumped core > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/ce3eaa22b582 > > (10) 8166552: SA: Missed testcase for add default methods to InstanceKlass > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/0ff97dc32114 > > (11) 8027920: SA: Add default methods to InstanceKlass > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/c8b3f8e5423b > > (12) 8163150: SA: CLHSDB printmdo throws an exception with "java.lang.InternalError: missing reason for 22" > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/3652a2a22916 > http://hg.openjdk.java.net/jdk9/hs/jdk/rev/8a0a818c3f28 > > (13) 8164562: serviceability/sa/TestInstanceKlassSizeForInterface.java: fails with NPE > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/1357a160e4f2 > > (14) 8163143: illegal bci error with interpreted frames in SA due to mirror being stored in interpreted frames > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/b84f097dc4c5 > http://hg.openjdk.java.net/jdk9/hs/jdk/rev/481ac1e59664 > > (15) 8145627: sun.jvm.hotspot.oops.InstanceKlass::getSize() returns the incorrect size and has no test > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/ca241ed18db8 > From harsha.wardhana.b at oracle.com Wed Feb 15 15:12:16 2017 From: harsha.wardhana.b at oracle.com (Harsha Wardhana B) Date: Wed, 15 Feb 2017 20:42:16 +0530 Subject: CFV: New JDK 9/10 Committer: Jini George In-Reply-To: References: <854DE5D9-F54A-446C-A98E-8714121E072A@oracle.com> Message-ID: Vote: yes -Harsha On Wednesday 15 February 2017 08:40 PM, Zolt?n Maj? wrote: > Vote: yes. > > Best regards, > > > Zoltan > > On 02/15/2017 04:03 PM, jesper.wilhelmsson at oracle.com wrote: >> I hereby nominate Jini George (jgeorge) to JDK 9 and JDK 10 Committer. >> >> Jini is part of the Monitoring and Management team and has >> contributed 15 changesets to JDK 9 [3]. >> >> Votes are due by Mars 1, 2017. >> >> Only current JDK 9/10 Committers [1] are eligible to vote on this >> nomination. >> Votes must be cast in the open by replying to this mailing list. >> Since we are in the borderland between JDK 9 and JDK 10 now, and the >> JDK 10 project has already been created, I'm not sure if we need a >> vote per project so I'm sending this CFV to both the JDK 9 and JDK 10 >> lists. Unless someone can verify that it is enough to vote for one of >> these projects I suggest that those of you that are in both lists >> replies to both mails and treat this as two separate votes. >> >> For Lazy Consensus voting instructions, see [2]. >> >> Thanks, >> /Jesper >> >> [1] http://openjdk.java.net/census >> [2] http://openjdk.java.net/bylaws#lazy-consensus >> >> [3] List of changes: >> >> (1) 8173896: SA: BasicLauncherTest.java (printmdo) fails for Client >> VM and Server VM with emulated-client >> http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/3bd7f52ecae6 >> >> http://hg.openjdk.java.net/jdk9/hs/jdk/rev/615d771202e8 >> >> >> (2) 8171084: heapdump/JMapHeapCore fails with >> java.lang.RuntimeException: Heap segment size overflow >> http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/2c44cff993b8 >> >> >> (3) 8159127: hprof heap dumps broken for lambda classdata >> http://hg.openjdk.java.net/jdk9/hs/./rev/e5605f29b00e >> >> http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/e5e4011e9c30 >> >> >> (4) 8169232: SA: TestCpoolForInvokeDynamic.java fails with >> sun.jvm.hotspot.debugger.DebuggerException: binary search bug: should >> have found entry 1 >> http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/13e6043fcdcb >> >> >> (5) 8169638: serviceability/sa/TestInstanceKlassSize.java and >> serviceability/sa/TestInstanceKlassSizeForInterface.java fail >> compilation >> http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/ae23c7acb99a >> >> >> (6) 8169344: Potential open file descriptor in exists() of >> hotspot/agent/src/os/bsd/ps_core.c >> http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/a71b53580d07 >> >> >> (7) 7107018: sun.jvm.hotspot.utilities.soql.JSJavaHeap.forEachClass >> incorrect test >> http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/a169535aff9d >> >> >> (8) 8164783: SA: jhsdb clhsdb 'printall' often throws "Corrupted >> constant pool" assertion failure >> http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/8c2f220c759c >> >> >> (9) 8164383: jhsdb dumps core on Solaris 12 when loading dumped core >> http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/ce3eaa22b582 >> >> >> (10) 8166552: SA: Missed testcase for add default methods to >> InstanceKlass >> http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/0ff97dc32114 >> >> >> (11) 8027920: SA: Add default methods to InstanceKlass >> http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/c8b3f8e5423b >> >> >> (12) 8163150: SA: CLHSDB printmdo throws an exception with >> "java.lang.InternalError: missing reason for 22" >> http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/3652a2a22916 >> >> http://hg.openjdk.java.net/jdk9/hs/jdk/rev/8a0a818c3f28 >> >> >> (13) 8164562: >> serviceability/sa/TestInstanceKlassSizeForInterface.java: fails with NPE >> http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/1357a160e4f2 >> >> >> (14) 8163143: illegal bci error with interpreted frames in SA due to >> mirror being stored in interpreted frames >> http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/b84f097dc4c5 >> >> http://hg.openjdk.java.net/jdk9/hs/jdk/rev/481ac1e59664 >> >> >> (15) 8145627: sun.jvm.hotspot.oops.InstanceKlass::getSize() returns >> the incorrect size and has no test >> http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/ca241ed18db8 >> >> > From rahul.v.raghavan at oracle.com Wed Feb 15 15:16:31 2017 From: rahul.v.raghavan at oracle.com (Rahul Raghavan) Date: Wed, 15 Feb 2017 07:16:31 -0800 (PST) Subject: CFV: New JDK 9/10 Committer: Jini George In-Reply-To: <854DE5D9-F54A-446C-A98E-8714121E072A@oracle.com> References: <854DE5D9-F54A-446C-A98E-8714121E072A@oracle.com> Message-ID: <2c2bb4e6-49e4-4abe-8c27-d660688f7aeb@default> Vote: yes Thanks, Rahul > -----Original Message----- > From: Jesper Wilhelmsson > Sent: Wednesday, February 15, 2017 8:34 PM > To: jdk9-dev at openjdk.java.net; jdk10-dev at openjdk.java.net > Subject: CFV: New JDK 9/10 Committer: Jini George > > I hereby nominate Jini George (jgeorge) to JDK 9 and JDK 10 Committer. > > Jini is part of the Monitoring and Management team and has contributed 15 changesets to JDK 9 [3]. > > Votes are due by Mars 1, 2017. > > Only current JDK 9/10 Committers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. Since we are in the borderland between JDK 9 and JDK 10 now, and the > JDK 10 project has already been created, I'm not sure if we need a vote per project so I'm sending this CFV to both the JDK 9 and JDK > 10 lists. Unless someone can verify that it is enough to vote for one of these projects I suggest that those of you that are in both lists > replies to both mails and treat this as two separate votes. > > For Lazy Consensus voting instructions, see [2]. > > Thanks, > /Jesper > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/bylaws#lazy-consensus > [3] List of changes: > > (1) 8173896: SA: BasicLauncherTest.java (printmdo) fails for Client VM and Server VM with emulated-client > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/3bd7f52ecae6 > http://hg.openjdk.java.net/jdk9/hs/jdk/rev/615d771202e8 > > (2) 8171084: heapdump/JMapHeapCore fails with java.lang.RuntimeException: Heap segment size overflow > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/2c44cff993b8 > > (3) 8159127: hprof heap dumps broken for lambda classdata > http://hg.openjdk.java.net/jdk9/hs/./rev/e5605f29b00e > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/e5e4011e9c30 > > (4) 8169232: SA: TestCpoolForInvokeDynamic.java fails with sun.jvm.hotspot.debugger.DebuggerException: binary search bug: should > have found entry 1 > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/13e6043fcdcb > > (5) 8169638: serviceability/sa/TestInstanceKlassSize.java and serviceability/sa/TestInstanceKlassSizeForInterface.java fail compilation > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/ae23c7acb99a > > (6) 8169344: Potential open file descriptor in exists() of hotspot/agent/src/os/bsd/ps_core.c > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/a71b53580d07 > > (7) 7107018: sun.jvm.hotspot.utilities.soql.JSJavaHeap.forEachClass incorrect test > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/a169535aff9d > > (8) 8164783: SA: jhsdb clhsdb 'printall' often throws "Corrupted constant pool" assertion failure > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/8c2f220c759c > > (9) 8164383: jhsdb dumps core on Solaris 12 when loading dumped core > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/ce3eaa22b582 > > (10) 8166552: SA: Missed testcase for add default methods to InstanceKlass > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/0ff97dc32114 > > (11) 8027920: SA: Add default methods to InstanceKlass > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/c8b3f8e5423b > > (12) 8163150: SA: CLHSDB printmdo throws an exception with "java.lang.InternalError: missing reason for 22" > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/3652a2a22916 > http://hg.openjdk.java.net/jdk9/hs/jdk/rev/8a0a818c3f28 > > (13) 8164562: serviceability/sa/TestInstanceKlassSizeForInterface.java: fails with NPE > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/1357a160e4f2 > > (14) 8163143: illegal bci error with interpreted frames in SA due to mirror being stored in interpreted frames > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/b84f097dc4c5 > http://hg.openjdk.java.net/jdk9/hs/jdk/rev/481ac1e59664 > > (15) 8145627: sun.jvm.hotspot.oops.InstanceKlass::getSize() returns the incorrect size and has no test > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/ca241ed18db8 > From jesper.wilhelmsson at oracle.com Wed Feb 15 15:19:06 2017 From: jesper.wilhelmsson at oracle.com (jesper.wilhelmsson at oracle.com) Date: Wed, 15 Feb 2017 16:19:06 +0100 Subject: CFV: New JDK 9/10 Committer: Jini George In-Reply-To: <854DE5D9-F54A-446C-A98E-8714121E072A@oracle.com> References: <854DE5D9-F54A-446C-A98E-8714121E072A@oracle.com> Message-ID: <0E733400-2F5C-45A0-8C87-13DD569B86BD@oracle.com> Vote: Yes /Jesper > On 15 Feb 2017, at 16:03, jesper.wilhelmsson at oracle.com wrote: > > I hereby nominate Jini George (jgeorge) to JDK 9 and JDK 10 Committer. > > Jini is part of the Monitoring and Management team and has contributed 15 changesets to JDK 9 [3]. > > Votes are due by Mars 1, 2017. > > Only current JDK 9/10 Committers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. Since we are in the borderland between JDK 9 and JDK 10 now, and the JDK 10 project has already been created, I'm not sure if we need a vote per project so I'm sending this CFV to both the JDK 9 and JDK 10 lists. Unless someone can verify that it is enough to vote for one of these projects I suggest that those of you that are in both lists replies to both mails and treat this as two separate votes. > > For Lazy Consensus voting instructions, see [2]. > > Thanks, > /Jesper > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/bylaws#lazy-consensus > [3] List of changes: > > (1) 8173896: SA: BasicLauncherTest.java (printmdo) fails for Client VM and Server VM with emulated-client > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/3bd7f52ecae6 > http://hg.openjdk.java.net/jdk9/hs/jdk/rev/615d771202e8 > > (2) 8171084: heapdump/JMapHeapCore fails with java.lang.RuntimeException: Heap segment size overflow > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/2c44cff993b8 > > (3) 8159127: hprof heap dumps broken for lambda classdata > http://hg.openjdk.java.net/jdk9/hs/./rev/e5605f29b00e > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/e5e4011e9c30 > > (4) 8169232: SA: TestCpoolForInvokeDynamic.java fails with sun.jvm.hotspot.debugger.DebuggerException: binary search bug: should have found entry 1 > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/13e6043fcdcb > > (5) 8169638: serviceability/sa/TestInstanceKlassSize.java and serviceability/sa/TestInstanceKlassSizeForInterface.java fail compilation > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/ae23c7acb99a > > (6) 8169344: Potential open file descriptor in exists() of hotspot/agent/src/os/bsd/ps_core.c > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/a71b53580d07 > > (7) 7107018: sun.jvm.hotspot.utilities.soql.JSJavaHeap.forEachClass incorrect test > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/a169535aff9d > > (8) 8164783: SA: jhsdb clhsdb 'printall' often throws "Corrupted constant pool" assertion failure > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/8c2f220c759c > > (9) 8164383: jhsdb dumps core on Solaris 12 when loading dumped core > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/ce3eaa22b582 > > (10) 8166552: SA: Missed testcase for add default methods to InstanceKlass > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/0ff97dc32114 > > (11) 8027920: SA: Add default methods to InstanceKlass > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/c8b3f8e5423b > > (12) 8163150: SA: CLHSDB printmdo throws an exception with "java.lang.InternalError: missing reason for 22" > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/3652a2a22916 > http://hg.openjdk.java.net/jdk9/hs/jdk/rev/8a0a818c3f28 > > (13) 8164562: serviceability/sa/TestInstanceKlassSizeForInterface.java: fails with NPE > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/1357a160e4f2 > > (14) 8163143: illegal bci error with interpreted frames in SA due to mirror being stored in interpreted frames > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/b84f097dc4c5 > http://hg.openjdk.java.net/jdk9/hs/jdk/rev/481ac1e59664 > > (15) 8145627: sun.jvm.hotspot.oops.InstanceKlass::getSize() returns the incorrect size and has no test > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/ca241ed18db8 > From staffan.larsen at oracle.com Wed Feb 15 15:46:59 2017 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 15 Feb 2017 16:46:59 +0100 Subject: CFV: New JDK 9/10 Committer: Jini George In-Reply-To: <854DE5D9-F54A-446C-A98E-8714121E072A@oracle.com> References: <854DE5D9-F54A-446C-A98E-8714121E072A@oracle.com> Message-ID: Vote: yes > On 15 Feb 2017, at 16:03, jesper.wilhelmsson at oracle.com wrote: > > I hereby nominate Jini George (jgeorge) to JDK 9 and JDK 10 Committer. > > Jini is part of the Monitoring and Management team and has contributed 15 changesets to JDK 9 [3]. > > Votes are due by Mars 1, 2017. > > Only current JDK 9/10 Committers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. Since we are in the borderland between JDK 9 and JDK 10 now, and the JDK 10 project has already been created, I'm not sure if we need a vote per project so I'm sending this CFV to both the JDK 9 and JDK 10 lists. Unless someone can verify that it is enough to vote for one of these projects I suggest that those of you that are in both lists replies to both mails and treat this as two separate votes. > > For Lazy Consensus voting instructions, see [2]. > > Thanks, > /Jesper > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/bylaws#lazy-consensus > [3] List of changes: > > (1) 8173896: SA: BasicLauncherTest.java (printmdo) fails for Client VM and Server VM with emulated-client > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/3bd7f52ecae6 > http://hg.openjdk.java.net/jdk9/hs/jdk/rev/615d771202e8 > > (2) 8171084: heapdump/JMapHeapCore fails with java.lang.RuntimeException: Heap segment size overflow > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/2c44cff993b8 > > (3) 8159127: hprof heap dumps broken for lambda classdata > http://hg.openjdk.java.net/jdk9/hs/./rev/e5605f29b00e > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/e5e4011e9c30 > > (4) 8169232: SA: TestCpoolForInvokeDynamic.java fails with sun.jvm.hotspot.debugger.DebuggerException: binary search bug: should have found entry 1 > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/13e6043fcdcb > > (5) 8169638: serviceability/sa/TestInstanceKlassSize.java and serviceability/sa/TestInstanceKlassSizeForInterface.java fail compilation > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/ae23c7acb99a > > (6) 8169344: Potential open file descriptor in exists() of hotspot/agent/src/os/bsd/ps_core.c > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/a71b53580d07 > > (7) 7107018: sun.jvm.hotspot.utilities.soql.JSJavaHeap.forEachClass incorrect test > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/a169535aff9d > > (8) 8164783: SA: jhsdb clhsdb 'printall' often throws "Corrupted constant pool" assertion failure > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/8c2f220c759c > > (9) 8164383: jhsdb dumps core on Solaris 12 when loading dumped core > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/ce3eaa22b582 > > (10) 8166552: SA: Missed testcase for add default methods to InstanceKlass > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/0ff97dc32114 > > (11) 8027920: SA: Add default methods to InstanceKlass > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/c8b3f8e5423b > > (12) 8163150: SA: CLHSDB printmdo throws an exception with "java.lang.InternalError: missing reason for 22" > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/3652a2a22916 > http://hg.openjdk.java.net/jdk9/hs/jdk/rev/8a0a818c3f28 > > (13) 8164562: serviceability/sa/TestInstanceKlassSizeForInterface.java: fails with NPE > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/1357a160e4f2 > > (14) 8163143: illegal bci error with interpreted frames in SA due to mirror being stored in interpreted frames > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/b84f097dc4c5 > http://hg.openjdk.java.net/jdk9/hs/jdk/rev/481ac1e59664 > > (15) 8145627: sun.jvm.hotspot.oops.InstanceKlass::getSize() returns the incorrect size and has no test > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/ca241ed18db8 > From daniel.fuchs at oracle.com Wed Feb 15 15:50:16 2017 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 15 Feb 2017 15:50:16 +0000 Subject: CFV: New JDK 9/10 Committer: Jini George In-Reply-To: <854DE5D9-F54A-446C-A98E-8714121E072A@oracle.com> References: <854DE5D9-F54A-446C-A98E-8714121E072A@oracle.com> Message-ID: <1a273223-a08f-4607-b8a4-284d169be8f3@oracle.com> Vote: yes On 15/02/17 15:03, jesper.wilhelmsson at oracle.com wrote: > I hereby nominate Jini George (jgeorge) to JDK 9 and JDK 10 Committer. > > Jini is part of the Monitoring and Management team and has contributed 15 changesets to JDK 9 [3]. > From jamsheed.c.m at oracle.com Wed Feb 15 15:59:36 2017 From: jamsheed.c.m at oracle.com (Jamsheed C m) Date: Wed, 15 Feb 2017 21:29:36 +0530 Subject: CFV: New JDK 9/10 Committer: Jini George In-Reply-To: <854DE5D9-F54A-446C-A98E-8714121E072A@oracle.com> References: <854DE5D9-F54A-446C-A98E-8714121E072A@oracle.com> Message-ID: <6d4a4109-9736-cb2e-75f3-1397dbc062fb@oracle.com> Vote: Yes Best Regards, Jamsheed On 2/15/2017 8:33 PM, jesper.wilhelmsson at oracle.com wrote: > I hereby nominate Jini George (jgeorge) to JDK 9 and JDK 10 Committer. > > Jini is part of the Monitoring and Management team and has contributed 15 changesets to JDK 9 [3]. > > Votes are due by Mars 1, 2017. > > Only current JDK 9/10 Committers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. Since we are in the borderland between JDK 9 and JDK 10 now, and the JDK 10 project has already been created, I'm not sure if we need a vote per project so I'm sending this CFV to both the JDK 9 and JDK 10 lists. Unless someone can verify that it is enough to vote for one of these projects I suggest that those of you that are in both lists replies to both mails and treat this as two separate votes. > > For Lazy Consensus voting instructions, see [2]. > > Thanks, > /Jesper > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/bylaws#lazy-consensus > [3] List of changes: > > (1) 8173896: SA: BasicLauncherTest.java (printmdo) fails for Client VM and Server VM with emulated-client > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/3bd7f52ecae6 > http://hg.openjdk.java.net/jdk9/hs/jdk/rev/615d771202e8 > > (2) 8171084: heapdump/JMapHeapCore fails with java.lang.RuntimeException: Heap segment size overflow > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/2c44cff993b8 > > (3) 8159127: hprof heap dumps broken for lambda classdata > http://hg.openjdk.java.net/jdk9/hs/./rev/e5605f29b00e > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/e5e4011e9c30 > > (4) 8169232: SA: TestCpoolForInvokeDynamic.java fails with sun.jvm.hotspot.debugger.DebuggerException: binary search bug: should have found entry 1 > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/13e6043fcdcb > > (5) 8169638: serviceability/sa/TestInstanceKlassSize.java and serviceability/sa/TestInstanceKlassSizeForInterface.java fail compilation > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/ae23c7acb99a > > (6) 8169344: Potential open file descriptor in exists() of hotspot/agent/src/os/bsd/ps_core.c > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/a71b53580d07 > > (7) 7107018: sun.jvm.hotspot.utilities.soql.JSJavaHeap.forEachClass incorrect test > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/a169535aff9d > > (8) 8164783: SA: jhsdb clhsdb 'printall' often throws "Corrupted constant pool" assertion failure > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/8c2f220c759c > > (9) 8164383: jhsdb dumps core on Solaris 12 when loading dumped core > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/ce3eaa22b582 > > (10) 8166552: SA: Missed testcase for add default methods to InstanceKlass > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/0ff97dc32114 > > (11) 8027920: SA: Add default methods to InstanceKlass > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/c8b3f8e5423b > > (12) 8163150: SA: CLHSDB printmdo throws an exception with "java.lang.InternalError: missing reason for 22" > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/3652a2a22916 > http://hg.openjdk.java.net/jdk9/hs/jdk/rev/8a0a818c3f28 > > (13) 8164562: serviceability/sa/TestInstanceKlassSizeForInterface.java: fails with NPE > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/1357a160e4f2 > > (14) 8163143: illegal bci error with interpreted frames in SA due to mirror being stored in interpreted frames > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/b84f097dc4c5 > http://hg.openjdk.java.net/jdk9/hs/jdk/rev/481ac1e59664 > > (15) 8145627: sun.jvm.hotspot.oops.InstanceKlass::getSize() returns the incorrect size and has no test > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/ca241ed18db8 > From andy.herrick at oracle.com Wed Feb 15 16:53:00 2017 From: andy.herrick at oracle.com (Andy Herrick) Date: Wed, 15 Feb 2017 11:53:00 -0500 Subject: CFV: New JDK 9/10 Committer: Jini George In-Reply-To: <854DE5D9-F54A-446C-A98E-8714121E072A@oracle.com> References: <854DE5D9-F54A-446C-A98E-8714121E072A@oracle.com> Message-ID: <2aa0094f-d65c-d0ca-fd46-88018cf1810f@oracle.com> vote: yes /Andy On 2/15/2017 10:03 AM, jesper.wilhelmsson at oracle.com wrote: > I hereby nominate Jini George (jgeorge) to JDK 9 and JDK 10 Committer. > > Jini is part of the Monitoring and Management team and has contributed 15 changesets to JDK 9 [3]. > > Votes are due by Mars 1, 2017. > > Only current JDK 9/10 Committers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. Since we are in the borderland between JDK 9 and JDK 10 now, and the JDK 10 project has already been created, I'm not sure if we need a vote per project so I'm sending this CFV to both the JDK 9 and JDK 10 lists. Unless someone can verify that it is enough to vote for one of these projects I suggest that those of you that are in both lists replies to both mails and treat this as two separate votes. > > For Lazy Consensus voting instructions, see [2]. > > Thanks, > /Jesper > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/bylaws#lazy-consensus > [3] List of changes: > > (1) 8173896: SA: BasicLauncherTest.java (printmdo) fails for Client VM and Server VM with emulated-client > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/3bd7f52ecae6 > http://hg.openjdk.java.net/jdk9/hs/jdk/rev/615d771202e8 > > (2) 8171084: heapdump/JMapHeapCore fails with java.lang.RuntimeException: Heap segment size overflow > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/2c44cff993b8 > > (3) 8159127: hprof heap dumps broken for lambda classdata > http://hg.openjdk.java.net/jdk9/hs/./rev/e5605f29b00e > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/e5e4011e9c30 > > (4) 8169232: SA: TestCpoolForInvokeDynamic.java fails with sun.jvm.hotspot.debugger.DebuggerException: binary search bug: should have found entry 1 > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/13e6043fcdcb > > (5) 8169638: serviceability/sa/TestInstanceKlassSize.java and serviceability/sa/TestInstanceKlassSizeForInterface.java fail compilation > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/ae23c7acb99a > > (6) 8169344: Potential open file descriptor in exists() of hotspot/agent/src/os/bsd/ps_core.c > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/a71b53580d07 > > (7) 7107018: sun.jvm.hotspot.utilities.soql.JSJavaHeap.forEachClass incorrect test > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/a169535aff9d > > (8) 8164783: SA: jhsdb clhsdb 'printall' often throws "Corrupted constant pool" assertion failure > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/8c2f220c759c > > (9) 8164383: jhsdb dumps core on Solaris 12 when loading dumped core > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/ce3eaa22b582 > > (10) 8166552: SA: Missed testcase for add default methods to InstanceKlass > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/0ff97dc32114 > > (11) 8027920: SA: Add default methods to InstanceKlass > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/c8b3f8e5423b > > (12) 8163150: SA: CLHSDB printmdo throws an exception with "java.lang.InternalError: missing reason for 22" > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/3652a2a22916 > http://hg.openjdk.java.net/jdk9/hs/jdk/rev/8a0a818c3f28 > > (13) 8164562: serviceability/sa/TestInstanceKlassSizeForInterface.java: fails with NPE > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/1357a160e4f2 > > (14) 8163143: illegal bci error with interpreted frames in SA due to mirror being stored in interpreted frames > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/b84f097dc4c5 > http://hg.openjdk.java.net/jdk9/hs/jdk/rev/481ac1e59664 > > (15) 8145627: sun.jvm.hotspot.oops.InstanceKlass::getSize() returns the incorrect size and has no test > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/ca241ed18db8 > From daniel.daugherty at oracle.com Wed Feb 15 18:31:58 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 15 Feb 2017 11:31:58 -0700 Subject: CFV: New JDK 9/10 Committer: Jini George In-Reply-To: <854DE5D9-F54A-446C-A98E-8714121E072A@oracle.com> References: <854DE5D9-F54A-446C-A98E-8714121E072A@oracle.com> Message-ID: <9418460d-3242-d216-2f3a-e6a5040fdcc9@oracle.com> Vote: yes Dan On 2/15/17 8:03 AM, jesper.wilhelmsson at oracle.com wrote: > I hereby nominate Jini George (jgeorge) to JDK 9 and JDK 10 Committer. > > Jini is part of the Monitoring and Management team and has contributed 15 changesets to JDK 9 [3]. > > Votes are due by Mars 1, 2017. > > Only current JDK 9/10 Committers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. Since we are in the borderland between JDK 9 and JDK 10 now, and the JDK 10 project has already been created, I'm not sure if we need a vote per project so I'm sending this CFV to both the JDK 9 and JDK 10 lists. Unless someone can verify that it is enough to vote for one of these projects I suggest that those of you that are in both lists replies to both mails and treat this as two separate votes. > > For Lazy Consensus voting instructions, see [2]. > > Thanks, > /Jesper > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/bylaws#lazy-consensus > [3] List of changes: > > (1) 8173896: SA: BasicLauncherTest.java (printmdo) fails for Client VM and Server VM with emulated-client > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/3bd7f52ecae6 > http://hg.openjdk.java.net/jdk9/hs/jdk/rev/615d771202e8 > > (2) 8171084: heapdump/JMapHeapCore fails with java.lang.RuntimeException: Heap segment size overflow > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/2c44cff993b8 > > (3) 8159127: hprof heap dumps broken for lambda classdata > http://hg.openjdk.java.net/jdk9/hs/./rev/e5605f29b00e > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/e5e4011e9c30 > > (4) 8169232: SA: TestCpoolForInvokeDynamic.java fails with sun.jvm.hotspot.debugger.DebuggerException: binary search bug: should have found entry 1 > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/13e6043fcdcb > > (5) 8169638: serviceability/sa/TestInstanceKlassSize.java and serviceability/sa/TestInstanceKlassSizeForInterface.java fail compilation > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/ae23c7acb99a > > (6) 8169344: Potential open file descriptor in exists() of hotspot/agent/src/os/bsd/ps_core.c > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/a71b53580d07 > > (7) 7107018: sun.jvm.hotspot.utilities.soql.JSJavaHeap.forEachClass incorrect test > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/a169535aff9d > > (8) 8164783: SA: jhsdb clhsdb 'printall' often throws "Corrupted constant pool" assertion failure > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/8c2f220c759c > > (9) 8164383: jhsdb dumps core on Solaris 12 when loading dumped core > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/ce3eaa22b582 > > (10) 8166552: SA: Missed testcase for add default methods to InstanceKlass > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/0ff97dc32114 > > (11) 8027920: SA: Add default methods to InstanceKlass > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/c8b3f8e5423b > > (12) 8163150: SA: CLHSDB printmdo throws an exception with "java.lang.InternalError: missing reason for 22" > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/3652a2a22916 > http://hg.openjdk.java.net/jdk9/hs/jdk/rev/8a0a818c3f28 > > (13) 8164562: serviceability/sa/TestInstanceKlassSizeForInterface.java: fails with NPE > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/1357a160e4f2 > > (14) 8163143: illegal bci error with interpreted frames in SA due to mirror being stored in interpreted frames > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/b84f097dc4c5 > http://hg.openjdk.java.net/jdk9/hs/jdk/rev/481ac1e59664 > > (15) 8145627: sun.jvm.hotspot.oops.InstanceKlass::getSize() returns the incorrect size and has no test > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/ca241ed18db8 > > From vladimir.kozlov at oracle.com Wed Feb 15 21:00:46 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 15 Feb 2017 13:00:46 -0800 Subject: How to handle future backports from JDK 10 into JDK 9? In-Reply-To: <58db6d43-3457-8bd9-bb04-3ab01aeb64e7@oracle.com> References: <49f8daf7-6c15-dec9-92e3-ef76dc6f2afb@oracle.com> <58db6d43-3457-8bd9-bb04-3ab01aeb64e7@oracle.com> Message-ID: <5df4217f-0a88-4938-a06f-e00176a5153b@oracle.com> We discussed this in Hotspot and support David's opinion here. We should not relax jcheck and we can use backport type different bug id as he suggested. Regards, Vladimir On 2/13/17 6:15 PM, David Holmes wrote: > On 14/02/2017 8:54 AM, joe darcy wrote: >> Hello, >> >> An open question in Mark's announcement that the JDK 10 forests are open >> [1] concerned how to manage backports from JDK 10 to JDK 9: >> >> "In the (hopefully infrequent) event that a change in JDK 10 needs to be >> back-ported to JDK 9 we'll have to figure out how to handle the duplicate >> bug ids that will arise when a back-ported change is later merged forward >> into JDK 10. One solution may just be to disable the unique bug-id test >> in jcheck, on the assumption that existing social conventions adequately >> protect us from the pathological scenarios that are prevented by this >> test. Thoughts welcome ..." >> >> As a reminder, the overall model (for now) is that all fixes from JDK 9 >> will be synced into JDK 10; the first sync of several hundred bugs >> happened recently and went smoothly. [2] >> >> The potentially problematic situation would occur if >> >> * Bug JDK-8181818 is first fixed in JDK 10 >> * Bug JDK-8181818 is then backported to JDK 9 >> * The next sync of JDK 9 into JDK 10 would fail on the duplicate bug id >> JDK-8181818 even though the code may be identical >> >> One way to avoid this problem would be to do the push to JDK 9 under an >> explicit backport bug id rather than the main bug id JDK-8181818. This >> approach has a number of drawback. First, long-standing social >> convention has been to "always use the main bug id." Second, tooling >> like Hg updater has been written on the assumption that the main bug id >> will always be used to conceptually refer to an issue. >> >> The purpose of the jcheck unique bug id check stems from preventing >> sloppy bug handling where multiple changesets partially and >> incrementally address a bug and it is not clear whether or not an issue >> is fully fixed or not. >> >> However, even without programmatic enforcement of unique bug id, I don't >> think JDK development practices would devolve in that way. As supporting >> evidence, the unique bug id check is disabled in the 8 update forests to >> allow fixes from multiple releases to come back together in the >> always-open forest and the pathologies around partial fixes have not >> occurred. >> >> Therefore, I think the better option is to also disable the unique bug >> id check for the JDK 10 forests to allow easier syncing between 9 and 10. > > I think that check has helped avoid pushes with mis-typed bug numbers. Unless we have a stronger "does this bug id match the bug synopsis" check I would not want to see this bug id check relaxed. > > I would not expect there to be many cases where something is deferred to 10, fixed, and then re-considered for 9. But if that does happen I think the simplest thing may be to do the backport under a > new bug id (as already happens at time in the update releases when the backport is not clean). > > Thanks, > David > ----- > >> Comments? >> >> Cheers, >> >> -Joe >> >> [1] >> http://mail.openjdk.java.net/pipermail/jdk10-dev/2017-January/000041.html >> >> [2] >> http://mail.openjdk.java.net/pipermail/jdk10-dev/2017-February/000054.html >> From serguei.spitsyn at oracle.com Wed Feb 15 21:33:45 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 15 Feb 2017 13:33:45 -0800 Subject: CFV: New JDK 9/10 Committer: Jini George In-Reply-To: References: <854DE5D9-F54A-446C-A98E-8714121E072A@oracle.com> Message-ID: <90edb5a9-5394-8654-28b4-64b0e307a2ba@oracle.com> Vote: yes From serguei.spitsyn at oracle.com Wed Feb 15 21:39:33 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 15 Feb 2017 13:39:33 -0800 Subject: CFV: New JDK 9/10 Committer: Jini George In-Reply-To: <854DE5D9-F54A-446C-A98E-8714121E072A@oracle.com> References: <854DE5D9-F54A-446C-A98E-8714121E072A@oracle.com> Message-ID: Vote: yes From david.holmes at oracle.com Wed Feb 15 22:39:56 2017 From: david.holmes at oracle.com (David Holmes) Date: Thu, 16 Feb 2017 08:39:56 +1000 Subject: CFV: New JDK 9/10 Committer: Jini George In-Reply-To: <854DE5D9-F54A-446C-A98E-8714121E072A@oracle.com> References: <854DE5D9-F54A-446C-A98E-8714121E072A@oracle.com> Message-ID: <159136ca-027e-9794-8823-7c0f29e7c840@oracle.com> Vote: yes David On 16/02/2017 1:03 AM, jesper.wilhelmsson at oracle.com wrote: > I hereby nominate Jini George (jgeorge) to JDK 9 and JDK 10 Committer. > > Jini is part of the Monitoring and Management team and has contributed 15 changesets to JDK 9 [3]. > > Votes are due by Mars 1, 2017. > > Only current JDK 9/10 Committers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. Since we are in the borderland between JDK 9 and JDK 10 now, and the JDK 10 project has already been created, I'm not sure if we need a vote per project so I'm sending this CFV to both the JDK 9 and JDK 10 lists. Unless someone can verify that it is enough to vote for one of these projects I suggest that those of you that are in both lists replies to both mails and treat this as two separate votes. > > For Lazy Consensus voting instructions, see [2]. > > Thanks, > /Jesper > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/bylaws#lazy-consensus > [3] List of changes: > > (1) 8173896: SA: BasicLauncherTest.java (printmdo) fails for Client VM and Server VM with emulated-client > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/3bd7f52ecae6 > http://hg.openjdk.java.net/jdk9/hs/jdk/rev/615d771202e8 > > (2) 8171084: heapdump/JMapHeapCore fails with java.lang.RuntimeException: Heap segment size overflow > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/2c44cff993b8 > > (3) 8159127: hprof heap dumps broken for lambda classdata > http://hg.openjdk.java.net/jdk9/hs/./rev/e5605f29b00e > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/e5e4011e9c30 > > (4) 8169232: SA: TestCpoolForInvokeDynamic.java fails with sun.jvm.hotspot.debugger.DebuggerException: binary search bug: should have found entry 1 > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/13e6043fcdcb > > (5) 8169638: serviceability/sa/TestInstanceKlassSize.java and serviceability/sa/TestInstanceKlassSizeForInterface.java fail compilation > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/ae23c7acb99a > > (6) 8169344: Potential open file descriptor in exists() of hotspot/agent/src/os/bsd/ps_core.c > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/a71b53580d07 > > (7) 7107018: sun.jvm.hotspot.utilities.soql.JSJavaHeap.forEachClass incorrect test > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/a169535aff9d > > (8) 8164783: SA: jhsdb clhsdb 'printall' often throws "Corrupted constant pool" assertion failure > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/8c2f220c759c > > (9) 8164383: jhsdb dumps core on Solaris 12 when loading dumped core > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/ce3eaa22b582 > > (10) 8166552: SA: Missed testcase for add default methods to InstanceKlass > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/0ff97dc32114 > > (11) 8027920: SA: Add default methods to InstanceKlass > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/c8b3f8e5423b > > (12) 8163150: SA: CLHSDB printmdo throws an exception with "java.lang.InternalError: missing reason for 22" > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/3652a2a22916 > http://hg.openjdk.java.net/jdk9/hs/jdk/rev/8a0a818c3f28 > > (13) 8164562: serviceability/sa/TestInstanceKlassSizeForInterface.java: fails with NPE > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/1357a160e4f2 > > (14) 8163143: illegal bci error with interpreted frames in SA due to mirror being stored in interpreted frames > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/b84f097dc4c5 > http://hg.openjdk.java.net/jdk9/hs/jdk/rev/481ac1e59664 > > (15) 8145627: sun.jvm.hotspot.oops.InstanceKlass::getSize() returns the incorrect size and has no test > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/ca241ed18db8 > From nadeesh.tv at oracle.com Thu Feb 16 05:27:17 2017 From: nadeesh.tv at oracle.com (nadeesh tv) Date: Thu, 16 Feb 2017 10:57:17 +0530 Subject: CFV: New JDK 9/10 Committer: Jini George In-Reply-To: <854DE5D9-F54A-446C-A98E-8714121E072A@oracle.com> References: <854DE5D9-F54A-446C-A98E-8714121E072A@oracle.com> Message-ID: <58A53835.7040102@oracle.com> Vote : Yes On 2/15/2017 8:33 PM, jesper.wilhelmsson at oracle.com wrote: > I hereby nominate Jini George (jgeorge) to JDK 9 and JDK 10 Committer. > > Jini is part of the Monitoring and Management team and has contributed 15 changesets to JDK 9 [3]. > > Votes are due by Mars 1, 2017. > > Only current JDK 9/10 Committers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. Since we are in the borderland between JDK 9 and JDK 10 now, and the JDK 10 project has already been created, I'm not sure if we need a vote per project so I'm sending this CFV to both the JDK 9 and JDK 10 lists. Unless someone can verify that it is enough to vote for one of these projects I suggest that those of you that are in both lists replies to both mails and treat this as two separate votes. > > For Lazy Consensus voting instructions, see [2]. > > Thanks, > /Jesper > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/bylaws#lazy-consensus > [3] List of changes: > > (1) 8173896: SA: BasicLauncherTest.java (printmdo) fails for Client VM and Server VM with emulated-client > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/3bd7f52ecae6 > http://hg.openjdk.java.net/jdk9/hs/jdk/rev/615d771202e8 > > (2) 8171084: heapdump/JMapHeapCore fails with java.lang.RuntimeException: Heap segment size overflow > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/2c44cff993b8 > > (3) 8159127: hprof heap dumps broken for lambda classdata > http://hg.openjdk.java.net/jdk9/hs/./rev/e5605f29b00e > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/e5e4011e9c30 > > (4) 8169232: SA: TestCpoolForInvokeDynamic.java fails with sun.jvm.hotspot.debugger.DebuggerException: binary search bug: should have found entry 1 > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/13e6043fcdcb > > (5) 8169638: serviceability/sa/TestInstanceKlassSize.java and serviceability/sa/TestInstanceKlassSizeForInterface.java fail compilation > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/ae23c7acb99a > > (6) 8169344: Potential open file descriptor in exists() of hotspot/agent/src/os/bsd/ps_core.c > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/a71b53580d07 > > (7) 7107018: sun.jvm.hotspot.utilities.soql.JSJavaHeap.forEachClass incorrect test > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/a169535aff9d > > (8) 8164783: SA: jhsdb clhsdb 'printall' often throws "Corrupted constant pool" assertion failure > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/8c2f220c759c > > (9) 8164383: jhsdb dumps core on Solaris 12 when loading dumped core > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/ce3eaa22b582 > > (10) 8166552: SA: Missed testcase for add default methods to InstanceKlass > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/0ff97dc32114 > > (11) 8027920: SA: Add default methods to InstanceKlass > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/c8b3f8e5423b > > (12) 8163150: SA: CLHSDB printmdo throws an exception with "java.lang.InternalError: missing reason for 22" > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/3652a2a22916 > http://hg.openjdk.java.net/jdk9/hs/jdk/rev/8a0a818c3f28 > > (13) 8164562: serviceability/sa/TestInstanceKlassSizeForInterface.java: fails with NPE > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/1357a160e4f2 > > (14) 8163143: illegal bci error with interpreted frames in SA due to mirror being stored in interpreted frames > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/b84f097dc4c5 > http://hg.openjdk.java.net/jdk9/hs/jdk/rev/481ac1e59664 > > (15) 8145627: sun.jvm.hotspot.oops.InstanceKlass::getSize() returns the incorrect size and has no test > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/ca241ed18db8 > -- Thanks and Regards, Nadeesh TV From rachna.goel at oracle.com Thu Feb 16 06:22:39 2017 From: rachna.goel at oracle.com (Rachna Goel) Date: Thu, 16 Feb 2017 11:52:39 +0530 Subject: CFV: New JDK 9/10 Committer: Jini George In-Reply-To: <854DE5D9-F54A-446C-A98E-8714121E072A@oracle.com> References: <854DE5D9-F54A-446C-A98E-8714121E072A@oracle.com> Message-ID: <9b6c866d-12a8-bec1-30e2-d2de72d2b6f7@oracle.com> Vote : yes On 15/02/17 8:33 PM, jesper.wilhelmsson at oracle.com wrote: > I hereby nominate Jini George (jgeorge) to JDK 9 and JDK 10 Committer. > > Jini is part of the Monitoring and Management team and has contributed 15 changesets to JDK 9 [3]. > > Votes are due by Mars 1, 2017. > > Only current JDK 9/10 Committers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. Since we are in the borderland between JDK 9 and JDK 10 now, and the JDK 10 project has already been created, I'm not sure if we need a vote per project so I'm sending this CFV to both the JDK 9 and JDK 10 lists. Unless someone can verify that it is enough to vote for one of these projects I suggest that those of you that are in both lists replies to both mails and treat this as two separate votes. > > For Lazy Consensus voting instructions, see [2]. > > Thanks, > /Jesper > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/bylaws#lazy-consensus > [3] List of changes: > > (1) 8173896: SA: BasicLauncherTest.java (printmdo) fails for Client VM and Server VM with emulated-client > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/3bd7f52ecae6 > http://hg.openjdk.java.net/jdk9/hs/jdk/rev/615d771202e8 > > (2) 8171084: heapdump/JMapHeapCore fails with java.lang.RuntimeException: Heap segment size overflow > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/2c44cff993b8 > > (3) 8159127: hprof heap dumps broken for lambda classdata > http://hg.openjdk.java.net/jdk9/hs/./rev/e5605f29b00e > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/e5e4011e9c30 > > (4) 8169232: SA: TestCpoolForInvokeDynamic.java fails with sun.jvm.hotspot.debugger.DebuggerException: binary search bug: should have found entry 1 > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/13e6043fcdcb > > (5) 8169638: serviceability/sa/TestInstanceKlassSize.java and serviceability/sa/TestInstanceKlassSizeForInterface.java fail compilation > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/ae23c7acb99a > > (6) 8169344: Potential open file descriptor in exists() of hotspot/agent/src/os/bsd/ps_core.c > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/a71b53580d07 > > (7) 7107018: sun.jvm.hotspot.utilities.soql.JSJavaHeap.forEachClass incorrect test > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/a169535aff9d > > (8) 8164783: SA: jhsdb clhsdb 'printall' often throws "Corrupted constant pool" assertion failure > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/8c2f220c759c > > (9) 8164383: jhsdb dumps core on Solaris 12 when loading dumped core > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/ce3eaa22b582 > > (10) 8166552: SA: Missed testcase for add default methods to InstanceKlass > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/0ff97dc32114 > > (11) 8027920: SA: Add default methods to InstanceKlass > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/c8b3f8e5423b > > (12) 8163150: SA: CLHSDB printmdo throws an exception with "java.lang.InternalError: missing reason for 22" > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/3652a2a22916 > http://hg.openjdk.java.net/jdk9/hs/jdk/rev/8a0a818c3f28 > > (13) 8164562: serviceability/sa/TestInstanceKlassSizeForInterface.java: fails with NPE > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/1357a160e4f2 > > (14) 8163143: illegal bci error with interpreted frames in SA due to mirror being stored in interpreted frames > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/b84f097dc4c5 > http://hg.openjdk.java.net/jdk9/hs/jdk/rev/481ac1e59664 > > (15) 8145627: sun.jvm.hotspot.oops.InstanceKlass::getSize() returns the incorrect size and has no test > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/ca241ed18db8 > -- Thanks, Rachna From nishit.jain at oracle.com Thu Feb 16 06:37:04 2017 From: nishit.jain at oracle.com (Nishit Jain) Date: Thu, 16 Feb 2017 12:07:04 +0530 Subject: CFV: New JDK 9/10 Committer: Jini George In-Reply-To: <854DE5D9-F54A-446C-A98E-8714121E072A@oracle.com> References: <854DE5D9-F54A-446C-A98E-8714121E072A@oracle.com> Message-ID: <6f1f4e00-8d3c-5529-fb9b-7e4e91f1cccb@oracle.com> Vote: Yes Regards, Nishit Jain On 15-02-2017 20:33, jesper.wilhelmsson at oracle.com wrote: > I hereby nominate Jini George (jgeorge) to JDK 9 and JDK 10 Committer. > > Jini is part of the Monitoring and Management team and has contributed 15 changesets to JDK 9 [3]. > > Votes are due by Mars 1, 2017. > > Only current JDK 9/10 Committers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. Since we are in the borderland between JDK 9 and JDK 10 now, and the JDK 10 project has already been created, I'm not sure if we need a vote per project so I'm sending this CFV to both the JDK 9 and JDK 10 lists. Unless someone can verify that it is enough to vote for one of these projects I suggest that those of you that are in both lists replies to both mails and treat this as two separate votes. > > For Lazy Consensus voting instructions, see [2]. > > Thanks, > /Jesper > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/bylaws#lazy-consensus > [3] List of changes: > > (1) 8173896: SA: BasicLauncherTest.java (printmdo) fails for Client VM and Server VM with emulated-client > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/3bd7f52ecae6 > http://hg.openjdk.java.net/jdk9/hs/jdk/rev/615d771202e8 > > (2) 8171084: heapdump/JMapHeapCore fails with java.lang.RuntimeException: Heap segment size overflow > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/2c44cff993b8 > > (3) 8159127: hprof heap dumps broken for lambda classdata > http://hg.openjdk.java.net/jdk9/hs/./rev/e5605f29b00e > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/e5e4011e9c30 > > (4) 8169232: SA: TestCpoolForInvokeDynamic.java fails with sun.jvm.hotspot.debugger.DebuggerException: binary search bug: should have found entry 1 > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/13e6043fcdcb > > (5) 8169638: serviceability/sa/TestInstanceKlassSize.java and serviceability/sa/TestInstanceKlassSizeForInterface.java fail compilation > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/ae23c7acb99a > > (6) 8169344: Potential open file descriptor in exists() of hotspot/agent/src/os/bsd/ps_core.c > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/a71b53580d07 > > (7) 7107018: sun.jvm.hotspot.utilities.soql.JSJavaHeap.forEachClass incorrect test > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/a169535aff9d > > (8) 8164783: SA: jhsdb clhsdb 'printall' often throws "Corrupted constant pool" assertion failure > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/8c2f220c759c > > (9) 8164383: jhsdb dumps core on Solaris 12 when loading dumped core > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/ce3eaa22b582 > > (10) 8166552: SA: Missed testcase for add default methods to InstanceKlass > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/0ff97dc32114 > > (11) 8027920: SA: Add default methods to InstanceKlass > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/c8b3f8e5423b > > (12) 8163150: SA: CLHSDB printmdo throws an exception with "java.lang.InternalError: missing reason for 22" > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/3652a2a22916 > http://hg.openjdk.java.net/jdk9/hs/jdk/rev/8a0a818c3f28 > > (13) 8164562: serviceability/sa/TestInstanceKlassSizeForInterface.java: fails with NPE > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/1357a160e4f2 > > (14) 8163143: illegal bci error with interpreted frames in SA due to mirror being stored in interpreted frames > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/b84f097dc4c5 > http://hg.openjdk.java.net/jdk9/hs/jdk/rev/481ac1e59664 > > (15) 8145627: sun.jvm.hotspot.oops.InstanceKlass::getSize() returns the incorrect size and has no test > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/ca241ed18db8 > From christoph.langer at sap.com Thu Feb 16 06:41:21 2017 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 16 Feb 2017 06:41:21 +0000 Subject: CFV: New JDK 9/10 Committer: Jini George Message-ID: <77d07d23776e4536af461a2509f341f4@derote13de46.global.corp.sap> Vote: yes Best regards Christoph > -----Original Message----- > From: jdk9-dev [mailto:jdk9-dev-bounces at openjdk.java.net] On Behalf Of > jesper.wilhelmsson at oracle.com > Sent: Mittwoch, 15. Februar 2017 16:04 > To: jdk9-dev at openjdk.java.net; jdk10-dev at openjdk.java.net > Subject: CFV: New JDK 9/10 Committer: Jini George > > I hereby nominate Jini George (jgeorge) to JDK 9 and JDK 10 Committer. > > Jini is part of the Monitoring and Management team and has contributed 15 > changesets to JDK 9 [3]. > > Votes are due by Mars 1, 2017. > > Only current JDK 9/10 Committers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. Since we are in > the borderland between JDK 9 and JDK 10 now, and the JDK 10 project has > already been created, I'm not sure if we need a vote per project so I'm > sending this CFV to both the JDK 9 and JDK 10 lists. Unless someone can > verify that it is enough to vote for one of these projects I suggest that those > of you that are in both lists replies to both mails and treat this as two > separate votes. > > For Lazy Consensus voting instructions, see [2]. > > Thanks, > /Jesper > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/bylaws#lazy-consensus > > [3] List of changes: > > (1) 8173896: SA: BasicLauncherTest.java (printmdo) fails for Client VM and > Server VM with emulated-client > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/3bd7f52ecae6 > > http://hg.openjdk.java.net/jdk9/hs/jdk/rev/615d771202e8 > > > (2) 8171084: heapdump/JMapHeapCore fails with > java.lang.RuntimeException: Heap segment size overflow > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/2c44cff993b8 > > > (3) 8159127: hprof heap dumps broken for lambda classdata > http://hg.openjdk.java.net/jdk9/hs/./rev/e5605f29b00e > > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/e5e4011e9c30 > > > (4) 8169232: SA: TestCpoolForInvokeDynamic.java fails with > sun.jvm.hotspot.debugger.DebuggerException: binary search bug: should > have found entry 1 > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/13e6043fcdcb > > > (5) 8169638: serviceability/sa/TestInstanceKlassSize.java and > serviceability/sa/TestInstanceKlassSizeForInterface.java fail compilation > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/ae23c7acb99a > > > (6) 8169344: Potential open file descriptor in exists() of > hotspot/agent/src/os/bsd/ps_core.c > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/a71b53580d07 > > > (7) 7107018: sun.jvm.hotspot.utilities.soql.JSJavaHeap.forEachClass incorrect > test > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/a169535aff9d > > > (8) 8164783: SA: jhsdb clhsdb 'printall' often throws "Corrupted constant > pool" assertion failure > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/8c2f220c759c > > > (9) 8164383: jhsdb dumps core on Solaris 12 when loading dumped core > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/ce3eaa22b582 > > > (10) 8166552: SA: Missed testcase for add default methods to InstanceKlass > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/0ff97dc32114 > > > (11) 8027920: SA: Add default methods to InstanceKlass > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/c8b3f8e5423b > > > (12) 8163150: SA: CLHSDB printmdo throws an exception with > "java.lang.InternalError: missing reason for 22" > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/3652a2a22916 > > http://hg.openjdk.java.net/jdk9/hs/jdk/rev/8a0a818c3f28 > > > (13) 8164562: serviceability/sa/TestInstanceKlassSizeForInterface.java: fails > with NPE > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/1357a160e4f2 > > > (14) 8163143: illegal bci error with interpreted frames in SA due to mirror > being stored in interpreted frames > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/b84f097dc4c5 > > http://hg.openjdk.java.net/jdk9/hs/jdk/rev/481ac1e59664 > > > (15) 8145627: sun.jvm.hotspot.oops.InstanceKlass::getSize() returns the > incorrect size and has no test > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/ca241ed18db8 > From volker.simonis at gmail.com Thu Feb 16 11:21:10 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 16 Feb 2017 12:21:10 +0100 Subject: CFV: New JDK 9/10 Committer: Jini George In-Reply-To: <854DE5D9-F54A-446C-A98E-8714121E072A@oracle.com> References: <854DE5D9-F54A-446C-A98E-8714121E072A@oracle.com> Message-ID: Vote: yes On Wed, Feb 15, 2017 at 4:03 PM, wrote: > I hereby nominate Jini George (jgeorge) to JDK 9 and JDK 10 Committer. > > Jini is part of the Monitoring and Management team and has contributed 15 changesets to JDK 9 [3]. > > Votes are due by Mars 1, 2017. > > Only current JDK 9/10 Committers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. Since we are in the borderland between JDK 9 and JDK 10 now, and the JDK 10 project has already been created, I'm not sure if we need a vote per project so I'm sending this CFV to both the JDK 9 and JDK 10 lists. Unless someone can verify that it is enough to vote for one of these projects I suggest that those of you that are in both lists replies to both mails and treat this as two separate votes. > > For Lazy Consensus voting instructions, see [2]. > > Thanks, > /Jesper > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/bylaws#lazy-consensus > [3] List of changes: > > (1) 8173896: SA: BasicLauncherTest.java (printmdo) fails for Client VM and Server VM with emulated-client > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/3bd7f52ecae6 > http://hg.openjdk.java.net/jdk9/hs/jdk/rev/615d771202e8 > > (2) 8171084: heapdump/JMapHeapCore fails with java.lang.RuntimeException: Heap segment size overflow > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/2c44cff993b8 > > (3) 8159127: hprof heap dumps broken for lambda classdata > http://hg.openjdk.java.net/jdk9/hs/./rev/e5605f29b00e > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/e5e4011e9c30 > > (4) 8169232: SA: TestCpoolForInvokeDynamic.java fails with sun.jvm.hotspot.debugger.DebuggerException: binary search bug: should have found entry 1 > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/13e6043fcdcb > > (5) 8169638: serviceability/sa/TestInstanceKlassSize.java and serviceability/sa/TestInstanceKlassSizeForInterface.java fail compilation > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/ae23c7acb99a > > (6) 8169344: Potential open file descriptor in exists() of hotspot/agent/src/os/bsd/ps_core.c > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/a71b53580d07 > > (7) 7107018: sun.jvm.hotspot.utilities.soql.JSJavaHeap.forEachClass incorrect test > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/a169535aff9d > > (8) 8164783: SA: jhsdb clhsdb 'printall' often throws "Corrupted constant pool" assertion failure > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/8c2f220c759c > > (9) 8164383: jhsdb dumps core on Solaris 12 when loading dumped core > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/ce3eaa22b582 > > (10) 8166552: SA: Missed testcase for add default methods to InstanceKlass > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/0ff97dc32114 > > (11) 8027920: SA: Add default methods to InstanceKlass > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/c8b3f8e5423b > > (12) 8163150: SA: CLHSDB printmdo throws an exception with "java.lang.InternalError: missing reason for 22" > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/3652a2a22916 > http://hg.openjdk.java.net/jdk9/hs/jdk/rev/8a0a818c3f28 > > (13) 8164562: serviceability/sa/TestInstanceKlassSizeForInterface.java: fails with NPE > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/1357a160e4f2 > > (14) 8163143: illegal bci error with interpreted frames in SA due to mirror being stored in interpreted frames > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/b84f097dc4c5 > http://hg.openjdk.java.net/jdk9/hs/jdk/rev/481ac1e59664 > > (15) 8145627: sun.jvm.hotspot.oops.InstanceKlass::getSize() returns the incorrect size and has no test > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/ca241ed18db8 > From sean.coffey at oracle.com Thu Feb 16 17:48:49 2017 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Thu, 16 Feb 2017 17:48:49 +0000 Subject: How to handle future backports from JDK 10 into JDK 9? In-Reply-To: <5df4217f-0a88-4938-a06f-e00176a5153b@oracle.com> References: <49f8daf7-6c15-dec9-92e3-ef76dc6f2afb@oracle.com> <58db6d43-3457-8bd9-bb04-3ab01aeb64e7@oracle.com> <5df4217f-0a88-4938-a06f-e00176a5153b@oracle.com> Message-ID: All JDK Update releases operate with the jcheck unique bug id check switched off. It's been that way for many years without issue. The Update release projects enjoy a model where a stabilization forest can be forked off the 'main' dev forest at RDP2 milestone every 3 months. By having the jcheck unique bug id check switched off, we've had maximum efficiency and flexibility in being able to move selected changes around from forest to forest without cost. I believe that disabling it for feature releases will also benefit release management and gatekeepers for those Projects. It's very rare that this jcheck would catch a genuine dup bug ID issue. Switching off will simplify release team and gatekeeper actions for the future. The alternative of logging secondary bug IDs for the purpose of porting a bug fix from one release to another would be cumbersome and would lead to longer bug tails on issues. I do welcome Phil's call for improving checks on jcheck to detect when backport IDs are erroneously used in changeset commits! regards, Sean. On 15/02/2017 21:00, Vladimir Kozlov wrote: > We discussed this in Hotspot and support David's opinion here. > We should not relax jcheck and we can use backport type different bug > id as he suggested. > > Regards, > Vladimir > > On 2/13/17 6:15 PM, David Holmes wrote: >> On 14/02/2017 8:54 AM, joe darcy wrote: >>> Hello, >>> >>> An open question in Mark's announcement that the JDK 10 forests are >>> open >>> [1] concerned how to manage backports from JDK 10 to JDK 9: >>> >>> "In the (hopefully infrequent) event that a change in JDK 10 needs >>> to be >>> back-ported to JDK 9 we'll have to figure out how to handle the >>> duplicate >>> bug ids that will arise when a back-ported change is later merged >>> forward >>> into JDK 10. One solution may just be to disable the unique bug-id >>> test >>> in jcheck, on the assumption that existing social conventions >>> adequately >>> protect us from the pathological scenarios that are prevented by this >>> test. Thoughts welcome ..." >>> >>> As a reminder, the overall model (for now) is that all fixes from JDK 9 >>> will be synced into JDK 10; the first sync of several hundred bugs >>> happened recently and went smoothly. [2] >>> >>> The potentially problematic situation would occur if >>> >>> * Bug JDK-8181818 is first fixed in JDK 10 >>> * Bug JDK-8181818 is then backported to JDK 9 >>> * The next sync of JDK 9 into JDK 10 would fail on the duplicate bug id >>> JDK-8181818 even though the code may be identical >>> >>> One way to avoid this problem would be to do the push to JDK 9 under an >>> explicit backport bug id rather than the main bug id JDK-8181818. This >>> approach has a number of drawback. First, long-standing social >>> convention has been to "always use the main bug id." Second, tooling >>> like Hg updater has been written on the assumption that the main bug id >>> will always be used to conceptually refer to an issue. >>> >>> The purpose of the jcheck unique bug id check stems from preventing >>> sloppy bug handling where multiple changesets partially and >>> incrementally address a bug and it is not clear whether or not an issue >>> is fully fixed or not. >>> >>> However, even without programmatic enforcement of unique bug id, I >>> don't >>> think JDK development practices would devolve in that way. As >>> supporting >>> evidence, the unique bug id check is disabled in the 8 update >>> forests to >>> allow fixes from multiple releases to come back together in the >>> always-open forest and the pathologies around partial fixes have not >>> occurred. >>> >>> Therefore, I think the better option is to also disable the unique bug >>> id check for the JDK 10 forests to allow easier syncing between 9 >>> and 10. >> >> I think that check has helped avoid pushes with mis-typed bug >> numbers. Unless we have a stronger "does this bug id match the bug >> synopsis" check I would not want to see this bug id check relaxed. >> >> I would not expect there to be many cases where something is deferred >> to 10, fixed, and then re-considered for 9. But if that does happen I >> think the simplest thing may be to do the backport under a >> new bug id (as already happens at time in the update releases when >> the backport is not clean). >> >> Thanks, >> David >> ----- >> >>> Comments? >>> >>> Cheers, >>> >>> -Joe >>> >>> [1] >>> http://mail.openjdk.java.net/pipermail/jdk10-dev/2017-January/000041.html >>> >>> >>> [2] >>> http://mail.openjdk.java.net/pipermail/jdk10-dev/2017-February/000054.html >>> >>> From openjdk at haupz.de Thu Feb 16 18:36:07 2017 From: openjdk at haupz.de (Michael Haupt) Date: Thu, 16 Feb 2017 19:36:07 +0100 Subject: CFV: New JDK 9/10 Committer: Jini George In-Reply-To: <2c2bb4e6-49e4-4abe-8c27-d660688f7aeb@default> References: <854DE5D9-F54A-446C-A98E-8714121E072A@oracle.com> <2c2bb4e6-49e4-4abe-8c27-d660688f7aeb@default> Message-ID: Vote: yes. Best, Michael > Am 15.02.2017 um 16:16 schrieb Rahul Raghavan : > > Vote: yes > > Thanks, > Rahul > >> -----Original Message----- >> From: Jesper Wilhelmsson >> Sent: Wednesday, February 15, 2017 8:34 PM >> To: jdk9-dev at openjdk.java.net; jdk10-dev at openjdk.java.net >> Subject: CFV: New JDK 9/10 Committer: Jini George >> >> I hereby nominate Jini George (jgeorge) to JDK 9 and JDK 10 Committer. >> >> Jini is part of the Monitoring and Management team and has contributed 15 changesets to JDK 9 [3]. >> >> Votes are due by Mars 1, 2017. >> >> Only current JDK 9/10 Committers [1] are eligible to vote on this nomination. >> Votes must be cast in the open by replying to this mailing list. Since we are in the borderland between JDK 9 and JDK 10 now, and the >> JDK 10 project has already been created, I'm not sure if we need a vote per project so I'm sending this CFV to both the JDK 9 and JDK >> 10 lists. Unless someone can verify that it is enough to vote for one of these projects I suggest that those of you that are in both lists >> replies to both mails and treat this as two separate votes. >> >> For Lazy Consensus voting instructions, see [2]. >> >> Thanks, >> /Jesper >> >> [1] http://openjdk.java.net/census >> [2] http://openjdk.java.net/bylaws#lazy-consensus >> [3] List of changes: >> >> (1) 8173896: SA: BasicLauncherTest.java (printmdo) fails for Client VM and Server VM with emulated-client >> http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/3bd7f52ecae6 >> http://hg.openjdk.java.net/jdk9/hs/jdk/rev/615d771202e8 >> >> (2) 8171084: heapdump/JMapHeapCore fails with java.lang.RuntimeException: Heap segment size overflow >> http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/2c44cff993b8 >> >> (3) 8159127: hprof heap dumps broken for lambda classdata >> http://hg.openjdk.java.net/jdk9/hs/./rev/e5605f29b00e >> http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/e5e4011e9c30 >> >> (4) 8169232: SA: TestCpoolForInvokeDynamic.java fails with sun.jvm.hotspot.debugger.DebuggerException: binary search bug: should >> have found entry 1 >> http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/13e6043fcdcb >> >> (5) 8169638: serviceability/sa/TestInstanceKlassSize.java and serviceability/sa/TestInstanceKlassSizeForInterface.java fail compilation >> http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/ae23c7acb99a >> >> (6) 8169344: Potential open file descriptor in exists() of hotspot/agent/src/os/bsd/ps_core.c >> http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/a71b53580d07 >> >> (7) 7107018: sun.jvm.hotspot.utilities.soql.JSJavaHeap.forEachClass incorrect test >> http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/a169535aff9d >> >> (8) 8164783: SA: jhsdb clhsdb 'printall' often throws "Corrupted constant pool" assertion failure >> http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/8c2f220c759c >> >> (9) 8164383: jhsdb dumps core on Solaris 12 when loading dumped core >> http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/ce3eaa22b582 >> >> (10) 8166552: SA: Missed testcase for add default methods to InstanceKlass >> http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/0ff97dc32114 >> >> (11) 8027920: SA: Add default methods to InstanceKlass >> http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/c8b3f8e5423b >> >> (12) 8163150: SA: CLHSDB printmdo throws an exception with "java.lang.InternalError: missing reason for 22" >> http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/3652a2a22916 >> http://hg.openjdk.java.net/jdk9/hs/jdk/rev/8a0a818c3f28 >> >> (13) 8164562: serviceability/sa/TestInstanceKlassSizeForInterface.java: fails with NPE >> http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/1357a160e4f2 >> >> (14) 8163143: illegal bci error with interpreted frames in SA due to mirror being stored in interpreted frames >> http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/b84f097dc4c5 >> http://hg.openjdk.java.net/jdk9/hs/jdk/rev/481ac1e59664 >> >> (15) 8145627: sun.jvm.hotspot.oops.InstanceKlass::getSize() returns the incorrect size and has no test >> http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/ca241ed18db8 >> From me at thomasshields.net Thu Feb 16 07:32:46 2017 From: me at thomasshields.net (Thomas Shields) Date: Thu, 16 Feb 2017 07:32:46 +0000 Subject: 8050818: add static java.util.Predicate.not(Predicate) method + questions about contribution In-Reply-To: References: Message-ID: Apologies, I intended to include a link to the feature request [1] in my previous email but fat-fingered the send button. Best, -T [1] https://bugs.openjdk.java.net/browse/JDK-8050818 On Thu, Feb 16, 2017 at 2:23 AM Thomas Shields wrote: > Greetings all, > I'm interested in beginning to contribute to the JDK and identified this > feature request [1] that reflected a desire of mine as well. I figured with > JDK9 development wrapping up I could focus on JDK10. > > I know this is a public-facing API change, so I'm curious what the > procedure is for beginning work on these kinds of tickets. > > Also, I noticed that the task is "assigned" on JBS to someone but I can't > find any indication any work has been done yet. Is it alright for me to > work on it? > > Finally, if the feature is desirable, may I submit a patch directly to > this group, or do I need to undergo some kind of approval process first? > > All the best, > Thomas Shields > -- > > Sent from my phone > -- Sent from my phone From sean.coffey at oracle.com Thu Feb 16 19:09:26 2017 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Thu, 16 Feb 2017 19:09:26 +0000 Subject: Proposal to use hgupdate-sync label on bugs synced from JDK 9 to JDK 10 In-Reply-To: <66b26b47-4546-5b67-0d17-cda481685019@oracle.com> References: <66b26b47-4546-5b67-0d17-cda481685019@oracle.com> Message-ID: <2334e879-3217-09c5-9305-5b13faa759fc@oracle.com> Looks like the correct approach Joe. The whole concept of the hgupdate-sync label was set up to cover such scenarios. regards, Sean. On 14/02/2017 02:10, joe darcy wrote: > Hello, > > With the policy of fixes in JDK 9 being periodically synced into JDK > 10 [1], the set of bugs in JBS and set of changesets in the JDK 10 > forests will include both fixes unique and newly introduced to JDK 10 > as well as hundreds of fixes "just" forward-ported from JDK 9. > > A similar situation occurs in the update release train when fixes from > the stabilization forest are pulled into the always-open forest. The > bug tracking in the update releases is assisted by use of the > "hgupdate-sync" label: "The 'hgupdate-sync' label is used to denote > bug records which are already fixed in a previous release. When code > lines are synced a new backport record will be created with the > hgupdate-sync label to capture the sync activity. For the most part, > such records can be ignored since they indicate that the issue was > resolved in an earlier update release." [2] > > For a particular example, the bug JDK-6515172: > "Runtime.availableProcessors() ignores Linux taskset command" has > several backports into the 8 update family. The earliest 8 update > release with a backport is 8u121; there is no hgupdate-sync label in > that case. However, when the fix was subsequently applied to 8u131 and > 8u152, the backports created for those releases have the hgupdate-sync > label: > > 8u121: https://bugs.openjdk.java.net/browse/JDK-8173345 > 8u131: https://bugs.openjdk.java.net/browse/JDK-8174019 > hgupdate-sync > 8u152: https://bugs.openjdk.java.net/browse/JDK-8166105 > hgupdate-sync > > When the pushes/syncs into 8u131 and 8u152 occurred, Hg-updater saw > that the bug was already fixed in an earlier 8uX release and thus > added the hgupdate-sync label to the newly-created backports. The > fixes unique to a release are (roughly) all the fixes with that > fixVersion minus the fixes with the hgupdate-sync label. > > The same convention may be helpful to follow for the bugs synced from > JDK 9 into JDK 10. Some small changes to Hg-updater would be necessary > to implement this policy since currently hgupdate-sync will only be > applied to fixes within the same update release family. A bulk edit > could be done to add the label retroactively to the JDK 9 changes > recently synced into JDK 10. > > Comments? > > Thanks, > > -Joe > > [1] > http://mail.openjdk.java.net/pipermail/jdk10-dev/2017-February/000054.html > > [2] https://wiki.openjdk.java.net/display/general/JBS+Overview > From jesper.wilhelmsson at oracle.com Thu Feb 16 19:54:29 2017 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Thu, 16 Feb 2017 20:54:29 +0100 Subject: Proposal to use hgupdate-sync label on bugs synced from JDK 9 to JDK 10 In-Reply-To: <2334e879-3217-09c5-9305-5b13faa759fc@oracle.com> References: <66b26b47-4546-5b67-0d17-cda481685019@oracle.com> <2334e879-3217-09c5-9305-5b13faa759fc@oracle.com> Message-ID: Agreed. It makes sense to use this label to make it easy to identify changes that was automatically pushed. Thanks, /Jesper On 2017-02-16 20:09, Se?n Coffey wrote: > Looks like the correct approach Joe. The whole concept of the > hgupdate-sync label was set up to cover such scenarios. > > regards, > Sean. > > On 14/02/2017 02:10, joe darcy wrote: >> Hello, >> >> With the policy of fixes in JDK 9 being periodically synced into JDK >> 10 [1], the set of bugs in JBS and set of changesets in the JDK 10 >> forests will include both fixes unique and newly introduced to JDK 10 >> as well as hundreds of fixes "just" forward-ported from JDK 9. >> >> A similar situation occurs in the update release train when fixes >> from the stabilization forest are pulled into the always-open forest. >> The bug tracking in the update releases is assisted by use of the >> "hgupdate-sync" label: "The 'hgupdate-sync' label is used to denote >> bug records which are already fixed in a previous release. When code >> lines are synced a new backport record will be created with the >> hgupdate-sync label to capture the sync activity. For the most part, >> such records can be ignored since they indicate that the issue was >> resolved in an earlier update release." [2] >> >> For a particular example, the bug JDK-6515172: >> "Runtime.availableProcessors() ignores Linux taskset command" has >> several backports into the 8 update family. The earliest 8 update >> release with a backport is 8u121; there is no hgupdate-sync label in >> that case. However, when the fix was subsequently applied to 8u131 >> and 8u152, the backports created for those releases have the >> hgupdate-sync label: >> >> 8u121: https://bugs.openjdk.java.net/browse/JDK-8173345 >> 8u131: https://bugs.openjdk.java.net/browse/JDK-8174019 >> hgupdate-sync >> 8u152: https://bugs.openjdk.java.net/browse/JDK-8166105 >> hgupdate-sync >> >> When the pushes/syncs into 8u131 and 8u152 occurred, Hg-updater saw >> that the bug was already fixed in an earlier 8uX release and thus >> added the hgupdate-sync label to the newly-created backports. The >> fixes unique to a release are (roughly) all the fixes with that >> fixVersion minus the fixes with the hgupdate-sync label. >> >> The same convention may be helpful to follow for the bugs synced from >> JDK 9 into JDK 10. Some small changes to Hg-updater would be >> necessary to implement this policy since currently hgupdate-sync will >> only be applied to fixes within the same update release family. A >> bulk edit could be done to add the label retroactively to the JDK 9 >> changes recently synced into JDK 10. >> >> Comments? >> >> Thanks, >> >> -Joe >> >> [1] >> http://mail.openjdk.java.net/pipermail/jdk10-dev/2017-February/000054.html >> >> [2] https://wiki.openjdk.java.net/display/general/JBS+Overview >> > From joe.darcy at oracle.com Thu Feb 16 20:01:06 2017 From: joe.darcy at oracle.com (joe darcy) Date: Thu, 16 Feb 2017 12:01:06 -0800 Subject: How to handle future backports from JDK 10 into JDK 9? In-Reply-To: <5df4217f-0a88-4938-a06f-e00176a5153b@oracle.com> References: <49f8daf7-6c15-dec9-92e3-ef76dc6f2afb@oracle.com> <58db6d43-3457-8bd9-bb04-3ab01aeb64e7@oracle.com> <5df4217f-0a88-4938-a06f-e00176a5153b@oracle.com> Message-ID: <3729188d-aa28-25bf-efaf-e74acc19437a@oracle.com> Hi Vladimir, If the HotSpot team is concerned matching bug id and summaries, I suggest using a wrapper script around jprt or hg push that does that check. I know various individuals have written such scripts for their own use; probably a case where we could do a better job sharing small tools. In my estimation, using back port bug ids for pushes would be more prone to errors/typos than continuing the long-standing policy of using the main bug id in such cases. Cheers, -Joe On 2/15/2017 1:00 PM, Vladimir Kozlov wrote: > We discussed this in Hotspot and support David's opinion here. > We should not relax jcheck and we can use backport type different bug > id as he suggested. > > Regards, > Vladimir > > On 2/13/17 6:15 PM, David Holmes wrote: >> On 14/02/2017 8:54 AM, joe darcy wrote: >>> Hello, >>> >>> An open question in Mark's announcement that the JDK 10 forests are >>> open >>> [1] concerned how to manage backports from JDK 10 to JDK 9: >>> >>> "In the (hopefully infrequent) event that a change in JDK 10 needs >>> to be >>> back-ported to JDK 9 we'll have to figure out how to handle the >>> duplicate >>> bug ids that will arise when a back-ported change is later merged >>> forward >>> into JDK 10. One solution may just be to disable the unique bug-id >>> test >>> in jcheck, on the assumption that existing social conventions >>> adequately >>> protect us from the pathological scenarios that are prevented by this >>> test. Thoughts welcome ..." >>> >>> As a reminder, the overall model (for now) is that all fixes from JDK 9 >>> will be synced into JDK 10; the first sync of several hundred bugs >>> happened recently and went smoothly. [2] >>> >>> The potentially problematic situation would occur if >>> >>> * Bug JDK-8181818 is first fixed in JDK 10 >>> * Bug JDK-8181818 is then backported to JDK 9 >>> * The next sync of JDK 9 into JDK 10 would fail on the duplicate bug id >>> JDK-8181818 even though the code may be identical >>> >>> One way to avoid this problem would be to do the push to JDK 9 under an >>> explicit backport bug id rather than the main bug id JDK-8181818. This >>> approach has a number of drawback. First, long-standing social >>> convention has been to "always use the main bug id." Second, tooling >>> like Hg updater has been written on the assumption that the main bug id >>> will always be used to conceptually refer to an issue. >>> >>> The purpose of the jcheck unique bug id check stems from preventing >>> sloppy bug handling where multiple changesets partially and >>> incrementally address a bug and it is not clear whether or not an issue >>> is fully fixed or not. >>> >>> However, even without programmatic enforcement of unique bug id, I >>> don't >>> think JDK development practices would devolve in that way. As >>> supporting >>> evidence, the unique bug id check is disabled in the 8 update >>> forests to >>> allow fixes from multiple releases to come back together in the >>> always-open forest and the pathologies around partial fixes have not >>> occurred. >>> >>> Therefore, I think the better option is to also disable the unique bug >>> id check for the JDK 10 forests to allow easier syncing between 9 >>> and 10. >> >> I think that check has helped avoid pushes with mis-typed bug >> numbers. Unless we have a stronger "does this bug id match the bug >> synopsis" check I would not want to see this bug id check relaxed. >> >> I would not expect there to be many cases where something is deferred >> to 10, fixed, and then re-considered for 9. But if that does happen I >> think the simplest thing may be to do the backport under a >> new bug id (as already happens at time in the update releases when >> the backport is not clean). >> >> Thanks, >> David >> ----- >> >>> Comments? >>> >>> Cheers, >>> >>> -Joe >>> >>> [1] >>> http://mail.openjdk.java.net/pipermail/jdk10-dev/2017-January/000041.html >>> >>> >>> [2] >>> http://mail.openjdk.java.net/pipermail/jdk10-dev/2017-February/000054.html >>> >>> From david.holmes at oracle.com Thu Feb 16 22:11:05 2017 From: david.holmes at oracle.com (David Holmes) Date: Fri, 17 Feb 2017 08:11:05 +1000 Subject: How to handle future backports from JDK 10 into JDK 9? In-Reply-To: <3729188d-aa28-25bf-efaf-e74acc19437a@oracle.com> References: <49f8daf7-6c15-dec9-92e3-ef76dc6f2afb@oracle.com> <58db6d43-3457-8bd9-bb04-3ab01aeb64e7@oracle.com> <5df4217f-0a88-4938-a06f-e00176a5153b@oracle.com> <3729188d-aa28-25bf-efaf-e74acc19437a@oracle.com> Message-ID: Hi Joe, On 17/02/2017 6:01 AM, joe darcy wrote: > Hi Vladimir, > > If the HotSpot team is concerned matching bug id and summaries, I > suggest using a wrapper script around jprt or hg push that does that > check. I know various individuals have written such scripts for their > own use; probably a case where we could do a better job sharing small > tools. That's solving the problem in the wrong place in my opinion. > In my estimation, using back port bug ids for pushes would be more prone > to errors/typos than continuing the long-standing policy of using the > main bug id in such cases. That wasn't the suggestion. The suggestion was to create a new bug eg "Backport 8134567 to JDK 9" and use that bugid for the "backport" instead of creating an actual backport-issue using the original main bug id. Cheers, David > Cheers, > > -Joe > > > On 2/15/2017 1:00 PM, Vladimir Kozlov wrote: >> We discussed this in Hotspot and support David's opinion here. >> We should not relax jcheck and we can use backport type different bug >> id as he suggested. >> >> Regards, >> Vladimir >> >> On 2/13/17 6:15 PM, David Holmes wrote: >>> On 14/02/2017 8:54 AM, joe darcy wrote: >>>> Hello, >>>> >>>> An open question in Mark's announcement that the JDK 10 forests are >>>> open >>>> [1] concerned how to manage backports from JDK 10 to JDK 9: >>>> >>>> "In the (hopefully infrequent) event that a change in JDK 10 needs >>>> to be >>>> back-ported to JDK 9 we'll have to figure out how to handle the >>>> duplicate >>>> bug ids that will arise when a back-ported change is later merged >>>> forward >>>> into JDK 10. One solution may just be to disable the unique bug-id >>>> test >>>> in jcheck, on the assumption that existing social conventions >>>> adequately >>>> protect us from the pathological scenarios that are prevented by this >>>> test. Thoughts welcome ..." >>>> >>>> As a reminder, the overall model (for now) is that all fixes from JDK 9 >>>> will be synced into JDK 10; the first sync of several hundred bugs >>>> happened recently and went smoothly. [2] >>>> >>>> The potentially problematic situation would occur if >>>> >>>> * Bug JDK-8181818 is first fixed in JDK 10 >>>> * Bug JDK-8181818 is then backported to JDK 9 >>>> * The next sync of JDK 9 into JDK 10 would fail on the duplicate bug id >>>> JDK-8181818 even though the code may be identical >>>> >>>> One way to avoid this problem would be to do the push to JDK 9 under an >>>> explicit backport bug id rather than the main bug id JDK-8181818. This >>>> approach has a number of drawback. First, long-standing social >>>> convention has been to "always use the main bug id." Second, tooling >>>> like Hg updater has been written on the assumption that the main bug id >>>> will always be used to conceptually refer to an issue. >>>> >>>> The purpose of the jcheck unique bug id check stems from preventing >>>> sloppy bug handling where multiple changesets partially and >>>> incrementally address a bug and it is not clear whether or not an issue >>>> is fully fixed or not. >>>> >>>> However, even without programmatic enforcement of unique bug id, I >>>> don't >>>> think JDK development practices would devolve in that way. As >>>> supporting >>>> evidence, the unique bug id check is disabled in the 8 update >>>> forests to >>>> allow fixes from multiple releases to come back together in the >>>> always-open forest and the pathologies around partial fixes have not >>>> occurred. >>>> >>>> Therefore, I think the better option is to also disable the unique bug >>>> id check for the JDK 10 forests to allow easier syncing between 9 >>>> and 10. >>> >>> I think that check has helped avoid pushes with mis-typed bug >>> numbers. Unless we have a stronger "does this bug id match the bug >>> synopsis" check I would not want to see this bug id check relaxed. >>> >>> I would not expect there to be many cases where something is deferred >>> to 10, fixed, and then re-considered for 9. But if that does happen I >>> think the simplest thing may be to do the backport under a >>> new bug id (as already happens at time in the update releases when >>> the backport is not clean). >>> >>> Thanks, >>> David >>> ----- >>> >>>> Comments? >>>> >>>> Cheers, >>>> >>>> -Joe >>>> >>>> [1] >>>> http://mail.openjdk.java.net/pipermail/jdk10-dev/2017-January/000041.html >>>> >>>> >>>> [2] >>>> http://mail.openjdk.java.net/pipermail/jdk10-dev/2017-February/000054.html >>>> >>>> > From volker.simonis at gmail.com Fri Feb 17 08:21:24 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 17 Feb 2017 09:21:24 +0100 Subject: How to handle future backports from JDK 10 into JDK 9? In-Reply-To: References: <49f8daf7-6c15-dec9-92e3-ef76dc6f2afb@oracle.com> <58db6d43-3457-8bd9-bb04-3ab01aeb64e7@oracle.com> <5df4217f-0a88-4938-a06f-e00176a5153b@oracle.com> <3729188d-aa28-25bf-efaf-e74acc19437a@oracle.com> Message-ID: On Thu, Feb 16, 2017 at 11:11 PM, David Holmes wrote: > Hi Joe, > > On 17/02/2017 6:01 AM, joe darcy wrote: >> >> Hi Vladimir, >> >> If the HotSpot team is concerned matching bug id and summaries, I >> suggest using a wrapper script around jprt or hg push that does that >> check. I know various individuals have written such scripts for their >> own use; probably a case where we could do a better job sharing small >> tools. > > > That's solving the problem in the wrong place in my opinion. > >> In my estimation, using back port bug ids for pushes would be more prone >> to errors/typos than continuing the long-standing policy of using the >> main bug id in such cases. > > > That wasn't the suggestion. The suggestion was to create a new bug eg > "Backport 8134567 to JDK 9" and use that bugid for the "backport" instead of > creating an actual backport-issue using the original main bug id. > I totally agree with David and would strongly support his suggestion. We could introduce a new line in the change comment like "Backport-of: " so we can easily find and identify such changes. And after all, there hopefully shouldn't be to many of them. > Cheers, > David > > >> Cheers, >> >> -Joe >> >> >> On 2/15/2017 1:00 PM, Vladimir Kozlov wrote: >>> >>> We discussed this in Hotspot and support David's opinion here. >>> We should not relax jcheck and we can use backport type different bug >>> id as he suggested. >>> >>> Regards, >>> Vladimir >>> >>> On 2/13/17 6:15 PM, David Holmes wrote: >>>> >>>> On 14/02/2017 8:54 AM, joe darcy wrote: >>>>> >>>>> Hello, >>>>> >>>>> An open question in Mark's announcement that the JDK 10 forests are >>>>> open >>>>> [1] concerned how to manage backports from JDK 10 to JDK 9: >>>>> >>>>> "In the (hopefully infrequent) event that a change in JDK 10 needs >>>>> to be >>>>> back-ported to JDK 9 we'll have to figure out how to handle the >>>>> duplicate >>>>> bug ids that will arise when a back-ported change is later merged >>>>> forward >>>>> into JDK 10. One solution may just be to disable the unique bug-id >>>>> test >>>>> in jcheck, on the assumption that existing social conventions >>>>> adequately >>>>> protect us from the pathological scenarios that are prevented by this >>>>> test. Thoughts welcome ..." >>>>> >>>>> As a reminder, the overall model (for now) is that all fixes from JDK 9 >>>>> will be synced into JDK 10; the first sync of several hundred bugs >>>>> happened recently and went smoothly. [2] >>>>> >>>>> The potentially problematic situation would occur if >>>>> >>>>> * Bug JDK-8181818 is first fixed in JDK 10 >>>>> * Bug JDK-8181818 is then backported to JDK 9 >>>>> * The next sync of JDK 9 into JDK 10 would fail on the duplicate bug id >>>>> JDK-8181818 even though the code may be identical >>>>> >>>>> One way to avoid this problem would be to do the push to JDK 9 under an >>>>> explicit backport bug id rather than the main bug id JDK-8181818. This >>>>> approach has a number of drawback. First, long-standing social >>>>> convention has been to "always use the main bug id." Second, tooling >>>>> like Hg updater has been written on the assumption that the main bug id >>>>> will always be used to conceptually refer to an issue. >>>>> >>>>> The purpose of the jcheck unique bug id check stems from preventing >>>>> sloppy bug handling where multiple changesets partially and >>>>> incrementally address a bug and it is not clear whether or not an issue >>>>> is fully fixed or not. >>>>> >>>>> However, even without programmatic enforcement of unique bug id, I >>>>> don't >>>>> think JDK development practices would devolve in that way. As >>>>> supporting >>>>> evidence, the unique bug id check is disabled in the 8 update >>>>> forests to >>>>> allow fixes from multiple releases to come back together in the >>>>> always-open forest and the pathologies around partial fixes have not >>>>> occurred. >>>>> >>>>> Therefore, I think the better option is to also disable the unique bug >>>>> id check for the JDK 10 forests to allow easier syncing between 9 >>>>> and 10. >>>> >>>> >>>> I think that check has helped avoid pushes with mis-typed bug >>>> numbers. Unless we have a stronger "does this bug id match the bug >>>> synopsis" check I would not want to see this bug id check relaxed. >>>> >>>> I would not expect there to be many cases where something is deferred >>>> to 10, fixed, and then re-considered for 9. But if that does happen I >>>> think the simplest thing may be to do the backport under a >>>> new bug id (as already happens at time in the update releases when >>>> the backport is not clean). >>>> >>>> Thanks, >>>> David >>>> ----- >>>> >>>>> Comments? >>>>> >>>>> Cheers, >>>>> >>>>> -Joe >>>>> >>>>> [1] >>>>> >>>>> http://mail.openjdk.java.net/pipermail/jdk10-dev/2017-January/000041.html >>>>> >>>>> >>>>> [2] >>>>> >>>>> http://mail.openjdk.java.net/pipermail/jdk10-dev/2017-February/000054.html >>>>> >>>>> >> > From martijnverburg at gmail.com Fri Feb 17 12:08:47 2017 From: martijnverburg at gmail.com (Martijn Verburg) Date: Fri, 17 Feb 2017 12:08:47 +0000 Subject: 8050818: add static java.util.Predicate.not(Predicate) method + questions about contribution In-Reply-To: References: Message-ID: Hi Thomas, See the Contribution Guide (http://openjdk.java.net/contribute/). You'll need to have your OCA signed, then it's a good idea to discuss the bug / change on the appropriate mailing list (which would be core-libs in this case I think). Assuming everyone is in agreement with how it should be implemented, you'd submit a signed patch via the webrev tool (hopefully this is explained in the contribution guide). If you get stuck then the adoption-discuss mailing list is a good place to go for help. Cheers, Martijn On 16 February 2017 at 07:32, Thomas Shields wrote: > Apologies, I intended to include a link to the feature request [1] in my > previous email but fat-fingered the send button. > > Best, > -T > > [1] https://bugs.openjdk.java.net/browse/JDK-8050818 > > On Thu, Feb 16, 2017 at 2:23 AM Thomas Shields > wrote: > > > Greetings all, > > I'm interested in beginning to contribute to the JDK and identified this > > feature request [1] that reflected a desire of mine as well. I figured > with > > JDK9 development wrapping up I could focus on JDK10. > > > > I know this is a public-facing API change, so I'm curious what the > > procedure is for beginning work on these kinds of tickets. > > > > Also, I noticed that the task is "assigned" on JBS to someone but I can't > > find any indication any work has been done yet. Is it alright for me to > > work on it? > > > > Finally, if the feature is desirable, may I submit a patch directly to > > this group, or do I need to undergo some kind of approval process first? > > > > All the best, > > Thomas Shields > > -- > > > > Sent from my phone > > > -- > > Sent from my phone > From joe.darcy at oracle.com Fri Feb 17 18:20:43 2017 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Fri, 17 Feb 2017 10:20:43 -0800 Subject: How to handle future backports from JDK 10 into JDK 9? In-Reply-To: References: <49f8daf7-6c15-dec9-92e3-ef76dc6f2afb@oracle.com> <58db6d43-3457-8bd9-bb04-3ab01aeb64e7@oracle.com> <5df4217f-0a88-4938-a06f-e00176a5153b@oracle.com> <3729188d-aa28-25bf-efaf-e74acc19437a@oracle.com> Message-ID: Hi David, On 2/16/2017 2:11 PM, David Holmes wrote: > Hi Joe, > > On 17/02/2017 6:01 AM, joe darcy wrote: >> Hi Vladimir, >> >> If the HotSpot team is concerned matching bug id and summaries, I >> suggest using a wrapper script around jprt or hg push that does that >> check. I know various individuals have written such scripts for their >> own use; probably a case where we could do a better job sharing small >> tools. > > That's solving the problem in the wrong place in my opinion. The designers of jcheck made an architectural decision to not have jcheck depend on or use the bug database. Without revisiting that design decision, a wrapper script of some sort is a way the check in question could be implemented today. > >> In my estimation, using back port bug ids for pushes would be more prone >> to errors/typos than continuing the long-standing policy of using the >> main bug id in such cases. > > That wasn't the suggestion. The suggestion was to create a new bug eg > "Backport 8134567 to JDK 9" and use that bugid for the "backport" > instead of creating an actual backport-issue using the original main > bug id. > That approach, while workable, seems to me to work across purposes with the bug tracking system. The most natural way to represent a backport is a backport issue. -Joe From stuart.marks at oracle.com Sat Feb 18 02:23:40 2017 From: stuart.marks at oracle.com (Stuart Marks) Date: Fri, 17 Feb 2017 18:23:40 -0800 Subject: How to handle future backports from JDK 10 into JDK 9? In-Reply-To: References: <49f8daf7-6c15-dec9-92e3-ef76dc6f2afb@oracle.com> <58db6d43-3457-8bd9-bb04-3ab01aeb64e7@oracle.com> <5df4217f-0a88-4938-a06f-e00176a5153b@oracle.com> <3729188d-aa28-25bf-efaf-e74acc19437a@oracle.com> Message-ID: <1995f77a-1364-84f9-b587-0b8007bba25f@oracle.com> On 2/17/17 10:20 AM, Joseph D. Darcy wrote: > The designers of jcheck made an architectural decision to not have jcheck depend > on or use the bug database. > > Without revisiting that design decision, a wrapper script of some sort is a way > the check in question could be implemented today. It's perhaps unfortunate that jcheck doesn't depend on the bug database, but I agree that we don't want to revisit this particular design decision at this point. (I suspect that if jcheck were to depend on the bug database, we'd be complaining continually about all the problems that this would have caused.) It remains true that there are several phenomena that can occur with the bug IDs in the changeset comments: 1) using the same bug ID for logically different changesets; 2) using the same bug ID for logically equivalent changesets introduced on a different branch; 3) typo in a bug ID resulting in a comment referring to a nonexistent bug; 4) typo in a bug ID resulting in a comment referring to a valid, but incorrect bug; and 5) use of a backport bug ID instead of the main bug ID. Cases 1, 3, 4, and 5 are considered to be errors, but the duplicate checking only prevents case 1. The other kinds of errors occur occasionally, and it's annoying when they do occur, but it's not a disaster. Meanwhile, duplicate checking gets in the way of case 2, the standard workflow for the sustaining releases, and thus it's been disabled for those releases for quite some time. It's also getting in the way of the proposed JDK 9 => JDK 10 workflow (pulling changes from the old release into the new release). Everybody on the planet except OpenJDK has been doing this for years. Its benefits outweigh the minor benefit of preventing duplicates. It would be helpful to think about approaches to prevent these kinds of errors. If jcheck isn't doing to depend on the bug database, perhaps an adjoint tool could be developed that does. I'd further suggest that the changeset comments be part of the code review, and that reviewers check this. I notice that many people post reviews of uncommitted changes. Perhaps we will have to change this practice. s'marks > >> >>> In my estimation, using back port bug ids for pushes would be more prone >>> to errors/typos than continuing the long-standing policy of using the >>> main bug id in such cases. >> >> That wasn't the suggestion. The suggestion was to create a new bug eg >> "Backport 8134567 to JDK 9" and use that bugid for the "backport" instead of >> creating an actual backport-issue using the original main bug id. >> > > That approach, while workable, seems to me to work across purposes with the bug > tracking system. The most natural way to represent a backport is a backport issue. > > -Joe From david.holmes at oracle.com Sat Feb 18 03:14:24 2017 From: david.holmes at oracle.com (David Holmes) Date: Sat, 18 Feb 2017 13:14:24 +1000 Subject: How to handle future backports from JDK 10 into JDK 9? In-Reply-To: References: <49f8daf7-6c15-dec9-92e3-ef76dc6f2afb@oracle.com> <58db6d43-3457-8bd9-bb04-3ab01aeb64e7@oracle.com> <5df4217f-0a88-4938-a06f-e00176a5153b@oracle.com> <3729188d-aa28-25bf-efaf-e74acc19437a@oracle.com> Message-ID: On 18/02/2017 4:20 AM, Joseph D. Darcy wrote: > Hi David, > > On 2/16/2017 2:11 PM, David Holmes wrote: >> Hi Joe, >> >> On 17/02/2017 6:01 AM, joe darcy wrote: >>> Hi Vladimir, >>> >>> If the HotSpot team is concerned matching bug id and summaries, I >>> suggest using a wrapper script around jprt or hg push that does that >>> check. I know various individuals have written such scripts for their >>> own use; probably a case where we could do a better job sharing small >>> tools. >> >> That's solving the problem in the wrong place in my opinion. > > The designers of jcheck made an architectural decision to not have > jcheck depend on or use the bug database. > > Without revisiting that design decision, a wrapper script of some sort > is a way the check in question could be implemented today. Perhaps that decision should be revisited - was it the same bug database when the decision was made? In any case perhaps we can distinguish between jcheck running on the hg servers versus jcheck running at hg commit time on the user's machine? After all the latter is no different from the ends users perspective, but it avoids the need for duplication of effort to create wrappers, and for people to have to opt-in to using those wrappers. >> >>> In my estimation, using back port bug ids for pushes would be more prone >>> to errors/typos than continuing the long-standing policy of using the >>> main bug id in such cases. >> >> That wasn't the suggestion. The suggestion was to create a new bug eg >> "Backport 8134567 to JDK 9" and use that bugid for the "backport" >> instead of creating an actual backport-issue using the original main >> bug id. >> > > That approach, while workable, seems to me to work across purposes with > the bug tracking system. The most natural way to represent a backport is > a backport issue. Yes that is the "most natural" way but can cause problems - hence this conversation. Creating a new bug for a "backport" is already existing practice for the update releases, so this isn't something radically new. And, again, we expect this to be a very rare occurrence. Cheers, David > -Joe From david.holmes at oracle.com Sat Feb 18 03:26:23 2017 From: david.holmes at oracle.com (David Holmes) Date: Sat, 18 Feb 2017 13:26:23 +1000 Subject: How to handle future backports from JDK 10 into JDK 9? In-Reply-To: <1995f77a-1364-84f9-b587-0b8007bba25f@oracle.com> References: <49f8daf7-6c15-dec9-92e3-ef76dc6f2afb@oracle.com> <58db6d43-3457-8bd9-bb04-3ab01aeb64e7@oracle.com> <5df4217f-0a88-4938-a06f-e00176a5153b@oracle.com> <3729188d-aa28-25bf-efaf-e74acc19437a@oracle.com> <1995f77a-1364-84f9-b587-0b8007bba25f@oracle.com> Message-ID: Hi Stuart, On 18/02/2017 12:23 PM, Stuart Marks wrote: > > > On 2/17/17 10:20 AM, Joseph D. Darcy wrote: >> The designers of jcheck made an architectural decision to not have >> jcheck depend >> on or use the bug database. >> >> Without revisiting that design decision, a wrapper script of some sort >> is a way >> the check in question could be implemented today. > > It's perhaps unfortunate that jcheck doesn't depend on the bug database, > but I agree that we don't want to revisit this particular design > decision at this point. (I suspect that if jcheck were to depend on the > bug database, we'd be complaining continually about all the problems > that this would have caused.) But we will be in exactly the same boat if the bug database access is in the wrappers we use! The person submitting won't know where in the chain the bug database occurs. > It remains true that there are several phenomena that can occur with the > bug IDs in the changeset comments: > > 1) using the same bug ID for logically different changesets; > > 2) using the same bug ID for logically equivalent changesets introduced > on a different branch; > > 3) typo in a bug ID resulting in a comment referring to a nonexistent bug; > > 4) typo in a bug ID resulting in a comment referring to a valid, but > incorrect bug; and > > 5) use of a backport bug ID instead of the main bug ID. > > Cases 1, 3, 4, and 5 are considered to be errors, but the duplicate > checking only prevents case 1. The other kinds of errors occur > occasionally, and it's annoying when they do occur, but it's not a > disaster. True. > Meanwhile, duplicate checking gets in the way of case 2, the standard > workflow for the sustaining releases, and thus it's been disabled for > those releases for quite some time. It's also getting in the way of the > proposed JDK 9 => JDK 10 workflow (pulling changes from the old release > into the new release). Everybody on the planet except OpenJDK has been > doing this for years. Its benefits outweigh the minor benefit of > preventing duplicates. Sorry have to correct you there. It is the flow from JDK 10 back to JDK 9 that has the problem, the other way is working fine AFAIK. Second point is that the "standard workflow" disables duplicate checking in the update-release forest _not_ the main forest. > It would be helpful to think about approaches to prevent these kinds of > errors. If jcheck isn't doing to depend on the bug database, perhaps an > adjoint tool could be developed that does. > > I'd further suggest that the changeset comments be part of the code > review, and that reviewers check this. I notice that many people post > reviews of uncommitted changes. Perhaps we will have to change this > practice. I find it painful to have to do commits, rollbacks and re-commits to allow a committed changeset to be used for review. Many others use "committed" but fake changesets via MQ etc so validating those at review time would be pointless. Plus we don't have Reviewers before the review - I guess we can use duke as a substitute - but then we might forget to update with the real reviewers. :) So, sorry but I don't really see this as a viable approach. Too much pain to prevent rare errors IMHO. Cheers, David > > s'marks > > >> >>> >>>> In my estimation, using back port bug ids for pushes would be more >>>> prone >>>> to errors/typos than continuing the long-standing policy of using the >>>> main bug id in such cases. >>> >>> That wasn't the suggestion. The suggestion was to create a new bug eg >>> "Backport 8134567 to JDK 9" and use that bugid for the "backport" >>> instead of >>> creating an actual backport-issue using the original main bug id. >>> >> >> That approach, while workable, seems to me to work across purposes >> with the bug >> tracking system. The most natural way to represent a backport is a >> backport issue. >> >> -Joe From sean.coffey at oracle.com Mon Feb 20 09:11:27 2017 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Mon, 20 Feb 2017 09:11:27 +0000 Subject: How to handle future backports from JDK 10 into JDK 9? In-Reply-To: References: <49f8daf7-6c15-dec9-92e3-ef76dc6f2afb@oracle.com> <58db6d43-3457-8bd9-bb04-3ab01aeb64e7@oracle.com> <5df4217f-0a88-4938-a06f-e00176a5153b@oracle.com> <3729188d-aa28-25bf-efaf-e74acc19437a@oracle.com> Message-ID: On 18/02/2017 03:14, David Holmes wrote: > Creating a new bug for a "backport" is already existing practice for > the update releases, so this isn't something radically new. I don't believe above to be accurate. An engineer rarely has to create a backport bug ID. For the majority of cases, it's automatically handled by hgupdater tooling and no one has to ever reference the backport ID. This is especially true for the automated sync ups that occur between forests. In the scenario where duplicate bug IDs are not allowed, a gatekeeper has to halt the sync and delay integration schedule in the event where duplicate bug IDs cross between different forests. The golden rule today is to use the same master bug ID for pushing the same fix across all JDK forests. Using a different bug ID to push the same fix would just add unnecessary confusion. It would also cause issue for automated scripts checking for bug fixes in various JDK forests. We'd be in a state of "did we use this bug ID or that bug ID to push the fix?". Rare or not, it would just break tooling and queries. It would be something radically new. regards, Sean. > On 18/02/2017 4:20 AM, Joseph D. Darcy wrote: >> Hi David, >> >> On 2/16/2017 2:11 PM, David Holmes wrote: >>> Hi Joe, >>> >>> On 17/02/2017 6:01 AM, joe darcy wrote: >>>> Hi Vladimir, >>>> >>>> If the HotSpot team is concerned matching bug id and summaries, I >>>> suggest using a wrapper script around jprt or hg push that does that >>>> check. I know various individuals have written such scripts for their >>>> own use; probably a case where we could do a better job sharing small >>>> tools. >>> >>> That's solving the problem in the wrong place in my opinion. >> >> The designers of jcheck made an architectural decision to not have >> jcheck depend on or use the bug database. >> >> Without revisiting that design decision, a wrapper script of some sort >> is a way the check in question could be implemented today. > > Perhaps that decision should be revisited - was it the same bug > database when the decision was made? In any case perhaps we can > distinguish between jcheck running on the hg servers versus jcheck > running at hg commit time on the user's machine? After all the latter > is no different from the ends users perspective, but it avoids the > need for duplication of effort to create wrappers, and for people to > have to opt-in to using those wrappers. > >>> >>>> In my estimation, using back port bug ids for pushes would be more >>>> prone >>>> to errors/typos than continuing the long-standing policy of using the >>>> main bug id in such cases. >>> >>> That wasn't the suggestion. The suggestion was to create a new bug eg >>> "Backport 8134567 to JDK 9" and use that bugid for the "backport" >>> instead of creating an actual backport-issue using the original main >>> bug id. >>> >> >> That approach, while workable, seems to me to work across purposes with >> the bug tracking system. The most natural way to represent a backport is >> a backport issue. > > Yes that is the "most natural" way but can cause problems - hence this > conversation. Creating a new bug for a "backport" is already existing > practice for the update releases, so this isn't something radically new. > > And, again, we expect this to be a very rare occurrence. > > Cheers, > David > >> -Joe From david.holmes at oracle.com Mon Feb 20 10:43:18 2017 From: david.holmes at oracle.com (David Holmes) Date: Mon, 20 Feb 2017 20:43:18 +1000 Subject: How to handle future backports from JDK 10 into JDK 9? In-Reply-To: References: <49f8daf7-6c15-dec9-92e3-ef76dc6f2afb@oracle.com> <58db6d43-3457-8bd9-bb04-3ab01aeb64e7@oracle.com> <5df4217f-0a88-4938-a06f-e00176a5153b@oracle.com> <3729188d-aa28-25bf-efaf-e74acc19437a@oracle.com> Message-ID: <3815dda4-c612-dd5a-547f-553477fad5d7@oracle.com> On 20/02/2017 7:11 PM, Se?n Coffey wrote: > On 18/02/2017 03:14, David Holmes wrote: > >> Creating a new bug for a "backport" is already existing practice for >> the update releases, so this isn't something radically new. > I don't believe above to be accurate. An engineer rarely has to create a > backport bug ID. For the majority of cases, it's automatically handled > by hgupdater tooling and no one has to ever reference the backport ID. I think there is a misunderstanding. What I am talking about is when a specific issue is created (of type bug or rfe) to handle the backporting of some fix or enhancement, when the use of a direct "backport" of the original fix/ref is not possible for some reason. The bug database is littered with such issues, for example: https://bugs.openjdk.java.net/browse/JDK-8038440 https://bugs.openjdk.java.net/browse/JDK-8052313 and there are many, many examples. David ----- > This is especially true for the automated sync ups that occur between > forests. In the scenario where duplicate bug IDs are not allowed, a > gatekeeper has to halt the sync and delay integration schedule in the > event where duplicate bug IDs cross between different forests. > > The golden rule today is to use the same master bug ID for pushing the > same fix across all JDK forests. > > Using a different bug ID to push the same fix would just add unnecessary > confusion. It would also cause issue for automated scripts checking for > bug fixes in various JDK forests. We'd be in a state of "did we use this > bug ID or that bug ID to push the fix?". Rare or not, it would just > break tooling and queries. It would be something radically new. > > regards, > Sean. > >> On 18/02/2017 4:20 AM, Joseph D. Darcy wrote: >>> Hi David, >>> >>> On 2/16/2017 2:11 PM, David Holmes wrote: >>>> Hi Joe, >>>> >>>> On 17/02/2017 6:01 AM, joe darcy wrote: >>>>> Hi Vladimir, >>>>> >>>>> If the HotSpot team is concerned matching bug id and summaries, I >>>>> suggest using a wrapper script around jprt or hg push that does that >>>>> check. I know various individuals have written such scripts for their >>>>> own use; probably a case where we could do a better job sharing small >>>>> tools. >>>> >>>> That's solving the problem in the wrong place in my opinion. >>> >>> The designers of jcheck made an architectural decision to not have >>> jcheck depend on or use the bug database. >>> >>> Without revisiting that design decision, a wrapper script of some sort >>> is a way the check in question could be implemented today. >> >> Perhaps that decision should be revisited - was it the same bug >> database when the decision was made? In any case perhaps we can >> distinguish between jcheck running on the hg servers versus jcheck >> running at hg commit time on the user's machine? After all the latter >> is no different from the ends users perspective, but it avoids the >> need for duplication of effort to create wrappers, and for people to >> have to opt-in to using those wrappers. >> >>>> >>>>> In my estimation, using back port bug ids for pushes would be more >>>>> prone >>>>> to errors/typos than continuing the long-standing policy of using the >>>>> main bug id in such cases. >>>> >>>> That wasn't the suggestion. The suggestion was to create a new bug eg >>>> "Backport 8134567 to JDK 9" and use that bugid for the "backport" >>>> instead of creating an actual backport-issue using the original main >>>> bug id. >>>> >>> >>> That approach, while workable, seems to me to work across purposes with >>> the bug tracking system. The most natural way to represent a backport is >>> a backport issue. >> >> Yes that is the "most natural" way but can cause problems - hence this >> conversation. Creating a new bug for a "backport" is already existing >> practice for the update releases, so this isn't something radically new. >> >> And, again, we expect this to be a very rare occurrence. >> >> Cheers, >> David >> >>> -Joe > From yumin.qi at gmail.com Mon Feb 20 17:38:35 2017 From: yumin.qi at gmail.com (yumin qi) Date: Mon, 20 Feb 2017 09:38:35 -0800 Subject: CFV: New JDK 9/10 Committer: Jini George In-Reply-To: References: <854DE5D9-F54A-446C-A98E-8714121E072A@oracle.com> <2c2bb4e6-49e4-4abe-8c27-d660688f7aeb@default> Message-ID: Vote: yes On Thu, Feb 16, 2017 at 10:36 AM, Michael Haupt wrote: > Vote: yes. > > Best, > > Michael > > > Am 15.02.2017 um 16:16 schrieb Rahul Raghavan < > rahul.v.raghavan at oracle.com>: > > > > Vote: yes > > > > Thanks, > > Rahul > > > >> -----Original Message----- > >> From: Jesper Wilhelmsson > >> Sent: Wednesday, February 15, 2017 8:34 PM > >> To: jdk9-dev at openjdk.java.net; jdk10-dev at openjdk.java.net > >> Subject: CFV: New JDK 9/10 Committer: Jini George > >> > >> I hereby nominate Jini George (jgeorge) to JDK 9 and JDK 10 Committer. > >> > >> Jini is part of the Monitoring and Management team and has contributed > 15 changesets to JDK 9 [3]. > >> > >> Votes are due by Mars 1, 2017. > >> > >> Only current JDK 9/10 Committers [1] are eligible to vote on this > nomination. > >> Votes must be cast in the open by replying to this mailing list. Since > we are in the borderland between JDK 9 and JDK 10 now, and the > >> JDK 10 project has already been created, I'm not sure if we need a vote > per project so I'm sending this CFV to both the JDK 9 and JDK > >> 10 lists. Unless someone can verify that it is enough to vote for one > of these projects I suggest that those of you that are in both lists > >> replies to both mails and treat this as two separate votes. > >> > >> For Lazy Consensus voting instructions, see [2]. > >> > >> Thanks, > >> /Jesper > >> > >> [1] http://openjdk.java.net/census > >> [2] http://openjdk.java.net/bylaws#lazy-consensus < > http://openjdk.java.net/bylaws#lazy-consensus> > >> [3] List of changes: > >> > >> (1) 8173896: SA: BasicLauncherTest.java (printmdo) fails for Client VM > and Server VM with emulated-client > >> http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/3bd7f52ecae6 < > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/3bd7f52ecae6> > >> http://hg.openjdk.java.net/jdk9/hs/jdk/rev/615d771202e8 < > http://hg.openjdk.java.net/jdk9/hs/jdk/rev/615d771202e8> > >> > >> (2) 8171084: heapdump/JMapHeapCore fails with > java.lang.RuntimeException: Heap segment size overflow > >> http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/2c44cff993b8 < > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/2c44cff993b8> > >> > >> (3) 8159127: hprof heap dumps broken for lambda classdata > >> http://hg.openjdk.java.net/jdk9/hs/./rev/e5605f29b00e < > http://hg.openjdk.java.net/jdk9/hs/rev/e5605f29b00e> > >> http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/e5e4011e9c30 < > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/e5e4011e9c30> > >> > >> (4) 8169232: SA: TestCpoolForInvokeDynamic.java fails with > sun.jvm.hotspot.debugger.DebuggerException: binary search bug: should > >> have found entry 1 > >> http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/13e6043fcdcb < > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/13e6043fcdcb> > >> > >> (5) 8169638: serviceability/sa/TestInstanceKlassSize.java and > serviceability/sa/TestInstanceKlassSizeForInterface.java fail compilation > >> http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/ae23c7acb99a < > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/ae23c7acb99a> > >> > >> (6) 8169344: Potential open file descriptor in exists() of > hotspot/agent/src/os/bsd/ps_core.c > >> http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/a71b53580d07 < > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/a71b53580d07> > >> > >> (7) 7107018: sun.jvm.hotspot.utilities.soql.JSJavaHeap.forEachClass > incorrect test > >> http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/a169535aff9d < > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/a169535aff9d> > >> > >> (8) 8164783: SA: jhsdb clhsdb 'printall' often throws "Corrupted > constant pool" assertion failure > >> http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/8c2f220c759c < > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/8c2f220c759c> > >> > >> (9) 8164383: jhsdb dumps core on Solaris 12 when loading dumped core > >> http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/ce3eaa22b582 < > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/ce3eaa22b582> > >> > >> (10) 8166552: SA: Missed testcase for add default methods to > InstanceKlass > >> http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/0ff97dc32114 < > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/0ff97dc32114> > >> > >> (11) 8027920: SA: Add default methods to InstanceKlass > >> http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/c8b3f8e5423b < > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/c8b3f8e5423b> > >> > >> (12) 8163150: SA: CLHSDB printmdo throws an exception with > "java.lang.InternalError: missing reason for 22" > >> http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/3652a2a22916 < > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/3652a2a22916> > >> http://hg.openjdk.java.net/jdk9/hs/jdk/rev/8a0a818c3f28 < > http://hg.openjdk.java.net/jdk9/hs/jdk/rev/8a0a818c3f28> > >> > >> (13) 8164562: serviceability/sa/TestInstanceKlassSizeForInterface.java: > fails with NPE > >> http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/1357a160e4f2 < > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/1357a160e4f2> > >> > >> (14) 8163143: illegal bci error with interpreted frames in SA due to > mirror being stored in interpreted frames > >> http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/b84f097dc4c5 < > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/b84f097dc4c5> > >> http://hg.openjdk.java.net/jdk9/hs/jdk/rev/481ac1e59664 < > http://hg.openjdk.java.net/jdk9/hs/jdk/rev/481ac1e59664> > >> > >> (15) 8145627: sun.jvm.hotspot.oops.InstanceKlass::getSize() returns > the incorrect size and has no test > >> http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/ca241ed18db8 < > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/ca241ed18db8> > >> > > From dalibor.topic at oracle.com Tue Feb 21 14:47:51 2017 From: dalibor.topic at oracle.com (dalibor topic) Date: Tue, 21 Feb 2017 15:47:51 +0100 Subject: CFV: New JDK 9/10 Committer: Jini George In-Reply-To: References: <854DE5D9-F54A-446C-A98E-8714121E072A@oracle.com> Message-ID: Vote: Yes. -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From Roger.Riggs at Oracle.com Tue Feb 21 15:04:00 2017 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Tue, 21 Feb 2017 10:04:00 -0500 Subject: CFV: New JDK 9/10 Committer: Jini George In-Reply-To: <854DE5D9-F54A-446C-A98E-8714121E072A@oracle.com> References: <854DE5D9-F54A-446C-A98E-8714121E072A@oracle.com> Message-ID: Vote: Yes On 2/15/2017 10:03 AM, jesper.wilhelmsson at oracle.com wrote: > I hereby nominate Jini George (jgeorge) to JDK 9 and JDK 10 Committer. > From joe.darcy at oracle.com Tue Feb 21 17:14:13 2017 From: joe.darcy at oracle.com (joe darcy) Date: Tue, 21 Feb 2017 09:14:13 -0800 Subject: How to handle future backports from JDK 10 into JDK 9? In-Reply-To: <3815dda4-c612-dd5a-547f-553477fad5d7@oracle.com> References: <49f8daf7-6c15-dec9-92e3-ef76dc6f2afb@oracle.com> <58db6d43-3457-8bd9-bb04-3ab01aeb64e7@oracle.com> <5df4217f-0a88-4938-a06f-e00176a5153b@oracle.com> <3729188d-aa28-25bf-efaf-e74acc19437a@oracle.com> <3815dda4-c612-dd5a-547f-553477fad5d7@oracle.com> Message-ID: <2a244a55-3576-1c69-b3c5-f0331df20f6c@oracle.com> On 2/20/2017 2:43 AM, David Holmes wrote: > On 20/02/2017 7:11 PM, Se?n Coffey wrote: >> On 18/02/2017 03:14, David Holmes wrote: >> >>> Creating a new bug for a "backport" is already existing practice for >>> the update releases, so this isn't something radically new. >> I don't believe above to be accurate. An engineer rarely has to create a >> backport bug ID. For the majority of cases, it's automatically handled >> by hgupdater tooling and no one has to ever reference the backport ID. > > I think there is a misunderstanding. What I am talking about is when a > specific issue is created (of type bug or rfe) to handle the > backporting of some fix or enhancement, when the use of a direct > "backport" of the original fix/ref is not possible for some reason. > > The bug database is littered with such issues, for example: > > https://bugs.openjdk.java.net/browse/JDK-8038440 > https://bugs.openjdk.java.net/browse/JDK-8052313 > > and there are many, many examples. The query summary ~ backport and project = JDK yields 398 results and the more specific query summary ~ backport and project = JDK and issuetype != Backport yields 262 results while summary ~ backport and project = JDK and issuetype != Backport and id > JDK-8000000 has only 182 results. Bug id 8000000 represents the start of using JBS as the bug system, circa September 2012. The query issuetype = backport and project = JDK and id > JDK-8000000 yields 52,604 results. Therefore, since JBS started the conventional use of the backport issue type is nearly 300 times as common as putting "backport" in the summary to indicate an issue is conceptually a backport without using a backport issue type at all. (The results are similar if legacy bugs imported into JBS are included in the analysis.) Post-JBS, the most frequent component to use "backport" in the summary without a backport issue type is core-libs (32 instances) followed by hotspot (31 instances) and FX (30 instances). If someone had asked my opinion on tracking fixes to multiple release trains using a backport-that-is-not-a-backport, I would have strongly advised against it. I don't think a relative handful of ill-advised uses of backports-that-are-not-backports should be used as a precedent to justify broader adoption of this (anti-)pattern. I don't understand the rationale for this usage. There is not a requirement that the patch of a backport apply cleanly for a backport issue type to be used. If one needs the specific backport issue to be created before pushing, one can do that manually as a backport issue type rather than an independent issue. -Joe From dmitry.samersoff at oracle.com Tue Feb 21 18:06:19 2017 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Tue, 21 Feb 2017 21:06:19 +0300 Subject: CFV: New JDK 9/10 Committer: Jini George In-Reply-To: <854DE5D9-F54A-446C-A98E-8714121E072A@oracle.com> References: <854DE5D9-F54A-446C-A98E-8714121E072A@oracle.com> Message-ID: <4f65c28c-e626-b3f8-10fe-7aef7a0ac817@oracle.com> Vote: yes -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From david.holmes at oracle.com Wed Feb 22 03:05:19 2017 From: david.holmes at oracle.com (David Holmes) Date: Wed, 22 Feb 2017 13:05:19 +1000 Subject: How to handle future backports from JDK 10 into JDK 9? In-Reply-To: <2a244a55-3576-1c69-b3c5-f0331df20f6c@oracle.com> References: <49f8daf7-6c15-dec9-92e3-ef76dc6f2afb@oracle.com> <58db6d43-3457-8bd9-bb04-3ab01aeb64e7@oracle.com> <5df4217f-0a88-4938-a06f-e00176a5153b@oracle.com> <3729188d-aa28-25bf-efaf-e74acc19437a@oracle.com> <3815dda4-c612-dd5a-547f-553477fad5d7@oracle.com> <2a244a55-3576-1c69-b3c5-f0331df20f6c@oracle.com> Message-ID: <77bbab8f-854a-e718-8d5c-e85faa8cc4f0@oracle.com> Hi Joe, From my own observation/experience the "why" we would create a new bug to "backport" something is when the something is not neatly packaged and obtainable through direct backports of specific issues. Take an example of an issue that is fixed but is buggy and has quite a lengthy bugtail - once it is reliable you want to backport it to an earlier release. Do you backport each individual bug (some of which may not even apply to the earlier release) or do you backport the resulting functionality that was finally obtained? There are pros and cons to both approaches - neither is clean nor ideal. Such is life. Cheers, David ----- On 22/02/2017 3:14 AM, joe darcy wrote: > On 2/20/2017 2:43 AM, David Holmes wrote: >> On 20/02/2017 7:11 PM, Se?n Coffey wrote: >>> On 18/02/2017 03:14, David Holmes wrote: >>> >>>> Creating a new bug for a "backport" is already existing practice for >>>> the update releases, so this isn't something radically new. >>> I don't believe above to be accurate. An engineer rarely has to create a >>> backport bug ID. For the majority of cases, it's automatically handled >>> by hgupdater tooling and no one has to ever reference the backport ID. >> >> I think there is a misunderstanding. What I am talking about is when a >> specific issue is created (of type bug or rfe) to handle the >> backporting of some fix or enhancement, when the use of a direct >> "backport" of the original fix/ref is not possible for some reason. >> >> The bug database is littered with such issues, for example: >> >> https://bugs.openjdk.java.net/browse/JDK-8038440 >> https://bugs.openjdk.java.net/browse/JDK-8052313 >> >> and there are many, many examples. > > The query > > summary ~ backport and project = JDK > > yields 398 results and the more specific query > > summary ~ backport and project = JDK and issuetype != Backport > > yields 262 results while > > summary ~ backport and project = JDK and issuetype != Backport and > id > JDK-8000000 > > has only 182 results. Bug id 8000000 represents the start of using JBS > as the bug system, circa September 2012. > > The query > > issuetype = backport and project = JDK and id > JDK-8000000 > > yields 52,604 results. Therefore, since JBS started the conventional use > of the backport issue type is nearly 300 times as common as putting > "backport" in the summary to indicate an issue is conceptually a > backport without using a backport issue type at all. (The results are > similar if legacy bugs imported into JBS are included in the analysis.) > > Post-JBS, the most frequent component to use "backport" in the summary > without a backport issue type is core-libs (32 instances) followed by > hotspot (31 instances) and FX (30 instances). > > If someone had asked my opinion on tracking fixes to multiple release > trains using a backport-that-is-not-a-backport, I would have strongly > advised against it. I don't think a relative handful of ill-advised uses > of backports-that-are-not-backports should be used as a precedent to > justify broader adoption of this (anti-)pattern. > > I don't understand the rationale for this usage. There is not a > requirement that the patch of a backport apply cleanly for a backport > issue type to be used. If one needs the specific backport issue to be > created before pushing, one can do that manually as a backport issue > type rather than an independent issue. > > -Joe From tobias.hartmann at oracle.com Thu Feb 23 14:36:16 2017 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Thu, 23 Feb 2017 15:36:16 +0100 Subject: CFV: New JDK 9/10 Committer: Jini George In-Reply-To: <854DE5D9-F54A-446C-A98E-8714121E072A@oracle.com> References: <854DE5D9-F54A-446C-A98E-8714121E072A@oracle.com> Message-ID: <58b32cec-a47e-f4e3-7c8f-e160e326e43e@oracle.com> Vote: yes On 15.02.2017 16:03, jesper.wilhelmsson at oracle.com wrote: > I hereby nominate Jini George (jgeorge) to JDK 9 and JDK 10 Committer. > > Jini is part of the Monitoring and Management team and has contributed 15 changesets to JDK 9 [3]. > > Votes are due by Mars 1, 2017. > > Only current JDK 9/10 Committers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. Since we are in the borderland between JDK 9 and JDK 10 now, and the JDK 10 project has already been created, I'm not sure if we need a vote per project so I'm sending this CFV to both the JDK 9 and JDK 10 lists. Unless someone can verify that it is enough to vote for one of these projects I suggest that those of you that are in both lists replies to both mails and treat this as two separate votes. > > For Lazy Consensus voting instructions, see [2]. > > Thanks, > /Jesper > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/bylaws#lazy-consensus > [3] List of changes: > > (1) 8173896: SA: BasicLauncherTest.java (printmdo) fails for Client VM and Server VM with emulated-client > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/3bd7f52ecae6 > http://hg.openjdk.java.net/jdk9/hs/jdk/rev/615d771202e8 > > (2) 8171084: heapdump/JMapHeapCore fails with java.lang.RuntimeException: Heap segment size overflow > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/2c44cff993b8 > > (3) 8159127: hprof heap dumps broken for lambda classdata > http://hg.openjdk.java.net/jdk9/hs/./rev/e5605f29b00e > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/e5e4011e9c30 > > (4) 8169232: SA: TestCpoolForInvokeDynamic.java fails with sun.jvm.hotspot.debugger.DebuggerException: binary search bug: should have found entry 1 > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/13e6043fcdcb > > (5) 8169638: serviceability/sa/TestInstanceKlassSize.java and serviceability/sa/TestInstanceKlassSizeForInterface.java fail compilation > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/ae23c7acb99a > > (6) 8169344: Potential open file descriptor in exists() of hotspot/agent/src/os/bsd/ps_core.c > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/a71b53580d07 > > (7) 7107018: sun.jvm.hotspot.utilities.soql.JSJavaHeap.forEachClass incorrect test > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/a169535aff9d > > (8) 8164783: SA: jhsdb clhsdb 'printall' often throws "Corrupted constant pool" assertion failure > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/8c2f220c759c > > (9) 8164383: jhsdb dumps core on Solaris 12 when loading dumped core > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/ce3eaa22b582 > > (10) 8166552: SA: Missed testcase for add default methods to InstanceKlass > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/0ff97dc32114 > > (11) 8027920: SA: Add default methods to InstanceKlass > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/c8b3f8e5423b > > (12) 8163150: SA: CLHSDB printmdo throws an exception with "java.lang.InternalError: missing reason for 22" > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/3652a2a22916 > http://hg.openjdk.java.net/jdk9/hs/jdk/rev/8a0a818c3f28 > > (13) 8164562: serviceability/sa/TestInstanceKlassSizeForInterface.java: fails with NPE > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/1357a160e4f2 > > (14) 8163143: illegal bci error with interpreted frames in SA due to mirror being stored in interpreted frames > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/b84f097dc4c5 > http://hg.openjdk.java.net/jdk9/hs/jdk/rev/481ac1e59664 > > (15) 8145627: sun.jvm.hotspot.oops.InstanceKlass::getSize() returns the incorrect size and has no test > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/ca241ed18db8 > From karen.kinnear at oracle.com Tue Feb 28 21:17:41 2017 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Tue, 28 Feb 2017 16:17:41 -0500 Subject: CFV: New JDK 9/10 Committer: Jini George In-Reply-To: <854DE5D9-F54A-446C-A98E-8714121E072A@oracle.com> References: <854DE5D9-F54A-446C-A98E-8714121E072A@oracle.com> Message-ID: <50CA0359-D05C-4965-888F-1B084F83C409@oracle.com> Vote: yes thanks, Karen > On Feb 15, 2017, at 10:03 AM, jesper.wilhelmsson at oracle.com wrote: > > I hereby nominate Jini George (jgeorge) to JDK 9 and JDK 10 Committer. > > Jini is part of the Monitoring and Management team and has contributed 15 changesets to JDK 9 [3]. > > Votes are due by Mars 1, 2017. > > Only current JDK 9/10 Committers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. Since we are in the borderland between JDK 9 and JDK 10 now, and the JDK 10 project has already been created, I'm not sure if we need a vote per project so I'm sending this CFV to both the JDK 9 and JDK 10 lists. Unless someone can verify that it is enough to vote for one of these projects I suggest that those of you that are in both lists replies to both mails and treat this as two separate votes. > > For Lazy Consensus voting instructions, see [2]. > > Thanks, > /Jesper > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/bylaws#lazy-consensus > [3] List of changes: > > (1) 8173896: SA: BasicLauncherTest.java (printmdo) fails for Client VM and Server VM with emulated-client > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/3bd7f52ecae6 > http://hg.openjdk.java.net/jdk9/hs/jdk/rev/615d771202e8 > > (2) 8171084: heapdump/JMapHeapCore fails with java.lang.RuntimeException: Heap segment size overflow > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/2c44cff993b8 > > (3) 8159127: hprof heap dumps broken for lambda classdata > http://hg.openjdk.java.net/jdk9/hs/./rev/e5605f29b00e > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/e5e4011e9c30 > > (4) 8169232: SA: TestCpoolForInvokeDynamic.java fails with sun.jvm.hotspot.debugger.DebuggerException: binary search bug: should have found entry 1 > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/13e6043fcdcb > > (5) 8169638: serviceability/sa/TestInstanceKlassSize.java and serviceability/sa/TestInstanceKlassSizeForInterface.java fail compilation > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/ae23c7acb99a > > (6) 8169344: Potential open file descriptor in exists() of hotspot/agent/src/os/bsd/ps_core.c > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/a71b53580d07 > > (7) 7107018: sun.jvm.hotspot.utilities.soql.JSJavaHeap.forEachClass incorrect test > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/a169535aff9d > > (8) 8164783: SA: jhsdb clhsdb 'printall' often throws "Corrupted constant pool" assertion failure > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/8c2f220c759c > > (9) 8164383: jhsdb dumps core on Solaris 12 when loading dumped core > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/ce3eaa22b582 > > (10) 8166552: SA: Missed testcase for add default methods to InstanceKlass > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/0ff97dc32114 > > (11) 8027920: SA: Add default methods to InstanceKlass > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/c8b3f8e5423b > > (12) 8163150: SA: CLHSDB printmdo throws an exception with "java.lang.InternalError: missing reason for 22" > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/3652a2a22916 > http://hg.openjdk.java.net/jdk9/hs/jdk/rev/8a0a818c3f28 > > (13) 8164562: serviceability/sa/TestInstanceKlassSizeForInterface.java: fails with NPE > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/1357a160e4f2 > > (14) 8163143: illegal bci error with interpreted frames in SA due to mirror being stored in interpreted frames > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/b84f097dc4c5 > http://hg.openjdk.java.net/jdk9/hs/jdk/rev/481ac1e59664 > > (15) 8145627: sun.jvm.hotspot.oops.InstanceKlass::getSize() returns the incorrect size and has no test > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/ca241ed18db8 >