From joe.darcy at oracle.com Fri Sep 1 01:12:30 2017 From: joe.darcy at oracle.com (joe darcy) Date: Thu, 31 Aug 2017 18:12:30 -0700 Subject: Update on JDK 10 repo consolidation; third generation prototype coming soon, September 2017 still the target In-Reply-To: <6ed232d7-7b84-b1b9-93e0-971678251563@oracle.com> References: <6ed232d7-7b84-b1b9-93e0-971678251563@oracle.com> Message-ID: <05cefb5a-0435-bec9-cccf-77cfb49eaf51@oracle.com> An update on the repo consolidation. On 8/25/2017 1:52 PM, joe darcy wrote: [snip] > > We're aiming to have the final pre-consolidation integrations of the > hs and client forests into JDK 10 master the week of August 28 or > shortly thereafter. Any work urgently needed to JDK 10 in areas that > push directly to master should also be pushed the week of August 28. > > On or about the week of September 4, JDK 10 master will be marked as > read-only and after it is marked read-only, no changes will be > accepted into the conceptual JDK 10 master line of development until > after the consolidation is complete and the necessary infrastructure > to support the consolidation updated. > As has been discussed on hotspot-dev [1], the JDK 10 integration forests are working on getting their outstanding fixes integrated into JDK 10 master ahead of the repo consolidation. The client forest is following a similar pattern. The hotspot integration is expected before September 4 and the client integration is targeted before September 9. Once the last expected fixes are in the integration forests, the forests will be closed to pushes from people other than those working on the integration to master. (The integrators may need to address problems in the integration, etc.) Likewise, early in the week of Sept. 4, the JDK 10 master forest will be configured to only allow pushes from integrators and people working on the consolidation. The master line of development will remain in that state until the consolidation is complete. The final pre-consolidated version will be tagged as build N. The functionally equivalent consolidated sources will be tagged as build (N+1). The current plan for the top-level JDK 10 forests is: * jdk10/jdk10 -- pre-consolidated version archived and ready-only to allow URL links from JBS to continue to function * jdk10/master -- new consolidated master repository hosted the sources previously spread out in jdk, langtools, hotspot, etc. * jdk10/client -- old "client" forest deleted, new "client" repo created as a child of the consolidated master * jdk10/hotspot -- old "hotspot" forest deleted, new "hotspot" repo created as a child of the consolidated master An implication of the above is that existing children of the pre-consolidated forest will no longer be directly usable for doing pushes. New clones of the appropriate consolidated repo will need to be used instead once the repos are opened for development. We are aiming to have all the necessary infrastructure changes in place to reopen development by the week of September 18. I'll be given updates on progress in the interim. Comments? Cheers, -Joe [1] http://mail.openjdk.java.net/pipermail/hotspot-dev/2017-August/028134.html From david.holmes at oracle.com Fri Sep 1 01:27:36 2017 From: david.holmes at oracle.com (David Holmes) Date: Fri, 1 Sep 2017 11:27:36 +1000 Subject: Update on JDK 10 repo consolidation; third generation prototype coming soon, September 2017 still the target In-Reply-To: <05cefb5a-0435-bec9-cccf-77cfb49eaf51@oracle.com> References: <6ed232d7-7b84-b1b9-93e0-971678251563@oracle.com> <05cefb5a-0435-bec9-cccf-77cfb49eaf51@oracle.com> Message-ID: <6cae530e-bbf1-2a1c-b6c5-e1dbb114e4eb@oracle.com> Hi Joe, On 1/09/2017 11:12 AM, joe darcy wrote: > An update on the repo consolidation. > > > On 8/25/2017 1:52 PM, joe darcy wrote: > > [snip] > >> >> We're aiming to have the final pre-consolidation integrations of the >> hs and client forests into JDK 10 master the week of August 28 or >> shortly thereafter. Any work urgently needed to JDK 10 in areas that >> push directly to master should also be pushed the week of August 28. >> >> On or about the week of September 4, JDK 10 master will be marked as >> read-only and after it is marked read-only, no changes will be >> accepted into the conceptual JDK 10 master line of development until >> after the consolidation is complete and the necessary infrastructure >> to support the consolidation updated. >> > > As has been discussed on hotspot-dev [1], the JDK 10 integration forests > are working on getting their outstanding fixes integrated into JDK 10 > master ahead of the repo consolidation. The client forest is following a > similar pattern. The hotspot integration is expected before September 4 > and the client integration is targeted before September 9. Once the last > expected fixes are in the integration forests, the forests will be > closed to pushes from people other than those working on the integration > to master. (The integrators may need to address problems in the > integration, etc.) > > Likewise, early in the week of Sept. 4, the JDK 10 master forest will be > configured to only allow pushes from integrators and people working on > the consolidation. The master line of development will remain in that > state until the consolidation is complete. > > The final pre-consolidated version will be tagged as build N. The > functionally equivalent consolidated sources will be tagged as build (N+1). > > The current plan for the top-level JDK 10 forests is: > > * jdk10/jdk10 -- pre-consolidated version archived and ready-only to > allow URL links from JBS to continue to function > * jdk10/master -- new consolidated master repository hosted the sources > previously spread out in jdk, langtools, hotspot, etc. > * jdk10/client -- old "client" forest deleted, new "client" repo created > as a child of the consolidated master > * jdk10/hotspot -- old "hotspot" forest deleted, new "hotspot" repo > created as a child of the consolidated master The existing forest is jdk10/hs not jdk10/hotspot, but renaming the new repo as "hotspot" might be a good idea. > An implication of the above is that existing children of the > pre-consolidated forest will no longer be directly usable for doing > pushes. New clones of the appropriate consolidated repo will need to be > used instead once the repos are opened for development. Any tools for making this migration easier? I personally have 6 clones I'd need to migrate. How do the project repos move across to the new consolidated form? Will we lose all the changeset history? Cheers, David > We are aiming to have all the necessary infrastructure changes in place > to reopen development by the week of September 18. I'll be given updates > on progress in the interim. > > Comments? > > Cheers, > > -Joe > > [1] > http://mail.openjdk.java.net/pipermail/hotspot-dev/2017-August/028134.html From joe.darcy at oracle.com Fri Sep 1 02:00:46 2017 From: joe.darcy at oracle.com (joe darcy) Date: Thu, 31 Aug 2017 19:00:46 -0700 Subject: Update on JDK 10 repo consolidation; third generation prototype coming soon, September 2017 still the target In-Reply-To: <6cae530e-bbf1-2a1c-b6c5-e1dbb114e4eb@oracle.com> References: <6ed232d7-7b84-b1b9-93e0-971678251563@oracle.com> <05cefb5a-0435-bec9-cccf-77cfb49eaf51@oracle.com> <6cae530e-bbf1-2a1c-b6c5-e1dbb114e4eb@oracle.com> Message-ID: Hi David, On 8/31/2017 6:27 PM, David Holmes wrote: > Hi Joe, > > On 1/09/2017 11:12 AM, joe darcy wrote: >> An update on the repo consolidation. >> >> >> [snip] >> >> The current plan for the top-level JDK 10 forests is: >> >> * jdk10/jdk10 -- pre-consolidated version archived and ready-only to >> allow URL links from JBS to continue to function >> * jdk10/master -- new consolidated master repository hosted the >> sources previously spread out in jdk, langtools, hotspot, etc. >> * jdk10/client -- old "client" forest deleted, new "client" repo >> created as a child of the consolidated master >> * jdk10/hotspot -- old "hotspot" forest deleted, new "hotspot" repo >> created as a child of the consolidated master > > The existing forest is jdk10/hs not jdk10/hotspot, but renaming the > new repo as "hotspot" might be a good idea. Right I meant to write "jdk10/hs" above rather than "jdk10/hotspot". It would certainly be possible to archive the jdk10/hs forest and restart development afresh in a consolidated jdk10/hotspot repo. I don't oppose that, but I don't think it is strictly necessary either. > >> An implication of the above is that existing children of the >> pre-consolidated forest will no longer be directly usable for doing >> pushes. New clones of the appropriate consolidated repo will need to >> be used instead once the repos are opened for development. > > Any tools for making this migration easier? I personally have 6 clones > I'd need to migrate. One of the infra-related items planned to be worked on is a patch conversion script analogous to (and perhaps sharing implementation with) the shuffle script used for the Jigsaw changes. > > How do the project repos move across to the new consolidated form? > Will we lose all the changeset history? > I recommend project forests sync up with the last pre-consolidated JDK 10, extract the patches from the changesets, and then reapply the changesets to a new consolidated baseline of the project forest. HTH, -Joe From joe.darcy at oracle.com Fri Sep 1 18:36:25 2017 From: joe.darcy at oracle.com (joe darcy) Date: Fri, 1 Sep 2017 11:36:25 -0700 Subject: Update on JDK 10 repo consolidation; third generation prototype published at http://hg.openjdk.java.net/jdk10/consol-proto In-Reply-To: <6ed232d7-7b84-b1b9-93e0-971678251563@oracle.com> References: <6ed232d7-7b84-b1b9-93e0-971678251563@oracle.com> Message-ID: <1f3fc74a-cc37-fdf0-91e5-20a3394f981e@oracle.com> On 8/25/2017 1:52 PM, joe darcy wrote: > Hello, > > A follow-up to the most recent update [1] on the JDK 10 repo > consolidation efforts, September 2017 is almost upon us and that month > remains the target to implement the repo consolidation. > > First, a third generation prototype having tags from both JDK 9 and > JDK 10 will be published in the near future. > [snip] Third generation prototype with tags from JDK 9 and JDK 10 available for browsing at: http://hg.openjdk.java.net/jdk10/consol-proto/tags Please sent comments by Wednesday, September 6. Thanks, -Joe From ashipile at redhat.com Mon Sep 4 10:21:10 2017 From: ashipile at redhat.com (Aleksey Shipilev) Date: Mon, 4 Sep 2017 12:21:10 +0200 Subject: Update on JDK 10 repo consolidation; third generation prototype published at http://hg.openjdk.java.net/jdk10/consol-proto In-Reply-To: <1f3fc74a-cc37-fdf0-91e5-20a3394f981e@oracle.com> References: <6ed232d7-7b84-b1b9-93e0-971678251563@oracle.com> <1f3fc74a-cc37-fdf0-91e5-20a3394f981e@oracle.com> Message-ID: On 09/01/2017 08:36 PM, joe darcy wrote: > Third generation prototype with tags from JDK 9 and JDK 10 available for browsing at: > > http://hg.openjdk.java.net/jdk10/consol-proto/tags > > Please sent comments by Wednesday, September 6. Looking at this: http://hg.openjdk.java.net/jdk10/consol-proto/file/b3acd2a9bbf1/src/ *) It is odd to see the high-level directories like: src/bsd src/solaris src/linux There seem to be man pages in them. Are those supposed to reside in src/doc/*? *) src/langtools seems to miss its contents? Was the code moved to (java|jdk).compiler, and samples left out? If so, src/langtools should really be under src/samples? -Aleksey From erik.joelsson at oracle.com Tue Sep 5 07:17:00 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 5 Sep 2017 09:17:00 +0200 Subject: Update on JDK 10 repo consolidation; third generation prototype published at http://hg.openjdk.java.net/jdk10/consol-proto In-Reply-To: References: <6ed232d7-7b84-b1b9-93e0-971678251563@oracle.com> <1f3fc74a-cc37-fdf0-91e5-20a3394f981e@oracle.com> Message-ID: <3dab8f2f-d259-85e8-8111-935fc4beb664@oracle.com> Hello Aleksey, Thank you for your comments, see below. On 2017-09-04 12:21, Aleksey Shipilev wrote: > On 09/01/2017 08:36 PM, joe darcy wrote: >> Third generation prototype with tags from JDK 9 and JDK 10 available for browsing at: >> >> http://hg.openjdk.java.net/jdk10/consol-proto/tags >> >> Please sent comments by Wednesday, September 6. > Looking at this: > http://hg.openjdk.java.net/jdk10/consol-proto/file/b3acd2a9bbf1/src/ > > *) It is odd to see the high-level directories like: > src/bsd > src/solaris > src/linux > > There seem to be man pages in them. Are those supposed to reside in src/doc/*? I agree those directories look weird and they only contain man pages. The long term plan for man pages is to move the sources to module specific source directories. That move will likely be more involved than just moving files (changing formats, build logic etc) so should be done separately from this reorg. Because of that I've intentionally not moved those files. > > *) src/langtools seems to miss its contents? Was the code moved to (java|jdk).compiler, and samples > left out? If so, src/langtools should really be under src/samples? This is actually a good catch. I have left src/ in some cases with files I didn't know where they belong, but then for nashorn I did move the samples dir into the common sample location. I should do the same here and will update the file moving script appropriately. And yes, all module src dirs are at the top level src/. In general though, we do expect more cleanup is going to be needed after this change as it settles in. In the build I have tried to keep the changes minimal to be able to keep the evolving patch set small until the actual conversion happens. /Erik > -Aleksey From Alan.Bateman at oracle.com Tue Sep 5 07:46:45 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 5 Sep 2017 08:46:45 +0100 Subject: Update on JDK 10 repo consolidation; third generation prototype published at http://hg.openjdk.java.net/jdk10/consol-proto In-Reply-To: <3dab8f2f-d259-85e8-8111-935fc4beb664@oracle.com> References: <6ed232d7-7b84-b1b9-93e0-971678251563@oracle.com> <1f3fc74a-cc37-fdf0-91e5-20a3394f981e@oracle.com> <3dab8f2f-d259-85e8-8111-935fc4beb664@oracle.com> Message-ID: On 05/09/2017 08:17, Erik Joelsson wrote: > Hello Aleksey, > > Thank you for your comments, see below. > > > On 2017-09-04 12:21, Aleksey Shipilev wrote: >> On 09/01/2017 08:36 PM, joe darcy wrote: >>> Third generation prototype with tags from JDK 9 and JDK 10 available >>> for browsing at: >>> >>> ???? http://hg.openjdk.java.net/jdk10/consol-proto/tags >>> >>> Please sent comments by Wednesday, September 6. >> Looking at this: >> http://hg.openjdk.java.net/jdk10/consol-proto/file/b3acd2a9bbf1/src/ >> >> *) It is odd to see the high-level directories like: >> ?? src/bsd >> ?? src/solaris >> ?? src/linux >> >> There seem to be man pages in them. Are those supposed to reside in >> src/doc/*? > I agree those directories look weird and they only contain man pages. > The long term plan for man pages is to move the sources to module > specific source directories. That move will likely be more involved > than just moving files (changing formats, build logic etc) so should > be done separately from this reorg. Because of that I've intentionally > not moved those files. Right and there is also an outstanding issue for JEP 201 to document the location of the man pages. -Alan From volker.simonis at gmail.com Tue Sep 5 09:38:09 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 5 Sep 2017 11:38:09 +0200 Subject: Update on JDK 10 repo consolidation; third generation prototype published at http://hg.openjdk.java.net/jdk10/consol-proto In-Reply-To: <1f3fc74a-cc37-fdf0-91e5-20a3394f981e@oracle.com> References: <6ed232d7-7b84-b1b9-93e0-971678251563@oracle.com> <1f3fc74a-cc37-fdf0-91e5-20a3394f981e@oracle.com> Message-ID: Hi Joe, generally looks good! I don't know if this has discussed before, but in my opinion the top-level src/ directory looks a little overloaded. Wouldn't it make sense to place all the modules into their own 'src/modules/' subdirectory? Should jdk10/consol-proto build out of t he box or are there any known issues? I'd like to give it a tray on AIX and Linux/ppc64 but if there are any known, generic problems I'll wait until they get fixed. Thank you and best regards, Volker On Fri, Sep 1, 2017 at 8:36 PM, joe darcy wrote: > On 8/25/2017 1:52 PM, joe darcy wrote: >> >> Hello, >> >> A follow-up to the most recent update [1] on the JDK 10 repo consolidation >> efforts, September 2017 is almost upon us and that month remains the target >> to implement the repo consolidation. >> >> First, a third generation prototype having tags from both JDK 9 and JDK 10 >> will be published in the near future. >> > > [snip] > > Third generation prototype with tags from JDK 9 and JDK 10 available for > browsing at: > > http://hg.openjdk.java.net/jdk10/consol-proto/tags > > Please sent comments by Wednesday, September 6. > > Thanks, > > -Joe From thomas.stuefe at gmail.com Tue Sep 5 10:26:21 2017 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 5 Sep 2017 12:26:21 +0200 Subject: Update on JDK 10 repo consolidation; third generation prototype published at http://hg.openjdk.java.net/jdk10/consol-proto In-Reply-To: References: <6ed232d7-7b84-b1b9-93e0-971678251563@oracle.com> <1f3fc74a-cc37-fdf0-91e5-20a3394f981e@oracle.com> Message-ID: Hi all, On Tue, Sep 5, 2017 at 11:38 AM, Volker Simonis wrote: > Hi Joe, > > generally looks good! > > I don't know if this has discussed before, but in my opinion the > top-level src/ directory looks a little overloaded. Wouldn't it make > sense to place all the modules into their own 'src/modules/' > subdirectory? > > I agree with Volker. While I prefer the one-repo approach and think this is the right direction, I am surprised that the directory structure changes so much. Why can we not keep the old structure, or at least the "jdk" super directory? Switching from forest to one repository will be disruptive enough without these structural changes. > Should jdk10/consol-proto build out of t he box or are there any known > issues? I'd like to give it a tray on AIX and Linux/ppc64 but if there > are any known, generic problems I'll wait until they get fixed. > > Thank you and best regards, > Volker > > Thank you and Kind Regards, Thomas > > On Fri, Sep 1, 2017 at 8:36 PM, joe darcy wrote: > > On 8/25/2017 1:52 PM, joe darcy wrote: > >> > >> Hello, > >> > >> A follow-up to the most recent update [1] on the JDK 10 repo > consolidation > >> efforts, September 2017 is almost upon us and that month remains the > target > >> to implement the repo consolidation. > >> > >> First, a third generation prototype having tags from both JDK 9 and JDK > 10 > >> will be published in the near future. > >> > > > > [snip] > > > > Third generation prototype with tags from JDK 9 and JDK 10 available for > > browsing at: > > > > http://hg.openjdk.java.net/jdk10/consol-proto/tags > > > > Please sent comments by Wednesday, September 6. > > > > Thanks, > > > > -Joe > From joe.darcy at oracle.com Tue Sep 5 15:58:16 2017 From: joe.darcy at oracle.com (joe darcy) Date: Tue, 5 Sep 2017 08:58:16 -0700 Subject: Update on JDK 10 repo consolidation; third generation prototype published at http://hg.openjdk.java.net/jdk10/consol-proto In-Reply-To: References: <6ed232d7-7b84-b1b9-93e0-971678251563@oracle.com> <1f3fc74a-cc37-fdf0-91e5-20a3394f981e@oracle.com> Message-ID: <8d6e93c0-741a-70e4-f5ec-d01cb0d609ff@oracle.com> Hi Volker, On 9/5/2017 2:38 AM, Volker Simonis wrote: > Hi Joe, > > generally looks good! > > I don't know if this has discussed before, but in my opinion the > top-level src/ directory looks a little overloaded. Wouldn't it make > sense to place all the modules into their own 'src/modules/' > subdirectory? To a first approximation, the subdirectories under the top-level src are the set of subdirectories moved over from the old $ROOT/jdk/src/, $ROOT/langtools/src, etc. Since essentially all the Java sources and modularized, a "modules" layer would be redundant. In earlier version of the prototype we did discuss various options for where the non-modularized HotSpot code would go and ended up on the src/hotspot directory. > > Should jdk10/consol-proto build out of t he box or are there any known > issues? I'd like to give it a tray on AIX and Linux/ppc64 but if there > are any known, generic problems I'll wait until they get fixed. We've successfully built the consolidated repo on the platforms we use internally. Thanks, -Joe From thomas.stuefe at gmail.com Tue Sep 5 16:19:30 2017 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 5 Sep 2017 18:19:30 +0200 Subject: Update on JDK 10 repo consolidation; third generation prototype published at http://hg.openjdk.java.net/jdk10/consol-proto In-Reply-To: References: <6ed232d7-7b84-b1b9-93e0-971678251563@oracle.com> <1f3fc74a-cc37-fdf0-91e5-20a3394f981e@oracle.com> Message-ID: Hi Joe, On Tue, Sep 5, 2017 at 12:26 PM, Thomas St?fe wrote: > Hi all, > > On Tue, Sep 5, 2017 at 11:38 AM, Volker Simonis > wrote: > >> Hi Joe, >> >> generally looks good! >> >> I don't know if this has discussed before, but in my opinion the >> top-level src/ directory looks a little overloaded. Wouldn't it make >> sense to place all the modules into their own 'src/modules/' >> subdirectory? >> >> > I agree with Volker. > > While I prefer the one-repo approach and think this is the right > direction, I am surprised that the directory structure changes so much. Why > can we not keep the old structure, or at least the "jdk" super directory? > Switching from forest to one repository will be disruptive enough without > these structural changes. > > > Okay, I read JEP 296 again, and the proposal for the new file structure is right there. We missed it apparently, focusing instead on the one-repository issues. So, this is my own fault for not reading the JEP closely when it was still in discussion. Sorry for the noise. Kind Regards, Thomas Should jdk10/consol-proto build out of t he box or are there any known >> issues? I'd like to give it a tray on AIX and Linux/ppc64 but if there >> are any known, generic problems I'll wait until they get fixed. >> >> Thank you and best regards, >> Volker >> >> > > Thank you and Kind Regards, Thomas > > >> >> On Fri, Sep 1, 2017 at 8:36 PM, joe darcy wrote: >> > On 8/25/2017 1:52 PM, joe darcy wrote: >> >> >> >> Hello, >> >> >> >> A follow-up to the most recent update [1] on the JDK 10 repo >> consolidation >> >> efforts, September 2017 is almost upon us and that month remains the >> target >> >> to implement the repo consolidation. >> >> >> >> First, a third generation prototype having tags from both JDK 9 and >> JDK 10 >> >> will be published in the near future. >> >> >> > >> > [snip] >> > >> > Third generation prototype with tags from JDK 9 and JDK 10 available for >> > browsing at: >> > >> > http://hg.openjdk.java.net/jdk10/consol-proto/tags >> > >> > Please sent comments by Wednesday, September 6. >> > >> > Thanks, >> > >> > -Joe >> > > From erik.joelsson at oracle.com Tue Sep 5 17:31:38 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 5 Sep 2017 19:31:38 +0200 Subject: Update on JDK 10 repo consolidation; third generation prototype published at http://hg.openjdk.java.net/jdk10/consol-proto In-Reply-To: References: <6ed232d7-7b84-b1b9-93e0-971678251563@oracle.com> <1f3fc74a-cc37-fdf0-91e5-20a3394f981e@oracle.com> Message-ID: On 2017-09-05 11:38, Volker Simonis wrote: > Hi Joe, > > generally looks good! > > I don't know if this has discussed before, but in my opinion the > top-level src/ directory looks a little overloaded. Wouldn't it make > sense to place all the modules into their own 'src/modules/' > subdirectory? I see what you mean, but it's no more overloaded than the jdk/src dir used to be. Also, the bsd, linux, solaris, demo and sample directories are all going away at some point in the (hopefully near) future. Left are hotspot and utils which I don't think warrant another directory level. > Should jdk10/consol-proto build out of t he box or are there any known > issues? I'd like to give it a tray on AIX and Linux/ppc64 but if there > are any known, generic problems I'll wait until they get fixed. Yes, please try it. I have put a lot of work into maintaining a set of patches and scripts to keep the generated consolidated repo working and (near) equivalent with the current forest. You can review those changes in the prototype forest if you like. /Erik > > Thank you and best regards, > Volker > > > On Fri, Sep 1, 2017 at 8:36 PM, joe darcy wrote: >> On 8/25/2017 1:52 PM, joe darcy wrote: >>> Hello, >>> >>> A follow-up to the most recent update [1] on the JDK 10 repo consolidation >>> efforts, September 2017 is almost upon us and that month remains the target >>> to implement the repo consolidation. >>> >>> First, a third generation prototype having tags from both JDK 9 and JDK 10 >>> will be published in the near future. >>> >> [snip] >> >> Third generation prototype with tags from JDK 9 and JDK 10 available for >> browsing at: >> >> http://hg.openjdk.java.net/jdk10/consol-proto/tags >> >> Please sent comments by Wednesday, September 6. >> >> Thanks, >> >> -Joe From joe.darcy at oracle.com Tue Sep 5 17:43:46 2017 From: joe.darcy at oracle.com (joe darcy) Date: Tue, 5 Sep 2017 10:43:46 -0700 Subject: jdk10/jdk10 forest now locked for pushes other than for integrations and consolidation Message-ID: Hello, The jdk10/jdk10 forest is now locked for pushes other than those related to integrations and the repo consolidation. The jdk10 master line of development will reopen after the repo consolidation is completed. I'll send periodic updates the progress of that task. Cheers, -Joe From weijun.wang at oracle.com Tue Sep 5 23:47:28 2017 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 6 Sep 2017 07:47:28 +0800 Subject: Update on JDK 10 repo consolidation; third generation prototype coming soon, September 2017 still the target In-Reply-To: References: <6ed232d7-7b84-b1b9-93e0-971678251563@oracle.com> <05cefb5a-0435-bec9-cccf-77cfb49eaf51@oracle.com> <6cae530e-bbf1-2a1c-b6c5-e1dbb114e4eb@oracle.com> Message-ID: <7804BC61-DF90-4BB2-881B-AEA872F83FED@oracle.com> > On Sep 1, 2017, at 10:00 AM, joe darcy wrote: > > One of the infra-related items planned to be worked on is a patch conversion script analogous to (and perhaps sharing implementation with) the shuffle script used for the Jigsaw changes. In fact, if the test directory is flattened (i.e. no more test/jdk), then there will be no need for a shuffle script. At least this is true for patches for the jdk sub-repo. --Max From hufeng1987 at gmail.com Wed Sep 6 00:57:15 2017 From: hufeng1987 at gmail.com (Netroby) Date: Wed, 6 Sep 2017 08:57:15 +0800 Subject: Update on JDK 10 repo consolidation; third generation prototype coming soon, September 2017 still the target In-Reply-To: <7804BC61-DF90-4BB2-881B-AEA872F83FED@oracle.com> References: <6ed232d7-7b84-b1b9-93e0-971678251563@oracle.com> <05cefb5a-0435-bec9-cccf-77cfb49eaf51@oracle.com> <6cae530e-bbf1-2a1c-b6c5-e1dbb114e4eb@oracle.com> <7804BC61-DF90-4BB2-881B-AEA872F83FED@oracle.com> Message-ID: Any plan to migrate from Mercurial(Hg) To Git ? There be less and less GUI tools around mercurial. Git got more and more GUI tools. That can help your work flow. Appreciate your time. ---------------------------- Netroby 2017-09-06 7:47 GMT+08:00 Weijun Wang : > >> On Sep 1, 2017, at 10:00 AM, joe darcy wrote: >> >> One of the infra-related items planned to be worked on is a patch conversion script analogous to (and perhaps sharing implementation with) the shuffle script used for the Jigsaw changes. > > In fact, if the test directory is flattened (i.e. no more test/jdk), then there will be no need for a shuffle script. At least this is true for patches for the jdk sub-repo. > > --Max > From joe.darcy at oracle.com Wed Sep 6 01:10:07 2017 From: joe.darcy at oracle.com (joe darcy) Date: Tue, 5 Sep 2017 18:10:07 -0700 Subject: Update on JDK 10 repo consolidation; third generation prototype coming soon, September 2017 still the target In-Reply-To: References: <6ed232d7-7b84-b1b9-93e0-971678251563@oracle.com> <05cefb5a-0435-bec9-cccf-77cfb49eaf51@oracle.com> <6cae530e-bbf1-2a1c-b6c5-e1dbb114e4eb@oracle.com> <7804BC61-DF90-4BB2-881B-AEA872F83FED@oracle.com> Message-ID: <50a46621-677e-62b7-942b-8a86ded99bb7@oracle.com> As noted in prior discussions, a git migration is outside of the scope of this project. We are aware of the market shares of different distributed SCM systems. Cheers, -Joe On 9/5/2017 5:57 PM, Netroby wrote: > Any plan to migrate from Mercurial(Hg) To Git ? > > There be less and less GUI tools around mercurial. > Git got more and more GUI tools. That can help your work flow. > > Appreciate your time. > ---------------------------- > Netroby > > From joe.darcy at oracle.com Wed Sep 6 01:20:27 2017 From: joe.darcy at oracle.com (joe darcy) Date: Tue, 5 Sep 2017 18:20:27 -0700 Subject: Update on JDK 10 repo consolidation; third generation prototype coming soon, September 2017 still the target In-Reply-To: <7804BC61-DF90-4BB2-881B-AEA872F83FED@oracle.com> References: <6ed232d7-7b84-b1b9-93e0-971678251563@oracle.com> <05cefb5a-0435-bec9-cccf-77cfb49eaf51@oracle.com> <6cae530e-bbf1-2a1c-b6c5-e1dbb114e4eb@oracle.com> <7804BC61-DF90-4BB2-881B-AEA872F83FED@oracle.com> Message-ID: <9b4f505b-4228-032c-2469-4bd565b89aaf@oracle.com> Hi Max, On 9/5/2017 4:47 PM, Weijun Wang wrote: >> On Sep 1, 2017, at 10:00 AM, joe darcy wrote: >> >> One of the infra-related items planned to be worked on is a patch conversion script analogous to (and perhaps sharing implementation with) the shuffle script used for the Jigsaw changes. > In fact, if the test directory is flattened (i.e. no more test/jdk), then there will be no need for a shuffle script. At least this is true for patches for the jdk sub-repo. As noted in the current text of the JEP, "As a consequence [of combining all the module src directories from each repo into consolidated directory], from the root of the repository the relative path of a source file in a module is preserved after the consolidation and src directory combination." Therefore, it is true that no relative path change needs to occur in the forward direction. However, if backporting a patch from a the consolidated repo to the split forest, multiple patches may need to be created. However, there are many more logistical issues and fewer concrete benefits from combining all the tests together. Additionally, the tests lack the strict module-based structure present under the src directory. For example, most tests today in core libs are are arranged by package rather than by module. Consequently, I don't think a wholesale rearrangement of the test is warranted at this time as part of repo consolidatoin, but I'd encourage teams to examine the structure of tests in their own areas. Thanks, -Joe From weijun.wang at oracle.com Wed Sep 6 02:02:15 2017 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 6 Sep 2017 10:02:15 +0800 Subject: Update on JDK 10 repo consolidation; third generation prototype coming soon, September 2017 still the target In-Reply-To: <9b4f505b-4228-032c-2469-4bd565b89aaf@oracle.com> References: <6ed232d7-7b84-b1b9-93e0-971678251563@oracle.com> <05cefb5a-0435-bec9-cccf-77cfb49eaf51@oracle.com> <6cae530e-bbf1-2a1c-b6c5-e1dbb114e4eb@oracle.com> <7804BC61-DF90-4BB2-881B-AEA872F83FED@oracle.com> <9b4f505b-4228-032c-2469-4bd565b89aaf@oracle.com> Message-ID: <436D2AA4-3C47-431B-826B-5070F09F7DC1@oracle.com> So there is no plan to deal with multiple ProblemList.txt files and groups defined in multiple TEST.groups? Thanks Max > On Sep 6, 2017, at 9:20 AM, joe darcy wrote: > > Hi Max, > > > On 9/5/2017 4:47 PM, Weijun Wang wrote: >>> On Sep 1, 2017, at 10:00 AM, joe darcy wrote: >>> >>> One of the infra-related items planned to be worked on is a patch conversion script analogous to (and perhaps sharing implementation with) the shuffle script used for the Jigsaw changes. >> In fact, if the test directory is flattened (i.e. no more test/jdk), then there will be no need for a shuffle script. At least this is true for patches for the jdk sub-repo. > > As noted in the current text of the JEP, "As a consequence [of combining all the module src directories from each repo into consolidated directory], from the root of the repository the relative path of a source file in a module is preserved after the consolidation and src directory combination." > > Therefore, it is true that no relative path change needs to occur in the forward direction. However, if backporting a patch from a the consolidated repo to the split forest, multiple patches may need to be created. > > However, there are many more logistical issues and fewer concrete benefits from combining all the tests together. Additionally, the tests lack the strict module-based structure present under the src directory. For example, most tests today in core libs are are arranged by package rather than by module. > > Consequently, I don't think a wholesale rearrangement of the test is warranted at this time as part of repo consolidatoin, but I'd encourage teams to examine the structure of tests in their own areas. > > Thanks, > > -Joe From david.holmes at oracle.com Wed Sep 6 02:18:29 2017 From: david.holmes at oracle.com (David Holmes) Date: Wed, 6 Sep 2017 12:18:29 +1000 Subject: Update on JDK 10 repo consolidation; third generation prototype coming soon, September 2017 still the target In-Reply-To: <436D2AA4-3C47-431B-826B-5070F09F7DC1@oracle.com> References: <6ed232d7-7b84-b1b9-93e0-971678251563@oracle.com> <05cefb5a-0435-bec9-cccf-77cfb49eaf51@oracle.com> <6cae530e-bbf1-2a1c-b6c5-e1dbb114e4eb@oracle.com> <7804BC61-DF90-4BB2-881B-AEA872F83FED@oracle.com> <9b4f505b-4228-032c-2469-4bd565b89aaf@oracle.com> <436D2AA4-3C47-431B-826B-5070F09F7DC1@oracle.com> Message-ID: On 6/09/2017 12:02 PM, Weijun Wang wrote: > So there is no plan to deal with multiple ProblemList.txt files and groups defined in multiple TEST.groups? I for one would not want to see the test directory flattened. I want to be able to focus on hotspot tests, or jdk tests, or whatever tests. Many of the hotspot tests would not make sense in a flattened layout - you would have no idea what they pertain to. I prefer to see the tests kept in functional groups. That said I would think it possible to define a top-level test/TEST.ROOT etc that allows all the underlying tests to be combined as needed. Cheers, David > Thanks > Max > >> On Sep 6, 2017, at 9:20 AM, joe darcy wrote: >> >> Hi Max, >> >> >> On 9/5/2017 4:47 PM, Weijun Wang wrote: >>>> On Sep 1, 2017, at 10:00 AM, joe darcy wrote: >>>> >>>> One of the infra-related items planned to be worked on is a patch conversion script analogous to (and perhaps sharing implementation with) the shuffle script used for the Jigsaw changes. >>> In fact, if the test directory is flattened (i.e. no more test/jdk), then there will be no need for a shuffle script. At least this is true for patches for the jdk sub-repo. >> >> As noted in the current text of the JEP, "As a consequence [of combining all the module src directories from each repo into consolidated directory], from the root of the repository the relative path of a source file in a module is preserved after the consolidation and src directory combination." >> >> Therefore, it is true that no relative path change needs to occur in the forward direction. However, if backporting a patch from a the consolidated repo to the split forest, multiple patches may need to be created. >> >> However, there are many more logistical issues and fewer concrete benefits from combining all the tests together. Additionally, the tests lack the strict module-based structure present under the src directory. For example, most tests today in core libs are are arranged by package rather than by module. >> >> Consequently, I don't think a wholesale rearrangement of the test is warranted at this time as part of repo consolidatoin, but I'd encourage teams to examine the structure of tests in their own areas. >> >> Thanks, >> >> -Joe > From weijun.wang at oracle.com Wed Sep 6 02:26:50 2017 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 6 Sep 2017 10:26:50 +0800 Subject: Update on JDK 10 repo consolidation; third generation prototype coming soon, September 2017 still the target In-Reply-To: References: <6ed232d7-7b84-b1b9-93e0-971678251563@oracle.com> <05cefb5a-0435-bec9-cccf-77cfb49eaf51@oracle.com> <6cae530e-bbf1-2a1c-b6c5-e1dbb114e4eb@oracle.com> <7804BC61-DF90-4BB2-881B-AEA872F83FED@oracle.com> <9b4f505b-4228-032c-2469-4bd565b89aaf@oracle.com> <436D2AA4-3C47-431B-826B-5070F09F7DC1@oracle.com> Message-ID: Hotspot is special, and it already has a src/hotspot which stands out, but it's still inside src. And I cannot see why jaxp and nashorn need to stay out of jdk. Maybe langtools is a little special. --Max > On Sep 6, 2017, at 10:18 AM, David Holmes wrote: > > On 6/09/2017 12:02 PM, Weijun Wang wrote: >> So there is no plan to deal with multiple ProblemList.txt files and groups defined in multiple TEST.groups? > > I for one would not want to see the test directory flattened. I want to be able to focus on hotspot tests, or jdk tests, or whatever tests. Many of the hotspot tests would not make sense in a flattened layout - you would have no idea what they pertain to. I prefer to see the tests kept in functional groups. > > That said I would think it possible to define a top-level test/TEST.ROOT etc that allows all the underlying tests to be combined as needed. > > Cheers, > David From joe.darcy at oracle.com Wed Sep 6 06:40:00 2017 From: joe.darcy at oracle.com (joe darcy) Date: Tue, 5 Sep 2017 23:40:00 -0700 Subject: Update on JDK 10 repo consolidation; third generation prototype coming soon, September 2017 still the target In-Reply-To: <436D2AA4-3C47-431B-826B-5070F09F7DC1@oracle.com> References: <6ed232d7-7b84-b1b9-93e0-971678251563@oracle.com> <05cefb5a-0435-bec9-cccf-77cfb49eaf51@oracle.com> <6cae530e-bbf1-2a1c-b6c5-e1dbb114e4eb@oracle.com> <7804BC61-DF90-4BB2-881B-AEA872F83FED@oracle.com> <9b4f505b-4228-032c-2469-4bd565b89aaf@oracle.com> <436D2AA4-3C47-431B-826B-5070F09F7DC1@oracle.com> Message-ID: On 9/5/2017 7:02 PM, Weijun Wang wrote: > So there is no plan to deal with multiple ProblemList.txt files and groups defined in multiple TEST.groups? > > It is possible that at least some of the ProblemList.txt and TEST.groups and TEST.ROOT files will get combined at some point, but that is not essential for the consolidation and will not happen before the consolidation goes live. Cheers, -Joe From thomas.stuefe at gmail.com Wed Sep 6 12:30:11 2017 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 6 Sep 2017 14:30:11 +0200 Subject: Update on JDK 10 repo consolidation; third generation prototype published at http://hg.openjdk.java.net/jdk10/consol-proto In-Reply-To: References: <6ed232d7-7b84-b1b9-93e0-971678251563@oracle.com> <1f3fc74a-cc37-fdf0-91e5-20a3394f981e@oracle.com> Message-ID: Erik, Volker, On Tue, Sep 5, 2017 at 7:31 PM, Erik Joelsson wrote: > > > On 2017-09-05 11:38, Volker Simonis wrote: > >> Hi Joe, >> >> generally looks good! >> >> I don't know if this has discussed before, but in my opinion the >> top-level src/ directory looks a little overloaded. Wouldn't it make >> sense to place all the modules into their own 'src/modules/' >> subdirectory? >> > I see what you mean, but it's no more overloaded than the jdk/src dir used > to be. Also, the bsd, linux, solaris, demo and sample directories are all > going away at some point in the (hopefully near) future. Left are hotspot > and utils which I don't think warrant another directory level. > >> Should jdk10/consol-proto build out of t he box or are there any known >> issues? I'd like to give it a tray on AIX and Linux/ppc64 but if there >> are any known, generic problems I'll wait until they get fixed. >> > Yes, please try it. I have put a lot of work into maintaining a set of > patches and scripts to keep the generated consolidated repo working and > (near) equivalent with the current forest. You can review those changes in > the prototype forest if you like. > > I cloned http://hg.openjdk.java.net/jdk10/consol-proto and built AIX. Build runs fine. However, I found cloning the repository painfully slow. On my Linux box clone took ~90 minutes. On Windows, I could not successfully clone, as cygwin mercurial did hit timeouts. I really hope this is only temporary and will improve? Kind Regards, Thomas > /Erik > > >> Thank you and best regards, >> Volker >> >> >> On Fri, Sep 1, 2017 at 8:36 PM, joe darcy wrote: >> >>> On 8/25/2017 1:52 PM, joe darcy wrote: >>> >>>> Hello, >>>> >>>> A follow-up to the most recent update [1] on the JDK 10 repo >>>> consolidation >>>> efforts, September 2017 is almost upon us and that month remains the >>>> target >>>> to implement the repo consolidation. >>>> >>>> First, a third generation prototype having tags from both JDK 9 and JDK >>>> 10 >>>> will be published in the near future. >>>> >>>> [snip] >>> >>> Third generation prototype with tags from JDK 9 and JDK 10 available for >>> browsing at: >>> >>> http://hg.openjdk.java.net/jdk10/consol-proto/tags >>> >>> Please sent comments by Wednesday, September 6. >>> >>> Thanks, >>> >>> -Joe >>> >> > From volker.simonis at gmail.com Wed Sep 6 15:35:32 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 6 Sep 2017 17:35:32 +0200 Subject: Update on JDK 10 repo consolidation; third generation prototype published at http://hg.openjdk.java.net/jdk10/consol-proto In-Reply-To: References: <6ed232d7-7b84-b1b9-93e0-971678251563@oracle.com> <1f3fc74a-cc37-fdf0-91e5-20a3394f981e@oracle.com> Message-ID: On Wed, Sep 6, 2017 at 2:30 PM, Thomas St?fe wrote: > Erik, Volker, > > On Tue, Sep 5, 2017 at 7:31 PM, Erik Joelsson > wrote: >> >> >> >> On 2017-09-05 11:38, Volker Simonis wrote: >>> >>> Hi Joe, >>> >>> generally looks good! >>> >>> I don't know if this has discussed before, but in my opinion the >>> top-level src/ directory looks a little overloaded. Wouldn't it make >>> sense to place all the modules into their own 'src/modules/' >>> subdirectory? >> >> I see what you mean, but it's no more overloaded than the jdk/src dir used >> to be. Also, the bsd, linux, solaris, demo and sample directories are all >> going away at some point in the (hopefully near) future. Left are hotspot >> and utils which I don't think warrant another directory level. >>> >>> Should jdk10/consol-proto build out of t he box or are there any known >>> issues? I'd like to give it a tray on AIX and Linux/ppc64 but if there >>> are any known, generic problems I'll wait until they get fixed. >> >> Yes, please try it. I have put a lot of work into maintaining a set of >> patches and scripts to keep the generated consolidated repo working and >> (near) equivalent with the current forest. You can review those changes in >> the prototype forest if you like. >> > > I cloned http://hg.openjdk.java.net/jdk10/consol-proto and built AIX. Build > runs fine. > Hi Thomas, thanks for checking the AIX build. > However, I found cloning the repository painfully slow. > > On my Linux box clone took ~90 minutes. On Windows, I could not successfully > clone, as cygwin mercurial did hit timeouts. I really hope this is only > temporary and will improve? > I think you should ask your company and/or Internet provider :) The new, consolidated repository is about 1.6GB in size (i.e. the size of .hg) and the cloning speed is actually pretty much proportional to the time you need to download this amount of data. When using our http-proxy I measured a download speed of about 350 KB/s. The calculation is quite simple: 1600000 KB / 350 KB/s = 4571 s / 60 = 76 min :( The actual cloning speed was slightly faster: $ time hg clone http://hg.openjdk.java.net/jdk10/consol-proto jdk10-cons-proto requesting all changes adding changesets adding manifests adding file changes added 46937 changesets with 397578 changes to 162338 files updating to branch default 57067 files updated, 0 files merged, 0 files removed, 0 files unresolved real 38m37.424s user 5m46.620s sys 0m33.976s which is probably because the 1.6 GB from the .hg repo may be compressed for the transport. Without proxy (i.e. 'transparent proxy') the average download speed is about 150 KB/s. I think this pretty much explains the ~90 minutes. I doubt that these poor download speeds are caused by hg.openjdk.java.net because then it would be the same for the proxy vs. non-proxy case. Nevertheless it would be interesting to see what amount of data hg.openjdk.java.net can actually serve to Europe. So if somebody with a decent Internet connection can share his experience, that would be interesting. Regards, Volker > Kind Regards, Thomas > > >> >> /Erik >> >>> >>> Thank you and best regards, >>> Volker >>> >>> >>> On Fri, Sep 1, 2017 at 8:36 PM, joe darcy wrote: >>>> >>>> On 8/25/2017 1:52 PM, joe darcy wrote: >>>>> >>>>> Hello, >>>>> >>>>> A follow-up to the most recent update [1] on the JDK 10 repo >>>>> consolidation >>>>> efforts, September 2017 is almost upon us and that month remains the >>>>> target >>>>> to implement the repo consolidation. >>>>> >>>>> First, a third generation prototype having tags from both JDK 9 and JDK >>>>> 10 >>>>> will be published in the near future. >>>>> >>>> [snip] >>>> >>>> Third generation prototype with tags from JDK 9 and JDK 10 available for >>>> browsing at: >>>> >>>> http://hg.openjdk.java.net/jdk10/consol-proto/tags >>>> >>>> Please sent comments by Wednesday, September 6. >>>> >>>> Thanks, >>>> >>>> -Joe >> >> > From thomas.stuefe at gmail.com Thu Sep 7 05:06:32 2017 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 7 Sep 2017 07:06:32 +0200 Subject: Update on JDK 10 repo consolidation; third generation prototype published at http://hg.openjdk.java.net/jdk10/consol-proto In-Reply-To: References: <6ed232d7-7b84-b1b9-93e0-971678251563@oracle.com> <1f3fc74a-cc37-fdf0-91e5-20a3394f981e@oracle.com> Message-ID: On Wed, Sep 6, 2017 at 5:35 PM, Volker Simonis wrote: > On Wed, Sep 6, 2017 at 2:30 PM, Thomas St?fe > wrote: > > Erik, Volker, > > > > On Tue, Sep 5, 2017 at 7:31 PM, Erik Joelsson > > wrote: > >> > >> > >> > >> On 2017-09-05 11:38, Volker Simonis wrote: > >>> > >>> Hi Joe, > >>> > >>> generally looks good! > >>> > >>> I don't know if this has discussed before, but in my opinion the > >>> top-level src/ directory looks a little overloaded. Wouldn't it make > >>> sense to place all the modules into their own 'src/modules/' > >>> subdirectory? > >> > >> I see what you mean, but it's no more overloaded than the jdk/src dir > used > >> to be. Also, the bsd, linux, solaris, demo and sample directories are > all > >> going away at some point in the (hopefully near) future. Left are > hotspot > >> and utils which I don't think warrant another directory level. > >>> > >>> Should jdk10/consol-proto build out of t he box or are there any known > >>> issues? I'd like to give it a tray on AIX and Linux/ppc64 but if there > >>> are any known, generic problems I'll wait until they get fixed. > >> > >> Yes, please try it. I have put a lot of work into maintaining a set of > >> patches and scripts to keep the generated consolidated repo working and > >> (near) equivalent with the current forest. You can review those changes > in > >> the prototype forest if you like. > >> > > > > I cloned http://hg.openjdk.java.net/jdk10/consol-proto and built AIX. > Build > > runs fine. > > > > Hi Thomas, > > thanks for checking the AIX build. > > > However, I found cloning the repository painfully slow. > > > > On my Linux box clone took ~90 minutes. On Windows, I could not > successfully > > clone, as cygwin mercurial did hit timeouts. I really hope this is only > > temporary and will improve? > > > > I think you should ask your company and/or Internet provider :) > > The new, consolidated repository is about 1.6GB in size (i.e. the size > of .hg) and the cloning speed is actually pretty much proportional to > the time you need to download this amount of data. > > When using our http-proxy I measured a download speed of about 350 > KB/s. The calculation is quite simple: > > 1600000 KB / 350 KB/s = 4571 s / 60 = 76 min :( > > The actual cloning speed was slightly faster: > > $ time hg clone http://hg.openjdk.java.net/jdk10/consol-proto > jdk10-cons-proto > requesting all changes > adding changesets > adding manifests > adding file changes > added 46937 changesets with 397578 changes to 162338 files > updating to branch default > 57067 files updated, 0 files merged, 0 files removed, 0 files > unresolved > > real 38m37.424s > user 5m46.620s > sys 0m33.976s > > which is probably because the 1.6 GB from the .hg repo may be > compressed for the transport. > > Without proxy (i.e. 'transparent proxy') the average download speed is > about 150 KB/s. I think this pretty much explains the ~90 minutes. > > I doubt that these poor download speeds are caused by > hg.openjdk.java.net because then it would be the same for the proxy > vs. non-proxy case. Nevertheless it would be interesting to see what > amount of data hg.openjdk.java.net can actually serve to Europe. So if > somebody with a decent Internet connection can share his experience, > that would be interesting. > > I'm on cable, with a download speed of 128Mbit. Cloning the new repo still took 39min. That was on Linux, with SSDs. Best Regards, Thomas > Regards, > Volker > > > Kind Regards, Thomas > > > > > >> > >> /Erik > >> > >>> > >>> Thank you and best regards, > >>> Volker > >>> > >>> > >>> On Fri, Sep 1, 2017 at 8:36 PM, joe darcy > wrote: > >>>> > >>>> On 8/25/2017 1:52 PM, joe darcy wrote: > >>>>> > >>>>> Hello, > >>>>> > >>>>> A follow-up to the most recent update [1] on the JDK 10 repo > >>>>> consolidation > >>>>> efforts, September 2017 is almost upon us and that month remains the > >>>>> target > >>>>> to implement the repo consolidation. > >>>>> > >>>>> First, a third generation prototype having tags from both JDK 9 and > JDK > >>>>> 10 > >>>>> will be published in the near future. > >>>>> > >>>> [snip] > >>>> > >>>> Third generation prototype with tags from JDK 9 and JDK 10 available > for > >>>> browsing at: > >>>> > >>>> http://hg.openjdk.java.net/jdk10/consol-proto/tags > >>>> > >>>> Please sent comments by Wednesday, September 6. > >>>> > >>>> Thanks, > >>>> > >>>> -Joe > >> > >> > > > From doug.simon at oracle.com Thu Sep 7 08:07:59 2017 From: doug.simon at oracle.com (Doug Simon) Date: Thu, 7 Sep 2017 10:07:59 +0200 Subject: Update on JDK 10 repo consolidation; third generation prototype published at http://hg.openjdk.java.net/jdk10/consol-proto In-Reply-To: References: <6ed232d7-7b84-b1b9-93e0-971678251563@oracle.com> <1f3fc74a-cc37-fdf0-91e5-20a3394f981e@oracle.com> Message-ID: > On 7 Sep 2017, at 07:06, Thomas St?fe wrote: > > On Wed, Sep 6, 2017 at 5:35 PM, Volker Simonis > wrote: > >> On Wed, Sep 6, 2017 at 2:30 PM, Thomas St?fe >> wrote: >>> Erik, Volker, >>> >>> On Tue, Sep 5, 2017 at 7:31 PM, Erik Joelsson >>> wrote: >>>> >>>> >>>> >>>> On 2017-09-05 11:38, Volker Simonis wrote: >>>>> >>>>> Hi Joe, >>>>> >>>>> generally looks good! >>>>> >>>>> I don't know if this has discussed before, but in my opinion the >>>>> top-level src/ directory looks a little overloaded. Wouldn't it make >>>>> sense to place all the modules into their own 'src/modules/' >>>>> subdirectory? >>>> >>>> I see what you mean, but it's no more overloaded than the jdk/src dir >> used >>>> to be. Also, the bsd, linux, solaris, demo and sample directories are >> all >>>> going away at some point in the (hopefully near) future. Left are >> hotspot >>>> and utils which I don't think warrant another directory level. >>>>> >>>>> Should jdk10/consol-proto build out of t he box or are there any known >>>>> issues? I'd like to give it a tray on AIX and Linux/ppc64 but if there >>>>> are any known, generic problems I'll wait until they get fixed. >>>> >>>> Yes, please try it. I have put a lot of work into maintaining a set of >>>> patches and scripts to keep the generated consolidated repo working and >>>> (near) equivalent with the current forest. You can review those changes >> in >>>> the prototype forest if you like. >>>> >>> >>> I cloned http://hg.openjdk.java.net/jdk10/consol-proto and built AIX. >> Build >>> runs fine. >>> >> >> Hi Thomas, >> >> thanks for checking the AIX build. >> >>> However, I found cloning the repository painfully slow. >>> >>> On my Linux box clone took ~90 minutes. On Windows, I could not >> successfully >>> clone, as cygwin mercurial did hit timeouts. I really hope this is only >>> temporary and will improve? >>> >> >> I think you should ask your company and/or Internet provider :) >> >> The new, consolidated repository is about 1.6GB in size (i.e. the size >> of .hg) and the cloning speed is actually pretty much proportional to >> the time you need to download this amount of data. >> >> When using our http-proxy I measured a download speed of about 350 >> KB/s. The calculation is quite simple: >> >> 1600000 KB / 350 KB/s = 4571 s / 60 = 76 min :( >> >> The actual cloning speed was slightly faster: >> >> $ time hg clone http://hg.openjdk.java.net/jdk10/consol-proto >> jdk10-cons-proto >> requesting all changes >> adding changesets >> adding manifests >> adding file changes >> added 46937 changesets with 397578 changes to 162338 files >> updating to branch default >> 57067 files updated, 0 files merged, 0 files removed, 0 files >> unresolved >> >> real 38m37.424s >> user 5m46.620s >> sys 0m33.976s >> >> which is probably because the 1.6 GB from the .hg repo may be >> compressed for the transport. >> >> Without proxy (i.e. 'transparent proxy') the average download speed is >> about 150 KB/s. I think this pretty much explains the ~90 minutes. >> >> I doubt that these poor download speeds are caused by >> hg.openjdk.java.net because then it would be the same for the proxy >> vs. non-proxy case. Nevertheless it would be interesting to see what >> amount of data hg.openjdk.java.net can actually serve to Europe. So if >> somebody with a decent Internet connection can share his experience, >> that would be interesting. >> >> > I'm on cable, with a download speed of 128Mbit. Cloning the new repo still > took 39min. That was on Linux, with SSDs. I'm in Switzerland, get 85Mbps according to fast.com and it took 42min to clone the new repo. -Doug > > Best Regards, Thomas > > >> Regards, >> Volker >> >>> Kind Regards, Thomas >>> >>> >>>> >>>> /Erik >>>> >>>>> >>>>> Thank you and best regards, >>>>> Volker >>>>> >>>>> >>>>> On Fri, Sep 1, 2017 at 8:36 PM, joe darcy >> wrote: >>>>>> >>>>>> On 8/25/2017 1:52 PM, joe darcy wrote: >>>>>>> >>>>>>> Hello, >>>>>>> >>>>>>> A follow-up to the most recent update [1] on the JDK 10 repo >>>>>>> consolidation >>>>>>> efforts, September 2017 is almost upon us and that month remains the >>>>>>> target >>>>>>> to implement the repo consolidation. >>>>>>> >>>>>>> First, a third generation prototype having tags from both JDK 9 and >> JDK >>>>>>> 10 >>>>>>> will be published in the near future. >>>>>>> >>>>>> [snip] >>>>>> >>>>>> Third generation prototype with tags from JDK 9 and JDK 10 available >> for >>>>>> browsing at: >>>>>> >>>>>> http://hg.openjdk.java.net/jdk10/consol-proto/tags >>>>>> >>>>>> Please sent comments by Wednesday, September 6. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> -Joe From volker.simonis at gmail.com Thu Sep 7 10:23:56 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 7 Sep 2017 12:23:56 +0200 Subject: Update on JDK 10 repo consolidation; third generation prototype published at http://hg.openjdk.java.net/jdk10/consol-proto In-Reply-To: References: <6ed232d7-7b84-b1b9-93e0-971678251563@oracle.com> <1f3fc74a-cc37-fdf0-91e5-20a3394f981e@oracle.com> Message-ID: Yes, I can also confirm Thomas' numbers. Tried from home on my 25Mbps line with both company/private PC and couldn't get more than 350KB download speed during cloning. I've also tested a traditional repository with the get_source.sh script. By default the script uses a concurrency of two (i.e. it always processes two repositories of the forest in parallel). This obviously starts two hg processes at a time and it seems that both of them can use up to 350KB during downloading. This gets the cloning time down to 12m (compared to 38m for the new, fat consolidated repository). The concurrency of get_source.sh can be increased by setting HGFOREST_CONCURRENCY. If I set this to 8 the cloning time only drops down to 11 minutes because it is bound by the time it takes to clone the jdk repository which is by far the biggest one. So it really seems that the hg.openjdk.java.net limits the download speed per connection. Before, with the forest, this was not so much of an issue, because cloning was done in parallel for each forest, but now, with the new, single, fat, consolidated repository, this becomes a real bottleneck. Can somebody from Oracle and/or the hg.openjdk.java.net operations team please comment on this and ideally fix it? Thank you and best regards, Volker On Thu, Sep 7, 2017 at 10:07 AM, Doug Simon wrote: > >> On 7 Sep 2017, at 07:06, Thomas St?fe wrote: >> >> On Wed, Sep 6, 2017 at 5:35 PM, Volker Simonis >> wrote: >> >>> On Wed, Sep 6, 2017 at 2:30 PM, Thomas St?fe >>> wrote: >>>> Erik, Volker, >>>> >>>> On Tue, Sep 5, 2017 at 7:31 PM, Erik Joelsson >>>> wrote: >>>>> >>>>> >>>>> >>>>> On 2017-09-05 11:38, Volker Simonis wrote: >>>>>> >>>>>> Hi Joe, >>>>>> >>>>>> generally looks good! >>>>>> >>>>>> I don't know if this has discussed before, but in my opinion the >>>>>> top-level src/ directory looks a little overloaded. Wouldn't it make >>>>>> sense to place all the modules into their own 'src/modules/' >>>>>> subdirectory? >>>>> >>>>> I see what you mean, but it's no more overloaded than the jdk/src dir >>> used >>>>> to be. Also, the bsd, linux, solaris, demo and sample directories are >>> all >>>>> going away at some point in the (hopefully near) future. Left are >>> hotspot >>>>> and utils which I don't think warrant another directory level. >>>>>> >>>>>> Should jdk10/consol-proto build out of t he box or are there any known >>>>>> issues? I'd like to give it a tray on AIX and Linux/ppc64 but if there >>>>>> are any known, generic problems I'll wait until they get fixed. >>>>> >>>>> Yes, please try it. I have put a lot of work into maintaining a set of >>>>> patches and scripts to keep the generated consolidated repo working and >>>>> (near) equivalent with the current forest. You can review those changes >>> in >>>>> the prototype forest if you like. >>>>> >>>> >>>> I cloned http://hg.openjdk.java.net/jdk10/consol-proto and built AIX. >>> Build >>>> runs fine. >>>> >>> >>> Hi Thomas, >>> >>> thanks for checking the AIX build. >>> >>>> However, I found cloning the repository painfully slow. >>>> >>>> On my Linux box clone took ~90 minutes. On Windows, I could not >>> successfully >>>> clone, as cygwin mercurial did hit timeouts. I really hope this is only >>>> temporary and will improve? >>>> >>> >>> I think you should ask your company and/or Internet provider :) >>> >>> The new, consolidated repository is about 1.6GB in size (i.e. the size >>> of .hg) and the cloning speed is actually pretty much proportional to >>> the time you need to download this amount of data. >>> >>> When using our http-proxy I measured a download speed of about 350 >>> KB/s. The calculation is quite simple: >>> >>> 1600000 KB / 350 KB/s = 4571 s / 60 = 76 min :( >>> >>> The actual cloning speed was slightly faster: >>> >>> $ time hg clone http://hg.openjdk.java.net/jdk10/consol-proto >>> jdk10-cons-proto >>> requesting all changes >>> adding changesets >>> adding manifests >>> adding file changes >>> added 46937 changesets with 397578 changes to 162338 files >>> updating to branch default >>> 57067 files updated, 0 files merged, 0 files removed, 0 files >>> unresolved >>> >>> real 38m37.424s >>> user 5m46.620s >>> sys 0m33.976s >>> >>> which is probably because the 1.6 GB from the .hg repo may be >>> compressed for the transport. >>> >>> Without proxy (i.e. 'transparent proxy') the average download speed is >>> about 150 KB/s. I think this pretty much explains the ~90 minutes. >>> >>> I doubt that these poor download speeds are caused by >>> hg.openjdk.java.net because then it would be the same for the proxy >>> vs. non-proxy case. Nevertheless it would be interesting to see what >>> amount of data hg.openjdk.java.net can actually serve to Europe. So if >>> somebody with a decent Internet connection can share his experience, >>> that would be interesting. >>> >>> >> I'm on cable, with a download speed of 128Mbit. Cloning the new repo still >> took 39min. That was on Linux, with SSDs. > > I'm in Switzerland, get 85Mbps according to fast.com and it took 42min to clone the new repo. > > -Doug > >> >> Best Regards, Thomas >> >> >>> Regards, >>> Volker >>> >>>> Kind Regards, Thomas >>>> >>>> >>>>> >>>>> /Erik >>>>> >>>>>> >>>>>> Thank you and best regards, >>>>>> Volker >>>>>> >>>>>> >>>>>> On Fri, Sep 1, 2017 at 8:36 PM, joe darcy >>> wrote: >>>>>>> >>>>>>> On 8/25/2017 1:52 PM, joe darcy wrote: >>>>>>>> >>>>>>>> Hello, >>>>>>>> >>>>>>>> A follow-up to the most recent update [1] on the JDK 10 repo >>>>>>>> consolidation >>>>>>>> efforts, September 2017 is almost upon us and that month remains the >>>>>>>> target >>>>>>>> to implement the repo consolidation. >>>>>>>> >>>>>>>> First, a third generation prototype having tags from both JDK 9 and >>> JDK >>>>>>>> 10 >>>>>>>> will be published in the near future. >>>>>>>> >>>>>>> [snip] >>>>>>> >>>>>>> Third generation prototype with tags from JDK 9 and JDK 10 available >>> for >>>>>>> browsing at: >>>>>>> >>>>>>> http://hg.openjdk.java.net/jdk10/consol-proto/tags >>>>>>> >>>>>>> Please sent comments by Wednesday, September 6. >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> -Joe > From erik.joelsson at oracle.com Thu Sep 7 11:17:54 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 7 Sep 2017 13:17:54 +0200 Subject: Update on JDK 10 repo consolidation; third generation prototype coming soon, September 2017 still the target In-Reply-To: References: <6ed232d7-7b84-b1b9-93e0-971678251563@oracle.com> <05cefb5a-0435-bec9-cccf-77cfb49eaf51@oracle.com> <6cae530e-bbf1-2a1c-b6c5-e1dbb114e4eb@oracle.com> <7804BC61-DF90-4BB2-881B-AEA872F83FED@oracle.com> <9b4f505b-4228-032c-2469-4bd565b89aaf@oracle.com> <436D2AA4-3C47-431B-826B-5070F09F7DC1@oracle.com> Message-ID: On 2017-09-06 08:40, joe darcy wrote: > > On 9/5/2017 7:02 PM, Weijun Wang wrote: >> So there is no plan to deal with multiple ProblemList.txt files and >> groups defined in multiple TEST.groups? >> >> > > It is possible that at least some of the ProblemList.txt and > TEST.groups and TEST.ROOT files will get combined at some point, but > that is not essential for the consolidation and will not happen before > the consolidation goes live. > I believe we should combine the TEST.ROOT and TEST.groups files, but doing that change at the same time with the rest of the consolidation was simply too much so I opted not to. We have every opportunity to continue to improve things after the consolidation is done, and such a change is much more easily done separately. Regarding flattening the test directory structure, again, some of them may make sense to combine while others may not. Again I think this is best done separately and on a case by case basis. /Erik > Cheers, > > -Joe From erik.joelsson at oracle.com Thu Sep 7 12:49:35 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 7 Sep 2017 14:49:35 +0200 Subject: Update on JDK 10 repo consolidation; third generation prototype coming soon, September 2017 still the target In-Reply-To: References: <6ed232d7-7b84-b1b9-93e0-971678251563@oracle.com> <05cefb5a-0435-bec9-cccf-77cfb49eaf51@oracle.com> <6cae530e-bbf1-2a1c-b6c5-e1dbb114e4eb@oracle.com> Message-ID: On 2017-09-01 04:00, joe darcy wrote: > >> Any tools for making this migration easier? I personally have 6 >> clones I'd need to migrate. > > One of the infra-related items planned to be worked on is a patch > conversion script analogous to (and perhaps sharing implementation > with) the shuffle script used for the Jigsaw changes. I have now pushed a first attempt at such a tool to the consol-proto repository. I re-purposed the unshuffle_patch.sh script from the Jigsaw code shuffle. It supports converting patches in both directions (9->10 and 10->9). When going to 9, it will automatically split patches for each target repo encountered. Please try it out. Suggestions and improvements are welcome. It would be nice if we could have a reasonably good version of this ready when the consolidated repo goes live. /Erik From gerard.ziemski at oracle.com Thu Sep 7 18:55:27 2017 From: gerard.ziemski at oracle.com (Gerard Ziemski) Date: Thu, 7 Sep 2017 13:55:27 -0500 Subject: Update on JDK 10 repo consolidation; third generation prototype coming soon, September 2017 still the target In-Reply-To: References: <6ed232d7-7b84-b1b9-93e0-971678251563@oracle.com> <05cefb5a-0435-bec9-cccf-77cfb49eaf51@oracle.com> <6cae530e-bbf1-2a1c-b6c5-e1dbb114e4eb@oracle.com> Message-ID: <7ABD4426-E607-4D4F-AC8C-FA257AE17DC5@oracle.com> hi Joe, > On Aug 31, 2017, at 9:00 PM, joe darcy wrote: > >> >> How do the project repos move across to the new consolidated form? Will we lose all the changeset history? >> > > I recommend project forests sync up with the last pre-consolidated JDK 10, extract the patches from the changesets, and then reapply the changesets to a new consolidated baseline of the project forest. A quick follow-up: you did not answer David?s question on preserving the files? history - is it going to be preserved? cheers From joe.darcy at oracle.com Thu Sep 7 19:05:57 2017 From: joe.darcy at oracle.com (joe darcy) Date: Thu, 7 Sep 2017 12:05:57 -0700 Subject: Update on JDK 10 repo consolidation; third generation prototype coming soon, September 2017 still the target In-Reply-To: <7ABD4426-E607-4D4F-AC8C-FA257AE17DC5@oracle.com> References: <6ed232d7-7b84-b1b9-93e0-971678251563@oracle.com> <05cefb5a-0435-bec9-cccf-77cfb49eaf51@oracle.com> <6cae530e-bbf1-2a1c-b6c5-e1dbb114e4eb@oracle.com> <7ABD4426-E607-4D4F-AC8C-FA257AE17DC5@oracle.com> Message-ID: Hello Gerard, On 9/7/2017 11:55 AM, Gerard Ziemski wrote: > hi Joe, > >> On Aug 31, 2017, at 9:00 PM, joe darcy wrote: >> >>> How do the project repos move across to the new consolidated form? Will we lose all the changeset history? >>> >> I recommend project forests sync up with the last pre-consolidated JDK 10, extract the patches from the changesets, and then reapply the changesets to a new consolidated baseline of the project forest. > A quick follow-up: you did not answer David?s question on preserving the files? history - is it going to be preserved? > Whether or not history is replicated on a per-file level will depend on how the teams using the project forests move their work over. If the work is moved as one huge patch, the history will not be preserved. If each changeset is isolated, converted to the new paths structure, and then applied again, the history would be replicated (modulo complications from merges). (It is not possible to run the conversion script on the project repos and then have them pull from the consolidated master.) HTH, -Joe From magnus.ihse.bursie at oracle.com Fri Sep 8 11:43:34 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 8 Sep 2017 13:43:34 +0200 Subject: Update on JDK 10 repo consolidation; third generation prototype published at http://hg.openjdk.java.net/jdk10/consol-proto In-Reply-To: References: <6ed232d7-7b84-b1b9-93e0-971678251563@oracle.com> <1f3fc74a-cc37-fdf0-91e5-20a3394f981e@oracle.com> Message-ID: <9ce3e813-9954-f68d-ba92-e2e45ac3ebd3@oracle.com> As a comparison, FWIW, I tested with my computer at home (nominally 250 Mbit/s). I cloned the consolidated repo in ~33 minutes, which corresponds to an average speed of 800 kB/s or rougly 6 Mbit/s), given that all that time was spent transmitting data (and that I've done the calculations right). That sounds like a transfer rate that's close to what I'd expect of an arbitrary, non-speed-optimized, service on the Internet in general. (On the other hand, one might argue that one would expect more of a service like hg.openjdk.java.net.) /Magnus On 2017-09-07 12:23, Volker Simonis wrote: > Yes, I can also confirm Thomas' numbers. Tried from home on my 25Mbps > line with both company/private PC and couldn't get more than 350KB > download speed during cloning. > > I've also tested a traditional repository with the get_source.sh > script. By default the script uses a concurrency of two (i.e. it > always processes two repositories of the forest in parallel). This > obviously starts two hg processes at a time and it seems that both of > them can use up to 350KB during downloading. This gets the cloning > time down to 12m (compared to 38m for the new, fat consolidated > repository). > > The concurrency of get_source.sh can be increased by setting > HGFOREST_CONCURRENCY. If I set this to 8 the cloning time only drops > down to 11 minutes because it is bound by the time it takes to clone > the jdk repository which is by far the biggest one. > > So it really seems that the hg.openjdk.java.net limits the download > speed per connection. Before, with the forest, this was not so much of > an issue, because cloning was done in parallel for each forest, but > now, with the new, single, fat, consolidated repository, this becomes > a real bottleneck. > > Can somebody from Oracle and/or the hg.openjdk.java.net operations > team please comment on this and ideally fix it? > > Thank you and best regards, > Volker > > > On Thu, Sep 7, 2017 at 10:07 AM, Doug Simon wrote: >>> On 7 Sep 2017, at 07:06, Thomas St?fe wrote: >>> >>> On Wed, Sep 6, 2017 at 5:35 PM, Volker Simonis >>> wrote: >>> >>>> On Wed, Sep 6, 2017 at 2:30 PM, Thomas St?fe >>>> wrote: >>>>> Erik, Volker, >>>>> >>>>> On Tue, Sep 5, 2017 at 7:31 PM, Erik Joelsson >>>>> wrote: >>>>>> >>>>>> >>>>>> On 2017-09-05 11:38, Volker Simonis wrote: >>>>>>> Hi Joe, >>>>>>> >>>>>>> generally looks good! >>>>>>> >>>>>>> I don't know if this has discussed before, but in my opinion the >>>>>>> top-level src/ directory looks a little overloaded. Wouldn't it make >>>>>>> sense to place all the modules into their own 'src/modules/' >>>>>>> subdirectory? >>>>>> I see what you mean, but it's no more overloaded than the jdk/src dir >>>> used >>>>>> to be. Also, the bsd, linux, solaris, demo and sample directories are >>>> all >>>>>> going away at some point in the (hopefully near) future. Left are >>>> hotspot >>>>>> and utils which I don't think warrant another directory level. >>>>>>> Should jdk10/consol-proto build out of t he box or are there any known >>>>>>> issues? I'd like to give it a tray on AIX and Linux/ppc64 but if there >>>>>>> are any known, generic problems I'll wait until they get fixed. >>>>>> Yes, please try it. I have put a lot of work into maintaining a set of >>>>>> patches and scripts to keep the generated consolidated repo working and >>>>>> (near) equivalent with the current forest. You can review those changes >>>> in >>>>>> the prototype forest if you like. >>>>>> >>>>> I cloned http://hg.openjdk.java.net/jdk10/consol-proto and built AIX. >>>> Build >>>>> runs fine. >>>>> >>>> Hi Thomas, >>>> >>>> thanks for checking the AIX build. >>>> >>>>> However, I found cloning the repository painfully slow. >>>>> >>>>> On my Linux box clone took ~90 minutes. On Windows, I could not >>>> successfully >>>>> clone, as cygwin mercurial did hit timeouts. I really hope this is only >>>>> temporary and will improve? >>>>> >>>> I think you should ask your company and/or Internet provider :) >>>> >>>> The new, consolidated repository is about 1.6GB in size (i.e. the size >>>> of .hg) and the cloning speed is actually pretty much proportional to >>>> the time you need to download this amount of data. >>>> >>>> When using our http-proxy I measured a download speed of about 350 >>>> KB/s. The calculation is quite simple: >>>> >>>> 1600000 KB / 350 KB/s = 4571 s / 60 = 76 min :( >>>> >>>> The actual cloning speed was slightly faster: >>>> >>>> $ time hg clone http://hg.openjdk.java.net/jdk10/consol-proto >>>> jdk10-cons-proto >>>> requesting all changes >>>> adding changesets >>>> adding manifests >>>> adding file changes >>>> added 46937 changesets with 397578 changes to 162338 files >>>> updating to branch default >>>> 57067 files updated, 0 files merged, 0 files removed, 0 files >>>> unresolved >>>> >>>> real 38m37.424s >>>> user 5m46.620s >>>> sys 0m33.976s >>>> >>>> which is probably because the 1.6 GB from the .hg repo may be >>>> compressed for the transport. >>>> >>>> Without proxy (i.e. 'transparent proxy') the average download speed is >>>> about 150 KB/s. I think this pretty much explains the ~90 minutes. >>>> >>>> I doubt that these poor download speeds are caused by >>>> hg.openjdk.java.net because then it would be the same for the proxy >>>> vs. non-proxy case. Nevertheless it would be interesting to see what >>>> amount of data hg.openjdk.java.net can actually serve to Europe. So if >>>> somebody with a decent Internet connection can share his experience, >>>> that would be interesting. >>>> >>>> >>> I'm on cable, with a download speed of 128Mbit. Cloning the new repo still >>> took 39min. That was on Linux, with SSDs. >> I'm in Switzerland, get 85Mbps according to fast.com and it took 42min to clone the new repo. >> >> -Doug >> >>> Best Regards, Thomas >>> >>> >>>> Regards, >>>> Volker >>>> >>>>> Kind Regards, Thomas >>>>> >>>>> >>>>>> /Erik >>>>>> >>>>>>> Thank you and best regards, >>>>>>> Volker >>>>>>> >>>>>>> >>>>>>> On Fri, Sep 1, 2017 at 8:36 PM, joe darcy >>>> wrote: >>>>>>>> On 8/25/2017 1:52 PM, joe darcy wrote: >>>>>>>>> Hello, >>>>>>>>> >>>>>>>>> A follow-up to the most recent update [1] on the JDK 10 repo >>>>>>>>> consolidation >>>>>>>>> efforts, September 2017 is almost upon us and that month remains the >>>>>>>>> target >>>>>>>>> to implement the repo consolidation. >>>>>>>>> >>>>>>>>> First, a third generation prototype having tags from both JDK 9 and >>>> JDK >>>>>>>>> 10 >>>>>>>>> will be published in the near future. >>>>>>>>> >>>>>>>> [snip] >>>>>>>> >>>>>>>> Third generation prototype with tags from JDK 9 and JDK 10 available >>>> for >>>>>>>> browsing at: >>>>>>>> >>>>>>>> http://hg.openjdk.java.net/jdk10/consol-proto/tags >>>>>>>> >>>>>>>> Please sent comments by Wednesday, September 6. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> -Joe From joe.darcy at oracle.com Mon Sep 11 15:45:29 2017 From: joe.darcy at oracle.com (joe darcy) Date: Mon, 11 Sep 2017 08:45:29 -0700 Subject: Repo consolidation update: JDK 10 b23 tagged Message-ID: <2b5ce3ba-5f8f-d884-64fe-ee144763a27e@oracle.com> Hello, The last pre-consolidation state of the jdk10/jdk10 forest, build 23, has been tagged. This will serve as the seed for the consolidation repo to be hosted as jdk10/master. Both the client and hotspot integration forests have synced down the contents of JDK 10 build 23 from jdk10/jdk10 master forest. Pull from any of these forests to get an up to date version of the JDK sources into your local JDK 10 clones. As previously announced [1], an initial script is available to help port patches across the consolidation boundary. We're investigation some possible updates to the OpenJDK Mercurial server to improve performance and disk usage of the consolidated repo. The contents at jdk10/master will likely be populated before we're ready to reopen the repo to pushes. Cheers, -Joe [1] http://mail.openjdk.java.net/pipermail/jdk10-dev/2017-September/000482.html From calvin.cheung at oracle.com Tue Sep 12 22:14:08 2017 From: calvin.cheung at oracle.com (Calvin Cheung) Date: Tue, 12 Sep 2017 15:14:08 -0700 Subject: RFR(S): 8138600: eliminate the need of ModuleLoaderMap.dat for CDS Message-ID: <59B85C30.1000108@oracle.com> With the fix for JDK-8186842 , we no longer need the ModuleLoaderMap to determine the loader type of a class during CDS dump time. This change is for removing the ModuleLoaderMap from the runtime image and the code which references it. bug: https://bugs.openjdk.java.net/browse/JDK-8138600 webrevs: http://cr.openjdk.java.net/~ccheung/8138600/jdk/webrev.00/ http://cr.openjdk.java.net/~ccheung/8138600/hotspot/webrev.00/ Testing: JPRT CDS tests hs-tier3 thanks, Calvin From jiangli.zhou at Oracle.COM Tue Sep 12 22:53:15 2017 From: jiangli.zhou at Oracle.COM (Jiangli Zhou) Date: Tue, 12 Sep 2017 15:53:15 -0700 Subject: RFR(S): 8138600: eliminate the need of ModuleLoaderMap.dat for CDS In-Reply-To: <59B85C30.1000108@oracle.com> References: <59B85C30.1000108@oracle.com> Message-ID: <45691800-61C9-4117-BEFB-993D0159DB33@oracle.com> Hi Calvin, Glad to see those code being eliminated. Please also remove the following in classLoader.hpp. These macros were only used by the module loader map related code. 43 // Initial sizes of the following arrays are based on the generated ModuleLoaderMap.dat 44 #define INITIAL_BOOT_MODULES_ARRAY_SIZE 30 45 #define INITIAL_PLATFORM_MODULES_ARRAY_SIZE 15 Thanks, Jiangli > On Sep 12, 2017, at 3:14 PM, Calvin Cheung wrote: > > With the fix for JDK-8186842 , we no longer need the ModuleLoaderMap to determine the loader type of a class during CDS dump time. This change is for removing the ModuleLoaderMap from the runtime image and the code which references it. > > bug: https://bugs.openjdk.java.net/browse/JDK-8138600 > > webrevs: > http://cr.openjdk.java.net/~ccheung/8138600/jdk/webrev.00/ > http://cr.openjdk.java.net/~ccheung/8138600/hotspot/webrev.00/ > > Testing: > JPRT > CDS tests > hs-tier3 > > thanks, > Calvin > From joe.darcy at oracle.com Wed Sep 13 00:04:10 2017 From: joe.darcy at oracle.com (joe darcy) Date: Tue, 12 Sep 2017 17:04:10 -0700 Subject: Repo consolidation update: jcheck update expected soon In-Reply-To: <2b5ce3ba-5f8f-d884-64fe-ee144763a27e@oracle.com> References: <2b5ce3ba-5f8f-d884-64fe-ee144763a27e@oracle.com> Message-ID: <6c6d93cd-eb53-f743-4322-279abf96b2c1@oracle.com> Hello, We've run into some jcheck failures associated with the consolidated repo. We're working on resolving them, which may require a jcheck update to add items to the white list, etc. Since the consolidation process alters the changeset hashes, the existing white list entries do to apply to the corresponding changesets in the consolidated repo. Cheers, -Joe On 9/11/2017 8:45 AM, joe darcy wrote: > Hello, > > The last pre-consolidation state of the jdk10/jdk10 forest, build 23, > has been tagged. This will serve as the seed for the consolidation > repo to be hosted as jdk10/master. > > Both the client and hotspot integration forests have synced down the > contents of JDK 10 build 23 from jdk10/jdk10 master forest. Pull from > any of these forests to get an up to date version of the JDK sources > into your local JDK 10 clones. As previously announced [1], an initial > script is available to help port patches across the consolidation > boundary. > > We're investigation some possible updates to the OpenJDK Mercurial > server to improve performance and disk usage of the consolidated repo. > > The contents at jdk10/master will likely be populated before we're > ready to reopen the repo to pushes. > > Cheers, > > -Joe > > [1] > http://mail.openjdk.java.net/pipermail/jdk10-dev/2017-September/000482.html > From joe.darcy at oracle.com Thu Sep 14 04:27:12 2017 From: joe.darcy at oracle.com (joe darcy) Date: Wed, 13 Sep 2017 21:27:12 -0700 Subject: Repo consolidation update: new jcheck published, jdk10/master populated! In-Reply-To: <6c6d93cd-eb53-f743-4322-279abf96b2c1@oracle.com> References: <2b5ce3ba-5f8f-d884-64fe-ee144763a27e@oracle.com> <6c6d93cd-eb53-f743-4322-279abf96b2c1@oracle.com> Message-ID: Hello, On 9/12/2017 5:04 PM, joe darcy wrote: > Hello, > > We've run into some jcheck failures associated with the consolidated > repo. We're working on resolving them, which may require a jcheck > update to add items to the white list, etc. Since the consolidation > process alters the changeset hashes, the existing white list entries > do to apply to the corresponding changesets in the consolidated repo. > > Cheers, > > -Joe A new version of jcheck has been published and installed on the OpenJDK Mercurial server. You can refresh your local copy from http://hg.openjdk.java.net/code-tools/jcheck/dist/raw-file/tip/jcheck.py The initial push to the new consolidated master repo http://hg.openjdk.java.net/jdk10/master has completed! Semantically, the sources are equivalent to those in the non-consolidated JDK 10 b23. The repo is currently closed to pushes other than those related to the consolidation. We're still working on updating our infrastructure and validating builds and tests of the consolidated repository. There may be a few small additional changes made to the repo as part of the preparation for opening it up again. We'll have another tagging of the post-consolidation state as b24 before general development resumes. Cheers, -Joe From martinrb at google.com Thu Sep 14 17:22:25 2017 From: martinrb at google.com (Martin Buchholz) Date: Thu, 14 Sep 2017 10:22:25 -0700 Subject: Repo consolidation update: new jcheck published, jdk10/master populated! In-Reply-To: References: <2b5ce3ba-5f8f-d884-64fe-ee144763a27e@oracle.com> <6c6d93cd-eb53-f743-4322-279abf96b2c1@oracle.com> Message-ID: I tried out jdk10 master for a test drive. Notes: I had to amend my jdk build tree version detector as follows: sed_if_file_found() { if [[ -f "${@: -1}" ]]; then sed -E "$@"; fi } major() { # works with jdk10 post-repo consolidation sed_if_file_found -n \ -e 's/^DEFAULT_VERSION_MAJOR=([0-9]+)$/\1/p' \ "make/autoconf/version-numbers" # works with jdk8 sed_if_file_found -n \ -e 's/^DEFAULT_VERSION_MAJOR=([0-9]+)$/\1/p' \ -e 's/^JDK_MINOR_VERSION=([0-9]+)$/\1/p' \ "common/autoconf/version-numbers" # works with jdk7 sed_if_file_found -n -e 's/JDK_MINOR_VERSION *= *([0-9]+)$/\1/p' \ "jdk/make/common/shared/Defs.gmk" } (Is there a blessed way to do this?) Looks like other scripts will need adjustment for the new directory layout. --- If I do hg log $(find -name AtomicInteger.java)) I only get one commit But hg log -f works well, and file locations have changed, so this is as expected. --- On Wed, Sep 13, 2017 at 9:27 PM, joe darcy wrote: > Hello, > > > On 9/12/2017 5:04 PM, joe darcy wrote: > >> Hello, >> >> We've run into some jcheck failures associated with the consolidated >> repo. We're working on resolving them, which may require a jcheck update to >> add items to the white list, etc. Since the consolidation process alters >> the changeset hashes, the existing white list entries do to apply to the >> corresponding changesets in the consolidated repo. >> >> Cheers, >> >> -Joe >> > > A new version of jcheck has been published and installed on the OpenJDK > Mercurial server. You can refresh your local copy from > > http://hg.openjdk.java.net/code-tools/jcheck/dist/raw-file/tip/jcheck.py > > The initial push to the new consolidated master repo > > http://hg.openjdk.java.net/jdk10/master > > has completed! Semantically, the sources are equivalent to those in the > non-consolidated JDK 10 b23. > > The repo is currently closed to pushes other than those related to the > consolidation. We're still working on updating our infrastructure and > validating builds and tests of the consolidated repository. There may be a > few small additional changes made to the repo as part of the preparation > for opening it up again. > > We'll have another tagging of the post-consolidation state as b24 before > general development resumes. > > Cheers, > > -Joe > From erik.joelsson at oracle.com Thu Sep 14 18:03:42 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 14 Sep 2017 11:03:42 -0700 Subject: Repo consolidation update: new jcheck published, jdk10/master populated! In-Reply-To: References: <2b5ce3ba-5f8f-d884-64fe-ee144763a27e@oracle.com> <6c6d93cd-eb53-f743-4322-279abf96b2c1@oracle.com> Message-ID: Hello Martin, On 2017-09-14 10:22, Martin Buchholz wrote: > I tried out jdk10 master for a test drive. Notes: > > I had to amend my jdk build tree version detector as follows: > > > sed_if_file_found() { > if [[ -f "${@: -1}" ]]; then sed -E "$@"; fi > } > > major() { > # works with jdk10 post-repo consolidation > sed_if_file_found -n \ > -e 's/^DEFAULT_VERSION_MAJOR=([0-9]+)$/\1/p' \ > "make/autoconf/version-numbers" > # works with jdk8 > sed_if_file_found -n \ > -e 's/^DEFAULT_VERSION_MAJOR=([0-9]+)$/\1/p' \ > -e 's/^JDK_MINOR_VERSION=([0-9]+)$/\1/p' \ > "common/autoconf/version-numbers" > # works with jdk7 > sed_if_file_found -n -e 's/JDK_MINOR_VERSION *= *([0-9]+)$/\1/p' \ > "jdk/make/common/shared/Defs.gmk" > } > > (Is there a blessed way to do this?) Not that I can think of. The directory moved because having a "common" no longer made sense, so we decided to put everything build related in "make". What is the use case for that script? I've never not known what source I'm dealing with. Just curious. /Erik /Erik From martinrb at google.com Thu Sep 14 18:17:32 2017 From: martinrb at google.com (Martin Buchholz) Date: Thu, 14 Sep 2017 11:17:32 -0700 Subject: Repo consolidation update: new jcheck published, jdk10/master populated! In-Reply-To: References: <2b5ce3ba-5f8f-d884-64fe-ee144763a27e@oracle.com> <6c6d93cd-eb53-f743-4322-279abf96b2c1@oracle.com> Message-ID: On Thu, Sep 14, 2017 at 11:03 AM, Erik Joelsson wrote: > Hello Martin, > > On 2017-09-14 10:22, Martin Buchholz wrote: > >> I tried out jdk10 master for a test drive. Notes: >> >> I had to amend my jdk build tree version detector as follows: >> >> >> sed_if_file_found() { >> if [[ -f "${@: -1}" ]]; then sed -E "$@"; fi >> } >> >> major() { >> # works with jdk10 post-repo consolidation >> sed_if_file_found -n \ >> -e 's/^DEFAULT_VERSION_MAJOR=([0-9]+)$/\1/p' \ >> "make/autoconf/version-numbers" >> # works with jdk8 >> sed_if_file_found -n \ >> -e 's/^DEFAULT_VERSION_MAJOR=([0-9]+)$/\1/p' \ >> -e 's/^JDK_MINOR_VERSION=([0-9]+)$/\1/p' \ >> "common/autoconf/version-numbers" >> # works with jdk7 >> sed_if_file_found -n -e 's/JDK_MINOR_VERSION *= *([0-9]+)$/\1/p' \ >> "jdk/make/common/shared/Defs.gmk" >> } >> >> (Is there a blessed way to do this?) >> > Not that I can think of. The directory moved because having a "common" no > longer made sense, so we decided to put everything build related in "make". > > What is the use case for that script? I've never not known what source I'm > dealing with. Just curious. > > You always want to be up to date, so you hg tupdate all your forests, and then rebuild them all, and you want to be able to do that with a single script, without keeping track of which one is which version. rebuild-openjdk ~/ws/* From mark.reinhold at oracle.com Thu Sep 14 21:36:24 2017 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 14 Sep 2017 14:36:24 -0700 Subject: JEP proposed to target JDK 10 (2017/9/14) Message-ID: <20170914143624.494138584@eggemoggin.niobe.net> The following JEP has been placed into the "Proposed to Target" state by its owner after discussion and review: 286: Local-Variable Type Inference http://openjdk.java.net/jeps/286 Feedback on this proposal is welcome, as are reasoned objections. If no such objections are raised by 22:00 UTC next Thursday, 21 September, or if they're raised and then satisfactorily answered, then per the JEP 2.0 process proposal [1] I'll target this JEP to JDK 10. (To answer an obvious question: The expectation is that JDK 10 will morph into JDK 18.3 under a new Project, as recently proposed [2]. Until that happens, however, we'll continue working here.) - Mark [1] http://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html [2] http://mail.openjdk.java.net/pipermail/discuss/2017-September/004281.html From volker.simonis at gmail.com Fri Sep 15 14:35:41 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 15 Sep 2017 16:35:41 +0200 Subject: New version schema and javax.lang.model.SourceVersion Message-ID: Hi, one minor glitch with the newly proposed version schema [1] (i.e. 18.3, 18.9, etc.) is that we have the enum javax.lang.model.SourceVersion which defines: RELEASE_0 The original version RELEASE_1 The version recognized by the Java Platform 1.1. ... RELEASE_9 The version recognized by the Java Platform, Standard Edition 9. As we can't use periods in constant names we'll probably have to stick to RELEASE_10 The version recognized by the Java Platform, Standard Edition 18.3. RELEASE_11 The version recognized by the Java Platform, Standard Edition 18.9. in the future. So Java 10, 11 etc. will at least stay with us forever (and if only through this little known API :) Regards, Volker [1] https://mreinhold.org/blog/forward-faster From joe.darcy at oracle.com Fri Sep 15 16:37:15 2017 From: joe.darcy at oracle.com (joe darcy) Date: Fri, 15 Sep 2017 09:37:15 -0700 Subject: New version schema and javax.lang.model.SourceVersion In-Reply-To: References: Message-ID: <4efc19d7-e4ed-d135-89d5-9bb27820a89b@oracle.com> Hi Volker, Yes, SourceVersion and several other javac-related pieces of functionality may need to be updated to accommodate the new version scheme. For javac, the -source, -target, and --release values may need updating or aliases. For example, perhaps "10" and "18.3" and equivalent, just as "8" and "1.8" are equivalent today. The policies we've been following in JEP 182: "Policy for Retiring javac -source and -target Options," supporting a source/target value for the current release + three back, may or may not be updated as well. The relative ordering of SouceVersion enum comes from their declaration order. We could have RELEASE_18_DOT_3 or even RELEASE_EIGHTEEN_DOT_THREE but I don't think the last of these is very likely ;-) Regards, -Joe On 9/15/2017 7:35 AM, Volker Simonis wrote: > Hi, > > one minor glitch with the newly proposed version schema [1] (i.e. > 18.3, 18.9, etc.) is that we have the enum > javax.lang.model.SourceVersion which defines: > > RELEASE_0 The original version > RELEASE_1 The version recognized by the Java Platform 1.1. > ... > RELEASE_9 The version recognized by the Java Platform, Standard Edition 9. > > As we can't use periods in constant names we'll probably have to stick to > > RELEASE_10 The version recognized by the Java Platform, Standard Edition 18.3. > RELEASE_11 The version recognized by the Java Platform, Standard Edition 18.9. > > in the future. So Java 10, 11 etc. will at least stay with us forever > (and if only through this little known API :) > > Regards, > Volker > > [1] https://mreinhold.org/blog/forward-faster From robert.field at oracle.com Fri Sep 15 17:08:46 2017 From: robert.field at oracle.com (Robert Field) Date: Fri, 15 Sep 2017 10:08:46 -0700 Subject: New version schema and javax.lang.model.SourceVersion In-Reply-To: <4efc19d7-e4ed-d135-89d5-9bb27820a89b@oracle.com> References: <4efc19d7-e4ed-d135-89d5-9bb27820a89b@oracle.com> Message-ID: Or, of course: RELEASE_18_3 Robert Sent from my iPad > On Sep 15, 2017, at 9:37 AM, joe darcy wrote: > > Hi Volker, > > Yes, SourceVersion and several other javac-related pieces of functionality may need to be updated to accommodate the new version scheme. For javac, the -source, -target, and --release values may need updating or aliases. For example, perhaps "10" and "18.3" and equivalent, just as "8" and "1.8" are equivalent today. The policies we've been following in JEP 182: "Policy for Retiring javac -source and -target Options," supporting a source/target value for the current release + three back, may or may not be updated as well. > > The relative ordering of SouceVersion enum comes from their declaration order. We could have > > RELEASE_18_DOT_3 > > or even > > RELEASE_EIGHTEEN_DOT_THREE > > but I don't think the last of these is very likely ;-) > > Regards, > > -Joe > > >> On 9/15/2017 7:35 AM, Volker Simonis wrote: >> Hi, >> >> one minor glitch with the newly proposed version schema [1] (i.e. >> 18.3, 18.9, etc.) is that we have the enum >> javax.lang.model.SourceVersion which defines: >> >> RELEASE_0 The original version >> RELEASE_1 The version recognized by the Java Platform 1.1. >> ... >> RELEASE_9 The version recognized by the Java Platform, Standard Edition 9. >> >> As we can't use periods in constant names we'll probably have to stick to >> >> RELEASE_10 The version recognized by the Java Platform, Standard Edition 18.3. >> RELEASE_11 The version recognized by the Java Platform, Standard Edition 18.9. >> >> in the future. So Java 10, 11 etc. will at least stay with us forever >> (and if only through this little known API :) >> >> Regards, >> Volker >> >> [1] https://mreinhold.org/blog/forward-faster > From joe.darcy at oracle.com Wed Sep 20 02:42:25 2017 From: joe.darcy at oracle.com (joe darcy) Date: Tue, 19 Sep 2017 19:42:25 -0700 Subject: Repo consolidation update: consolidated JDK 10 b24 promoted In-Reply-To: References: <2b5ce3ba-5f8f-d884-64fe-ee144763a27e@oracle.com> <6c6d93cd-eb53-f743-4322-279abf96b2c1@oracle.com> Message-ID: <4b214f54-88c9-55e7-c5e0-bdf6ca352686@oracle.com> Hello, As seen in http://hg.openjdk.java.net/jdk10/master/tags the "10+24" tag has been added to the new consolidated JDK 10 master line of development. This is the first promotion based on the consolidated repository. Other than the changes directly related to the consolidation, there were only a handful of makefile and test-only changes in this build; in particular, there were no changes to files under /src. Therefore, builds of JDK 10 b23 should be semantically equivalent to JDK 10 b24. We're still working on finishing the infrastructure updates. I'll provide an update on opening jdk10/master up for general development and a more precise timeline for creating and opening jdk10/client, jdk10/hotspot, and other derived lines of development by Friday, September 22, 2017. Cheers, -Joe From joe.darcy at oracle.com Wed Sep 20 22:12:29 2017 From: joe.darcy at oracle.com (joe darcy) Date: Wed, 20 Sep 2017 15:12:29 -0700 Subject: Repo consolidation update: jdk10/master, jdk10/client, and jdk10/hotspot open for pushes In-Reply-To: <4b214f54-88c9-55e7-c5e0-bdf6ca352686@oracle.com> References: <2b5ce3ba-5f8f-d884-64fe-ee144763a27e@oracle.com> <6c6d93cd-eb53-f743-4322-279abf96b2c1@oracle.com> <4b214f54-88c9-55e7-c5e0-bdf6ca352686@oracle.com> Message-ID: <4de3c93d-5091-f0e8-9bc3-54db95965d6f@oracle.com> Hello, The JDK 10 master line of development at http://hg.openjdk.java.net/jdk10/master/ and the two integration lines of development at http://hg.openjdk.java.net/jdk10/client/ http://hg.openjdk.java.net/jdk10/hs/ are now open for pushes. All three are consolidated and are currently equivalent to JDK 10 b24. Consolidated versions of other JDK 10-derived lines of development, such as for Project Amber, Project Valhalla, and the sandbox, will be created in the coming days. If you have clones of any of the old non-consolidated JDK 10 forests with outstanding work to bring over, you can: * Synchronize the old forest with jdk10/jdk10. The jdk10/jdk10 forest is an archive of the non-consolidated master forest at build 23. Before being closed to pushes, both the jdk10/client and jdk10/hs forests were synchronized with jdk10/jdk10. * Extract the patch of the in-progress work. * Run the patch through the patch conversion script, bin/unshuffle_patch.sh in the consolidated repository. * Apply the converted patch to a clone of a consolidated repo and resolved any conflicts, etc. Thank you to the many people who worked on the consolidation project! Cheers, -Joe From mikael.vidstedt at oracle.com Thu Sep 21 00:17:02 2017 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Wed, 20 Sep 2017 17:17:02 -0700 Subject: Repo consolidation update: jdk10/master, jdk10/client, and jdk10/hotspot open for pushes In-Reply-To: <4de3c93d-5091-f0e8-9bc3-54db95965d6f@oracle.com> References: <2b5ce3ba-5f8f-d884-64fe-ee144763a27e@oracle.com> <6c6d93cd-eb53-f743-4322-279abf96b2c1@oracle.com> <4b214f54-88c9-55e7-c5e0-bdf6ca352686@oracle.com> <4de3c93d-5091-f0e8-9bc3-54db95965d6f@oracle.com> Message-ID: All, TL;DR: jdk10/hs remains closed for now. As Joe mentions the consolidated jdk10/hs repo has been created, but please hold off on pushing anything for now. We?d like to have some time to do a full test run and verify that we start off with the new repo in a known good state. Hopefully we?ll have the necessary test result data within the next day or two and if everything looks good the repos will be opened. Thanks, Mikael > On Sep 20, 2017, at 3:12 PM, joe darcy wrote: > > Hello, > > The JDK 10 master line of development at > > http://hg.openjdk.java.net/jdk10/master/ > > and the two integration lines of development at > > http://hg.openjdk.java.net/jdk10/client/ > http://hg.openjdk.java.net/jdk10/hs/ > > are now open for pushes. All three are consolidated and are currently equivalent to JDK 10 b24. > > Consolidated versions of other JDK 10-derived lines of development, such as for Project Amber, Project Valhalla, and the sandbox, will be created in the coming days. > > If you have clones of any of the old non-consolidated JDK 10 forests with outstanding work to bring over, you can: > > * Synchronize the old forest with jdk10/jdk10. The jdk10/jdk10 forest is an archive of the non-consolidated master forest at build 23. Before being closed to pushes, both the jdk10/client and jdk10/hs forests were synchronized with jdk10/jdk10. > > * Extract the patch of the in-progress work. > > * Run the patch through the patch conversion script, bin/unshuffle_patch.sh in the consolidated repository. > > * Apply the converted patch to a clone of a consolidated repo and resolved any conflicts, etc. > > Thank you to the many people who worked on the consolidation project! > > Cheers, > > -Joe > From mark.reinhold at oracle.com Thu Sep 21 02:55:24 2017 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Wed, 20 Sep 2017 19:55:24 -0700 Subject: Repo consolidation update: jdk10/master, jdk10/client, and jdk10/hotspot open for pushes In-Reply-To: <4de3c93d-5091-f0e8-9bc3-54db95965d6f@oracle.com> References: <2b5ce3ba-5f8f-d884-64fe-ee144763a27e@oracle.com> <6c6d93cd-eb53-f743-4322-279abf96b2c1@oracle.com> <4b214f54-88c9-55e7-c5e0-bdf6ca352686@oracle.com> <4de3c93d-5091-f0e8-9bc3-54db95965d6f@oracle.com> Message-ID: <20170920195524.641030905@eggemoggin.niobe.net> 2017/9/20 15:12:29 -0700, joe.darcy at oracle.com: > ... > > Thank you to the many people who worked on the consolidation project! Indeed -- thanks everyone, and thanks to Joe for leading this effort. This is going to help us all be more productive. - Mark From coleen.phillimore at oracle.com Fri Sep 22 14:38:30 2017 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Fri, 22 Sep 2017 10:38:30 -0400 Subject: Repo consolidation update: jdk10/master, jdk10/client, and jdk10/hotspot open for pushes In-Reply-To: References: <2b5ce3ba-5f8f-d884-64fe-ee144763a27e@oracle.com> <6c6d93cd-eb53-f743-4322-279abf96b2c1@oracle.com> <4b214f54-88c9-55e7-c5e0-bdf6ca352686@oracle.com> <4de3c93d-5091-f0e8-9bc3-54db95965d6f@oracle.com> Message-ID: <29bc94c0-385c-a40f-1a5e-af2282e0f525@oracle.com> Can we check stuff in to jdk10/hs yet? thanks, Coleen On 9/20/17 8:17 PM, Mikael Vidstedt wrote: > All, > > TL;DR: jdk10/hs remains closed for now. > > As Joe mentions the consolidated jdk10/hs repo has been created, but please hold off on pushing anything for now. We?d like to have some time to do a full test run and verify that we start off with the new repo in a known good state. Hopefully we?ll have the necessary test result data within the next day or two and if everything looks good the repos will be opened. > > Thanks, > Mikael > >> On Sep 20, 2017, at 3:12 PM, joe darcy wrote: >> >> Hello, >> >> The JDK 10 master line of development at >> >> http://hg.openjdk.java.net/jdk10/master/ >> >> and the two integration lines of development at >> >> http://hg.openjdk.java.net/jdk10/client/ >> http://hg.openjdk.java.net/jdk10/hs/ >> >> are now open for pushes. All three are consolidated and are currently equivalent to JDK 10 b24. >> >> Consolidated versions of other JDK 10-derived lines of development, such as for Project Amber, Project Valhalla, and the sandbox, will be created in the coming days. >> >> If you have clones of any of the old non-consolidated JDK 10 forests with outstanding work to bring over, you can: >> >> * Synchronize the old forest with jdk10/jdk10. The jdk10/jdk10 forest is an archive of the non-consolidated master forest at build 23. Before being closed to pushes, both the jdk10/client and jdk10/hs forests were synchronized with jdk10/jdk10. >> >> * Extract the patch of the in-progress work. >> >> * Run the patch through the patch conversion script, bin/unshuffle_patch.sh in the consolidated repository. >> >> * Apply the converted patch to a clone of a consolidated repo and resolved any conflicts, etc. >> >> Thank you to the many people who worked on the consolidation project! >> >> Cheers, >> >> -Joe >> From daniel.daugherty at oracle.com Fri Sep 22 15:09:26 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 22 Sep 2017 09:09:26 -0600 Subject: Repo consolidation update: jdk10/master, jdk10/client, and jdk10/hotspot open for pushes In-Reply-To: <29bc94c0-385c-a40f-1a5e-af2282e0f525@oracle.com> References: <2b5ce3ba-5f8f-d884-64fe-ee144763a27e@oracle.com> <6c6d93cd-eb53-f743-4322-279abf96b2c1@oracle.com> <4b214f54-88c9-55e7-c5e0-bdf6ca352686@oracle.com> <4de3c93d-5091-f0e8-9bc3-54db95965d6f@oracle.com> <29bc94c0-385c-a40f-1a5e-af2282e0f525@oracle.com> Message-ID: <321b6bf7-6a9f-ef59-6752-c5346931c644@oracle.com> No. We still haven't been able to execute HotSpot specific testing on the repo. Calvin has been trying to push a fix for one of the problems, but JPRT is _not happy_ with the new JDK10/hs repo... Stay tuned. People are working on it. Dan On 9/22/17 8:38 AM, coleen.phillimore at oracle.com wrote: > Can we check stuff in to jdk10/hs yet? > thanks, > Coleen > > On 9/20/17 8:17 PM, Mikael Vidstedt wrote: >> All, >> >> TL;DR: jdk10/hs remains closed for now. >> >> As Joe mentions the consolidated jdk10/hs repo has been created, but >> please hold off on pushing anything for now. We?d like to have some >> time to do a full test run and verify that we start off with the new >> repo in a known good state. Hopefully we?ll have the necessary test >> result data within the next day or two and if everything looks good >> the repos will be opened. >> >> Thanks, >> Mikael >> >>> On Sep 20, 2017, at 3:12 PM, joe darcy wrote: >>> >>> Hello, >>> >>> The JDK 10 master line of development at >>> >>> ??? http://hg.openjdk.java.net/jdk10/master/ >>> >>> and the two integration lines of development at >>> >>> ??? http://hg.openjdk.java.net/jdk10/client/ >>> ??? http://hg.openjdk.java.net/jdk10/hs/ >>> >>> are now open for pushes. All three are consolidated and are >>> currently equivalent to JDK 10 b24. >>> >>> Consolidated versions of other JDK 10-derived lines of development, >>> such as for Project Amber, Project Valhalla, and the sandbox, will >>> be created in the coming days. >>> >>> If you have clones of any of the old non-consolidated JDK 10 forests >>> with outstanding work to bring over, you can: >>> >>> * Synchronize the old forest with jdk10/jdk10. The jdk10/jdk10 >>> forest is an archive of the non-consolidated master forest at build >>> 23. Before being closed to pushes, both the jdk10/client and >>> jdk10/hs forests were synchronized with jdk10/jdk10. >>> >>> * Extract the patch of the in-progress work. >>> >>> * Run the patch through the patch conversion script, >>> bin/unshuffle_patch.sh in the consolidated repository. >>> >>> * Apply the converted patch to a clone of a consolidated repo and >>> resolved any conflicts, etc. >>> >>> Thank you to the many people who worked on the consolidation project! >>> >>> Cheers, >>> >>> -Joe >>> > From mark.reinhold at oracle.com Mon Sep 25 22:01:48 2017 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Mon, 25 Sep 2017 15:01:48 -0700 Subject: JEP proposed to target JDK 10 (2017/9/14) In-Reply-To: <20170914143624.494138584@eggemoggin.niobe.net> References: <20170914143624.494138584@eggemoggin.niobe.net> Message-ID: <20170925150148.467586941@eggemoggin.niobe.net> 2017/9/14 14:36:24 -0700, mark.reinhold at oracle.com: > The following JEP has been placed into the "Proposed to Target" > state by its owner after discussion and review: > > 286: Local-Variable Type Inference > http://openjdk.java.net/jeps/286 > > Feedback on this proposal is welcome, as are reasoned objections. > If no such objections are raised by 22:00 UTC next Thursday, 21 > September, or if they're raised and then satisfactorily answered, > then per the JEP 2.0 process proposal [1] I'll target this JEP > to JDK 10. > > (To answer an obvious question: The expectation is that JDK 10 will > morph into JDK 18.3 under a new Project, as recently proposed [2]. > Until that happens, however, we'll continue working here.) Hearing no objections, I've targeted this JEP to JDK 10. - Mark From fridrich.strba at suse.com Wed Sep 27 08:28:22 2017 From: fridrich.strba at suse.com (Fridrich Strba) Date: Wed, 27 Sep 2017 10:28:22 +0200 Subject: A possible fix for JDK-8165852: Mount point not found for a file which is present in overlayfs Message-ID: <39b5aafd-a862-427c-6234-4dc3b66e3d33@suse.com> Hello, good people, I think I fixed the overlayfs and btrfs problems in LinuxFileStore. The attached patch is what makes it work for us. Basically, when we come to the device-id boundary, we check whether it corresponds to a mount point in the files and if so, we return. If not, we go down the file system looking for another boundary. If we come to the root of the file-system without finding other mount-point and if the / is in the files, we return the entry that corresponds to it. If not, we throw the exception. It is not elegant, but it works. I would love to have someone to look at it and consider whether it could be up-streamed. Thanks in advance Fridrich -------------- next part -------------- A non-text attachment was scrubbed... Name: java-10-openjdk-linuxfilestore.patch Type: text/x-patch Size: 948 bytes Desc: not available URL: From Alan.Bateman at oracle.com Wed Sep 27 09:48:58 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 27 Sep 2017 10:48:58 +0100 Subject: A possible fix for JDK-8165852: Mount point not found for a file which is present in overlayfs In-Reply-To: <39b5aafd-a862-427c-6234-4dc3b66e3d33@suse.com> References: <39b5aafd-a862-427c-6234-4dc3b66e3d33@suse.com> Message-ID: <47819c1e-d052-5c1c-619e-ef0147efcb38@oracle.com> This is the right list for issues in specific areas, can you bring this to nio-dev instead? -Alan On 27/09/2017 09:28, Fridrich Strba wrote: > Hello, good people, > > I think I fixed the overlayfs and btrfs problems in LinuxFileStore. The > attached patch is what makes it work for us. Basically, when we come to > the device-id boundary, we check whether it corresponds to a mount point > in the files and if so, we return. If not, we go down the file system > looking for another boundary. If we come to the root of the file-system > without finding other mount-point and if the / is in the files, we > return the entry that corresponds to it. If not, we throw the exception. > > It is not elegant, but it works. I would love to have someone to look at > it and consider whether it could be up-streamed. > > Thanks in advance > > Fridrich > From volker.simonis at gmail.com Thu Sep 28 22:15:25 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 29 Sep 2017 00:15:25 +0200 Subject: Consolidated repo vs. old forest size differences Message-ID: Hi, not sure if this has been discussed before but at least I couldn't find any references in the previous mail threads on the repo consolidation. I've just realized that the size of the repository history (i.e. everything under .hg) has doubled in the new consolidated repo (800mb vs. 1600mb) and I don't exactly understand why: $ du -shc jdk10-hs-old/*/.hg jdk10-hs-old/.hg 16M jdk10-hs-old/corba/.hg 141M jdk10-hs-old/hotspot/.hg 49M jdk10-hs-old/jaxp/.hg 57M jdk10-hs-old/jaxws/.hg 453M jdk10-hs-old/jdk/.hg 76M jdk10-hs-old/langtools/.hg 33M jdk10-hs-old/nashorn/.hg 8,1M jdk10-hs-old/.hg 829M total $ du -sh jdk10-hs/.hg 1,6G jdk10-hs/.hg I wonder why this is the case? Is this because the consolidated repo has more and bigger merge changes? The consolidated repo has a total of 47297 changes with about 13878 merge changes: $ hg -R jdk10-hs log --template "{rev}\n" -r tip 47297 $ hg -R jdk10-hs log --template "{rev}\n" -k Merge | wc 13878 13878 79600 The old forest had a total of 43102 changes with about 10408 merge changes: $ bash common/bin/hgforest.sh log --template "{rev}\n" | wc 43102 86285 1295798 $ bash common/bin/hgforest.sh log -k "Merge" --template "{rev}\n" | wc 10408 20897 312491 So the new consolidated repo has about 3000-4000 more changes of which all are merge changesets. Does anybody know a nice command to sum up the size of all merge changesets? Any other insights or comments? It would be especially interesting to know how this will evolve in the future. Regards, Volker PS: this also partially explains why downloading the new repo takes considerably longer compared to the old forest (the fact that the get_sources.sh script downloaded the forest in parallel being the second reason). From joe.darcy at oracle.com Thu Sep 28 22:48:54 2017 From: joe.darcy at oracle.com (joe darcy) Date: Thu, 28 Sep 2017 15:48:54 -0700 Subject: Consolidated repo vs. old forest size differences In-Reply-To: References: Message-ID: <01ca6959-ad11-a8f7-5e2c-1d6a3be90dd0@oracle.com> Hi Volker, When there is a file move in Hg, it starts a fresh snapshot of the file. With the reorganized source structure, having a single top-level src subdirectory instead of jdk/src, langtools/src, etc. all the source files were moved. This accounts for such of the greater size post consolidation. We're looking into some ways to mitigate the impact of the larger size. Thanks, -Joe On 9/28/2017 3:15 PM, Volker Simonis wrote: > Hi, > > not sure if this has been discussed before but at least I couldn't > find any references in the previous mail threads on the repo > consolidation. > > I've just realized that the size of the repository history (i.e. > everything under .hg) has doubled in the new consolidated repo (800mb > vs. 1600mb) and I don't exactly understand why: > > $ du -shc jdk10-hs-old/*/.hg jdk10-hs-old/.hg > 16M jdk10-hs-old/corba/.hg > 141M jdk10-hs-old/hotspot/.hg > 49M jdk10-hs-old/jaxp/.hg > 57M jdk10-hs-old/jaxws/.hg > 453M jdk10-hs-old/jdk/.hg > 76M jdk10-hs-old/langtools/.hg > 33M jdk10-hs-old/nashorn/.hg > 8,1M jdk10-hs-old/.hg > 829M total > > $ du -sh jdk10-hs/.hg > 1,6G jdk10-hs/.hg > > I wonder why this is the case? > > Is this because the consolidated repo has more and bigger merge changes? > > The consolidated repo has a total of 47297 changes with about 13878 > merge changes: > > $ hg -R jdk10-hs log --template "{rev}\n" -r tip > 47297 > $ hg -R jdk10-hs log --template "{rev}\n" -k Merge | wc > 13878 13878 79600 > > The old forest had a total of 43102 changes with about 10408 merge changes: > > $ bash common/bin/hgforest.sh log --template "{rev}\n" | wc > 43102 86285 1295798 > $ bash common/bin/hgforest.sh log -k "Merge" --template "{rev}\n" | wc > 10408 20897 312491 > > So the new consolidated repo has about 3000-4000 more changes of which > all are merge changesets. Does anybody know a nice command to sum up > the size of all merge changesets? > > Any other insights or comments? It would be especially interesting to > know how this will evolve in the future. > > Regards, > Volker > > PS: this also partially explains why downloading the new repo takes > considerably longer compared to the old forest (the fact that the > get_sources.sh script downloaded the forest in parallel being the > second reason). From volker.simonis at gmail.com Thu Sep 28 23:09:19 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 29 Sep 2017 01:09:19 +0200 Subject: Consolidated repo vs. old forest size differences In-Reply-To: <01ca6959-ad11-a8f7-5e2c-1d6a3be90dd0@oracle.com> References: <01ca6959-ad11-a8f7-5e2c-1d6a3be90dd0@oracle.com> Message-ID: Hi Joe, thanks for the quick answer. Yes, that explains the double size. So at least it is a one time effect only. Regards, Volker On Fri, Sep 29, 2017 at 12:48 AM, joe darcy wrote: > Hi Volker, > > When there is a file move in Hg, it starts a fresh snapshot of the file. > With the reorganized source structure, having a single top-level src > subdirectory instead of jdk/src, langtools/src, etc. all the source files > were moved. > > This accounts for such of the greater size post consolidation. We're looking > into some ways to mitigate the impact of the larger size. > > Thanks, > > -Joe > > > > On 9/28/2017 3:15 PM, Volker Simonis wrote: >> >> Hi, >> >> not sure if this has been discussed before but at least I couldn't >> find any references in the previous mail threads on the repo >> consolidation. >> >> I've just realized that the size of the repository history (i.e. >> everything under .hg) has doubled in the new consolidated repo (800mb >> vs. 1600mb) and I don't exactly understand why: >> >> $ du -shc jdk10-hs-old/*/.hg jdk10-hs-old/.hg >> 16M jdk10-hs-old/corba/.hg >> 141M jdk10-hs-old/hotspot/.hg >> 49M jdk10-hs-old/jaxp/.hg >> 57M jdk10-hs-old/jaxws/.hg >> 453M jdk10-hs-old/jdk/.hg >> 76M jdk10-hs-old/langtools/.hg >> 33M jdk10-hs-old/nashorn/.hg >> 8,1M jdk10-hs-old/.hg >> 829M total >> >> $ du -sh jdk10-hs/.hg >> 1,6G jdk10-hs/.hg >> >> I wonder why this is the case? >> >> Is this because the consolidated repo has more and bigger merge changes? >> >> The consolidated repo has a total of 47297 changes with about 13878 >> merge changes: >> >> $ hg -R jdk10-hs log --template "{rev}\n" -r tip >> 47297 >> $ hg -R jdk10-hs log --template "{rev}\n" -k Merge | wc >> 13878 13878 79600 >> >> The old forest had a total of 43102 changes with about 10408 merge >> changes: >> >> $ bash common/bin/hgforest.sh log --template "{rev}\n" | wc >> 43102 86285 1295798 >> $ bash common/bin/hgforest.sh log -k "Merge" --template "{rev}\n" | wc >> 10408 20897 312491 >> >> So the new consolidated repo has about 3000-4000 more changes of which >> all are merge changesets. Does anybody know a nice command to sum up >> the size of all merge changesets? >> >> Any other insights or comments? It would be especially interesting to >> know how this will evolve in the future. >> >> Regards, >> Volker >> >> PS: this also partially explains why downloading the new repo takes >> considerably longer compared to the old forest (the fact that the >> get_sources.sh script downloaded the forest in parallel being the >> second reason). > > From erik.joelsson at oracle.com Fri Sep 29 11:20:10 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 29 Sep 2017 13:20:10 +0200 Subject: Consolidated repo vs. old forest size differences In-Reply-To: References: <01ca6959-ad11-a8f7-5e2c-1d6a3be90dd0@oracle.com> Message-ID: <5b59d403-1c02-356a-7d63-c5950deced85@oracle.com> Hello Volker, As the implementor of the conversion strategy, I have investigated and played around with this a lot. There are two main contributors to the increased size. * First, as Joe said, the file moves, which account for around 350MB. A similar (though not quite as big) size increase occurred when we reorganized the source into modules. * The second is caused by inefficient storage in the "manifest" file in the metadata. This file can grow large when adjacent changesets have large diffs between them, typically from non linear history. By merging together previously unrelated histories, we created quite a few of those. If you check your .hg dir, you will see that this file is around 400MB. There is a way to reduce the size of the manifest file, but it requires a newer version of Mercurial than we have on our servers and the feature is not well documented (see aggressiveMergeDeltas). Because of this, we have been hesitant to deploy that change on our main servers. If you are curious, you can convert your repository locally using a command like this: hg --config=format.generaldelta=1 --config=format.aggressivemergedeltas=1 clone --pull That should result in a manifest file size of around 40MB and bring down the metadata total size to around 1100MB. All of the conversion was done with this option enabled, but by pushing to an older server, the "compression" didn't stick, which it otherwise would have. /Erik On 2017-09-29 01:09, Volker Simonis wrote: > Hi Joe, > > thanks for the quick answer. Yes, that explains the double size. So at > least it is a one time effect only. > > Regards, > Volker > > > On Fri, Sep 29, 2017 at 12:48 AM, joe darcy wrote: >> Hi Volker, >> >> When there is a file move in Hg, it starts a fresh snapshot of the file. >> With the reorganized source structure, having a single top-level src >> subdirectory instead of jdk/src, langtools/src, etc. all the source files >> were moved. >> >> This accounts for such of the greater size post consolidation. We're looking >> into some ways to mitigate the impact of the larger size. >> >> Thanks, >> >> -Joe >> >> >> >> On 9/28/2017 3:15 PM, Volker Simonis wrote: >>> Hi, >>> >>> not sure if this has been discussed before but at least I couldn't >>> find any references in the previous mail threads on the repo >>> consolidation. >>> >>> I've just realized that the size of the repository history (i.e. >>> everything under .hg) has doubled in the new consolidated repo (800mb >>> vs. 1600mb) and I don't exactly understand why: >>> >>> $ du -shc jdk10-hs-old/*/.hg jdk10-hs-old/.hg >>> 16M jdk10-hs-old/corba/.hg >>> 141M jdk10-hs-old/hotspot/.hg >>> 49M jdk10-hs-old/jaxp/.hg >>> 57M jdk10-hs-old/jaxws/.hg >>> 453M jdk10-hs-old/jdk/.hg >>> 76M jdk10-hs-old/langtools/.hg >>> 33M jdk10-hs-old/nashorn/.hg >>> 8,1M jdk10-hs-old/.hg >>> 829M total >>> >>> $ du -sh jdk10-hs/.hg >>> 1,6G jdk10-hs/.hg >>> >>> I wonder why this is the case? >>> >>> Is this because the consolidated repo has more and bigger merge changes? >>> >>> The consolidated repo has a total of 47297 changes with about 13878 >>> merge changes: >>> >>> $ hg -R jdk10-hs log --template "{rev}\n" -r tip >>> 47297 >>> $ hg -R jdk10-hs log --template "{rev}\n" -k Merge | wc >>> 13878 13878 79600 >>> >>> The old forest had a total of 43102 changes with about 10408 merge >>> changes: >>> >>> $ bash common/bin/hgforest.sh log --template "{rev}\n" | wc >>> 43102 86285 1295798 >>> $ bash common/bin/hgforest.sh log -k "Merge" --template "{rev}\n" | wc >>> 10408 20897 312491 >>> >>> So the new consolidated repo has about 3000-4000 more changes of which >>> all are merge changesets. Does anybody know a nice command to sum up >>> the size of all merge changesets? >>> >>> Any other insights or comments? It would be especially interesting to >>> know how this will evolve in the future. >>> >>> Regards, >>> Volker >>> >>> PS: this also partially explains why downloading the new repo takes >>> considerably longer compared to the old forest (the fact that the >>> get_sources.sh script downloaded the forest in parallel being the >>> second reason). >> From nils.eliasson at oracle.com Fri Sep 29 12:43:35 2017 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Fri, 29 Sep 2017 14:43:35 +0200 Subject: CFV: New JDK 10 Committer: Patric Hedlin Message-ID: <0625b99a-5377-0081-c247-998fc6a34725@oracle.com> I hereby nominate Patric Hedlin (phedlin) to JDK 10 Committer. Patric Hedlin is a member of the Hotspot JVM Compiler Team at Oracle. Over the past 14 months, he has contributed 14 changesets [3] primarily targeting better code generation for SPARC hardware. Votes are due by 16:00 GMT, October 13 2017. Only current JDK 10 Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [2]. Nils Eliasson [1] http://openjdk.java.net/census [2] http://openjdk.java.net/projects/#committer-vote [3]http://hg.openjdk.java.net/jdk10/hs/search/?rev=%28keyword%28hedlin%29%20or%20keyword%28phedlin%29%29&revcount=20 From vladimir.x.ivanov at oracle.com Fri Sep 29 12:57:22 2017 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 29 Sep 2017 15:57:22 +0300 Subject: CFV: New JDK 10 Committer: Patric Hedlin In-Reply-To: <0625b99a-5377-0081-c247-998fc6a34725@oracle.com> References: <0625b99a-5377-0081-c247-998fc6a34725@oracle.com> Message-ID: Vote: yes Best regards, Vladimir Ivanov On 9/29/17 3:43 PM, Nils Eliasson wrote: > I hereby nominate Patric Hedlin (phedlin) to JDK 10 Committer. From claes.redestad at oracle.com Fri Sep 29 13:22:55 2017 From: claes.redestad at oracle.com (Claes Redestad) Date: Fri, 29 Sep 2017 15:22:55 +0200 Subject: CFV: New JDK 10 Committer: Patric Hedlin In-Reply-To: <0625b99a-5377-0081-c247-998fc6a34725@oracle.com> References: <0625b99a-5377-0081-c247-998fc6a34725@oracle.com> Message-ID: <2cd9a618-b77c-a173-ad04-96adfe18e030@oracle.com> Vote: yes /Claes From erik.joelsson at oracle.com Fri Sep 29 13:22:33 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 29 Sep 2017 15:22:33 +0200 Subject: CFV: New JDK 10 Committer: Patric Hedlin In-Reply-To: <0625b99a-5377-0081-c247-998fc6a34725@oracle.com> References: <0625b99a-5377-0081-c247-998fc6a34725@oracle.com> Message-ID: Vote: yes /Erik On 2017-09-29 14:43, Nils Eliasson wrote: > I hereby nominate Patric Hedlin (phedlin) to JDK 10 Committer. > > Patric Hedlin is a member of the Hotspot JVM Compiler Team at Oracle. > Over the past 14 months, he has contributed 14 changesets [3] > primarily targeting better code generation for SPARC hardware. > > Votes are due by 16:00 GMT, October 13 2017. > > Only current JDK 10 Committers [1] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Lazy Consensus voting instructions, see [2]. > > Nils Eliasson > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3]http://hg.openjdk.java.net/jdk10/hs/search/?rev=%28keyword%28hedlin%29%20or%20keyword%28phedlin%29%29&revcount=20 > From stefan.karlsson at oracle.com Fri Sep 29 13:37:31 2017 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Fri, 29 Sep 2017 15:37:31 +0200 Subject: CFV: New JDK 10 Committer: Patric Hedlin In-Reply-To: <0625b99a-5377-0081-c247-998fc6a34725@oracle.com> References: <0625b99a-5377-0081-c247-998fc6a34725@oracle.com> Message-ID: Vote: yes StefanK On 2017-09-29 14:43, Nils Eliasson wrote: > I hereby nominate Patric Hedlin (phedlin) to JDK 10 Committer. > > Patric Hedlin is a member of the Hotspot JVM Compiler Team at Oracle. > Over the past 14 months, he has contributed 14 changesets [3] primarily > targeting better code generation for SPARC hardware. > > Votes are due by 16:00 GMT, October 13 2017. > > Only current JDK 10 Committers [1] are eligible to vote on this > nomination.? Votes must be cast in the open by replying to this mailing > list. > > For Lazy Consensus voting instructions, see [2]. > > Nils Eliasson > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3]http://hg.openjdk.java.net/jdk10/hs/search/?rev=%28keyword%28hedlin%29%20or%20keyword%28phedlin%29%29&revcount=20 > From jesper.wilhelmsson at oracle.com Fri Sep 29 13:41:57 2017 From: jesper.wilhelmsson at oracle.com (jesper.wilhelmsson at oracle.com) Date: Fri, 29 Sep 2017 15:41:57 +0200 Subject: CFV: New JDK 10 Committer: Patric Hedlin In-Reply-To: <0625b99a-5377-0081-c247-998fc6a34725@oracle.com> References: <0625b99a-5377-0081-c247-998fc6a34725@oracle.com> Message-ID: Vote: Yes /Jesper > On 29 Sep 2017, at 14:43, Nils Eliasson wrote: > > I hereby nominate Patric Hedlin (phedlin) to JDK 10 Committer. > > Patric Hedlin is a member of the Hotspot JVM Compiler Team at Oracle. Over the past 14 months, he has contributed 14 changesets [3] primarily targeting better code generation for SPARC hardware. > > Votes are due by 16:00 GMT, October 13 2017. > > Only current JDK 10 Committers [1] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Lazy Consensus voting instructions, see [2]. > > Nils Eliasson > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3]http://hg.openjdk.java.net/jdk10/hs/search/?rev=%28keyword%28hedlin%29%20or%20keyword%28phedlin%29%29&revcount=20 From erik.osterlund at oracle.com Fri Sep 29 14:38:39 2017 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Fri, 29 Sep 2017 16:38:39 +0200 Subject: CFV: New JDK 10 Committer: Patric Hedlin In-Reply-To: <0625b99a-5377-0081-c247-998fc6a34725@oracle.com> References: <0625b99a-5377-0081-c247-998fc6a34725@oracle.com> Message-ID: <59CE5AEF.9020705@oracle.com> Vote: yes /Erik On 2017-09-29 14:43, Nils Eliasson wrote: > I hereby nominate Patric Hedlin (phedlin) to JDK 10 Committer. > > Patric Hedlin is a member of the Hotspot JVM Compiler Team at Oracle. > Over the past 14 months, he has contributed 14 changesets [3] > primarily targeting better code generation for SPARC hardware. > > Votes are due by 16:00 GMT, October 13 2017. > > Only current JDK 10 Committers [1] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Lazy Consensus voting instructions, see [2]. > > Nils Eliasson > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3]http://hg.openjdk.java.net/jdk10/hs/search/?rev=%28keyword%28hedlin%29%20or%20keyword%28phedlin%29%29&revcount=20 > From vladimir.kozlov at oracle.com Fri Sep 29 17:43:12 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 29 Sep 2017 10:43:12 -0700 Subject: CFV: New JDK 10 Committer: Patric Hedlin In-Reply-To: <0625b99a-5377-0081-c247-998fc6a34725@oracle.com> References: <0625b99a-5377-0081-c247-998fc6a34725@oracle.com> Message-ID: Vote: yes On 9/29/17 5:43 AM, Nils Eliasson wrote: > I hereby nominate Patric Hedlin (phedlin) to JDK 10 Committer. > > Patric Hedlin is a member of the Hotspot JVM Compiler Team at Oracle. Over the past 14 months, he has contributed 14 > changesets [3] primarily targeting better code generation for SPARC hardware. > > Votes are due by 16:00 GMT, October 13 2017. > > Only current JDK 10 Committers [1] are eligible to vote on this > nomination.? Votes must be cast in the open by replying to this mailing > list. > > For Lazy Consensus voting instructions, see [2]. > > Nils Eliasson > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3]http://hg.openjdk.java.net/jdk10/hs/search/?rev=%28keyword%28hedlin%29%20or%20keyword%28phedlin%29%29&revcount=20 From serguei.spitsyn at oracle.com Fri Sep 29 19:43:02 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 29 Sep 2017 12:43:02 -0700 Subject: CFV: New JDK 10 Committer: Patric Hedlin In-Reply-To: <0625b99a-5377-0081-c247-998fc6a34725@oracle.com> References: <0625b99a-5377-0081-c247-998fc6a34725@oracle.com> Message-ID: <2d4a213c-a28a-2291-a035-571f60f03d82@oracle.com> Vote: yes From igor.ignatyev at oracle.com Fri Sep 29 19:45:46 2017 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Fri, 29 Sep 2017 12:45:46 -0700 Subject: CFV: New JDK 10 Committer: Patric Hedlin In-Reply-To: <0625b99a-5377-0081-c247-998fc6a34725@oracle.com> References: <0625b99a-5377-0081-c247-998fc6a34725@oracle.com> Message-ID: <57C35820-E85E-4BA6-B65D-D25803328790@oracle.com> Vote: yes -- Igor > On Sep 29, 2017, at 5:43 AM, Nils Eliasson wrote: > > I hereby nominate Patric Hedlin (phedlin) to JDK 10 Committer.