From roman at kennke.org Mon Jul 6 10:03:24 2015 From: roman at kennke.org (Roman Kennke) Date: Mon, 06 Jul 2015 12:03:24 +0200 Subject: Project proposal: Shenandoah In-Reply-To: <54F22501.8050304@oracle.com> References: <1424371356.29919.20.camel@localhost> <54F0B27B.3010401@oracle.com> <1425063556.32230.92.camel@localhost> <54F0E172.3090404@oracle.com> <1425128485.32230.109.camel@localhost> <54F22501.8050304@oracle.com> Message-ID: <1436177004.5893.6.camel@kennke.org> Hi all, What is the status of this Shenandoah project proposal? Has the Hotspot group leadership issue been resolved? We still need a Hotspot group lead to announce support for project creation... Kind regards, Roman Am Samstag, den 28.02.2015, 12:28 -0800 schrieb Jon Masamitsu: > Roman, > > Thank you for the further information. This large a contribution > is new territory for us so we'll be taking a bit of time to mull it > over. > > Jon > > On 2/28/2015 5:01 AM, Roman Kennke wrote: > > Hi Jon, > > > >>> Shenandoah is developed and maintained by Red Hat, yes, but the > >>> intention is, and has always been, to integrate it into upstream > >>> Hotspot, if OpenJDK people think it's feasible. The first step in this > >>> direction is the creation of a Shenandoah project (this proposal) and we > >>> also want to move forward with the Shenandoah JEP 189. > >> I would also like to understand how an integration of Shenandoah into > >> Hotspot would affect my day-to-day work. For example if I build Hotspot > >> will I skip the build of Shenandoah sources by default? > > Build-wise Shenandoah is a GC like all other GCs. When you build > > Hotspot, you build Shenandoah. It will be excluded by setting > > INCLUDE_ALL_GCS to false, iirc. We could add a build flag to exclude > > Shenandoah, but I don't really see the point of it. > > > > Shenandoah is a bit special because it requires read and write barriers > > in the interpreter, C1, C2 and the runtime. We tried as much as possible > > to make this a clean interface, such to avoid scattering Shenandoah code > > all over the place. One of our goals is to not impact performance or > > behaviour with any other GC. If any other GC in the future requires > > similar barriers, it could just implement those interfaces. It is not > > perfect yet and needs some cleanup. > > > > All that being said, the intention of this project proposal is not > > directly to integrate Shenandoah into upstream Hotspot yet (that's the > > purpose of the JEP, ultimately), but to provide a development space for > > Shenandoah under the OpenJDK umbrella, where it belongs, where OpenJDK > > people can easily try it out, etc. > > > > BTW, according to http://openjdk.java.net/projects/#new-project we need > > a Hotspot group lead to declare to sponsor the project: > > > > "At least one Group Lead must declare that their Group is a sponsor of > > the proposed Project." > > > > Best regards, > > Roman > > > > > >> Jon > >> > >>> Best regards, > >>> Roman > >>> > >>>> My impression of Shenandoah was that it would be a project > >>>> developed and maintained by Redhat and (I don't recall where > >>>> this last part of my recollection comes from) that it would be kept > >>>> separate from the OpenJDK hotspot sources. Is that all > >>>> correct? > >>>> > >>>> Jon > >>>> > >>>> On 2/19/2015 10:42 AM, Roman Kennke wrote: > >>>>> I'd like to discuss the creation of the project Shenandoah with myself > >>>>> *and/or* Christine Flood as initial lead and the Hotspot group as > >>>>> sponsoring group. > >>>>> > >>>>> It's aim is to implement a new garbage collector that reduces GC pause > >>>>> times for applications that require really large heaps. Existing GCs > >>>>> show pause times of several 100ms up to several seconds on heaps > > >>>>> 100GB. That is because they need to stop all Java threads for compacting > >>>>> the heap. Shenandoah implements a new algorithm that allows to compact > >>>>> heap while only stopping the Java threads briefly for root scanning, and > >>>>> then evacuates the heap concurrently. This makes pause times unrelated > >>>>> to the heap size and only proportional to the root set size. > >>>>> > >>>>> Shenandoah has so far been developed as part of the IcedTea project: > >>>>> > >>>>> http://icedtea.classpath.org/wiki/Shenandoah > >>>>> > >>>>> It has usable implementations for OpenJDK9 and OpenJDK8. > >>>>> > >>>>> Roman Kennke (me) is Principle Software Engineer at Red Hat, working on > >>>>> Shenandoah since two years now. Before this, he worked on Thermostat, > >>>>> and contributed to OpenJDK in several areas, most importantly the Zero > >>>>> and Shark ports, graphics, and ports to embedded platforms. > >>>>> > >>>>> Christine H. Flood is a prinicpal software engineer at Red Hat. Most > >>>>> recently she's been working on Shenandoah, before that she worked at > >>>>> Oracle/Sun labs on the Fortress programming language, and on JVM > >>>>> Scalability. She's one of the inventors of both the parallel GC > >>>>> algorithm and G1. > >>>>> > >>>>> Initial committers and reviewers would be me and Christine. > >>>>> > >>>>> Could we both be project leads? Christine doesn't have an OpenJDK > >>>>> idendity yet... > >>>>> > >>>>> Best regards, > >>>>> Roman > >>>>> > >>>>> > >> > > > > From asashour at yahoo.com Tue Jul 7 07:19:20 2015 From: asashour at yahoo.com (Ahmed Ashour) Date: Tue, 7 Jul 2015 07:19:20 +0000 (UTC) Subject: Introduction Message-ID: <387857274.261255.1436253560428.JavaMail.yahoo@mail.yahoo.com> Hi everybody, Hope you are fine. I am one of the developers of HtmlUnit, which is an open-source headless browser simulator in java (Chrome, FF, and IE). It supports JavaScript, DOM, CSS, etc. My current OpenJDK interest is Nashorn, and the plan is replace Rhino with it, in the next months. There are some general points I would like to take your opinion about: ? ? - What is the right place to ask about general/user Nashorn questions? As I guess nashorn-dev is not the right place for basic ones.? ? - Since the development is in JDK 9 mainly, what is commonly used IDE? Eclipse support for Java 9 [1] doesn't work at the moment.? ? - I believe the JDK source code should be a model, for all Java developers. ?I guess there is no code style tool used, but I am not sure why.? ? - In Mercurial, what is the difference between jdk9/dev and jdk9/jdk9 [2]? ? - What is the list to post typos patch for 'javax.script' package [3], is it nashorn-dev or jdk9-dev? Thanks a lot for your guidance. Ahmed [1]?https://wiki.eclipse.org/Java9[2]?http://hg.openjdk.java.net/jdk9[3]?http://hg.openjdk.java.net/jdk9/dev/jdk/file/cce0dee6d995/src/java.scripting/share/classes/javax/script From martijnverburg at gmail.com Tue Jul 7 08:20:12 2015 From: martijnverburg at gmail.com (Martijn Verburg) Date: Tue, 7 Jul 2015 09:20:12 +0100 Subject: Introduction In-Reply-To: <387857274.261255.1436253560428.JavaMail.yahoo@mail.yahoo.com> References: <387857274.261255.1436253560428.JavaMail.yahoo@mail.yahoo.com> Message-ID: Hi Ahmed, Welcome to OpenJDK! A great place to ask these types of questions in is the adoption group . I'll CC them in here so you can see what mailing list to sign up for. Some answers inline: On 7 July 2015 at 08:19, Ahmed Ashour wrote: > Hi everybody, > Hope you are fine. > I am one of the developers of HtmlUnit, which is an open-source headless > browser simulator in java (Chrome, FF, and IE). It supports JavaScript, > DOM, CSS, etc. > My current OpenJDK interest is Nashorn, and the plan is replace Rhino with > it, in the next months. > Great! Nashorn is a very strong replacement and improvement on Rhino. > There are some general points I would like to take your opinion about: > - What is the right place to ask about general/user Nashorn questions? > As I guess nashorn-dev is not the right place for basic ones. Stackoverflow is actually a pretty good place for Nashorn questions . > - Since the development is in JDK 9 mainly, what is commonly used IDE? > Eclipse support for Java 9 [1] doesn't work at the moment. All 3 major IDEs have early access versions with Java 9 support. Please not that in particular the modularisation work in JDK9 is not yet feature complete and so there will likely be many glitches: * Eclipse * NetBeans * IntelliJ 14.1 > - I believe the JDK source code should be a model, for all Java > developers. I guess there is no code style tool used, but I am not sure > why. Each OpenJDK project maintains its own code style (the reasons are probably long forgotten in history). As change sets that are purely stylistic in nature can cause merge issues in large code bases, coming to a common style in OpenJDK is not a priority at this stage. That said, the Adoption Group has been exploring some tools and processes that could be used. Jump over there if you'd like to get involved. > - In Mercurial, what is the difference between jdk9/dev and jdk9/jdk9 > [2] jdk9-dev is the development forest for JDK9 corelibs and some other APIs. jdk9/jdk9 is more like the semi-stable integration forest for all of OpenJDK '9', it has regular merges in from Hotspot, Nashorn, langtools and jaxws. If you are a fairly casual contributor/explorer then jdk9 is the one you want to base things off. > - What is the list to post typos patch for 'javax.script' package [3], is > it nashorn-dev or jdk9-dev? > nashorn-dev in the first instance, the helpful people there will advise if it needs to go to jdk9-dev as well. > Thanks a lot for your guidance. > Hope that helps! Cheers, Martijn > Ahmed > [1] https://wiki.eclipse.org/Java9[2] http://hg.openjdk.java.net/jdk9[3] > http://hg.openjdk.java.net/jdk9/dev/jdk/file/cce0dee6d995/src/java.scripting/share/classes/javax/script > > From jon.masamitsu at oracle.com Wed Jul 8 16:41:24 2015 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Wed, 08 Jul 2015 09:41:24 -0700 Subject: Project proposal: Shenandoah In-Reply-To: <1436177004.5893.6.camel@kennke.org> References: <1424371356.29919.20.camel@localhost> <54F0B27B.3010401@oracle.com> <1425063556.32230.92.camel@localhost> <54F0E172.3090404@oracle.com> <1425128485.32230.109.camel@localhost> <54F22501.8050304@oracle.com> <1436177004.5893.6.camel@kennke.org> Message-ID: <559D52B4.6020906@oracle.com> Roman, We don't have a Hotspot group lead just yet. The vote among members has been completed but there is still some approval process that needs to be done. I was told governing board approval or something like that. Jon On 07/06/2015 03:03 AM, Roman Kennke wrote: > Hi all, > > What is the status of this Shenandoah project proposal? Has the Hotspot > group leadership issue been resolved? We still need a Hotspot group lead > to announce support for project creation... > > Kind regards, > Roman > > > Am Samstag, den 28.02.2015, 12:28 -0800 schrieb Jon Masamitsu: >> Roman, >> >> Thank you for the further information. This large a contribution >> is new territory for us so we'll be taking a bit of time to mull it >> over. >> >> Jon >> >> On 2/28/2015 5:01 AM, Roman Kennke wrote: >>> Hi Jon, >>> >>>>> Shenandoah is developed and maintained by Red Hat, yes, but the >>>>> intention is, and has always been, to integrate it into upstream >>>>> Hotspot, if OpenJDK people think it's feasible. The first step in this >>>>> direction is the creation of a Shenandoah project (this proposal) and we >>>>> also want to move forward with the Shenandoah JEP 189. >>>> I would also like to understand how an integration of Shenandoah into >>>> Hotspot would affect my day-to-day work. For example if I build Hotspot >>>> will I skip the build of Shenandoah sources by default? >>> Build-wise Shenandoah is a GC like all other GCs. When you build >>> Hotspot, you build Shenandoah. It will be excluded by setting >>> INCLUDE_ALL_GCS to false, iirc. We could add a build flag to exclude >>> Shenandoah, but I don't really see the point of it. >>> >>> Shenandoah is a bit special because it requires read and write barriers >>> in the interpreter, C1, C2 and the runtime. We tried as much as possible >>> to make this a clean interface, such to avoid scattering Shenandoah code >>> all over the place. One of our goals is to not impact performance or >>> behaviour with any other GC. If any other GC in the future requires >>> similar barriers, it could just implement those interfaces. It is not >>> perfect yet and needs some cleanup. >>> >>> All that being said, the intention of this project proposal is not >>> directly to integrate Shenandoah into upstream Hotspot yet (that's the >>> purpose of the JEP, ultimately), but to provide a development space for >>> Shenandoah under the OpenJDK umbrella, where it belongs, where OpenJDK >>> people can easily try it out, etc. >>> >>> BTW, according to http://openjdk.java.net/projects/#new-project we need >>> a Hotspot group lead to declare to sponsor the project: >>> >>> "At least one Group Lead must declare that their Group is a sponsor of >>> the proposed Project." >>> >>> Best regards, >>> Roman >>> >>> >>>> Jon >>>> >>>>> Best regards, >>>>> Roman >>>>> >>>>>> My impression of Shenandoah was that it would be a project >>>>>> developed and maintained by Redhat and (I don't recall where >>>>>> this last part of my recollection comes from) that it would be kept >>>>>> separate from the OpenJDK hotspot sources. Is that all >>>>>> correct? >>>>>> >>>>>> Jon >>>>>> >>>>>> On 2/19/2015 10:42 AM, Roman Kennke wrote: >>>>>>> I'd like to discuss the creation of the project Shenandoah with myself >>>>>>> *and/or* Christine Flood as initial lead and the Hotspot group as >>>>>>> sponsoring group. >>>>>>> >>>>>>> It's aim is to implement a new garbage collector that reduces GC pause >>>>>>> times for applications that require really large heaps. Existing GCs >>>>>>> show pause times of several 100ms up to several seconds on heaps > >>>>>>> 100GB. That is because they need to stop all Java threads for compacting >>>>>>> the heap. Shenandoah implements a new algorithm that allows to compact >>>>>>> heap while only stopping the Java threads briefly for root scanning, and >>>>>>> then evacuates the heap concurrently. This makes pause times unrelated >>>>>>> to the heap size and only proportional to the root set size. >>>>>>> >>>>>>> Shenandoah has so far been developed as part of the IcedTea project: >>>>>>> >>>>>>> http://icedtea.classpath.org/wiki/Shenandoah >>>>>>> >>>>>>> It has usable implementations for OpenJDK9 and OpenJDK8. >>>>>>> >>>>>>> Roman Kennke (me) is Principle Software Engineer at Red Hat, working on >>>>>>> Shenandoah since two years now. Before this, he worked on Thermostat, >>>>>>> and contributed to OpenJDK in several areas, most importantly the Zero >>>>>>> and Shark ports, graphics, and ports to embedded platforms. >>>>>>> >>>>>>> Christine H. Flood is a prinicpal software engineer at Red Hat. Most >>>>>>> recently she's been working on Shenandoah, before that she worked at >>>>>>> Oracle/Sun labs on the Fortress programming language, and on JVM >>>>>>> Scalability. She's one of the inventors of both the parallel GC >>>>>>> algorithm and G1. >>>>>>> >>>>>>> Initial committers and reviewers would be me and Christine. >>>>>>> >>>>>>> Could we both be project leads? Christine doesn't have an OpenJDK >>>>>>> idendity yet... >>>>>>> >>>>>>> Best regards, >>>>>>> Roman >>>>>>> >>>>>>> >> > From dalibor.topic at oracle.com Thu Jul 9 12:32:20 2015 From: dalibor.topic at oracle.com (dalibor topic) Date: Thu, 9 Jul 2015 14:32:20 +0200 Subject: Project proposal: Shenandoah In-Reply-To: <559D52B4.6020906@oracle.com> References: <1424371356.29919.20.camel@localhost> <54F0B27B.3010401@oracle.com> <1425063556.32230.92.camel@localhost> <54F0E172.3090404@oracle.com> <1425128485.32230.109.camel@localhost> <54F22501.8050304@oracle.com> <1436177004.5893.6.camel@kennke.org> <559D52B4.6020906@oracle.com> Message-ID: <559E69D4.5070203@oracle.com> On 08.07.2015 18:41, Jon Masamitsu wrote: > Roman, > > We don't have a Hotspot group lead just yet. > > The vote among members has been completed but > there is still some approval process that needs to be done. > I was told governing board approval or something > like that. That's correct - see step 4 of http://openjdk.java.net/groups/#lead 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, Astrid Kepper, Val Maher Oracle is committed to developing practices and products that help protect the environment From volker.simonis at gmail.com Thu Jul 23 15:43:06 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 23 Jul 2015 17:43:06 +0200 Subject: Inconsistency in the JEP 2.0, draft 2 document Message-ID: Hi, the JEP 2.0, draft 2 document [1] states: The first three states for a Feature or Infrastructure JEP are: Draft - Initial state in which the JEP is drafted, reviewed, revised, and endorsed Submitted - By the JEP?s owner, declaring the JEP ready to be evaluated for the JDK Roadmap Candidate - By the OpenJDK Lead, to add the JEP to the JDK Roadmap However that's not totally accurate, because a JEP owner can only move a JEP from "Draft" to "Submitted" if he is also a Committer. This restriction is made at the end of the document in the section "Additional changes to the JEP Process". So maybe the before mentioned section could be clarified and reworded to something like: Submitted - By the JEP?s owner (if he is a Committer or by a sponsor with Committer status otherwise), declaring the JEP ready to be evaluated for the JDK Roadmap Thank you and best regards, Volker [1] http://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html