From openjdk at haupz.de Thu Feb 1 08:17:06 2018 From: openjdk at haupz.de (Michael Haupt) Date: Thu, 1 Feb 2018 09:17:06 +0100 Subject: CFV: New Project: Detroit In-Reply-To: <5A71F9C4.1040502@oracle.com> References: <682C4141-D48C-469B-BE0A-BBB1D803EE81@oracle.com> <5A71F9C4.1040502@oracle.com> Message-ID: <44B6E3A4-0569-4F50-BD3E-7200FF43B8A2@haupz.de> Vote: yes > Am 31.01.2018 um 18:15 schrieb Sundararajan Athijegannathan : > > Vote: Yes > > -Sundar > >> On 31/01/18, 10:08 PM, Jim Laskey wrote: >> I hereby propose the creation of the Detroit Project with Hannes >> Walln?fer as the Lead and the Compiler Group as the sponsoring Group. >> >> In accordance with the OpenJDK guidelines [1], this project will provide >> the home for the development of a native implementation of the >> javax.script package based on the Chrome V8 JavaScript engine [2]. Our >> starting point is the prototype presented by James Laskey at JVMLS 2017 [3]. >> >> The resulting implementation will contain V8 itself together with the >> necessary Java and JavaScript bindings. When loaded by a JVM process it >> provides a new javax.script.ScriptEngine [4] called "V8" that allows >> loading and execution of JavaScript code via V8. >> >> We also want to support a significant subset of the JavaScript >> extensions implemented in Nashorn [5], including accessing, >> instantiating, and extending or implementing Java types from JavaScript. >> >> The initially targeted platforms are Linux and Mac OS X. V8 sources are >> acquired by build processes. We do not plan to modify the V8 sources in >> any way. Thus, maintenance and updating to new upstream releases will >> be straightforward. >> >> While the initial implementation will be based on JNI, the project could >> act as a platform for new technologies developed in Project Panama [6] >> in the future. >> >> The initial list of reviewers and committers will be based on the >> current reviewers and committers of the Nashorn team: >> >> James Laskey (reviewer) >> Sundararajan Athijegannathan (reviewer) >> Hannes Walln?fer (reviewer) >> Srinivas Dama (committer) >> Priya Lakshmi Muthuswamy (committer) >> >> Votes are due by the end of Wednesday, February 7, 2018. >> >> Only current OpenJDK Members [7] are eligible to vote on this >> motion. Votes must be cast in the open on the discuss list. >> Replying to this message is sufficient if your mail program >> honors the Reply-To header. >> >> For Lazy Consensus voting instructions, see [8]. >> >> Jim Laskey >> >> [1] http://openjdk.java.net/projects/#new-project >> [2] https://developers.google.com/v8/ >> [3] https://www.youtube.com/watch?v=-JLhwsbMvjQ >> [4] https://docs.oracle.com/javase/9/docs/api/javax/script/package-summary.html >> [5] https://wiki.openjdk.java.net/display/Nashorn/Nashorn+extensions >> [6] http://openjdk.java.net/projects/panama/ >> [7] http://openjdk.java.net/census#members >> [8] http://openjdk.java.net/projects/#new-project-vote From neugens.limasoftware at gmail.com Thu Feb 1 09:10:31 2018 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Thu, 01 Feb 2018 09:10:31 +0000 Subject: CFV: New Project: Detroit In-Reply-To: <682C4141-D48C-469B-BE0A-BBB1D803EE81@oracle.com> References: <682C4141-D48C-469B-BE0A-BBB1D803EE81@oracle.com> Message-ID: Vote: yes! Mario On Wed 31. Jan 2018 at 17:54, Jim Laskey wrote: > I hereby propose the creation of the Detroit Project with Hannes > Walln?fer as the Lead and the Compiler Group as the sponsoring Group. > > In accordance with the OpenJDK guidelines [1], this project will provide > the home for the development of a native implementation of the > javax.script package based on the Chrome V8 JavaScript engine [2]. Our > starting point is the prototype presented by James Laskey at JVMLS 2017 > [3]. > > The resulting implementation will contain V8 itself together with the > necessary Java and JavaScript bindings. When loaded by a JVM process it > provides a new javax.script.ScriptEngine [4] called "V8" that allows > loading and execution of JavaScript code via V8. > > We also want to support a significant subset of the JavaScript > extensions implemented in Nashorn [5], including accessing, > instantiating, and extending or implementing Java types from JavaScript. > > The initially targeted platforms are Linux and Mac OS X. V8 sources are > acquired by build processes. We do not plan to modify the V8 sources in > any way. Thus, maintenance and updating to new upstream releases will > be straightforward. > > While the initial implementation will be based on JNI, the project could > act as a platform for new technologies developed in Project Panama [6] > in the future. > > The initial list of reviewers and committers will be based on the > current reviewers and committers of the Nashorn team: > > James Laskey (reviewer) > Sundararajan Athijegannathan (reviewer) > Hannes Walln?fer (reviewer) > Srinivas Dama (committer) > Priya Lakshmi Muthuswamy (committer) > > Votes are due by the end of Wednesday, February 7, 2018. > > Only current OpenJDK Members [7] are eligible to vote on this > motion. Votes must be cast in the open on the discuss list. > Replying to this message is sufficient if your mail program > honors the Reply-To header. > > For Lazy Consensus voting instructions, see [8]. > > Jim Laskey > > [1] http://openjdk.java.net/projects/#new-project > [2] https://developers.google.com/v8/ > [3] https://www.youtube.com/watch?v=-JLhwsbMvjQ > [4] > https://docs.oracle.com/javase/9/docs/api/javax/script/package-summary.html > [5] https://wiki.openjdk.java.net/display/Nashorn/Nashorn+extensions > [6] http://openjdk.java.net/projects/panama/ > [7] http://openjdk.java.net/census#members > [8] http://openjdk.java.net/projects/#new-project-vote From neugens.limasoftware at gmail.com Thu Feb 1 09:19:56 2018 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Thu, 01 Feb 2018 09:19:56 +0000 Subject: CFV: New Project: Detroit In-Reply-To: <20180131140118.497997289@eggemoggin.niobe.net> References: <682C4141-D48C-469B-BE0A-BBB1D803EE81@oracle.com> <20180131134418.995772018@eggemoggin.niobe.net> <12B52167-3146-47F3-8027-3486BF04A599@oracle.com> <20180131140118.497997289@eggemoggin.niobe.net> Message-ID: That would have been nice, however the scope of the project is sufficiently clear I think. Basically, the current implementation can?t possibly keep up with any advancement in JavaScript, both as in performance and as in spec, so it makes sense to dispatch everything to a dedicated JavaScript vm (eh eh, irony). One question I would have is what happens to nashorn? Some of the types and APIs mentioned I believe are internal, so also done code that allows class filtering etc.. What will happen to that? Is the project be obsoleted? Cheers, Mario On Wed 31. Jan 2018 at 23:02, wrote: > 2018/1/31 13:54:28 -0800, thomas.wuerthinger at oracle.com: > > OK, thanks for clarification. If this is intentional, I guess a > > discussion within the community is then not desired for this project. > > Perhaps the submitter of the proposal just didn't think it would be > controversial, given that there are no viable open-source alternatives. > > In any case, further discussion during the CFV period is perfectly fine. > > - Mark > From hannes.wallnoefer at oracle.com Thu Feb 1 10:59:50 2018 From: hannes.wallnoefer at oracle.com (=?utf-8?Q?Hannes_Walln=C3=B6fer?=) Date: Thu, 1 Feb 2018 11:59:50 +0100 Subject: CFV: New Project: Detroit In-Reply-To: References: <682C4141-D48C-469B-BE0A-BBB1D803EE81@oracle.com> <20180131134418.995772018@eggemoggin.niobe.net> <12B52167-3146-47F3-8027-3486BF04A599@oracle.com> <20180131140118.497997289@eggemoggin.niobe.net> Message-ID: <82BCB6D7-1823-4522-9EE1-A12EB0189734@oracle.com> Hi Mario, > Am 01.02.2018 um 10:19 schrieb Mario Torre : > > One question I would have is what happens to nashorn? Some of the types and > APIs mentioned I believe are internal, so also done code that allows class > filtering etc.. > > What will happen to that? Is the project be obsoleted? > We can support most of the Java interoperability features of Nashorn with V8, including class filtering. Where we are more confined is with extensions of the language itself, of which Nashorn has a few [1]. However, most of those have been addressed in recent additions to the ECMA standard (and V8), so it?s not really something to worry about. [1] https://wiki.openjdk.java.net/display/Nashorn/Nashorn+extensions Regarding Nashorn: I think it still serves a purpose and isn?t going away anytime soon. We?ll see how things work out in the future, but I?m not the right person to speculate about that. Hannes From maurizio.cimadamore at oracle.com Thu Feb 1 11:47:54 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 1 Feb 2018 11:47:54 +0000 Subject: CFV: New Project: Detroit In-Reply-To: <682C4141-D48C-469B-BE0A-BBB1D803EE81@oracle.com> References: <682C4141-D48C-469B-BE0A-BBB1D803EE81@oracle.com> Message-ID: <75b892a0-2083-37fb-c583-29f79edba3b3@oracle.com> Vote: yes! Maurizio On 31/01/18 16:38, Jim Laskey wrote: > I hereby propose the creation of the Detroit Project with Hannes > Walln?fer as the Lead and the Compiler Group as the sponsoring Group. > > In accordance with the OpenJDK guidelines [1], this project will provide > the home for the development of a native implementation of the > javax.script package based on the Chrome V8 JavaScript engine [2]. Our > starting point is the prototype presented by James Laskey at JVMLS 2017 [3]. > > The resulting implementation will contain V8 itself together with the > necessary Java and JavaScript bindings. When loaded by a JVM process it > provides a new javax.script.ScriptEngine [4] called "V8" that allows > loading and execution of JavaScript code via V8. > > We also want to support a significant subset of the JavaScript > extensions implemented in Nashorn [5], including accessing, > instantiating, and extending or implementing Java types from JavaScript. > > The initially targeted platforms are Linux and Mac OS X. V8 sources are > acquired by build processes. We do not plan to modify the V8 sources in > any way. Thus, maintenance and updating to new upstream releases will > be straightforward. > > While the initial implementation will be based on JNI, the project could > act as a platform for new technologies developed in Project Panama [6] > in the future. > > The initial list of reviewers and committers will be based on the > current reviewers and committers of the Nashorn team: > > James Laskey (reviewer) > Sundararajan Athijegannathan (reviewer) > Hannes Walln?fer (reviewer) > Srinivas Dama (committer) > Priya Lakshmi Muthuswamy (committer) > > Votes are due by the end of Wednesday, February 7, 2018. > > Only current OpenJDK Members [7] are eligible to vote on this > motion. Votes must be cast in the open on the discuss list. > Replying to this message is sufficient if your mail program > honors the Reply-To header. > > For Lazy Consensus voting instructions, see [8]. > > Jim Laskey > > [1] http://openjdk.java.net/projects/#new-project > [2] https://developers.google.com/v8/ > [3] https://www.youtube.com/watch?v=-JLhwsbMvjQ > [4] https://docs.oracle.com/javase/9/docs/api/javax/script/package-summary.html > [5] https://wiki.openjdk.java.net/display/Nashorn/Nashorn+extensions > [6] http://openjdk.java.net/projects/panama/ > [7] http://openjdk.java.net/census#members > [8] http://openjdk.java.net/projects/#new-project-vote From augustnagro at gmail.com Thu Feb 1 17:53:48 2018 From: augustnagro at gmail.com (August Nagro) Date: Thu, 01 Feb 2018 17:53:48 +0000 Subject: CFV: New Project: Detroit Message-ID: Question: Would it be worthwhile considering WebKit over V8? JavaFX already includes the WebKit-based WebEngine [1], which provides "two-way communication between a Java application and JavaScript code," in addition to rendering web content. Depending on only one native engine may ease maintenance costs and additionally reduce download size (at least for the JDK, given Jigsaw). Regards, August [1]: https://docs.oracle.com/javase/9/docs/api/javafx/scene/web/WebEngine.html On 31/01/18, 10:08 PM, Jim Laskey wrote: > I hereby propose the creation of the Detroit Project with Hannes > Walln?fer as the Lead and the Compiler Group as the sponsoring Group. > > In accordance with the OpenJDK guidelines [1], this project will provide > the home for the development of a native implementation of the > javax.script package based on the Chrome V8 JavaScript engine [2]. Our > starting point is the prototype presented by James Laskey at JVMLS 2017 [3]. > > The resulting implementation will contain V8 itself together with the > necessary Java and JavaScript bindings. When loaded by a JVM process it > provides a new javax.script.ScriptEngine [4] called "V8" that allows > loading and execution of JavaScript code via V8. > > We also want to support a significant subset of the JavaScript > extensions implemented in Nashorn [5], including accessing, > instantiating, and extending or implementing Java types from JavaScript. > > The initially targeted platforms are Linux and Mac OS X. V8 sources are > acquired by build processes. We do not plan to modify the V8 sources in > any way. Thus, maintenance and updating to new upstream releases will > be straightforward. > > While the initial implementation will be based on JNI, the project could > act as a platform for new technologies developed in Project Panama [6] > in the future. > > The initial list of reviewers and committers will be based on the > current reviewers and committers of the Nashorn team: > > James Laskey (reviewer) > Sundararajan Athijegannathan (reviewer) > Hannes Walln?fer (reviewer) > Srinivas Dama (committer) > Priya Lakshmi Muthuswamy (committer) > > Votes are due by the end of Wednesday, February 7, 2018. > > Only current OpenJDK Members [7] are eligible to vote on this > motion. Votes must be cast in the open on the discuss list. > Replying to this message is sufficient if your mail program > honors the Reply-To header. > > For Lazy Consensus voting instructions, see [8]. > > Jim Laskey > > [1] http://openjdk.java.net/projects/#new-project > [2] https://developers.google.com/v8/ > [3] https://www.youtube.com/watch?v=-JLhwsbMvjQ > [4] https://docs.oracle.com/javase/9/docs/api/javax/script/package-summary.html > [5] https://wiki.openjdk.java.net/display/Nashorn/Nashorn+extensions > [6] http://openjdk.java.net/projects/panama/ > [7] http://openjdk.java.net/census#members > [8] http://openjdk.java.net/projects/#new-project-vote From hannes.wallnoefer at oracle.com Thu Feb 1 19:52:27 2018 From: hannes.wallnoefer at oracle.com (=?utf-8?Q?Hannes_Walln=C3=B6fer?=) Date: Thu, 1 Feb 2018 20:52:27 +0100 Subject: CFV: New Project: Detroit In-Reply-To: References: Message-ID: > Am 01.02.2018 um 18:53 schrieb August Nagro : > > Question: Would it be worthwhile considering WebKit over V8? > > JavaFX already includes the WebKit-based WebEngine [1], which provides > "two-way communication between a Java application and JavaScript code," in > addition to rendering web content. Depending on only one native engine may > ease maintenance costs and additionally reduce download size (at least for > the JDK, given Jigsaw). That?s an interesting idea, but there are some problems with this approach. Most importantly, just executing a script and getting back the result is not enough, we need quite complex interaction with the JS engine to provide the level of integration we aim for. I don?t think we could piggyback that on the JavaFX WebEngine component without practically hijacking it. Even if we could, we?d then have to move in lockstep with JFX in terms of versions and configurations. Apart from these considerations, it certainly matters that Node.js is the most popular way of running JS in server/cloud environments, so using V8 opens a lot of doors. Hannes From akashche at redhat.com Thu Feb 1 21:46:08 2018 From: akashche at redhat.com (Alex Kashchenko) Date: Thu, 1 Feb 2018 21:46:08 +0000 Subject: CFV: New Project: Detroit In-Reply-To: References: Message-ID: Hi, On 02/01/2018 07:52 PM, Hannes Walln?fer wrote: > >> Am 01.02.2018 um 18:53 schrieb August Nagro : >> >> Question: Would it be worthwhile considering WebKit over V8? >> >> JavaFX already includes the WebKit-based WebEngine [1], which provides >> "two-way communication between a Java application and JavaScript code," in >> addition to rendering web content. Depending on only one native engine may >> ease maintenance costs and additionally reduce download size (at least for >> the JDK, given Jigsaw). > > That?s an interesting idea, but there are some problems with this approach. > > Most importantly, just executing a script and getting back the result is not enough, we need quite complex interaction with the JS engine to provide the level of integration we aim for. I don?t think we could piggyback that on the JavaFX WebEngine component without practically hijacking it. Even if we could, we?d then have to move in lockstep with JFX in terms of versions and configurations. FWIW, WebKit JS engine - JavaScriptCore [1] can be used directly (not through WebEngine) - it has stable C API [2]. And besides being shipped as a part of JavaFX, it is also available in many Linux distros as a shared library [3]. But from description it looks clear that other JS engines besides V8 are out of scope for the proposed project, so this is just my 2 cents. > Apart from these considerations, it certainly matters that Node.js is the most popular way of running JS in server/cloud environments, so using V8 opens a lot of doors. Absolutely agree. > > Hannes > [1] https://trac.webkit.org/wiki/JavaScriptCore [2] http://hg.openjdk.java.net/openjfx/jfx/rt/file/f09aa59ddcca/modules/javafx.web/src/main/native/Source/JavaScriptCore/API [3] https://packages.ubuntu.com/xenial/libjavascriptcoregtk-4.0-dev -- -Alex From joe.darcy at oracle.com Fri Feb 2 00:46:42 2018 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Thu, 01 Feb 2018 16:46:42 -0800 Subject: CFV: New Project: Detroit In-Reply-To: <682C4141-D48C-469B-BE0A-BBB1D803EE81@oracle.com> References: <682C4141-D48C-469B-BE0A-BBB1D803EE81@oracle.com> Message-ID: <5A73B4F2.6030305@oracle.com> Vote: yes -Joe On 1/31/2018 8:38 AM, Jim Laskey wrote: > I hereby propose the creation of the Detroit Project with Hannes > Walln?fer as the Lead and the Compiler Group as the sponsoring Group. > > In accordance with the OpenJDK guidelines [1], this project will provide > the home for the development of a native implementation of the > javax.script package based on the Chrome V8 JavaScript engine [2]. Our > starting point is the prototype presented by James Laskey at JVMLS 2017 [3]. > > The resulting implementation will contain V8 itself together with the > necessary Java and JavaScript bindings. When loaded by a JVM process it > provides a new javax.script.ScriptEngine [4] called "V8" that allows > loading and execution of JavaScript code via V8. > > We also want to support a significant subset of the JavaScript > extensions implemented in Nashorn [5], including accessing, > instantiating, and extending or implementing Java types from JavaScript. > > The initially targeted platforms are Linux and Mac OS X. V8 sources are > acquired by build processes. We do not plan to modify the V8 sources in > any way. Thus, maintenance and updating to new upstream releases will > be straightforward. > > While the initial implementation will be based on JNI, the project could > act as a platform for new technologies developed in Project Panama [6] > in the future. > > The initial list of reviewers and committers will be based on the > current reviewers and committers of the Nashorn team: > > James Laskey (reviewer) > Sundararajan Athijegannathan (reviewer) > Hannes Walln?fer (reviewer) > Srinivas Dama (committer) > Priya Lakshmi Muthuswamy (committer) > > Votes are due by the end of Wednesday, February 7, 2018. > > Only current OpenJDK Members [7] are eligible to vote on this > motion. Votes must be cast in the open on the discuss list. > Replying to this message is sufficient if your mail program > honors the Reply-To header. > > For Lazy Consensus voting instructions, see [8]. > > Jim Laskey > > [1] http://openjdk.java.net/projects/#new-project > [2] https://developers.google.com/v8/ > [3] https://www.youtube.com/watch?v=-JLhwsbMvjQ > [4] https://docs.oracle.com/javase/9/docs/api/javax/script/package-summary.html > [5] https://wiki.openjdk.java.net/display/Nashorn/Nashorn+extensions > [6] http://openjdk.java.net/projects/panama/ > [7] http://openjdk.java.net/census#members > [8] http://openjdk.java.net/projects/#new-project-vote From stuart.marks at oracle.com Sat Feb 3 15:18:37 2018 From: stuart.marks at oracle.com (Stuart Marks) Date: Sat, 3 Feb 2018 07:18:37 -0800 Subject: CFV: New Project: Detroit In-Reply-To: <682C4141-D48C-469B-BE0A-BBB1D803EE81@oracle.com> References: <682C4141-D48C-469B-BE0A-BBB1D803EE81@oracle.com> Message-ID: <032e30c6-8183-86e6-58a2-1103dd8d8ee5@oracle.com> Vote: yes On 1/31/18 8:38 AM, Jim Laskey wrote: > I hereby propose the creation of the Detroit Project with Hannes > Walln?fer as the Lead and the Compiler Group as the sponsoring Group. > > In accordance with the OpenJDK guidelines [1], this project will provide > the home for the development of a native implementation of the > javax.script package based on the Chrome V8 JavaScript engine [2]. Our > starting point is the prototype presented by James Laskey at JVMLS 2017 [3]. > > The resulting implementation will contain V8 itself together with the > necessary Java and JavaScript bindings. When loaded by a JVM process it > provides a new javax.script.ScriptEngine [4] called "V8" that allows > loading and execution of JavaScript code via V8. > > We also want to support a significant subset of the JavaScript > extensions implemented in Nashorn [5], including accessing, > instantiating, and extending or implementing Java types from JavaScript. > > The initially targeted platforms are Linux and Mac OS X. V8 sources are > acquired by build processes. We do not plan to modify the V8 sources in > any way. Thus, maintenance and updating to new upstream releases will > be straightforward. > > While the initial implementation will be based on JNI, the project could > act as a platform for new technologies developed in Project Panama [6] > in the future. > > The initial list of reviewers and committers will be based on the > current reviewers and committers of the Nashorn team: > > James Laskey (reviewer) > Sundararajan Athijegannathan (reviewer) > Hannes Walln?fer (reviewer) > Srinivas Dama (committer) > Priya Lakshmi Muthuswamy (committer) > > Votes are due by the end of Wednesday, February 7, 2018. > > Only current OpenJDK Members [7] are eligible to vote on this > motion. Votes must be cast in the open on the discuss list. > Replying to this message is sufficient if your mail program > honors the Reply-To header. > > For Lazy Consensus voting instructions, see [8]. > > Jim Laskey > > [1] http://openjdk.java.net/projects/#new-project > [2] https://developers.google.com/v8/ > [3] https://www.youtube.com/watch?v=-JLhwsbMvjQ > [4] https://docs.oracle.com/javase/9/docs/api/javax/script/package-summary.html > [5] https://wiki.openjdk.java.net/display/Nashorn/Nashorn+extensions > [6] http://openjdk.java.net/projects/panama/ > [7] http://openjdk.java.net/census#members > [8] http://openjdk.java.net/projects/#new-project-vote > From vicente.romero at oracle.com Sat Feb 3 22:23:44 2018 From: vicente.romero at oracle.com (Vicente Romero) Date: Sat, 3 Feb 2018 17:23:44 -0500 Subject: CFV: New Project: Detroit In-Reply-To: <682C4141-D48C-469B-BE0A-BBB1D803EE81@oracle.com> References: <682C4141-D48C-469B-BE0A-BBB1D803EE81@oracle.com> Message-ID: <08d61aa6-b86d-f4a3-e4b0-27f348f9fb80@oracle.com> vote: yes On 01/31/2018 11:38 AM, Jim Laskey wrote: > I hereby propose the creation of the Detroit Project with Hannes > Walln?fer as the Lead and the Compiler Group as the sponsoring Group. > > In accordance with the OpenJDK guidelines [1], this project will provide > the home for the development of a native implementation of the > javax.script package based on the Chrome V8 JavaScript engine [2]. Our > starting point is the prototype presented by James Laskey at JVMLS 2017 [3]. > > The resulting implementation will contain V8 itself together with the > necessary Java and JavaScript bindings. When loaded by a JVM process it > provides a new javax.script.ScriptEngine [4] called "V8" that allows > loading and execution of JavaScript code via V8. > > We also want to support a significant subset of the JavaScript > extensions implemented in Nashorn [5], including accessing, > instantiating, and extending or implementing Java types from JavaScript. > > The initially targeted platforms are Linux and Mac OS X. V8 sources are > acquired by build processes. We do not plan to modify the V8 sources in > any way. Thus, maintenance and updating to new upstream releases will > be straightforward. > > While the initial implementation will be based on JNI, the project could > act as a platform for new technologies developed in Project Panama [6] > in the future. > > The initial list of reviewers and committers will be based on the > current reviewers and committers of the Nashorn team: > > James Laskey (reviewer) > Sundararajan Athijegannathan (reviewer) > Hannes Walln?fer (reviewer) > Srinivas Dama (committer) > Priya Lakshmi Muthuswamy (committer) > > Votes are due by the end of Wednesday, February 7, 2018. > > Only current OpenJDK Members [7] are eligible to vote on this > motion. Votes must be cast in the open on the discuss list. > Replying to this message is sufficient if your mail program > honors the Reply-To header. > > For Lazy Consensus voting instructions, see [8]. > > Jim Laskey > > [1] http://openjdk.java.net/projects/#new-project > [2] https://developers.google.com/v8/ > [3] https://www.youtube.com/watch?v=-JLhwsbMvjQ > [4] https://docs.oracle.com/javase/9/docs/api/javax/script/package-summary.html > [5] https://wiki.openjdk.java.net/display/Nashorn/Nashorn+extensions > [6] http://openjdk.java.net/projects/panama/ > [7] http://openjdk.java.net/census#members > [8] http://openjdk.java.net/projects/#new-project-vote From volker.simonis at gmail.com Mon Feb 5 17:38:14 2018 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 5 Feb 2018 18:38:14 +0100 Subject: Group Proposal, for further discussion: Vulnerability Group In-Reply-To: <20180131164449.2D7BB15E0AA@eggemoggin.niobe.net> References: <20180131164449.2D7BB15E0AA@eggemoggin.niobe.net> Message-ID: On Wed, Jan 31, 2018 at 5:44 PM, wrote: > (This is not a call for votes; it is just a call for discussion.) > > To follow up on my initial call for discussion last August [1], I've > posted a revised proposal for the Vulnerability Group together with > the final version of the non-disclosure and license agreement, and > diffs of the final version with respect to the first version: > > http://cr.openjdk.java.net/~mr/ojvg/ > http://cr.openjdk.java.net/~mr/ojvg/ojvg-ndla-2018-01-30.pdf > http://cr.openjdk.java.net/~mr/ojvg/ojvg-ndla-2018-01-30-diffs.pdf > > The only change to the proposal itself is to add a link to define the > term "rough consensus," as suggested by Volker [2]. > Thanks for considering my suggestion. I actually didn't expected that the definition of "rough consensus" will be longer than the entire "OpenJDK Vulnerability Group" proposal, but rough consensus seems to be a complex topic :) The final agreement is under review. I'll let you know once it's done and we can finally sign it. Regards, Volker > I'll propose to create the Vulnerability Group in one week, after > prospective initial Group Members have had time to review the final > agreement. > > - Mark > > > [1] http://mail.openjdk.java.net/pipermail/discuss/2017-August/004267.html > [2] http://mail.openjdk.java.net/pipermail/discuss/2017-October/004509.html From martijnverburg at gmail.com Tue Feb 6 05:47:16 2018 From: martijnverburg at gmail.com (Martijn Verburg) Date: Tue, 6 Feb 2018 18:47:16 +1300 Subject: Group Proposal, for further discussion: Vulnerability Group In-Reply-To: References: <20180131164449.2D7BB15E0AA@eggemoggin.niobe.net> Message-ID: Thanks Mark, Looks good to us (ran it past legal for LJC / Adopt Build Farm). Cheers, Martijn On 6 February 2018 at 06:38, Volker Simonis wrote: > On Wed, Jan 31, 2018 at 5:44 PM, wrote: > > (This is not a call for votes; it is just a call for discussion.) > > > > To follow up on my initial call for discussion last August [1], I've > > posted a revised proposal for the Vulnerability Group together with > > the final version of the non-disclosure and license agreement, and > > diffs of the final version with respect to the first version: > > > > http://cr.openjdk.java.net/~mr/ojvg/ > > http://cr.openjdk.java.net/~mr/ojvg/ojvg-ndla-2018-01-30.pdf > > http://cr.openjdk.java.net/~mr/ojvg/ojvg-ndla-2018-01-30-diffs.pdf > > > > The only change to the proposal itself is to add a link to define the > > term "rough consensus," as suggested by Volker [2]. > > > > Thanks for considering my suggestion. I actually didn't expected that > the definition of "rough consensus" will be longer than the entire > "OpenJDK Vulnerability Group" proposal, but rough consensus seems to > be a complex topic :) > > The final agreement is under review. I'll let you know once it's done > and we can finally sign it. > > Regards, > Volker > > > I'll propose to create the Vulnerability Group in one week, after > > prospective initial Group Members have had time to review the final > > agreement. > > > > - Mark > > > > > > [1] http://mail.openjdk.java.net/pipermail/discuss/2017-August/ > 004267.html > > [2] http://mail.openjdk.java.net/pipermail/discuss/2017- > October/004509.html > From magnus.ihse.bursie at oracle.com Tue Feb 6 10:54:48 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 6 Feb 2018 11:54:48 +0100 Subject: CFV: New Project: Detroit In-Reply-To: <682C4141-D48C-469B-BE0A-BBB1D803EE81@oracle.com> References: <682C4141-D48C-469B-BE0A-BBB1D803EE81@oracle.com> Message-ID: <0d4b4f03-0223-6e1a-7b04-f8e063be79c3@oracle.com> From a build perspective, I'm highly skeptical of build changes that "acquite sources" during the build process. I think the proper way to connect OpenJDK and the V8 sources is an implementation detail that can be solved as part of the Detroit project together with the Build Team, and not be decided upfront before the creation of the project. If this is what you really meant, I'm all for a "yes" vote. /Magnus On 2018-01-31 17:38, Jim Laskey wrote: > I hereby propose the creation of the Detroit Project with Hannes > Walln?fer as the Lead and the Compiler Group as the sponsoring Group. > > In accordance with the OpenJDK guidelines [1], this project will provide > the home for the development of a native implementation of the > javax.script package based on the Chrome V8 JavaScript engine [2]. Our > starting point is the prototype presented by James Laskey at JVMLS 2017 [3]. > > The resulting implementation will contain V8 itself together with the > necessary Java and JavaScript bindings. When loaded by a JVM process it > provides a new javax.script.ScriptEngine [4] called "V8" that allows > loading and execution of JavaScript code via V8. > > We also want to support a significant subset of the JavaScript > extensions implemented in Nashorn [5], including accessing, > instantiating, and extending or implementing Java types from JavaScript. > > The initially targeted platforms are Linux and Mac OS X. V8 sources are > acquired by build processes. We do not plan to modify the V8 sources in > any way. Thus, maintenance and updating to new upstream releases will > be straightforward. > > While the initial implementation will be based on JNI, the project could > act as a platform for new technologies developed in Project Panama [6] > in the future. > > The initial list of reviewers and committers will be based on the > current reviewers and committers of the Nashorn team: > > James Laskey (reviewer) > Sundararajan Athijegannathan (reviewer) > Hannes Walln?fer (reviewer) > Srinivas Dama (committer) > Priya Lakshmi Muthuswamy (committer) > > Votes are due by the end of Wednesday, February 7, 2018. > > Only current OpenJDK Members [7] are eligible to vote on this > motion. Votes must be cast in the open on the discuss list. > Replying to this message is sufficient if your mail program > honors the Reply-To header. > > For Lazy Consensus voting instructions, see [8]. > > Jim Laskey > > [1] http://openjdk.java.net/projects/#new-project > [2] https://developers.google.com/v8/ > [3] https://www.youtube.com/watch?v=-JLhwsbMvjQ > [4] https://docs.oracle.com/javase/9/docs/api/javax/script/package-summary.html > [5] https://wiki.openjdk.java.net/display/Nashorn/Nashorn+extensions > [6] http://openjdk.java.net/projects/panama/ > [7] http://openjdk.java.net/census#members > [8] http://openjdk.java.net/projects/#new-project-vote From dalibor.topic at oracle.com Tue Feb 6 11:41:30 2018 From: dalibor.topic at oracle.com (dalibor topic) Date: Tue, 6 Feb 2018 12:41:30 +0100 Subject: CFV: New Project: Detroit In-Reply-To: <682C4141-D48C-469B-BE0A-BBB1D803EE81@oracle.com> References: <682C4141-D48C-469B-BE0A-BBB1D803EE81@oracle.com> Message-ID: <1357276e-e1a6-3508-8390-8b013e782b01@oracle.com> Vote: Yes. On 31.01.2018 17:38, Jim Laskey wrote: > The initially targeted platforms are Linux and Mac OS X. V8 sources are > acquired by build processes. Why not simply link to libv8.so/dylib from the OS as you have no plans to modify it anyway? cheers, dalibor topic -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From hannes.wallnoefer at oracle.com Tue Feb 6 13:30:42 2018 From: hannes.wallnoefer at oracle.com (=?utf-8?Q?Hannes_Walln=C3=B6fer?=) Date: Tue, 6 Feb 2018 14:30:42 +0100 Subject: CFV: New Project: Detroit In-Reply-To: <0d4b4f03-0223-6e1a-7b04-f8e063be79c3@oracle.com> References: <682C4141-D48C-469B-BE0A-BBB1D803EE81@oracle.com> <0d4b4f03-0223-6e1a-7b04-f8e063be79c3@oracle.com> Message-ID: <4212DE98-745D-4DCC-A364-B72352B4F0B5@oracle.com> Hi Magnus, > Am 06.02.2018 um 11:54 schrieb Magnus Ihse Bursie : > > From a build perspective, I'm highly skeptical of build changes that "acquite sources" during the build process. I think the proper way to connect OpenJDK and the V8 sources is an implementation detail that can be solved as part of the Detroit project together with the Build Team, and not be decided upfront before the creation of the project. Yes, the build process is definitely to be worked out together with the Build Team, so that statement was premature. Hannes > If this is what you really meant, I'm all for a "yes" vote. > > /Magnus From magnus.ihse.bursie at oracle.com Tue Feb 6 19:36:06 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 6 Feb 2018 20:36:06 +0100 Subject: CFV: New Project: Detroit In-Reply-To: <682C4141-D48C-469B-BE0A-BBB1D803EE81@oracle.com> References: <682C4141-D48C-469B-BE0A-BBB1D803EE81@oracle.com> Message-ID: <128a986f-575c-bf47-3ce3-7977e27e1cd7@oracle.com> Vote: yes /Magnus On 2018-01-31 17:38, Jim Laskey wrote: > I hereby propose the creation of the Detroit Project with Hannes > Walln?fer as the Lead and the Compiler Group as the sponsoring Group. > > In accordance with the OpenJDK guidelines [1], this project will provide > the home for the development of a native implementation of the > javax.script package based on the Chrome V8 JavaScript engine [2]. Our > starting point is the prototype presented by James Laskey at JVMLS 2017 [3]. > > The resulting implementation will contain V8 itself together with the > necessary Java and JavaScript bindings. When loaded by a JVM process it > provides a new javax.script.ScriptEngine [4] called "V8" that allows > loading and execution of JavaScript code via V8. > > We also want to support a significant subset of the JavaScript > extensions implemented in Nashorn [5], including accessing, > instantiating, and extending or implementing Java types from JavaScript. > > The initially targeted platforms are Linux and Mac OS X. V8 sources are > acquired by build processes. We do not plan to modify the V8 sources in > any way. Thus, maintenance and updating to new upstream releases will > be straightforward. > > While the initial implementation will be based on JNI, the project could > act as a platform for new technologies developed in Project Panama [6] > in the future. > > The initial list of reviewers and committers will be based on the > current reviewers and committers of the Nashorn team: > > James Laskey (reviewer) > Sundararajan Athijegannathan (reviewer) > Hannes Walln?fer (reviewer) > Srinivas Dama (committer) > Priya Lakshmi Muthuswamy (committer) > > Votes are due by the end of Wednesday, February 7, 2018. > > Only current OpenJDK Members [7] are eligible to vote on this > motion. Votes must be cast in the open on the discuss list. > Replying to this message is sufficient if your mail program > honors the Reply-To header. > > For Lazy Consensus voting instructions, see [8]. > > Jim Laskey > > [1] http://openjdk.java.net/projects/#new-project > [2] https://developers.google.com/v8/ > [3] https://www.youtube.com/watch?v=-JLhwsbMvjQ > [4] https://docs.oracle.com/javase/9/docs/api/javax/script/package-summary.html > [5] https://wiki.openjdk.java.net/display/Nashorn/Nashorn+extensions > [6] http://openjdk.java.net/projects/panama/ > [7] http://openjdk.java.net/census#members > [8] http://openjdk.java.net/projects/#new-project-vote From magnus.ihse.bursie at oracle.com Tue Feb 6 19:43:16 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 6 Feb 2018 20:43:16 +0100 Subject: CFV: New Project: Detroit In-Reply-To: <4212DE98-745D-4DCC-A364-B72352B4F0B5@oracle.com> References: <682C4141-D48C-469B-BE0A-BBB1D803EE81@oracle.com> <0d4b4f03-0223-6e1a-7b04-f8e063be79c3@oracle.com> <4212DE98-745D-4DCC-A364-B72352B4F0B5@oracle.com> Message-ID: On 2018-02-06 14:30, Hannes Walln?fer wrote: > Hi Magnus, > >> Am 06.02.2018 um 11:54 schrieb Magnus Ihse Bursie : >> >> From a build perspective, I'm highly skeptical of build changes that "acquite sources" during the build process. I think the proper way to connect OpenJDK and the V8 sources is an implementation detail that can be solved as part of the Detroit project together with the Build Team, and not be decided upfront before the creation of the project. > Yes, the build process is definitely to be worked out together with the Build Team, so that statement was premature. Good. /Magnus > > Hannes > > >> If this is what you really meant, I'm all for a "yes" vote. >> >> /Magnus From Daniel.Christensen at microfocus.com Tue Feb 6 23:31:45 2018 From: Daniel.Christensen at microfocus.com (Daniel Christensen) Date: Tue, 06 Feb 2018 16:31:45 -0700 Subject: OpenJDK LTS Releases Message-ID: <5A7A3AE1020000BE00072C9C@prvgwdev-52.provo.novell.com> I've been sifting through information about the changes to the Java release cycle and it seems that there is conflicting information about LTS releases of the OpenJDK. In the YouTube video, "Moving Java Forward Faster by Mark Reinhold & Brian Goetz" [1], Mark puts up a slide at time 06:10 or so that shows that OpenJDK releases of Java 11 and 17 will be LTS releases that last 3 years. However, in the more recent video, "Changes to the JDK Release Model with Sharat Chander" [2], a slide is put up at time 20:36 or so that shows the _Oracle_ JDK releases of 11 and 17 as getting 3 years of support but that the OpenJDK releases of 11 and 17 are only supported for 6 months. So, what exactly constitutes a Long Term Support Release in the context of the OpenJDK? Does the OpenJDK project intend to release regular security updates of the OpenJDK LTS releases (11, 17, etc.)? Or did I misunderstand that from Mark's original video. I also see that Oracle is sponsoring builds of the OpenJDK for Linux, Mac and Win64. Will these binaries be available for LTS releases and their subsequent security updates or are they only available during the 6 month feature release cycle? Thanks in advance for your help! I'm just trying to wrap my head around these changes to ensure that my company does the right thing. -Dan [1] - https://www.youtube.com/watch?v=x7pkWlost64 [2] - https://www.youtube.com/watch?v=YauqubC8FKM Daniel L. Christensen Distinguished Engineer Micro Focus http://www.microfocus.com From aph at redhat.com Thu Feb 8 16:12:24 2018 From: aph at redhat.com (Andrew Haley) Date: Thu, 8 Feb 2018 16:12:24 +0000 Subject: [sw-dev] Project proposal: RISC-V port In-Reply-To: References: Message-ID: <858dfbd1-5665-4b2a-70e2-ed790e17a2a8@redhat.com> On 07/02/18 22:00, Palmer Dabbelt wrote: > There appears to be considerable community interest in a RISC-V > OpenJDK port, so my hope is that while I don't have time to directly > contribute much myself that we'll be able to get something sane up > and running. Interested users can test on QEMU, and we've recently > announced a board (and associated beta program that provide free > boards to open source developers) so there's some hardware to run on > as well. I'd like to request that the Porters Group sponsors this > project with me as the lead. It's a multi-engineer-year project. Two engineers with deep knowledge of HotSpot could get a bare-bones port done in a year, one doing the assembler, C1, and template interpreter, and the other doing C2. Both would work on the shared runtime. To get a really performant port done would take at least twice that, probably longer. Anyone wanting to lead a porting project had better have plenty of time and considerable expertise, or it'll go nowhere. I'll be happy to advise, cajole, and generally encourage, but it's going to take boots on the ground. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Thu Feb 8 18:23:58 2018 From: aph at redhat.com (Andrew Haley) Date: Thu, 8 Feb 2018 18:23:58 +0000 Subject: [sw-dev] Project proposal: RISC-V port In-Reply-To: References: <858dfbd1-5665-4b2a-70e2-ed790e17a2a8@redhat.com> Message-ID: On 08/02/18 17:20, Bruce Hoult wrote: > Having been involved in porting Microsoft's CoreCLR JIT to ARM (for Tizen > 4.0) I'd say that's an underestimate, unless OpenJDK is somehow far better > written. We have done it before. It's a lower bound. Mind you, unless there's some real hardware available it'll take a lot longer. For AArch64 we wrote a tiny simulator and lined it in to the HotSpot runtime so that everything except the JIT-generated code ran as native optimized x86-64 code. That helped a lot: if you had to run the entire JVM in emulation you'd die waiting for it to get as far as generating the interpreter. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From edward.nevill at gmail.com Fri Feb 9 10:57:21 2018 From: edward.nevill at gmail.com (Edward Nevill) Date: Fri, 09 Feb 2018 10:57:21 +0000 Subject: Project proposal: RISC-V port In-Reply-To: References: Message-ID: <1518173841.2854.29.camel@gmail.com> Hi, I would like to voice my support for the creation of this project. The process for creation of a new OpenJDK project is described at http://openjdk.java.net/projects/#new-project The initial discussion should be sent to the general discussion list, discuss.at.openjdk.dot.java.dot.net. I have cc'd this to the general discussion list. Assuming that the group lead of the porters project agrees to sponsor the project then the call for votes should be sent to announce.at.openjdk.dot.java.dot.net. Note that only current OpenJDK contributors may propose the creation of a new project. If you are not a current OpenJDK contributor I am happy to propose the project on your behalf. http://openjdk.java.net/bylaws#contributor I am happy to devote some 'spare' time to this project, but this will me limited to a few hours per week. I agree with the overall approach you outline below. You will probably end up doing C1 anyway. The s390 port tried to do it without doing C1 and they ended up doing C1. Andrew Haley's suggestion of using a built in simulator is a good one. This was the approach used on the aarch64 project and it was invaluable not just in terms of development time in the absence of hardware but in terms of debuggability. Also OpenJDK depends on a huge list of packages to build. Using this approach you can build and run on x86 while all the dependant packages are being ported. All the best, Ed. On Thu, 2018-02-08 at 08:38 -0800, Palmer Dabbelt wrote: > [Sorry for the second email, it appears my SiFive email doesn't want to > subscribe to porters-dev.] > > RISC-V is an open standard ISA stewarded by the RISC-V foundation > . With the recent release of glibc 2.27 we now have the full > RISC-V software base released from the various upstream repositories, which > means it's time to start moving forward with the rest of the software stack. I > ran into Erik at FOSDEM a few days ago and he suggested that we open up the > discussion of an OpenJDK port for RISC-V. While I'm not familiar with the > RISC-V Java efforts, I did part of a Hotspot port (a bit of the template > interpreter and much of C2) to Tilera's TilePro and TileGx architectures a few > years ago so I know a bit about the OpenJDK internals. > > In the RISC-V community we view Java as a very important missing component of > the software ecosystem, so I was thrilled when Erik found me at FOSDMEM and > suggested there was community interest in a port. Unfortunately, I won't have > time to properly help out with the port (I'm maintaining Linux, as well as > co-maintaining binutils, GCC, and glibc). That said, I'd be very happy to help > out where I can. I think a good way to move forward might be to: > > * Create a project to own the RISC-V port, which is what this email is about. > I'm OK being the project lead, at least until we find someone who will have > * Clean up our libffi port and submit it upstream. Stefan O'Rear is in the > process of submitting the port now, so it should all be moving smoothly soon. > Submit patches for our Zero port. While I didn't do the port I don't mind > cleaning it up and submitting it. I've added Martin who was more involved > with the original port. I think he's not working on RISC-V stuff now that > he's at Google, though. > * Move forward with a proper OpenJDK port, starting with the template > interpreter and eventually adding C2. I'm not sure if C1 is actually > deprecated, but we decided not to bother with it at Tilera because it didn't > seem worth the extra effort at the time. Of course, this would be up to > whomever is actually doing the work :). > > There appears to be considerable community interest in a RISC-V OpenJDK port, > so my hope is that while I don't have time to directly contribute much myself > that we'll be able to get something sane up and running. Interested users can > test on QEMU, and we've recently announced a board (and associated beta program > that provide free boards to open source developers) so there's some hardware to > run on as well. > > I'd like to request that the Porters Group sponsors this project with me as the > lead. > > Thanks! From adinn at redhat.com Fri Feb 9 14:08:05 2018 From: adinn at redhat.com (Andrew Dinn) Date: Fri, 9 Feb 2018 14:08:05 +0000 Subject: Project proposal: RISC-V port In-Reply-To: <1518173841.2854.29.camel@gmail.com> References: <1518173841.2854.29.camel@gmail.com> Message-ID: <6763ccdb-c0f7-46b9-809e-f476abad9407@redhat.com> On 09/02/18 10:57, Edward Nevill wrote: > I would like to voice my support for the creation of this project. Ditto! > I am happy to devote some 'spare' time to this project, but this will > me limited to a few hours per week. I wish I could make a similar offer but unfortunately I cannot make that commitment at present. > I agree with the overall approach you outline below. You will > probably end up doing C1 anyway. The s390 port tried to do it without > doing C1 and they ended up doing C1. I'd second that view. Also, C1 is more valuable than it appears e.g. it is still very valuable as a companion to Graal when the latter replaces C2 via JVMCI. > Andrew Haley's suggestion of using a built in simulator is a good > one. This was the approach used on the aarch64 project and it was > invaluable not just in terms of development time in the absence of > hardware but in terms of debuggability. Also OpenJDK depends on a > huge list of packages to build. Using this approach you can build and > run on x86 while all the dependant packages are being ported. I agree. This was an enormous boost to productivity when doing the AArch64 port and I would recommend it to anyone doing a port -- especially while early chips still run the risk of hardware bugs. Andrew Haley and I did document this process, albeit only in overview, in our FOSDEM talk from 2013. I'd be happy to help anyone wishing to attempt the same trick understand in more detail how we did it -- in particular how we implemented debug support in the simulator (of course, the AArch64 sim code, including debugger is still available on sourceforge and the jdk code which used it is still in the AArch64 port repo). regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From cthalinger at twitter.com Wed Feb 14 02:56:55 2018 From: cthalinger at twitter.com (Christian Thalinger) Date: Tue, 13 Feb 2018 18:56:55 -0800 Subject: Project proposal: RISC-V port In-Reply-To: <6763ccdb-c0f7-46b9-809e-f476abad9407@redhat.com> References: <1518173841.2854.29.camel@gmail.com> <6763ccdb-c0f7-46b9-809e-f476abad9407@redhat.com> Message-ID: <6A9A634A-59B9-4BC1-ADF0-591EAD1967AE@twitter.com> > On Feb 9, 2018, at 6:08 AM, Andrew Dinn wrote: > > On 09/02/18 10:57, Edward Nevill wrote: >> I would like to voice my support for the creation of this project. > > Ditto! > >> I am happy to devote some 'spare' time to this project, but this will >> me limited to a few hours per week. > > I wish I could make a similar offer but unfortunately I cannot make that > commitment at present. > >> I agree with the overall approach you outline below. You will >> probably end up doing C1 anyway. The s390 port tried to do it without >> doing C1 and they ended up doing C1. > > I'd second that view. Also, C1 is more valuable than it appears e.g. it > is still very valuable as a companion to Graal when the latter replaces > C2 via JVMCI. ?or don?t do C2 or C1 at all and just do Graal and use AOT :-) Everything else is a waste of time, in my very biased opinion. > >> Andrew Haley's suggestion of using a built in simulator is a good >> one. This was the approach used on the aarch64 project and it was >> invaluable not just in terms of development time in the absence of >> hardware but in terms of debuggability. Also OpenJDK depends on a >> huge list of packages to build. Using this approach you can build and >> run on x86 while all the dependant packages are being ported. > > I agree. This was an enormous boost to productivity when doing the > AArch64 port and I would recommend it to anyone doing a port -- > especially while early chips still run the risk of hardware bugs. > > Andrew Haley and I did document this process, albeit only in overview, > in our FOSDEM talk from 2013. I'd be happy to help anyone wishing to > attempt the same trick understand in more detail how we did it -- in > particular how we implemented debug support in the simulator (of course, > the AArch64 sim code, including debugger is still available on > sourceforge and the jdk code which used it is still in the AArch64 port > repo). > > regards, > > > Andrew Dinn > ----------- > Senior Principal Software Engineer > Red Hat UK Ltd > Registered in England and Wales under Company Registration No. 03798903 > Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From thomas.wuerthinger at oracle.com Wed Feb 14 11:24:48 2018 From: thomas.wuerthinger at oracle.com (Thomas Wuerthinger) Date: Wed, 14 Feb 2018 12:24:48 +0100 Subject: Project proposal: RISC-V port In-Reply-To: <6763ccdb-c0f7-46b9-809e-f476abad9407@redhat.com> References: <1518173841.2854.29.camel@gmail.com> <6763ccdb-c0f7-46b9-809e-f476abad9407@redhat.com> Message-ID: We are working on a Graal configuration that can be competitive with C1 in terms of compilation times. Graal?s design is actually much closer to C1 than C2. Significant parts including backend and register allocation originate directly from a port of C1 sources from C++ to Java (e.g., https://github.com/beehive-lab/Maxine-VM/commit/75e69aeccaf9960c7e842de40e41f8b518273e7d). - thomas > On 9 Feb 2018, at 15:08, Andrew Dinn wrote: > > On 09/02/18 10:57, Edward Nevill wrote: > >> I agree with the overall approach you outline below. You will >> probably end up doing C1 anyway. The s390 port tried to do it without >> doing C1 and they ended up doing C1. > > I'd second that view. Also, C1 is more valuable than it appears e.g. it > is still very valuable as a companion to Graal when the latter replaces > C2 via JVMCI. From adinn at redhat.com Wed Feb 14 13:05:41 2018 From: adinn at redhat.com (Andrew Dinn) Date: Wed, 14 Feb 2018 13:05:41 +0000 Subject: Project proposal: RISC-V port In-Reply-To: <6A9A634A-59B9-4BC1-ADF0-591EAD1967AE@twitter.com> References: <1518173841.2854.29.camel@gmail.com> <6763ccdb-c0f7-46b9-809e-f476abad9407@redhat.com> <6A9A634A-59B9-4BC1-ADF0-591EAD1967AE@twitter.com> Message-ID: On 14/02/18 02:56, Christian Thalinger wrote: >> On Feb 9, 2018, at 6:08 AM, Andrew Dinn wrote: >> I'd second that view. Also, C1 is more valuable than it appears e.g. it >> is still very valuable as a companion to Graal when the latter replaces >> C2 via JVMCI. > > ?or don?t do C2 or C1 at all and just do Graal and use AOT :-) > > Everything else is a waste of time, in my very biased opinion. This is a bit of a diversion from the original topic but it is relevant and also a relevant subject to discuss on discuss list so here goes ... First, let me state that I don't want to suggest that we don't pursue Graal because that is the exact opposite of what I believe. I think Graal is a critical tool for pursuing a lot of very interesting and highly important goals for the JVM. However, I think the current code base is going to need to mature for a lot longer (and, hence, require a lot more developer input) before it will be in any way capable of replacing C2 as the production compiler of choice. That's not primarily a question of making it generate comparably performant code in present or near-present circumstances (yes, Chris, that means you :-p so don't start quoting x86 benchmark figures at me and claiming the job is nearly done). It's also about ensuring that Graal is capable of continuing to deliver high quality code in the face of currently unmet and/or future requirements. What do I mean by that? Well, I found some troubling issues with the code base when trying to get Graal to generate decent quality AArch64 code. I would classify the problem as significant technical debt accumulated on the way to making x86 work well (which, indeed, it does). I suspect similar problems are going to bite a RISC-V port of Graal (especially as regards weak vs TSO memory model). I also worry they the same technical debt may make reliable implementation of new JVM features more difficult than it ought to be. C2, by contrast, is a well known implementation with well-known merits and flaws (yeah, it's old, people have kicked the tires). So, we know what we can and can't do with it and, in particular, how it will cater for upcoming JVM changes. The biggest flaw that gets cited (especially by Chris :-) is: it is so hard to learn C2 hat only a very few people know how it works. Having actually fixed some reasonable sized and reasonably complex things in both Graal and C2, I'm not personally convinced that Graal is any different in that regard. What I find more pertinent: having been pointed at the relevant literature some while back by John (and Kim?) -- Principles of Program Analysis by Nielson, Nielson and Hankin -- I am of the opinion that C2 actually has a much firmer theoretical footing than I have been able to spot in Graal. Also, I believe C2's use of the infamous sea of nodes and its type lattice implementation means that the code sits more cleanly and clearly within that theoretical framework than Graal does in whatever formal model it is based on. It looks like it relies on the same sort of theory but it's hard for me to tell how well it matches it, given the complexity and verbosity of the Graal class base. I know Graal has things that are 'sort-of' equivalent -- e.g. for the C2 type lattice we have Graal stamps. However, the former is clean and complete (albeit with known failure points) whereas the Graal version makes a real hash of reference types and then mostly ignores them, instead relying on location types to distinguish different memory slices. C2 cleanly and /clearly/ implements the type lattice model in the code base and employs on it, as far as possible, to retain maximal type info. I am not at all sure that Graal stamps live up to the requirements for iterative graph transforms to be valid. Oh and while we are here I'll note that location types seem to have been shoe-horned in in a horribly messy way. Method getLocationType is overloaded (on about 20 or so different types of access node -- yes really) via 3 (or more?) different interfaces. However, the method also exists in, and is called direct from, classes which don't implement any of those interfaces. This method is used to signal the memory slice operated on by an access, Unfortunately, it is also overloaded on membars to return a value that poisons all memory slices. That dual contract makes implementing a single node to model both an access combined with a memory barrier an impossibility. That is a disaster for an architecture like AArch64 which wants to model an instruction that can be generated as an ldar or stlr. Similarly, in place of the sea of nodes we have a plethora of fixed nodes for the control flow graph and floating nodes for stuff that is not pinned to control flow. That looks like a nice simplification but one of the problems I came across (match rules not matching) was precisely because this 'simplification' forced false control dependencies onto a match set containing pure dataflow dependencies, thus poisoning a lot of perfectly valid matches. Essentially the check for the match reduction serialized the floating graph and fixed graph into an arbitrarily chosen full order and then found a 'fake' intervening side-effect because some incidental node ended up between two of the matched nodes. In order to fix this I had to give up on using match rules and instead introduce yet another transform phase. No such false dependency occurs in the C2 graph. So, its match rules can happily reduce equivalent cases. Sea of nodes control graphs may indeed be harder to follow than the fixed node tree but that's because they model the dependencies more cleanly. It might be possible to upgrade Graal's matcher so it can distinguish real and fake dependencies but that will require work -- n.b. work that is not needed when you have a single, simple, uniform and complete representation for dependencies. I realise most of the above detail is much more relevant to the Graal list than to this list. However, the point is not really to air these problems but to make it clear that issues of this significance exist and that they point at a larger problem: maturity takes time and experience, as do the reliability and awareness of what will and won't work that come with it. Much as I consider Graal to be a great, ongoing experiment I think C2 is going to be indispensable for quite some time. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From thomas.wuerthinger at oracle.com Wed Feb 14 14:22:00 2018 From: thomas.wuerthinger at oracle.com (Thomas Wuerthinger) Date: Wed, 14 Feb 2018 15:22:00 +0100 Subject: Project proposal: RISC-V port In-Reply-To: References: <1518173841.2854.29.camel@gmail.com> <6763ccdb-c0f7-46b9-809e-f476abad9407@redhat.com> <6A9A634A-59B9-4BC1-ADF0-591EAD1967AE@twitter.com> Message-ID: We welcome anybody who helps mature the code base. Different compilers have different strengths. Our focus is on improving performance of modern JVM workloads with Graal (like the one from Twitter). One can have long discussions whether this aspect or that aspect is ?cleaner? or has the better ?theoretical foundation?. Ultimately, the performance results are the objective measure that counts and what we care about most. We do have plans to improve the type system (in particular around reference types). We have however not seen scenarios where this would make a large difference for the given workload and therefore prioritised other optimisations. Compiler optimisations like loop transformations, code duplications, and inlining can help simplify the scenarios the compiler has to reason about and create additional performance opportunities without requiring a more complex type system. As mentioned, we are working on a Graal version that has the potential to replace both C1 and C2. It is however clearly at the discretion of the OpenJDK community if/when they will pick up any of these versions in the OpenJDK source base and build. Meanwhile, we are providing our own Graal-based builds for anybody who wants to test them. We are also happy to assist any experiments with Graal. Regards, thomas > On 14 Feb 2018, at 14:05, Andrew Dinn wrote: > > On 14/02/18 02:56, Christian Thalinger wrote: >>> On Feb 9, 2018, at 6:08 AM, Andrew Dinn wrote: >>> I'd second that view. Also, C1 is more valuable than it appears e.g. it >>> is still very valuable as a companion to Graal when the latter replaces >>> C2 via JVMCI. >> >> ?or don?t do C2 or C1 at all and just do Graal and use AOT :-) >> >> Everything else is a waste of time, in my very biased opinion. > This is a bit of a diversion from the original topic but it is relevant > and also a relevant subject to discuss on discuss list so here goes ... > > First, let me state that I don't want to suggest that we don't pursue > Graal because that is the exact opposite of what I believe. I think > Graal is a critical tool for pursuing a lot of very interesting and > highly important goals for the JVM. However, I think the current code > base is going to need to mature for a lot longer (and, hence, require a > lot more developer input) before it will be in any way capable of > replacing C2 as the production compiler of choice. > > That's not primarily a question of making it generate comparably > performant code in present or near-present circumstances (yes, Chris, > that means you :-p so don't start quoting x86 benchmark figures at me > and claiming the job is nearly done). It's also about ensuring that > Graal is capable of continuing to deliver high quality code in the face > of currently unmet and/or future requirements. > > What do I mean by that? Well, I found some troubling issues with the > code base when trying to get Graal to generate decent quality AArch64 > code. I would classify the problem as significant technical debt > accumulated on the way to making x86 work well (which, indeed, it does). > I suspect similar problems are going to bite a RISC-V port of Graal > (especially as regards weak vs TSO memory model). I also worry they the > same technical debt may make reliable implementation of new JVM features > more difficult than it ought to be. > > C2, by contrast, is a well known implementation with well-known merits > and flaws (yeah, it's old, people have kicked the tires). So, we know > what we can and can't do with it and, in particular, how it will cater > for upcoming JVM changes. > > The biggest flaw that gets cited (especially by Chris :-) is: it is so > hard to learn C2 hat only a very few people know how it works. Having > actually fixed some reasonable sized and reasonably complex things in > both Graal and C2, I'm not personally convinced that Graal is any > different in that regard. > > What I find more pertinent: having been pointed at the relevant > literature some while back by John (and Kim?) -- Principles of Program > Analysis by Nielson, Nielson and Hankin -- I am of the opinion that C2 > actually has a much firmer theoretical footing than I have been able to > spot in Graal. Also, I believe C2's use of the infamous sea of nodes and > its type lattice implementation means that the code sits more cleanly > and clearly within that theoretical framework than Graal does in > whatever formal model it is based on. It looks like it relies on the > same sort of theory but it's hard for me to tell how well it matches it, > given the complexity and verbosity of the Graal class base. > > I know Graal has things that are 'sort-of' equivalent -- e.g. for the C2 > type lattice we have Graal stamps. However, the former is clean and > complete (albeit with known failure points) whereas the Graal version > makes a real hash of reference types and then mostly ignores them, > instead relying on location types to distinguish different memory > slices. C2 cleanly and /clearly/ implements the type lattice model in > the code base and employs on it, as far as possible, to retain maximal > type info. I am not at all sure that Graal stamps live up to the > requirements for iterative graph transforms to be valid. > > Oh and while we are here I'll note that location types seem to have been > shoe-horned in in a horribly messy way. Method getLocationType is > overloaded (on about 20 or so different types of access node -- yes > really) via 3 (or more?) different interfaces. However, the method also > exists in, and is called direct from, classes which don't implement any > of those interfaces. This method is used to signal the memory slice > operated on by an access, Unfortunately, it is also overloaded on > membars to return a value that poisons all memory slices. That dual > contract makes implementing a single node to model both an access > combined with a memory barrier an impossibility. That is a disaster for > an architecture like AArch64 which wants to model an instruction that > can be generated as an ldar or stlr. > > Similarly, in place of the sea of nodes we have a plethora of fixed > nodes for the control flow graph and floating nodes for stuff that is > not pinned to control flow. That looks like a nice simplification but > one of the problems I came across (match rules not matching) was > precisely because this 'simplification' forced false control > dependencies onto a match set containing pure dataflow dependencies, > thus poisoning a lot of perfectly valid matches. Essentially the check > for the match reduction serialized the floating graph and fixed graph > into an arbitrarily chosen full order and then found a 'fake' > intervening side-effect because some incidental node ended up between > two of the matched nodes. In order to fix this I had to give up on using > match rules and instead introduce yet another transform phase. > > No such false dependency occurs in the C2 graph. So, its match rules can > happily reduce equivalent cases. Sea of nodes control graphs may indeed > be harder to follow than the fixed node tree but that's because they > model the dependencies more cleanly. It might be possible to upgrade > Graal's matcher so it can distinguish real and fake dependencies but > that will require work -- n.b. work that is not needed when you have a > single, simple, uniform and complete representation for dependencies. > > I realise most of the above detail is much more relevant to the Graal > list than to this list. However, the point is not really to air these > problems but to make it clear that issues of this significance exist and > that they point at a larger problem: maturity takes time and experience, > as do the reliability and awareness of what will and won't work that > come with it. Much as I consider Graal to be a great, ongoing experiment > I think C2 is going to be indispensable for quite some time. > > regards, > > > Andrew Dinn > ----------- > Senior Principal Software Engineer > Red Hat UK Ltd > Registered in England and Wales under Company Registration No. 03798903 > Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From jcoomes at twitter.com Wed Feb 21 06:04:16 2018 From: jcoomes at twitter.com (John Coomes) Date: Tue, 20 Feb 2018 22:04:16 -0800 Subject: Group Proposal, for further discussion: Vulnerability Group Message-ID: > On January 31, 2018 at 8:44 AM mark.reinhold at oracle.com wrote: > > > (This is not a call for votes; it is just a call for discussion.) > > To follow up on my initial call for discussion last August [1], I've > posted a revised proposal for the Vulnerability Group together with > the final version of the non-disclosure and license agreement, and > diffs of the final version with respect to the first version: > > http://cr.openjdk.java.net/~mr/ojvg/ > http://cr.openjdk.java.net/~mr/ojvg/ojvg-ndla-2018-01-30.pdf > http://cr.openjdk.java.net/~mr/ojvg/ojvg-ndla-2018-01-30-diffs.pdf > ... Hi Mark, I've read the NDLA and definitely struggled with the legalese. While our lawyers are reading it, I was hoping to get some clarification on the intent of the Group with regard to sharing information. I'm not asking you for a legal opinion, but for your opinion as an engineer on the expected operation of the Group. The most efficient way of developing, testing, and sharing vulnerability fixes is via a shared repository (at least IMHO). Obviously, any such repository would have to have access restrictions in place so that until the fixes were otherwise publicly disclosed, only Vulnerability Group Members would have access to the repo. The NDLA seems overly focused on the mailing list as a means of sharing information among Members, as that is the only means mentioned. First, is it the intent of the Group to allow sharing of vulnerability fixes ("Confidential Information" is the term used in the NDLA) among Members via means other than the mailing list? Second, more specifically, would a repository shared exclusively among Members be an acceptable means of sharing vulnerability fixes? If the answer to either of the above is yes, it would be helpful to amend the NDLA to make that clear. If the answer to either of the above is no, the obvious follow-on question is: Why not? Again, I'm asking for an opinion on the expected operation of the Group, not a legal opinion on the NDLA. Once the intent is clear, it should make it easier for the attorneys to analyze the language in the NDLA to verify it matches the intent. -John From aph at redhat.com Mon Feb 26 08:19:44 2018 From: aph at redhat.com (Andrew Haley) Date: Mon, 26 Feb 2018 08:19:44 +0000 Subject: Group Proposal, for further discussion: Vulnerability Group In-Reply-To: References: Message-ID: On 21/02/18 06:04, John Coomes wrote: > First, is it the intent of the Group to allow sharing of vulnerability > fixes ("Confidential Information" is the term used in the NDLA) among > Members via means other than the mailing list? Second, more specifically, > would a repository shared exclusively among Members be an acceptable means > of sharing vulnerability fixes? > > If the answer to either of the above is yes, it would be helpful to amend > the NDLA to make that clear. We don't want to overly restrict the means we use to communicate. Getting the legal agreement changed once it's signed will be extremely difficult. Having said that, a single shared repository that contains all of our most secret information and its entire history doesn't immediately sound to me like a good idea if we can avoid it. Whatever we do, we must agree to it as a group, with help and advice from other security experts. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From mark.reinhold at oracle.com Mon Feb 26 17:37:45 2018 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Mon, 26 Feb 2018 09:37:45 -0800 Subject: Group Proposal, for further discussion: Vulnerability Group In-Reply-To: References: Message-ID: <20180226093745.19880058@eggemoggin.niobe.net> 2018/2/20 22:04:16 -0800, John Coomes : > ... > > The most efficient way of developing, testing, and sharing vulnerability > fixes is via a shared repository (at least IMHO). Obviously, any such > repository would have to have access restrictions in place so that until > the fixes were otherwise publicly disclosed, only Vulnerability Group > Members would have access to the repo. The NDLA seems overly focused on > the mailing list as a means of sharing information among Members, as that > is the only means mentioned. I will not comment here upon the NDLA, nor upon interpretations of it. Anything I write here is intended only to clarify what I wrote in the proposal [1]. > First, is it the intent of the Group to allow sharing of vulnerability > fixes ("Confidential Information" is the term used in the NDLA) among > Members via means other than the mailing list? The proposal describes two communication channels for the discussion of vulnerability fixes: The vuln-dev list and the JDK bug system (JBS) [2]. It does not explicitly limit the sharing of fixes to those two channels. The adoption of some other channel would have to be consistent with the proposal, agreed to by the Group, and subject to the NDLA. > Second, more specifically, > would a repository shared exclusively among Members be an acceptable means > of sharing vulnerability fixes? It might, if it could be made sufficiently secure, but I share Andrew's concern, expressed nearby -- a single repository containing all current and historical vulnerability information could itself present security risks, and would require careful thought. > If the answer to either of the above is yes, it would be helpful to amend > the NDLA to make that clear. The NDLA has been available in draft form since last August. If you think that a change is needed at this late date then we can certainly discuss it, but it would further delay the formation of the Group. - Mark [1] http://cr.openjdk.java.net/~mr/ojvg/ [2] http://cr.openjdk.java.net/~mr/ojvg/#communication-channels From cello86 at gmail.com Wed Feb 28 10:18:50 2018 From: cello86 at gmail.com (Marcello Lorenzi) Date: Wed, 28 Feb 2018 11:18:50 +0100 Subject: sun.rmi.transport.tcp.responseTimeout ignored Message-ID: Hi All, We started a new Java standalone application with OpenJDK Runtime Environment (build 1.8.0_161-b14). This application has a network problem to connect to a RMI service and the application threads remained in hang status. We tried to apply the parameter sun.rmi.transport.tcp.responseTimeout but the threads on JVM side remained in stuck and the connection to the RMI server was in SYN_SENT status. Could it be related with bug https://bugs.openjdk.java.net/browse/JDK-8151212? Thanks, Marcello From martijnverburg at gmail.com Wed Feb 28 11:27:41 2018 From: martijnverburg at gmail.com (Martijn Verburg) Date: Wed, 28 Feb 2018 11:27:41 +0000 Subject: sun.rmi.transport.tcp.responseTimeout ignored In-Reply-To: References: Message-ID: Hi Marcello, Welcome to OpenJDK. The mailing list you're after is core-libs Cheers, Martijn On 28 February 2018 at 10:18, Marcello Lorenzi wrote: > Hi All, > We started a new Java standalone application with OpenJDK Runtime > Environment (build 1.8.0_161-b14). This application has a network problem > to connect to a RMI service and the application threads remained in hang > status. We tried to apply the parameter > sun.rmi.transport.tcp.responseTimeout but the threads on JVM side remained > in stuck and the connection to the RMI server was in SYN_SENT status. Could > it be related with bug https://bugs.openjdk.java.net/browse/JDK-8151212? > > Thanks, > Marcello > From mark.reinhold at oracle.com Wed Feb 28 16:15:52 2018 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Wed, 28 Feb 2018 08:15:52 -0800 Subject: Group Proposal, for further discussion: Vulnerability Group In-Reply-To: <20180131164449.2D7BB15E0AA@eggemoggin.niobe.net> References: <20180131164449.2D7BB15E0AA@eggemoggin.niobe.net> Message-ID: <20180228081552.748201064@eggemoggin.niobe.net> 2018/1/31 8:44:49 -0800, mark.reinhold at oracle.com: > To follow up on my initial call for discussion last August [1], I've > posted a revised proposal for the Vulnerability Group together with > the final version of the non-disclosure and license agreement, and > diffs of the final version with respect to the first version: > > http://cr.openjdk.java.net/~mr/ojvg/ > http://cr.openjdk.java.net/~mr/ojvg/ojvg-ndla-2018-01-30.pdf > http://cr.openjdk.java.net/~mr/ojvg/ojvg-ndla-2018-01-30-diffs.pdf > > The only change to the proposal itself is to add a link to define the > term "rough consensus," as suggested by Volker [2]. FYI, I've asked the Governing Board to approve the creation of this Group: http://mail.openjdk.java.net/pipermail/gb-discuss/2018-February/000329.html - Mark From jcoomes at twitter.com Wed Feb 28 22:13:23 2018 From: jcoomes at twitter.com (John Coomes) Date: Wed, 28 Feb 2018 14:13:23 -0800 Subject: Group Proposal, for further discussion: Vulnerability Group In-Reply-To: <20180226093745.19880058@eggemoggin.niobe.net> References: <20180226093745.19880058@eggemoggin.niobe.net> Message-ID: On Mon, Feb 26, 2018 at 9:37 AM, wrote: > 2018/2/20 22:04:16 -0800, John Coomes : > > ... > First, is it the intent of the Group to allow sharing of vulnerability > > fixes ("Confidential Information" is the term used in the NDLA) among > > Members via means other than the mailing list? > > The proposal describes two communication channels for the discussion of > vulnerability fixes: The vuln-dev list and the JDK bug system (JBS) [2]. > It does not explicitly limit the sharing of fixes to those two channels. > The adoption of some other channel would have to be consistent with the > proposal, agreed to by the Group, and subject to the NDLA. > > > Second, more > specifically, > > would a repository shared exclusively among Members be an acceptable > means > > of sharing vulnerability fixes? > > It might, if it could be made sufficiently secure, but I share Andrew's > concern, expressed nearby -- a single repository containing all current > and historical vulnerability information could itself present security > risks, and would require careful thought. > Hi Mark, Thanks for clarifying the intent of the proposal. We're meeting with our legal folks today to review the NDLA as it relates to this; I will follow up again soon. Assuming proper management, I think the risks of a shared repo are comparable to (and potentially even lower than) the mailing list and other alternatives. Clearly this needs a longer discussion; I simply want to ensure that that NDLA is flexible enough to allow it and other reasonable alternatives. -John