From bruno.kremel at gmail.com Sun Apr 2 17:09:39 2017 From: bruno.kremel at gmail.com (Bruno Kremel) Date: Sun, 02 Apr 2017 19:09:39 +0200 Subject: Fwd: Crosscopiled OpenJRE 9 crashes on java -h References: <8737dqn3sr.fsf@bruno-dell> Message-ID: <871stan3cc.fsf@bruno-dell> Bruno Kremel writes: Hi All, I have crosscompiled OpenJDK 9 for ARM (Freescale iMX6). Now I have issues running it. If I run: # java --help # # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x76e40324, pid=234, tid=235 # # JRE version: (9.0) (build ) # Java VM: OpenJDK Client VM (9-internal+0-adhoc.bruno.openjdk-jdk-9163, mixed mode, sharing, serial gc, linux-arm) # Problematic frame: # C [libc.so.6+0x58324] strlen+0x23 # # No core dump will be written. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again # # An error report file with more information is saved as: # /root/hs_err_pid234.log # # If you would like to submit a bug report, please visit: # http://bugreport.java.com/bugreport/crash.jsp # Aborted I also attach the generated error log: I built tag 163 in HG. These are the configure switches: ./configure --with-freetype-include=/home/bruno/linux/buildroot/output/host/usr/arm-buildroot-linux-gnueabihf/sysroot/usr/include/freetype2 --with-freetype-lib=/home/bruno/linux/buildroot/output/host/usr/arm-buildroot-linux-gnueabihf/sysroot/usr/lib --with-freetype=/home/bruno/linux/buildroot/output/host/usr/arm-buildroot-linux-gnueabihf/sysroot/usr/ --with-debug-level=release --with-native-debug-symbols=none --openjdk-target=arm-buildroot-linux-gnueabihf --with-sys-root=/home/bruno/linux/buildroot/output/host/usr/arm-buildroot-linux-gnueabihf/sysroot --with-tools-dir=/home/bruno/linux/buildroot/output/host --disable-freetype-bundling --enable-unlimited-crypto --enable-headless-only --disable-warnings-as-errors --with-abi-profile=arm-vfp-hflt --with-jvm-variants=client OBJCOPY=/home/bruno/linux/buildroot/output/host/usr/bin/arm-linux-gnueabihf-objcopy STRIP=/home/bruno/linux/buildroot/output/host/usr/bin/arm-linux-gnueabihf-strip CPP_FLAGS=-lstdc++ CXX_FLAGS=-lstdc++ CPP=/home/bruno/linux/buildroot/output/host/usr/bin/arm-linux-gnueabihf-cpp CXX=/home/bruno/linux/buildroot/output/host/usr/bin/arm-linux-gnueabihf-g++ CC=/home/bruno/linux/buildroot/output/host/usr/bin/arm-linux-gnueabihf-gcc LD=/home/bruno/linux/buildroot/output/host/usr/bin/arm-linux-gnueabihf-gcc And make: make OBJCOPY=/home/bruno/linux/buildroot/output/host/usr/bin/arm-linux-gnueabihf-objcopy \ STRIP=/home/bruno/linux/buildroot/output/host/usr/bin/arm-linux-gnueabihf-strip \ BUILD_CC=gcc BUILD_LD=gcc \ CPP=/home/bruno/linux/buildroot/output/host/usr/bin/arm-linux-gnueabihf-cpp \ CXX=/home/bruno/linux/buildroot/output/host/usr/bin/arm-linux-gnueabihf-g++\ CC=/home/bruno/linux/buildroot/output/host/usr/bin/arm-linux-gnueabihf-gcc\ LD=/home/bruno/linux/buildroot/output/host/usr/bin/arm-linux-gnueabihf-gcc\ -C /home/bruno/linux/buildroot/output/build/openjdk-jdk-9+163 CONF=linux-arm-normal-client-release Do you have any suggestion as what can cause this? Thanks Bruno From david.holmes at oracle.com Sun Apr 2 20:42:19 2017 From: david.holmes at oracle.com (David Holmes) Date: Mon, 3 Apr 2017 06:42:19 +1000 Subject: Fwd: Crosscopiled OpenJRE 9 crashes on java -h In-Reply-To: <871stan3cc.fsf@bruno-dell> References: <8737dqn3sr.fsf@bruno-dell> <871stan3cc.fsf@bruno-dell> Message-ID: <6c16d981-e258-8163-d425-fb7e5548bc65@oracle.com> Hi Bruno, Were these set explicitly? > CPP_FLAGS=-lstdc++ CXX_FLAGS=-lstdc++ > CPP=/home/bruno/linux/buildroot/output/host/usr/bin/arm-linux-gnueabihf-cpp > CXX=/home/bruno/linux/buildroot/output/host/usr/bin/arm-linux-gnueabihf-g++ > CC=/home/bruno/linux/buildroot/output/host/usr/bin/arm-linux-gnueabihf-gcc > LD=/home/bruno/linux/buildroot/output/host/usr/bin/arm-linux-gnueabihf-gcc For the first one you should be using --with-stdc++lib=dynamic|static For the toolkit you should be using --with-devkit=xxx My guess is that the wrong libc has been statically linked. David On 3/04/2017 3:09 AM, Bruno Kremel wrote: > > Bruno Kremel writes: > > Hi All, > > I have crosscompiled OpenJDK 9 for ARM (Freescale iMX6). > Now I have issues running it. If I run: > # java --help > # > # A fatal error has been detected by the Java Runtime Environment: > # > # SIGSEGV (0xb) at pc=0x76e40324, pid=234, tid=235 > # > # JRE version: (9.0) (build ) > # Java VM: OpenJDK Client VM (9-internal+0-adhoc.bruno.openjdk-jdk-9163, mixed mode, sharing, serial gc, linux-arm) > # Problematic frame: > # C [libc.so.6+0x58324] strlen+0x23 > # > # No core dump will be written. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again > # > # An error report file with more information is saved as: > # /root/hs_err_pid234.log > # > # If you would like to submit a bug report, please visit: > # http://bugreport.java.com/bugreport/crash.jsp > # > Aborted > > I also attach the generated error log: > > I built tag 163 in HG. > > These are the configure switches: > ./configure > --with-freetype-include=/home/bruno/linux/buildroot/output/host/usr/arm-buildroot-linux-gnueabihf/sysroot/usr/include/freetype2 > --with-freetype-lib=/home/bruno/linux/buildroot/output/host/usr/arm-buildroot-linux-gnueabihf/sysroot/usr/lib > --with-freetype=/home/bruno/linux/buildroot/output/host/usr/arm-buildroot-linux-gnueabihf/sysroot/usr/ > --with-debug-level=release --with-native-debug-symbols=none > --openjdk-target=arm-buildroot-linux-gnueabihf > --with-sys-root=/home/bruno/linux/buildroot/output/host/usr/arm-buildroot-linux-gnueabihf/sysroot > --with-tools-dir=/home/bruno/linux/buildroot/output/host > --disable-freetype-bundling --enable-unlimited-crypto > --enable-headless-only --disable-warnings-as-errors > --with-abi-profile=arm-vfp-hflt --with-jvm-variants=client > OBJCOPY=/home/bruno/linux/buildroot/output/host/usr/bin/arm-linux-gnueabihf-objcopy > STRIP=/home/bruno/linux/buildroot/output/host/usr/bin/arm-linux-gnueabihf-strip > CPP_FLAGS=-lstdc++ CXX_FLAGS=-lstdc++ > CPP=/home/bruno/linux/buildroot/output/host/usr/bin/arm-linux-gnueabihf-cpp > CXX=/home/bruno/linux/buildroot/output/host/usr/bin/arm-linux-gnueabihf-g++ > CC=/home/bruno/linux/buildroot/output/host/usr/bin/arm-linux-gnueabihf-gcc > LD=/home/bruno/linux/buildroot/output/host/usr/bin/arm-linux-gnueabihf-gcc > > And make: > make > OBJCOPY=/home/bruno/linux/buildroot/output/host/usr/bin/arm-linux-gnueabihf-objcopy \ > STRIP=/home/bruno/linux/buildroot/output/host/usr/bin/arm-linux-gnueabihf-strip \ > BUILD_CC=gcc BUILD_LD=gcc \ > CPP=/home/bruno/linux/buildroot/output/host/usr/bin/arm-linux-gnueabihf-cpp \ > CXX=/home/bruno/linux/buildroot/output/host/usr/bin/arm-linux-gnueabihf-g++\ > CC=/home/bruno/linux/buildroot/output/host/usr/bin/arm-linux-gnueabihf-gcc\ > LD=/home/bruno/linux/buildroot/output/host/usr/bin/arm-linux-gnueabihf-gcc\ > -C /home/bruno/linux/buildroot/output/build/openjdk-jdk-9+163 CONF=linux-arm-normal-client-release > > > Do you have any suggestion as what can cause this? > > Thanks > Bruno > From mark.reinhold at oracle.com Tue Apr 4 21:20:38 2017 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Tue, 04 Apr 2017 14:20:38 -0700 Subject: JEPs proposed to target JDK 9 (2017/4/4) Message-ID: <20170404142038.986268464@eggemoggin.niobe.net> The following JEPs have been placed into the "Proposed to Target" state by their owners after discussion and review: 291: Deprecate the Concurrent Mark Sweep (CMS) Garbage Collector http://openjdk.java.net/jeps/291 299: Reorganize Documentation http://openjdk.java.net/jeps/299 Feedback on these proposals is more than welcome, as are reasoned objections. If no such objections are raised by 23:00 UTC on Tuesday, 11 April, or if they're raised and then satisfactorily answered, then per the JEP 2.0 process proposal [1] I'll target these JEPs to JDK 9. To answer the obvious question: Yes, it is "highly unlikely that any further JEPs will be targeted to the release" [2], but that doesn't mean "never" when there are good reasons and low risks. In these cases: - JEP 291 requires only a minuscule code change, to enable the proposed warning message to be issued. It's a JEP in the first place not because it's a risky change but to bring visibility to the plan to remove the CMS collector in the long term. - JEP 299 is a worthwhile documentation enhancement that requires only makefile and text changes; there are no changes to product code. - Mark [1] http://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html [2] http://openjdk.java.net/projects/jdk9/#Status From aguibert at us.ibm.com Tue Apr 4 21:44:00 2017 From: aguibert at us.ibm.com (Andrew Guibert) Date: Tue, 4 Apr 2017 16:44:00 -0500 Subject: Behavior difference in java.text.DateFormat API between JDK 8 and 9 Message-ID: Hi all, My team has observed that the following code produces different output on JDK 8 and 9: import java.text.*; import java.util.*; DateFormat formatter = DateFormat.getDateTimeInstance(DateFormat.SHORT, DateFormat.MEDIUM); long time = System.currentTimeMillis(); Date date = new Date(time); System.out.println(formatter.format(date)); Output is: JDK 9 (b162): 4/4/17, 2:13:38 PM JDK 8 (121): 4/4/17 2:14:16 PM The only difference is that in JDK 9 there is a comma separating the date and time, whereas in JDK 8 there is not. I'm not signed up as a contributor so I don't think I can open a bug in the OpenJDK bug tracking system, so hopefully someone from the OpenJDK team can take care of this one for me. Thanks, Andy Guibert From naoto.sato at oracle.com Tue Apr 4 22:30:16 2017 From: naoto.sato at oracle.com (Naoto Sato) Date: Tue, 4 Apr 2017 15:30:16 -0700 Subject: Behavior difference in java.text.DateFormat API between JDK 8 and 9 In-Reply-To: References: Message-ID: Hi Andrew, The behavior you are observing is the expected one. As in JDK9, the default locale data is now based on Unicode Consortium's CLDR [1], and their date/time combined medium format in English contains a comma between date and time [2]. Naoto [1]: http://docs.oracle.com/javase/9/intl/internationalization-enhancements-jdk-9.htm#JSINT-GUID-9DCDB41C-A989-4220-8140-DBFB844A0FCA [2]: http://www.unicode.org/cldr/charts/28/by_type/date_&_time.gregorian.html#7a365a21694f0127 On 4/4/17 2:44 PM, Andrew Guibert wrote: > > > Hi all, > > My team has observed that the following code produces different output on > JDK 8 and 9: > > import java.text.*; > import java.util.*; > > DateFormat formatter = DateFormat.getDateTimeInstance(DateFormat.SHORT, > DateFormat.MEDIUM); > long time = System.currentTimeMillis(); > Date date = new Date(time); > System.out.println(formatter.format(date)); > > Output is: > JDK 9 (b162): 4/4/17, 2:13:38 PM > JDK 8 (121): 4/4/17 2:14:16 PM > > The only difference is that in JDK 9 there is a comma separating the date > and time, whereas in JDK 8 there is not. I'm not signed up as a > contributor so I don't think I can open a bug in the OpenJDK bug tracking > system, so hopefully someone from the OpenJDK team can take care of this > one for me. > > Thanks, Andy Guibert > From chris at hazelcast.com Wed Apr 5 05:49:10 2017 From: chris at hazelcast.com (Christoph Engelbert) Date: Wed, 5 Apr 2017 07:49:10 +0200 Subject: JEP 291: Deprecate the Concurrent Mark Sweep (CMS) Garbage Collector Message-ID: <76CF5376-C3A8-45FB-BC03-C9FFC64C1127@hazelcast.com> Hey guys, Regarding the proposal for JEP 291 to remove the CMS GC. I understand that the CMS code is extremely hard to maintain and spread all over the JVM (tried to understand myself once and gave up ;-)) but looking at it from my own experience, as well as our customer base, CMS+ParNew is the most commonly deployed solution and a lot of applications are optimized to the behavior of CMS. Even with G1 coming as the default GC in Java 9 I don?t see a lot of people moving for existing applications (that already use explicit command line GC settings). Apart from the completely different behavior of G1 over CMS. In general I think Krik or Martijn can give a deeper insight into the deployment base of the different GCs. Anyhow I?m ok with a warning message as it won?t hurt application runtime but I think it is too early to announce removal and, as mentioned above, I don?t expect people to move away from it as their application system is too closely bound to CMS and includes weeks of work on application and GC optimizations. From my point of view there are other GCs that could go first but as said, I understand where the wish to remove CMS comes from. What would be the prospected timeline to remove it? Java 10? Thanks, Christoph Engelbert Manager Developer Relations From kanth909 at gmail.com Wed Apr 5 06:48:17 2017 From: kanth909 at gmail.com (kant kodali) Date: Tue, 4 Apr 2017 23:48:17 -0700 Subject: JEP 291: Deprecate the Concurrent Mark Sweep (CMS) Garbage Collector In-Reply-To: <76CF5376-C3A8-45FB-BC03-C9FFC64C1127@hazelcast.com> References: <76CF5376-C3A8-45FB-BC03-C9FFC64C1127@hazelcast.com> Message-ID: I don't really understand the rationale for JEP 291. If the whole point of Jigsaw is to reduce the memory footprint such that Java can run effectively on containers and smaller devices such as raspberry pi then I wonder how G1 flares on these small devices ? especially when we know CMS performs well on smaller heap sizes. In short, I'm just trying to say while its great that JDK team came up with Jigsaw to optimize and run effectively for smaller devices but then we are introducing slower Garbage collector?! On Tue, Apr 4, 2017 at 10:49 PM, Christoph Engelbert wrote: > Hey guys, > > Regarding the proposal for JEP 291 to remove the CMS GC. I understand that > the CMS code is extremely hard to maintain and spread all over the JVM > (tried to understand myself once and gave up ;-)) but looking at it from my > own experience, as well as our customer base, CMS+ParNew is the most > commonly deployed solution and a lot of applications are optimized to the > behavior of CMS. > > Even with G1 coming as the default GC in Java 9 I don?t see a lot of > people moving for existing applications (that already use explicit command > line GC settings). Apart from the completely different behavior of G1 over > CMS. In general I think Krik or Martijn can give a deeper insight into the > deployment base of the different GCs. > > Anyhow I?m ok with a warning message as it won?t hurt application runtime > but I think it is too early to announce removal and, as mentioned above, I > don?t expect people to move away from it as their application system is too > closely bound to CMS and includes weeks of work on application and GC > optimizations. > > From my point of view there are other GCs that could go first but as said, > I understand where the wish to remove CMS comes from. What would be the > prospected timeline to remove it? Java 10? > > Thanks, > > > > Christoph Engelbert > Manager Developer Relations > > From Alan.Bateman at oracle.com Wed Apr 5 07:04:24 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 5 Apr 2017 08:04:24 +0100 Subject: Behavior difference in java.text.DateFormat API between JDK 8 and 9 In-Reply-To: References: Message-ID: <646f1eee-8729-f75d-e493-0459267c5761@oracle.com> On 04/04/2017 23:30, Naoto Sato wrote: > Hi Andrew, > > The behavior you are observing is the expected one. As in JDK9, the > default locale data is now based on Unicode Consortium's CLDR [1], and > their date/time combined medium format in English contains a comma > between date and time [2]. Just to add to Naoto's comments. JEP 252 [1] has more on this, including the system property to use "JRE" locale data where needed. -Alan [1] http://openjdk.java.net/jeps/252 From rkennke at redhat.com Wed Apr 5 07:45:13 2017 From: rkennke at redhat.com (Roman Kennke) Date: Wed, 5 Apr 2017 09:45:13 +0200 Subject: JEP 291: Deprecate the Concurrent Mark Sweep (CMS) Garbage Collector In-Reply-To: <76CF5376-C3A8-45FB-BC03-C9FFC64C1127@hazelcast.com> References: <76CF5376-C3A8-45FB-BC03-C9FFC64C1127@hazelcast.com> Message-ID: Am 05.04.2017 um 07:49 schrieb Christoph Engelbert: > Hey guys, > > Regarding the proposal for JEP 291 to remove the CMS GC. I understand that the CMS code is extremely hard to maintain and spread all over the JVM (tried to understand myself once and gave up ;-)) but looking at it from my own experience, as well as our customer base, CMS+ParNew is the most commonly deployed solution and a lot of applications are optimized to the behavior of CMS. > > Even with G1 coming as the default GC in Java 9 I don?t see a lot of people moving for existing applications (that already use explicit command line GC settings). Apart from the completely different behavior of G1 over CMS. In general I think Krik or Martijn can give a deeper insight into the deployment base of the different GCs. > > Anyhow I?m ok with a warning message as it won?t hurt application runtime but I think it is too early to announce removal and, as mentioned above, I don?t expect people to move away from it as their application system is too closely bound to CMS and includes weeks of work on application and GC optimizations. > > From my point of view there are other GCs that could go first but as said, I understand where the wish to remove CMS comes from. What would be the prospected timeline to remove it? Java 10? There's also the JEP: "GC Interface: Better isolation of GC implementations" (it's submitted, but not a candidate yet, thus has no number). One of the motivations for the GC interface JEP was exactly the CMS deprecation issue: it will provide much better isolation of CMS (and the other collectors) and thus remove one of the big obstacles for maintaining the code. If all goes as planned, all CMS code will reside under one directory (in contrast to being spread all over the place), and possibly even built optionally (if anybody needs this). All it takes from there is somebody who steps in and takes responsibility for maintaining CMS. I'd say it's too early to talk about removing CMS. And, to be honest, I even question the move to deprecate it. What's going to happen if somebody actually takes over CMS maintainership? Un-deprecate it? The GC interface JEP is ready, I've already got a good prototype that covers a lot of the pressing issues (with CMS and isolation in general). Maybe move it to candidate, and possibly propose to target JDK10? https://bugs.openjdk.java.net/browse/JDK-8163329 Also, I am not sure when to start proposing actual code related to GC interface to JDK10? Right now? After JDK9 is GA'd? When the JEP is proposed to target, or even targetted? Roman From aph at redhat.com Wed Apr 5 08:29:28 2017 From: aph at redhat.com (Andrew Haley) Date: Wed, 5 Apr 2017 09:29:28 +0100 Subject: JEP 291: Deprecate the Concurrent Mark Sweep (CMS) Garbage Collector In-Reply-To: References: <76CF5376-C3A8-45FB-BC03-C9FFC64C1127@hazelcast.com> Message-ID: <2c16aa1f-ffe1-aa67-71c7-fe09a4aa3283@redhat.com> On 05/04/17 08:45, Roman Kennke wrote: > I'd say it's too early to talk about removing CMS. And, to be honest, I > even question the move to deprecate it. What's going to happen if > somebody actually takes over CMS maintainership? Un-deprecate it? Indeed. We need to think about this first. I expect that there will be someone interested enough to keep it going. > The GC interface JEP is ready, I've already got a good prototype that > covers a lot of the pressing issues (with CMS and isolation in general). > Maybe move it to candidate, and possibly propose to target JDK10? It certainly should be moved to candidate. It's been discussed at some length, and I've not found anybody willing to argue that there should not be a clean abstraction layer between the VM and the garbage collectors. Andrew. From mark.reinhold at oracle.com Wed Apr 5 16:05:56 2017 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Wed, 05 Apr 2017 09:05:56 -0700 Subject: JEP 291: Deprecate the Concurrent Mark Sweep (CMS) Garbage Collector In-Reply-To: <2c16aa1f-ffe1-aa67-71c7-fe09a4aa3283@redhat.com> References: <76CF5376-C3A8-45FB-BC03-C9FFC64C1127@hazelcast.com> <2c16aa1f-ffe1-aa67-71c7-fe09a4aa3283@redhat.com> Message-ID: <20170405090556.939725504@eggemoggin.niobe.net> 2017/4/5 1:29:28 -0700, aph at redhat.com: > On 05/04/17 08:45, Roman Kennke wrote: >> I'd say it's too early to talk about removing CMS. And, to be honest, I >> even question the move to deprecate it. What's going to happen if >> somebody actually takes over CMS maintainership? Un-deprecate it? > > Indeed. We need to think about this first. I expect that there > will be someone interested enough to keep it going. Since this JEP was posted last summer we've had several discussions aimed at identifying a new maintainer for CMS, on the hotspot-gc-dev list [1][2] and in open meetings whose minutes are attached to the JEP issue [3]. So far, no one has stepped up. If someone does step up soon then I expect the owner of this JEP will withdraw it. If someone does so later on then CMS can be un-deprecated at that time. In any case, Oracle does intend to stop maintaining CMS at some point in the not-to-distant future, and if no one ever steps up then we'll remove the code. - Mark [1] http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2016-July/018545.html [2] http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2016-July/thread.html#18532 [3] https://bugs.openjdk.java.net/browse/JDK-8142518 From joe.darcy at oracle.com Wed Apr 5 16:51:52 2017 From: joe.darcy at oracle.com (joe darcy) Date: Wed, 5 Apr 2017 09:51:52 -0700 Subject: Looking ahead: proposed Hg forest consolidation for JDK 10 -- prototype repo now on hg.openjdk.java.net In-Reply-To: References: <4ea8f2e7-7a10-e949-d920-81ae5f610f24@oracle.com> Message-ID: <407a62cd-1bd8-2a96-6ae5-3ec5d88ec5af@oracle.com> FYI, follow-up discussions on this topic now occurring on jdk10-dev: "Coming soon: second generation prototype of Hg forest consolidation," http://mail.openjdk.java.net/pipermail/jdk10-dev/2017-April/000155.html -Joe On 10/14/2016 3:40 PM, joe darcy wrote: > On 10/10/2016 7:11 PM, joe darcy wrote: >> Hello, >> >> Looking ahead to JDK 10, a group of JDK engineers have been exploring >> consolidating the large number of Hg repositories in an open JDK >> forest to a single one with the goal of using the consolidated >> arrangement for JDK 10. >> >> This message is being sent to jdk9-dev since a jdk10-dev alias to >> discuss JDK 10 doesn't exist yet. >> >> A JEP describing the project has been submitted : >> >> JDK-8167368: Consolidate JDK 10 OpenJDK repositories to a single >> repository >> https://bugs.openjdk.java.net/browse/JDK-8167368 >> >> The text of the JEP describes the motivation and current state of the >> work in more detail, including proposed changes to the file layout. >> Publication of the prototype consolidated repository is planned, but >> not done yet. > > [snip] > > The prototype is now available from > > http://hg.openjdk.java.net/jdk9/consol-proto/ > > As implied by the tags, at present the prototype should be > functionally equivalent to jdk-9+138. > > Enjoy, > > -Joe From lana.steuck at oracle.com Wed Apr 5 18:51:34 2017 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 5 Apr 2017 18:51:34 GMT Subject: jdk9-b164: dev Message-ID: <201704051851.v35IpYBg000505@scaaa563.us.oracle.com> http://hg.openjdk.java.net/jdk9/jdk9/rev/7810f75d016a http://hg.openjdk.java.net/jdk9/jdk9/nashorn/rev/b473fab09baa http://hg.openjdk.java.net/jdk9/jdk9/langtools/rev/c7f3df19667b http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/6dea581453d7 http://hg.openjdk.java.net/jdk9/jdk9/jaxws/rev/1a52de2da827 http://hg.openjdk.java.net/jdk9/jdk9/jaxp/rev/6dc790a4e831 http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/0af429be8bba http://hg.openjdk.java.net/jdk9/jdk9/corba/rev/965bbae30727 --- All the fixes will be tested during promotion (no PIT testing at this point): List of all fixes: =================== JDK-8155052 core-libs add notes and links to j.u.Observer/Observable deprecation comments JDK-8173871 core-libs Typos in Jar Packer/Unpacker PROGRESS field documentation JDK-8174148 core-libs Typo in java.util.jar.Pack200.Unpacker.properties() method documentati JDK-8175013 core-libs (ann) Add @Generated JDK-8177136 core-libs Caller sensitive method System::getLogger should specify what happens JDK-8177559 core-libs Enable java/nio/channels/Selector/OutOfBand.java for macOS >= 10.10.5 JDK-8177638 core-libs com/sun/jarsigner, jdk/internal/loader (and more) are missed in TEST.g JDK-8177653 core-libs clarify restrictions on Iterator.forEachRemaining JDK-8177722 core-libs Improve grouping of jdk/internal/math tests JDK-8177835 core-libs System.LoggerFinder#getLogger or getLocalizedLogger does not throw NPE JDK-8177910 core-libs Update zlib copyright note in idk/src/java.base/share/legal/zlib.md JDK-8176533 core-svc REGRESSION: a java process is not recognized by jcmd/jinfo/jstack/jmap JDK-8177092 core-svc [TESTBUG] JMX test on MinimalVM fails after fix for 8176533 JDK-8165358 hotspot vmassert_status is not debug-only JDK-8176100 hotspot [REDO][REDO] G1 Needs pre barrier on dereference of weak JNI handles JDK-8176176 hotspot fix @modules in jdk_svc tests JDK-8176518 hotspot C2: Invalid ImplicitNullChecks with non-protected heap base JDK-8177374 hotspot fix module dependency declaration in jdk_svc tests JDK-8177390 hotspot java -version does not differentiate between which port of AArch64 is JDK-8173303 infrastructure Add module-subgraph images to main platform documentation JDK-8177135 infrastructure OpenJDK 9 freetype needs msvcr100.dll JDK-8177634 infrastructure Fix for 8175307 may cause linker errors on OS X 10.9 JDK-8177569 security-libs keytool should not warn if signature algorithm used in cacerts is weak JDK-8175116 tools jtreg agentvms uses more virtual address space in langtool/test :tier1 JDK-8175277 tools javadoc AssertionError when specified with release 8 JDK-8177076 tools jshell tool: usability of completion JDK-8177078 tools jshell tool: fix documentation of /help shortcuts JDK-8177079 tools jshell tool: usability of /help for commands and sub-commands JDK-8177308 tools jshell tool: documentation: multiple start-up files and predefines not JDK-8177311 tools Denied access when named module accesses unreferences package from the JDK-8177484 tools The old standard doclet should be deprecated for removal. JDK-8177567 tools cache VisibleMemberMap JDK-8177667 tools Langtools ant build has issues with Windows file separators JDK-8177735 tools jshell tool: /help /help -- typo "comand" From rkennke at redhat.com Thu Apr 6 09:37:58 2017 From: rkennke at redhat.com (Roman Kennke) Date: Thu, 6 Apr 2017 11:37:58 +0200 Subject: JEP 291: Deprecate the Concurrent Mark Sweep (CMS) Garbage Collector In-Reply-To: <20170405090556.939725504@eggemoggin.niobe.net> References: <76CF5376-C3A8-45FB-BC03-C9FFC64C1127@hazelcast.com> <2c16aa1f-ffe1-aa67-71c7-fe09a4aa3283@redhat.com> <20170405090556.939725504@eggemoggin.niobe.net> Message-ID: <4c9c6cb1-8c5c-60af-a12a-ff4eee012e42@redhat.com> > 2017/4/5 1:29:28 -0700, aph at redhat.com: >> On 05/04/17 08:45, Roman Kennke wrote: >>> I'd say it's too early to talk about removing CMS. And, to be honest, I >>> even question the move to deprecate it. What's going to happen if >>> somebody actually takes over CMS maintainership? Un-deprecate it? >> Indeed. We need to think about this first. I expect that there >> will be someone interested enough to keep it going. > Since this JEP was posted last summer we've had several discussions > aimed at identifying a new maintainer for CMS, on the hotspot-gc-dev > list [1][2] and in open meetings whose minutes are attached to the > JEP issue [3]. > > So far, no one has stepped up. > > If someone does step up soon then I expect the owner of this JEP will > withdraw it. If someone does so later on then CMS can be un-deprecated > at that time. In any case, Oracle does intend to stop maintaining CMS > at some point in the not-to-distant future, and if no one ever steps up > then we'll remove the code. Ok, I'll bite. I've heard a lot of people saying that they're interested in keeping it alive, but no-one stepped up yet. I can say that I wouldn't step up personally and take all of it. But I'd certainly participate in such an effort. (In a sense I'm already doing it by working on the GC interface). So why not pull our resources together and do it as a shared/community effort? Then it probably doesn't take that much from every single person/entity involved? From the top off my head, here's some items that would need to be done: 1. continuous build with CMS turned on (assuming it can be disabled by a build-time switch) 2. fix occasional build failure (caused by changes in, e.g., the GC interfaces or other runtime stuff) 3. run tests with CMS 4 triage bug reports 5 fix bugs I have certainly missed some aspects? Please feel free to add them! CMS is a pretty mature code base, so I'd expect most work in 1 and 3 (which should be mostly automated after initial set-up), and 2 (which shouldn't be very hard). 4 is also not very difficult. If something comes up in 5, it's probably very hard. I'm not afraid to touch GC code, so I'd be willing to participate in anything code related (e.g. 2 and 5). Oracle: you folks probably have CMS specific tests that are not in OpenJDK yet? If so, would you be willing to contribute those? Everybody (I've seen Google, jClarity, Twitter, SAP and a bunch of individuals involved in discussions): who else would be willing to contribute? And in which way? Best regards, Roman From thomas.schatzl at oracle.com Thu Apr 6 15:06:02 2017 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Thu, 06 Apr 2017 17:06:02 +0200 Subject: JEP 291: Deprecate the Concurrent Mark Sweep (CMS) Garbage Collector In-Reply-To: References: <76CF5376-C3A8-45FB-BC03-C9FFC64C1127@hazelcast.com> Message-ID: <1491491162.3141.19.camel@oracle.com> Hi, On Tue, 2017-04-04 at 23:48 -0700, kant kodali wrote: > I don't really understand the rationale for JEP 291. If the whole > point of Jigsaw is to reduce the memory footprint such that Java can > run effectively on containers and smaller devices such as raspberry > pi then I wonder how G1 flares on these small devices ? especially > when we know CMS performs well on smaller heap sizes. In short, I'm > just trying to say while its great that JDK team came up with Jigsaw > to optimize and run effectively for smaller devices but then we are > introducing slower Garbage collector?! ? just curious: what "smaller heap sizes" on these devices do you have in mind? Maybe you can even provide some kind of application where CMS significantly outperforms (on which metric(s)) G1? Thanks, ? Thomas From swpalmer at gmail.com Thu Apr 6 16:13:17 2017 From: swpalmer at gmail.com (Scott Palmer) Date: Thu, 6 Apr 2017 12:13:17 -0400 Subject: JEP 291: Deprecate the Concurrent Mark Sweep (CMS) Garbage Collector In-Reply-To: <1491491162.3141.19.camel@oracle.com> References: <76CF5376-C3A8-45FB-BC03-C9FFC64C1127@hazelcast.com> <1491491162.3141.19.camel@oracle.com> Message-ID: <71618EFE-7190-4E81-8DF5-0B8C1B84776B@gmail.com> > On Apr 6, 2017, at 11:06 AM, Thomas Schatzl wrote: > > Hi, > > On Tue, 2017-04-04 at 23:48 -0700, kant kodali wrote: >> I don't really understand the rationale for JEP 291. If the whole >> point of Jigsaw is to reduce the memory footprint such that Java can >> run effectively on containers and smaller devices such as raspberry >> pi then I wonder how G1 flares on these small devices ? especially >> when we know CMS performs well on smaller heap sizes. In short, I'm >> just trying to say while its great that JDK team came up with Jigsaw >> to optimize and run effectively for smaller devices but then we are >> introducing slower Garbage collector?! > > just curious: what "smaller heap sizes" on these devices do you have > in mind? > > Maybe you can even provide some kind of application where CMS > significantly outperforms (on which metric(s)) G1? I?ve been monitoring this conversation wondering what the alternative is for a low-pause collector. My company makes video software and we have spent a lot of time dealing with GC pause times that can introduce glitches in a live video stream. I'm talking about network broadcast TV where glitches in the output are deal-breakers. With buffering we can reduce the disruption to a live stream, but it introduces latency. We must have low latency. In our application, we have found that so far the CMS collector has significantly lower maximum pause times than G1. It might be possible to tune G1 to get the times down, but our initial attempts were unsuccessful. Tuning GC can be a complex and time-consuming task and there was only so much time to go down that path with G1 when we were managing with CMS. (Though we do have some ugly hacks to keep it performing, like forcing full GCs at regular intervals.) We have max GC pause times with CMS in the range of 30-50ms. I believe we found that G1 was 2x to 3x worse than that. The Java heap size in our application is generally under 1GB. From what I?ve read it seems that G1 is really designed for larger heaps. Regards, Scott From jeremymanson at google.com Thu Apr 6 23:54:22 2017 From: jeremymanson at google.com (Jeremy Manson) Date: Thu, 6 Apr 2017 16:54:22 -0700 Subject: JEP 291: Deprecate the Concurrent Mark Sweep (CMS) Garbage Collector In-Reply-To: <4c9c6cb1-8c5c-60af-a12a-ff4eee012e42@redhat.com> References: <76CF5376-C3A8-45FB-BC03-C9FFC64C1127@hazelcast.com> <2c16aa1f-ffe1-aa67-71c7-fe09a4aa3283@redhat.com> <20170405090556.939725504@eggemoggin.niobe.net> <4c9c6cb1-8c5c-60af-a12a-ff4eee012e42@redhat.com> Message-ID: Since I was the one driving conversations when we discussed this 6 months ago, I should give an update from our end. After internal conversations, we decided that supporting CMS in any sort of ongoing fashion should be a last resort after we try getting G1 to do what we need it to do. Our belief is that fewer collectors is better. We spent some time over the last few months coordinating with some of the folks at Oracle and experimenting to see if there were plausible ways forward with G1. We couldn't find anything obvious. I spent some time last week talking with Tony Printezis, who had a few concrete ideas we had not tried. Unfortunately, our lead (Jungwoo) is now moving on, so we are left with a person-doing-this-shaped hole (by the way - we're hiring for people to work on GC, if you happen to know anyone!). We have someone who can step in, but she has to get up to speed. That's the current status. The short of it is: We are still willing to contribute work to support CMS, but we want to make sure we've done our due diligence on G1 first. Our belief has been that the JDK 10 timeframe is long enough that we don't have to make this decision hurriedly. Jeremy On Thu, Apr 6, 2017 at 2:37 AM, Roman Kennke wrote: > > > 2017/4/5 1:29:28 -0700, aph at redhat.com: > >> On 05/04/17 08:45, Roman Kennke wrote: > >>> I'd say it's too early to talk about removing CMS. And, to be honest, I > >>> even question the move to deprecate it. What's going to happen if > >>> somebody actually takes over CMS maintainership? Un-deprecate it? > >> Indeed. We need to think about this first. I expect that there > >> will be someone interested enough to keep it going. > > Since this JEP was posted last summer we've had several discussions > > aimed at identifying a new maintainer for CMS, on the hotspot-gc-dev > > list [1][2] and in open meetings whose minutes are attached to the > > JEP issue [3]. > > > > So far, no one has stepped up. > > > > If someone does step up soon then I expect the owner of this JEP will > > withdraw it. If someone does so later on then CMS can be un-deprecated > > at that time. In any case, Oracle does intend to stop maintaining CMS > > at some point in the not-to-distant future, and if no one ever steps up > > then we'll remove the code. > > Ok, I'll bite. I've heard a lot of people saying that they're interested > in keeping it alive, but no-one stepped up yet. I can say that I > wouldn't step up personally and take all of it. But I'd certainly > participate in such an effort. (In a sense I'm already doing it by > working on the GC interface). So why not pull our resources together and > do it as a shared/community effort? Then it probably doesn't take that > much from every single person/entity involved? > > From the top off my head, here's some items that would need to be done: > 1. continuous build with CMS turned on (assuming it can be disabled by a > build-time switch) > 2. fix occasional build failure (caused by changes in, e.g., the GC > interfaces or other runtime stuff) > 3. run tests with CMS > 4 triage bug reports > 5 fix bugs > > I have certainly missed some aspects? Please feel free to add them! > > CMS is a pretty mature code base, so I'd expect most work in 1 and 3 > (which should be mostly automated after initial set-up), and 2 (which > shouldn't be very hard). 4 is also not very difficult. If something > comes up in 5, it's probably very hard. > > I'm not afraid to touch GC code, so I'd be willing to participate in > anything code related (e.g. 2 and 5). > > Oracle: you folks probably have CMS specific tests that are not in > OpenJDK yet? If so, would you be willing to contribute those? > > Everybody (I've seen Google, jClarity, Twitter, SAP and a bunch of > individuals involved in discussions): who else would be willing to > contribute? And in which way? > > Best regards, Roman > > From martijnverburg at gmail.com Fri Apr 7 13:05:05 2017 From: martijnverburg at gmail.com (Martijn Verburg) Date: Fri, 7 Apr 2017 14:05:05 +0100 Subject: JEP 291: Deprecate the Concurrent Mark Sweep (CMS) Garbage Collector In-Reply-To: References: <76CF5376-C3A8-45FB-BC03-C9FFC64C1127@hazelcast.com> <2c16aa1f-ffe1-aa67-71c7-fe09a4aa3283@redhat.com> <20170405090556.939725504@eggemoggin.niobe.net> <4c9c6cb1-8c5c-60af-a12a-ff4eee012e42@redhat.com> Message-ID: Hi all, We are now constantly asked to tune G1 for customers and have found that even with our most advanced analytics (in combination with some of the common and more esoteric tuning options), we are unable to get G1 to outperform CMS for *certain* use cases. Several customers have therefore reverted to CMS and are very interested in its future (as consumers). jClarity is not (at this stage) of the size where we can contribute a lot of effort for the native code refactor/maintenance, but we can definitely assist with tooling and statistical analysis of the results of any refactoring and compare and contrast that against the existing implementation. We're also happy to lend our tooling to others who are looking to understand G1 better (we have a free license programme for OSS, especially OpenJDK developers). Several members of the Adoption Group have also started a new initiative (not an official OpenJDK project yet) to provide a build farm for the OpenJDK community so that some of the more experimental forests can be built and tested on a wide range of platforms. We have Mac OS X, Windows, Linux variants, PowerPC, ARM etc, and expect to release this to the broader OpenJDK community in the next two weeks, so I'm confident we will have decent infrastructure to support that aspect of a refactor. Cheers, Martijn On 7 April 2017 at 00:54, Jeremy Manson wrote: > Since I was the one driving conversations when we discussed this 6 months > ago, I should give an update from our end. > > After internal conversations, we decided that supporting CMS in any sort of > ongoing fashion should be a last resort after we try getting G1 to do what > we need it to do. Our belief is that fewer collectors is better. > > We spent some time over the last few months coordinating with some of the > folks at Oracle and experimenting to see if there were plausible ways > forward with G1. We couldn't find anything obvious. > > I spent some time last week talking with Tony Printezis, who had a few > concrete ideas we had not tried. Unfortunately, our lead (Jungwoo) is now > moving on, so we are left with a person-doing-this-shaped hole (by the way > - we're hiring for people to work on GC, if you happen to know anyone!). > We have someone who can step in, but she has to get up to speed. That's > the current status. > > The short of it is: We are still willing to contribute work to support CMS, > but we want to make sure we've done our due diligence on G1 first. Our > belief has been that the JDK 10 timeframe is long enough that we don't have > to make this decision hurriedly. > > Jeremy > > On Thu, Apr 6, 2017 at 2:37 AM, Roman Kennke wrote: > > > > > > 2017/4/5 1:29:28 -0700, aph at redhat.com: > > >> On 05/04/17 08:45, Roman Kennke wrote: > > >>> I'd say it's too early to talk about removing CMS. And, to be > honest, I > > >>> even question the move to deprecate it. What's going to happen if > > >>> somebody actually takes over CMS maintainership? Un-deprecate it? > > >> Indeed. We need to think about this first. I expect that there > > >> will be someone interested enough to keep it going. > > > Since this JEP was posted last summer we've had several discussions > > > aimed at identifying a new maintainer for CMS, on the hotspot-gc-dev > > > list [1][2] and in open meetings whose minutes are attached to the > > > JEP issue [3]. > > > > > > So far, no one has stepped up. > > > > > > If someone does step up soon then I expect the owner of this JEP will > > > withdraw it. If someone does so later on then CMS can be un-deprecated > > > at that time. In any case, Oracle does intend to stop maintaining CMS > > > at some point in the not-to-distant future, and if no one ever steps up > > > then we'll remove the code. > > > > Ok, I'll bite. I've heard a lot of people saying that they're interested > > in keeping it alive, but no-one stepped up yet. I can say that I > > wouldn't step up personally and take all of it. But I'd certainly > > participate in such an effort. (In a sense I'm already doing it by > > working on the GC interface). So why not pull our resources together and > > do it as a shared/community effort? Then it probably doesn't take that > > much from every single person/entity involved? > > > > From the top off my head, here's some items that would need to be done: > > 1. continuous build with CMS turned on (assuming it can be disabled by a > > build-time switch) > > 2. fix occasional build failure (caused by changes in, e.g., the GC > > interfaces or other runtime stuff) > > 3. run tests with CMS > > 4 triage bug reports > > 5 fix bugs > > > > I have certainly missed some aspects? Please feel free to add them! > > > > CMS is a pretty mature code base, so I'd expect most work in 1 and 3 > > (which should be mostly automated after initial set-up), and 2 (which > > shouldn't be very hard). 4 is also not very difficult. If something > > comes up in 5, it's probably very hard. > > > > I'm not afraid to touch GC code, so I'd be willing to participate in > > anything code related (e.g. 2 and 5). > > > > Oracle: you folks probably have CMS specific tests that are not in > > OpenJDK yet? If so, would you be willing to contribute those? > > > > Everybody (I've seen Google, jClarity, Twitter, SAP and a bunch of > > individuals involved in discussions): who else would be willing to > > contribute? And in which way? > > > > Best regards, Roman > > > > > From li.jiang at oracle.com Mon Apr 10 08:38:45 2017 From: li.jiang at oracle.com (Leo Jiang) Date: Mon, 10 Apr 2017 16:38:45 +0800 Subject: Last message drop of JDK9 on April 27th Message-ID: Hi, After communication with Engineering and QA team, we have decided the date for last JDK9 message drop on April 27th. Please submit your code into jdk9-dev forest before this deadline. I will hold the resource processing until the source trees to be promotion build tagged on 4/27 Thursday. Thanks, Leo From thomas.schatzl at oracle.com Tue Apr 11 16:29:33 2017 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 11 Apr 2017 18:29:33 +0200 Subject: JEP 291: Deprecate the Concurrent Mark Sweep (CMS) Garbage Collector In-Reply-To: <71618EFE-7190-4E81-8DF5-0B8C1B84776B@gmail.com> References: <76CF5376-C3A8-45FB-BC03-C9FFC64C1127@hazelcast.com> <1491491162.3141.19.camel@oracle.com> <71618EFE-7190-4E81-8DF5-0B8C1B84776B@gmail.com> Message-ID: <1491928173.2754.108.camel@oracle.com> Hi Scott, On Thu, 2017-04-06 at 12:13 -0400, Scott Palmer wrote: > > > > On Apr 6, 2017, at 11:06 AM, Thomas Schatzl > com> wrote: > > > > Hi, > > [...] > > In our application, we have found that so far the CMS collector has > significantly lower maximum pause times than G1.??It might be > possible to tune G1 to get the times down, but our initial attempts > were unsuccessful.??Tuning GC can be a complex and time-consuming > task and there was only so much time to go down that path with G1 > when we were managing with CMS. (Though we do have some ugly hacks to > keep it performing, like forcing full GCs at regular intervals.) > > We have max GC pause times with CMS in the range of 30-50ms.??I > believe we found that G1 was 2x to 3x worse than that.??The Java heap > size in our application is generally under 1GB.??From what I?ve read > it seems that G1 is really designed for larger heaps. ? the stated latency goals and heap requirements do not seem to be problematic to achieve with G1. The "designed for larger heaps" tends to be limited to ergonomics, i.e. how resources are allocated and used by default. E.g. it tends to use too many threads at the moment. Actually the reverse seems to be the case for CMS, as sometimes extensive tuning is required for larger heaps; this may be due to CMS having evolved with smaller applications. Also, since there is more experience with CMS in the community, it may be more approachable. But from an implementation POV, the improvements for e.g. jdk9 almost all improve throughput and latency regardless of heap size (some just don't have any impact), and we will look into improving G1 further. There are some known concerns about throughput or footprint requirements G1 not being able to fulfill due to more low-level implementation choices. For those known to us (e.g. [5],[6]) we earlier proposed to the community to work on e.g. the Throughput Barriers For G1 [1] (to get throughput/footprint on par with parallel/parnew) or Rebuilding remembered sets during Concurrent Mark [2] (to get remembered set footprint of "G1 proper" down); currently Stefan Johansson is working on a parallel full gc [3] (people are complaining that g1 full gc is too slow ;)) too. With good implementations of those in place, I am confident that in almost all but very extreme cases where e.g. CMS fits perfectly, G1 can be on par or better than both parallel and/or CMS. Actually, due to G1's peculiarities, quite a few interesting other optimizations that neither CMS nor Parallel are able to profit from easily are relatively easy to implement (like [4]). To provide an easier transition we are in the process of updating and heavily revising the GC tuning guide, particularly for G1. An EA version is available at?https://docs.oracle.com/javase/9/gctuning/toc.h tm?that gives significantly more guidance than before. If you happen to give moving to G1 another try (e.g. when transitioning to JDK9), and you still encounter issues, feel free to drop by with your problem on the hotspot-gc-use mailing list. It is always interesting to learn about details of particular problems people have with G1, and often very acceptable solutions can be found there. Thanks, ? Thomas [1]?http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2016-November /019215.html [2]?http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2016-November /019217.html [3]?http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2016-November /019216.html [4]?https://bugs.openjdk.java.net/browse/JDK-8027959?(yes, that's already implemented ;) [5]?https://bugs.openjdk.java.net/browse/JDK-8062128 [6]?https://bugs.openjdk.java.net/browse/JDK-8133055 From benjamin.john.evans at gmail.com Tue Apr 11 16:42:13 2017 From: benjamin.john.evans at gmail.com (Ben Evans) Date: Tue, 11 Apr 2017 17:42:13 +0100 Subject: JEP 291: Deprecate the Concurrent Mark Sweep (CMS) Garbage Collector In-Reply-To: <1491928173.2754.108.camel@oracle.com> References: <76CF5376-C3A8-45FB-BC03-C9FFC64C1127@hazelcast.com> <1491491162.3141.19.camel@oracle.com> <71618EFE-7190-4E81-8DF5-0B8C1B84776B@gmail.com> <1491928173.2754.108.camel@oracle.com> Message-ID: Hi Thomas, If you have an example application that can demonstrably be tuned to have a max pause time of 50ms (on, say, a 2G heap), I would suggest that it would be highly advantageous to release it to the community as open source, at once. I have never seen *any* non-toy application of that heap size that can hit that pause goal & I have looked at quite a few recently. Thanks, Ben On Tue, Apr 11, 2017 at 5:29 PM, Thomas Schatzl wrote: > Hi Scott, > > On Thu, 2017-04-06 at 12:13 -0400, Scott Palmer wrote: >> > >> > On Apr 6, 2017, at 11:06 AM, Thomas Schatzl > > com> wrote: >> > >> > Hi, >> > [...] >> >> In our application, we have found that so far the CMS collector has >> significantly lower maximum pause times than G1. It might be >> possible to tune G1 to get the times down, but our initial attempts >> were unsuccessful. Tuning GC can be a complex and time-consuming >> task and there was only so much time to go down that path with G1 >> when we were managing with CMS. (Though we do have some ugly hacks to >> keep it performing, like forcing full GCs at regular intervals.) >> >> We have max GC pause times with CMS in the range of 30-50ms. I >> believe we found that G1 was 2x to 3x worse than that. The Java heap >> size in our application is generally under 1GB. From what I?ve read >> it seems that G1 is really designed for larger heaps. > > the stated latency goals and heap requirements do not seem to be > problematic to achieve with G1. > > The "designed for larger heaps" tends to be limited to ergonomics, i.e. > how resources are allocated and used by default. E.g. it tends to use > too many threads at the moment. Actually the reverse seems to be the > case for CMS, as sometimes extensive tuning is required for larger > heaps; this may be due to CMS having evolved with smaller applications. > Also, since there is more experience with CMS in the community, it may > be more approachable. > > But from an implementation POV, the improvements for e.g. jdk9 almost > all improve throughput and latency regardless of heap size (some just > don't have any impact), and we will look into improving G1 further. > > There are some known concerns about throughput or footprint > requirements G1 not being able to fulfill due to more low-level > implementation choices. > For those known to us (e.g. [5],[6]) we earlier proposed to the > community to work on e.g. the Throughput Barriers For G1 [1] (to get > throughput/footprint on par with parallel/parnew) or Rebuilding > remembered sets during Concurrent Mark [2] (to get remembered set > footprint of "G1 proper" down); currently Stefan Johansson is working > on a parallel full gc [3] (people are complaining that g1 full gc is > too slow ;)) too. > With good implementations of those in place, I am confident that in > almost all but very extreme cases where e.g. CMS fits perfectly, G1 can > be on par or better than both parallel and/or CMS. > > Actually, due to G1's peculiarities, quite a few interesting other > optimizations that neither CMS nor Parallel are able to profit from > easily are relatively easy to implement (like [4]). > > To provide an easier transition we are in the process of updating and > heavily revising the GC tuning guide, particularly for G1. An EA > version is available at https://docs.oracle.com/javase/9/gctuning/toc.h > tm that gives significantly more guidance than before. > > If you happen to give moving to G1 another try (e.g. when transitioning > to JDK9), and you still encounter issues, feel free to drop by with > your problem on the hotspot-gc-use mailing list. It is always > interesting to learn about details of particular problems people have > with G1, and often very acceptable solutions can be found there. > > Thanks, > Thomas > > [1] http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2016-November > /019215.html > [2] http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2016-November > /019217.html > [3] http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2016-November > /019216.html > [4] https://bugs.openjdk.java.net/browse/JDK-8027959 (yes, that's > already implemented ;) > [5] https://bugs.openjdk.java.net/browse/JDK-8062128 > [6] https://bugs.openjdk.java.net/browse/JDK-8133055 From jesper.wilhelmsson at oracle.com Tue Apr 11 17:08:54 2017 From: jesper.wilhelmsson at oracle.com (jesper.wilhelmsson at oracle.com) Date: Tue, 11 Apr 2017 19:08:54 +0200 Subject: RFR(xs): JDK-8178447 - Remove link from JavaDoc to Dev guide Message-ID: Hi, The link from the JavaDoc for VMOption to the JVM guide does not provide any additional information in the given context and should be removed. Bug: https://bugs.openjdk.java.net/browse/JDK-8178447 Webrev: http://cr.openjdk.java.net/~jwilhelm/8178447/webrev.00/ Thanks, /Jesper From thomas.schatzl at oracle.com Tue Apr 11 17:35:45 2017 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 11 Apr 2017 19:35:45 +0200 Subject: RFR(xs): JDK-8178447 - Remove link from JavaDoc to Dev guide In-Reply-To: References: Message-ID: <1491932145.2786.8.camel@oracle.com> Hi Jesper, On Tue, 2017-04-11 at 19:08 +0200, jesper.wilhelmsson at oracle.com wrote: > Hi, > > The link from the JavaDoc for VMOption to the JVM guide does not > provide any additional information in the given context and should be > removed. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8178447 > Webrev: http://cr.openjdk.java.net/~jwilhelm/8178447/webrev.00/ > ? looks good to me. Thanks, ? Thomas From jesper.wilhelmsson at oracle.com Tue Apr 11 17:39:18 2017 From: jesper.wilhelmsson at oracle.com (jesper.wilhelmsson at oracle.com) Date: Tue, 11 Apr 2017 19:39:18 +0200 Subject: RFR(xs): JDK-8178447 - Remove link from JavaDoc to Dev guide In-Reply-To: <1491932145.2786.8.camel@oracle.com> References: <1491932145.2786.8.camel@oracle.com> Message-ID: Thanks, /Jesper > On 11 Apr 2017, at 19:35, Thomas Schatzl wrote: > > Hi Jesper, > > On Tue, 2017-04-11 at 19:08 +0200, jesper.wilhelmsson at oracle.com wrote: >> Hi, >> >> The link from the JavaDoc for VMOption to the JVM guide does not >> provide any additional information in the given context and should be >> removed. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8178447 >> Webrev: http://cr.openjdk.java.net/~jwilhelm/8178447/webrev.00/ >> > > looks good to me. > > Thanks, > Thomas From david.holmes at oracle.com Tue Apr 11 21:34:24 2017 From: david.holmes at oracle.com (David Holmes) Date: Wed, 12 Apr 2017 07:34:24 +1000 Subject: RFR(xs): JDK-8178447 - Remove link from JavaDoc to Dev guide In-Reply-To: References: Message-ID: On 12/04/2017 3:08 AM, jesper.wilhelmsson at oracle.com wrote: > Hi, > > The link from the JavaDoc for VMOption to the JVM guide does not provide any additional information in the given context and should be removed. I agree that link serves no purpose. What we could have is a link to something that tells you what VM options exist! For 9 that would be the "java command" doc page. Thanks, David > Bug: https://bugs.openjdk.java.net/browse/JDK-8178447 > Webrev: http://cr.openjdk.java.net/~jwilhelm/8178447/webrev.00/ > > Thanks, > /Jesper > From thomas.schatzl at oracle.com Wed Apr 12 14:30:52 2017 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 12 Apr 2017 16:30:52 +0200 Subject: JEP 291: Deprecate the Concurrent Mark Sweep (CMS) Garbage Collector In-Reply-To: References: <76CF5376-C3A8-45FB-BC03-C9FFC64C1127@hazelcast.com> <1491491162.3141.19.camel@oracle.com> <71618EFE-7190-4E81-8DF5-0B8C1B84776B@gmail.com> <1491928173.2754.108.camel@oracle.com> Message-ID: <1492007452.2497.9.camel@oracle.com> Hi Ben, On Tue, 2017-04-11 at 17:42 +0100, Ben Evans wrote: >? > Hi Thomas, >? > If you have an example application that can demonstrably be tuned to > have a max pause time of 50ms (on, say, a 2G heap), I would suggest > that it would be highly advantageous to release it to the community > as open source, at once. >? > I have never seen *any* non-toy application of that heap size that > can hit that pause goal & I have looked at quite a few recently. >? ? when I mentioned "the stated latency goals and heap requirements do not seem to be problematic to achieve with G1" please be aware that we are very likely looking at quite different instances of G1.? >From various internal and external sources we know that you and the community are (obviously) running some JDK 8u release. Many do not use the latest JDK 8u, and there are still questions about G1 on JDK 7u. As a HotSpot dev, my focus is naturally on the the very latest version of the code and on upcoming changes. So for me, the point of comparison for G1 vs. CMS should at least be JDK 9 (if not 10). As dev I know that there has been a lot of progress on many aspects of G1 in JDK 9 compared to JDK 8u, and we are already ramping up pushing JDK 10 improvements. This does not mean G1 is a perfect replacement for CMS even now in JDK 10 repos :), but the completion of one of the originally intended goals of G1, replacing CMS in the long term [1], is drawing closer. The deprecation of CMS with JDK 9 just indicates that; support for CMS may go away in the future, and we think that in JDK 9 G1 is in a state to very seriously consider moving to it or at least try it out and give feedback. Due to other changes in JDK 9, a serious re-evaluation of GC usage may need to be done anyway. We very appreciate such experience reports and requests for help on channels like hotspot-gc-use. These are very valuable contributions from you to us. They help us to better understand what and where pain points are with G1, so that we can improve the collector accordingly. Getting back to your request, I stand by my assertion, that (with JDK 9/10) the given 50ms latency goals with the given heap size is achievable on at least one non-toy application :) But I am no good at determining what constitutes a toy-application, and obviously I am biased here, so this is where I would be grateful if you or somebody else could step in with a non-toy application setup. Even if this investigation fails, we devs get useful information to improve G1 in the future, and you will most likely get your application meeting requirements with suggested tunings (either immediately, or at a later point). Thanks, ? Thomas [1] http://www.oracle.com/technetwork/java/javase/tech/g1-intro-jsp-135 488.html From jesper.wilhelmsson at oracle.com Wed Apr 12 15:40:01 2017 From: jesper.wilhelmsson at oracle.com (jesper.wilhelmsson at oracle.com) Date: Wed, 12 Apr 2017 17:40:01 +0200 Subject: RFR(xs): JDK-8178447 - Remove link from JavaDoc to Dev guide In-Reply-To: References: Message-ID: <56721F11-AB91-433A-899B-755858EEB5D3@oracle.com> David, Thanks for looking! Do you have a link to the page you refer to? It sounds to me as you refer to a page that is not part of the JavaDoc. One of the reasons we found this link is that the docs team is reorganising the docs and are trying to avoid links for the JavaDoc into the guides etc. As the guides etc are moving to the new format an indirection link would be required to refer into the new place, which is of course doable, but some more work than just removing the old link. Thanks, /Jesper > On 11 Apr 2017, at 23:34, David Holmes wrote: > > On 12/04/2017 3:08 AM, jesper.wilhelmsson at oracle.com wrote: >> Hi, >> >> The link from the JavaDoc for VMOption to the JVM guide does not provide any additional information in the given context and should be removed. > > I agree that link serves no purpose. What we could have is a link to something that tells you what VM options exist! For 9 that would be the "java command" doc page. > > Thanks, > David > >> Bug: https://bugs.openjdk.java.net/browse/JDK-8178447 >> Webrev: http://cr.openjdk.java.net/~jwilhelm/8178447/webrev.00/ >> >> Thanks, >> /Jesper >> From daniel at starlis.com Wed Apr 12 02:04:31 2017 From: daniel at starlis.com (Daniel Ennis) Date: Tue, 11 Apr 2017 22:04:31 -0400 Subject: JEP 291: Deprecate the Concurrent Mark Sweep (CMS) Garbage Collector Message-ID: Hello, I've pretty much been the lead on GC research as it applies to Minecraft servers. I spent a few months researching everything I could on GC tuning, and analyzing my server using VisualGC inside of VisualVM. I chose to study G1 as the CMS fragmentation issue constantly causes MC servers problems with large spikes (which is extremely visible for a realtime game) when the full collections trigger. In the end, I was able to optimize G1 to provide 25ms pause times on lower sized heaps such as 2G, and 40 to 100ms on 10G heap. GC Logs: 2GB test environment: https://gist.github.com/aikar/ee619c12103c6d1700e1349bd9e21792 10GB prod environment: https://gist.github.com/aikar/5fd99dd4b8c4b573a39f5c99ce5dda00 Test Environment - 2GB heap: Minecraft server with high Entity activity (monsters running AI engines, collisions to each other) clustered in a single area. Enough to cause performance problems with the server. I wrote an article on all of my flag choices and why I chose them here: https://mcflags.emc.gs (redirects to aquifermc blog post) I use 10GB heap on my production server and average 50-100ms pauses with the following flags -Dfile.encoding=UTF-8 -XX:+UseG1GC -XX:+UnlockExperimentalVMOptions -XX:MaxGCPauseMillis=50 -XX:+DisableExplicitGC -XX:G1HeapRegionSize=8M -XX:TargetSurvivorRatio=90 -XX:+AggressiveOpts -XX:HeapDumpPath=crash-reports/ -XX:+HeapDumpOnOutOfMemoryError -Xloggc:logs/gc.log -XX:+PrintGCDateStamps -XX:+PrintGCTimeStamps -XX:NumberOfGCLogFiles=1 -XX:GCLogFileSize=20M -XX:LargePageSizeInBytes=2M -XX:+UseLargePages -XX:+AlwaysPreTouch -XX:+UseLargePagesInMetaspace -XX:G1NewSizePercent=50 -XX:G1MaxNewSizePercent=80 -XX:InitiatingHeapOccupancyPercent=20 -XX:G1MixedGCLiveThresholdPercent=40 -XX:ParallelGCThreads=6 -DprintSaveStats=60 -Xmx10G -Xms10 The key here really is the Experimental options G1NewSizePercent and G1MaxNewSizePercent. These instructions let me constrain G1's predictive calculations. You give it a closer to normal window, and it still does its predictive calculations inside of that window. With this setup, most collections are young. A few are mixed to keep old somewhat maintained. I'm not confident I have the best G1MixedGCLiveThresholdPercent or InitiatingHeapOccupancyPercent configurations for maintaining old, but things are so buttery smooth for me now I haven't had justification to mess with them. My ultimate focus is on Young Generation. Minecraft servers allocate a ton of short lived memory. My end goal is to avoid EVER triggering a full collection. I focus on keeping the intervals between young collections as long as possible, giving old only enough room that it ultimately needs + room for unexpected load (if I gain more than expected, then full collections are triggered) If your allocation rate is high, and the memory is short lived, having less space on Eden results in survivor filling up fast, and premature promotions. Eden is cheap to collect, so my tuning aims to let the memory die while still in Eden and before age 15 of survivor, providing these consistently low pause times. I believe that is the key to maintaining the low pauses, is to keep most focus in young and avoid having to ever do much work in old. Hope this helps! From aph at redhat.com Wed Apr 12 18:25:28 2017 From: aph at redhat.com (Andrew Haley) Date: Wed, 12 Apr 2017 19:25:28 +0100 Subject: JEP 291: Deprecate the Concurrent Mark Sweep (CMS) Garbage Collector In-Reply-To: References: Message-ID: On 12/04/17 03:04, Daniel Ennis wrote: > My end goal is to avoid EVER triggering a full collection. I focus on > keeping the intervals between young collections as long as possible, giving > old only enough room that it ultimately needs + room for unexpected load > (if I gain more than expected, then full collections are triggered) We'd love to see how well the Shenandoah collector works for you. We have a JDK8 port, if you're interested. Andrew. From david.holmes at oracle.com Thu Apr 13 01:50:41 2017 From: david.holmes at oracle.com (David Holmes) Date: Thu, 13 Apr 2017 11:50:41 +1000 Subject: RFR(xs): JDK-8178447 - Remove link from JavaDoc to Dev guide In-Reply-To: <56721F11-AB91-433A-899B-755858EEB5D3@oracle.com> References: <56721F11-AB91-433A-899B-755858EEB5D3@oracle.com> Message-ID: Hi Jesper, On 13/04/2017 1:40 AM, jesper.wilhelmsson at oracle.com wrote: > David, > > Thanks for looking! > > Do you have a link to the page you refer to? It sounds to me as you refer to a page that is not part of the JavaDoc. One of the reasons we found this link is that the docs team is reorganising the docs and are trying to avoid links for the JavaDoc into the guides etc. As the guides etc are moving to the new format an indirection link would be required to refer into the new place, which is of course doable, but some more work than just removing the old link. I don't know how everything will end up being laid out in the new doc set. But no it isn't API Javadoc, but tool doc. If cross-linking is problematic then don't worry about it. Thanks, David > Thanks, > /Jesper > >> On 11 Apr 2017, at 23:34, David Holmes wrote: >> >> On 12/04/2017 3:08 AM, jesper.wilhelmsson at oracle.com wrote: >>> Hi, >>> >>> The link from the JavaDoc for VMOption to the JVM guide does not provide any additional information in the given context and should be removed. >> >> I agree that link serves no purpose. What we could have is a link to something that tells you what VM options exist! For 9 that would be the "java command" doc page. >> >> Thanks, >> David >> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8178447 >>> Webrev: http://cr.openjdk.java.net/~jwilhelm/8178447/webrev.00/ >>> >>> Thanks, >>> /Jesper >>> > From jesper.wilhelmsson at oracle.com Thu Apr 13 02:07:06 2017 From: jesper.wilhelmsson at oracle.com (jesper.wilhelmsson at oracle.com) Date: Thu, 13 Apr 2017 04:07:06 +0200 Subject: RFR(xs): JDK-8178447 - Remove link from JavaDoc to Dev guide In-Reply-To: References: <56721F11-AB91-433A-899B-755858EEB5D3@oracle.com> Message-ID: OK, thanks! /Jesper > On 13 Apr 2017, at 03:50, David Holmes wrote: > > Hi Jesper, > > On 13/04/2017 1:40 AM, jesper.wilhelmsson at oracle.com wrote: >> David, >> >> Thanks for looking! >> >> Do you have a link to the page you refer to? It sounds to me as you refer to a page that is not part of the JavaDoc. One of the reasons we found this link is that the docs team is reorganising the docs and are trying to avoid links for the JavaDoc into the guides etc. As the guides etc are moving to the new format an indirection link would be required to refer into the new place, which is of course doable, but some more work than just removing the old link. > > I don't know how everything will end up being laid out in the new doc set. But no it isn't API Javadoc, but tool doc. If cross-linking is problematic then don't worry about it. > > Thanks, > David > > >> Thanks, >> /Jesper >> >>> On 11 Apr 2017, at 23:34, David Holmes wrote: >>> >>> On 12/04/2017 3:08 AM, jesper.wilhelmsson at oracle.com wrote: >>>> Hi, >>>> >>>> The link from the JavaDoc for VMOption to the JVM guide does not provide any additional information in the given context and should be removed. >>> >>> I agree that link serves no purpose. What we could have is a link to something that tells you what VM options exist! For 9 that would be the "java command" doc page. >>> >>> Thanks, >>> David >>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8178447 >>>> Webrev: http://cr.openjdk.java.net/~jwilhelm/8178447/webrev.00/ >>>> >>>> Thanks, >>>> /Jesper >>>> >> From lana.steuck at oracle.com Thu Apr 13 04:06:08 2017 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Thu, 13 Apr 2017 04:06:08 GMT Subject: jdk9-b165: dev Message-ID: <201704130406.v3D468VJ024967@scaaa563.us.oracle.com> http://hg.openjdk.java.net/jdk9/jdk9/rev/aff4f339acd4 http://hg.openjdk.java.net/jdk9/jdk9/nashorn/rev/e36e62d3ea53 http://hg.openjdk.java.net/jdk9/jdk9/langtools/rev/98108b7d4cb6 http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/a7942c3b1e59 http://hg.openjdk.java.net/jdk9/jdk9/jaxws/rev/a987401bac0d http://hg.openjdk.java.net/jdk9/jdk9/jaxp/rev/554196039897 http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/c92c6416ca03 http://hg.openjdk.java.net/jdk9/jdk9/corba/rev/a510b2201154 --- All the fixes will be tested during promotion (no PIT testing at this point): List of all fixes: =================== JDK-8165641 core-libs Deprecate Object.finalize JDK-8173152 core-libs Wrong wording in Comparator.compare() method spec JDK-8177449 core-libs (tz) Support tzdata2017b JDK-8177526 core-libs BufferedReader readLine() javadoc does not match the implementation re JDK-8177530 core-libs Module system implementation refresh (4/2017) JDK-8177640 core-libs jdk/internal/util/jar/TestVersionedStream.java fails on Windows JDK-8177949 core-libs @link tag arguments need correction for ElementType documentation JDK-8177980 core-libs ResourceBundle.getBundle throws NoClassDefFoundError when fails to def JDK-8177984 core-libs (ch) java/nio/channels/SocketChannel/VectorIO.java should use RandomFa JDK-8178074 core-libs (ch) java/nio/channels/etc/AdaptorCloseAndInterrupt.java: add instrume JDK-8178101 core-libs (thread) Migrate the thread deprecation technote to javadoc doc-files JDK-8178130 core-libs Minor updates to Connection javadocs JDK-8178139 core-libs Minor typo in API documentation of java.util.logging.Logger JDK-8178154 core-libs Typo in Object.finalize deprecation javadoc JDK-8178161 core-libs Default multicast interface on Mac JDK-8178286 core-libs Missing @moduleGraph in javadoc JDK-8176204 core-svc [DOC] ThreadMXBean Fails to Detect ReentrantReadWriteLock Deadlock JDK-8177855 docs Clean up legal files JDK-8170812 hotspot Metaspace corruption caused by incorrect memory size for MethodCounter JDK-8177507 hotspot line number sensitive tests for jdi should be unified JDK-8177673 hotspot [JVMCI] missing checks in HotSpotMemoryAccessProviderImpl can cause VM JDK-8177856 hotspot [AOT] EliminateRedundantInitializationPhase is not working JDK-8177963 hotspot Parallel GC fails fast when per-thread task log overflows JDK-8178033 hotspot C1 crashes with -XX:UseAVX = 3: "not a mov [reg+offs], reg instruction JDK-8178333 hotspot CTW/PathHandler uses == instead of String::equals for string compariso JDK-8177955 infrastructure Add testing documentation JDK-8165367 security-libs Additional tests for JEP 288: Disable SHA-1 Certificates JDK-8065825 tools Make the java -help consistent with the man page JDK-8175218 tools The fix for JDK-8141492 broke formatting of some javadoc documentation JDK-8176572 tools Javac does not enforce module name restrictions JDK-8176901 tools Internal error running javadoc over jdk internal classes JDK-8177332 tools The presence of a file with a Japanese ShiftJIS name can cause javac t JDK-8177417 tools Constructor Summary readability problems in jdk9 javadoc JDK-8177562 tools Small updates to module summary page JDK-8177933 tools Stackoverflow during compilation, starting jdk-9+163 JDK-8178011 tools Automatic module warnings JDK-8178013 tools Finetuning of merged tab and shift tab completion JDK-8178077 tools jshell tool: crash on ctrl-up or ctrl-down JDK-8178078 tools jdk/javadoc/doclet/testDeprecatedDocs/TestDeprecatedDocs.java failed d JDK-8178079 tools jdk/javadoc/doclet/testModules/TestModules.java failed due to some sub JDK-8178283 tools tools/javac/lambda/speculative/T8177933.java fails with assertion erro From thomas.schatzl at oracle.com Sat Apr 15 15:57:00 2017 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Sat, 15 Apr 2017 17:57:00 +0200 Subject: JEP 291: Deprecate the Concurrent Mark Sweep (CMS) Garbage Collector In-Reply-To: References: Message-ID: <1492271820.9784.11.camel@oracle.com> Hi Daniel, On Tue, 2017-04-11 at 22:04 -0400, Daniel Ennis wrote: > Hello, > I've pretty much been the lead on GC research as it applies to > Minecraft servers. I spent a few months researching everything I > could on GC tuning, and analyzing my server using VisualGC inside of > VisualVM. > > I chose to study G1 as the CMS fragmentation issue constantly causes > MC servers problems with large spikes (which is extremely visible for > a realtime game) when the full collections trigger. > > In the end, I was able to optimize G1 to provide 25ms pause times on > lower sized heaps such as 2G, and 40 to 100ms on 10G heap. > [...] > I use 10GB heap on my production server and average 50-100ms pauses > with the following flags > > ?-Dfile.encoding=UTF-8 -XX:+UseG1GC -XX:+UnlockExperimentalVMOptions > -XX:MaxGCPauseMillis=50 -XX:+DisableExplicitGC > -XX:G1HeapRegionSize=8M > -XX:TargetSurvivorRatio=90 -XX:+AggressiveOpts > -XX:HeapDumpPath=crash-reports/ -XX:+HeapDumpOnOutOfMemoryError > -Xloggc:logs/gc.log -XX:+PrintGCDateStamps -XX:+PrintGCTimeStamps > -XX:NumberOfGCLogFiles=1 -XX:GCLogFileSize=20M > -XX:LargePageSizeInBytes=2M > -XX:+UseLargePages -XX:+AlwaysPreTouch -XX:+UseLargePagesInMetaspace > -XX:G1NewSizePercent=50 -XX:G1MaxNewSizePercent=80 > -XX:InitiatingHeapOccupancyPercent=20 > -XX:G1MixedGCLiveThresholdPercent=40 > -XX:ParallelGCThreads=6 -DprintSaveStats=60 -Xmx10G -Xms10 > > The key here really is the Experimental options G1NewSizePercent and > G1MaxNewSizePercent. These instructions let me constrain G1's > predictive calculations. You give it a closer to normal window, and > it still does its predictive calculations inside of that window. >From the logs, it may be that G1NewSizePercent may be just a tad too high to keep the 50ms pause time all the time, but I may be wrong. Maybe -XX:+PrintGCDetails could give details about the reason. > With this setup, most collections are young. A few are mixed to keep > old somewhat maintained. > > I'm not confident I have the best G1MixedGCLiveThresholdPercent or > InitiatingHeapOccupancyPercent configurations for maintaining old, > but things are so buttery smooth for me now I haven't had > justification to mess with them. If you have, particularly when you move to JDK 9, feel free to drop a note about your experience on hotspot-gc-use, or just want to discuss your thoughts. > My ultimate focus is on Young Generation. Minecraft servers allocate > a ton of short lived memory. > > My end goal is to avoid EVER triggering a full collection. I focus on > keeping the intervals between young collections as long as possible, > giving old only enough room that it ultimately needs + room for > unexpected load (if I gain more than expected, then full collections > are triggered) > > If your allocation rate is high, and the memory is short lived, > having less space on Eden results in survivor filling up fast, and > premature promotions. > > Eden is cheap to collect, so my tuning aims to let the memory die > while still in Eden and before age 15 of survivor, providing these > consistently low pause times. Unfortunately the logs do not show the tenuring distribution, if you enabled -XX:+PrintTenuringDistribution we would know more. Note that G1 can manage allocation in old gen, and particularly one that just dies off quickly can also be very quickly reclaimed. The concurrent marking on the 10g heap only takes half a second and you are very far from going out of memory. So some throughput may be reclaimed by increasing the?InitiatingHeapOccupancyPercent. Note that JDK 9 will try to automatically determine one, most of the time giving a very good baseline. > I believe that is the key to maintaining the low pauses, is to keep > most focus in young and avoid having to ever do much work in old. Thanks a lot for stepping in, ? Thomas From benjamin.john.evans at gmail.com Sun Apr 16 11:38:59 2017 From: benjamin.john.evans at gmail.com (Ben Evans) Date: Sun, 16 Apr 2017 12:38:59 +0100 Subject: JEP 291: Deprecate the Concurrent Mark Sweep (CMS) Garbage Collector In-Reply-To: <1492271820.9784.11.camel@oracle.com> References: <1492271820.9784.11.camel@oracle.com> Message-ID: Hi Thomas, I'm very glad the community has been able to provide an example of an experimental configuration that's able to meet your publicised claims - and all it took was unlocking experimental options and several months of tuning work! However, if I'm reading your mail correctly, your point is that the version of G1 that will be delivered & made default in Java 9 is substantially different from anything that has been seen so far in shipping versions of Java 8? Is that correct? Oracle are planning to make default a GC which has had, essentially, zero testing on actual production workloads? Thanks, Ben On Sat, Apr 15, 2017 at 4:57 PM, Thomas Schatzl wrote: > Hi Daniel, > > On Tue, 2017-04-11 at 22:04 -0400, Daniel Ennis wrote: >> Hello, >> I've pretty much been the lead on GC research as it applies to >> Minecraft servers. I spent a few months researching everything I >> could on GC tuning, and analyzing my server using VisualGC inside of >> VisualVM. >> >> I chose to study G1 as the CMS fragmentation issue constantly causes >> MC servers problems with large spikes (which is extremely visible for >> a realtime game) when the full collections trigger. >> >> In the end, I was able to optimize G1 to provide 25ms pause times on >> lower sized heaps such as 2G, and 40 to 100ms on 10G heap. >> > [...] > >> I use 10GB heap on my production server and average 50-100ms pauses >> with the following flags >> >> -Dfile.encoding=UTF-8 -XX:+UseG1GC -XX:+UnlockExperimentalVMOptions >> -XX:MaxGCPauseMillis=50 -XX:+DisableExplicitGC >> -XX:G1HeapRegionSize=8M >> -XX:TargetSurvivorRatio=90 -XX:+AggressiveOpts >> -XX:HeapDumpPath=crash-reports/ -XX:+HeapDumpOnOutOfMemoryError >> -Xloggc:logs/gc.log -XX:+PrintGCDateStamps -XX:+PrintGCTimeStamps >> -XX:NumberOfGCLogFiles=1 -XX:GCLogFileSize=20M >> -XX:LargePageSizeInBytes=2M >> -XX:+UseLargePages -XX:+AlwaysPreTouch -XX:+UseLargePagesInMetaspace >> -XX:G1NewSizePercent=50 -XX:G1MaxNewSizePercent=80 >> -XX:InitiatingHeapOccupancyPercent=20 >> -XX:G1MixedGCLiveThresholdPercent=40 >> -XX:ParallelGCThreads=6 -DprintSaveStats=60 -Xmx10G -Xms10 >> >> The key here really is the Experimental options G1NewSizePercent and >> G1MaxNewSizePercent. These instructions let me constrain G1's >> predictive calculations. You give it a closer to normal window, and >> it still does its predictive calculations inside of that window. > > From the logs, it may be that G1NewSizePercent may be just a tad too > high to keep the 50ms pause time all the time, but I may be wrong. > > Maybe -XX:+PrintGCDetails could give details about the reason. > >> With this setup, most collections are young. A few are mixed to keep >> old somewhat maintained. >> >> I'm not confident I have the best G1MixedGCLiveThresholdPercent or >> InitiatingHeapOccupancyPercent configurations for maintaining old, >> but things are so buttery smooth for me now I haven't had >> justification to mess with them. > > If you have, particularly when you move to JDK 9, feel free to drop a > note about your experience on hotspot-gc-use, or just want to discuss > your thoughts. > >> My ultimate focus is on Young Generation. Minecraft servers allocate >> a ton of short lived memory. >> >> My end goal is to avoid EVER triggering a full collection. I focus on >> keeping the intervals between young collections as long as possible, >> giving old only enough room that it ultimately needs + room for >> unexpected load (if I gain more than expected, then full collections >> are triggered) >> >> If your allocation rate is high, and the memory is short lived, >> having less space on Eden results in survivor filling up fast, and >> premature promotions. >> >> Eden is cheap to collect, so my tuning aims to let the memory die >> while still in Eden and before age 15 of survivor, providing these >> consistently low pause times. > > Unfortunately the logs do not show the tenuring distribution, if you > enabled -XX:+PrintTenuringDistribution we would know more. > > Note that G1 can manage allocation in old gen, and particularly one > that just dies off quickly can also be very quickly reclaimed. The > concurrent marking on the 10g heap only takes half a second and you are > very far from going out of memory. > > So some throughput may be reclaimed by increasing > the InitiatingHeapOccupancyPercent. > > Note that JDK 9 will try to automatically determine one, most of the > time giving a very good baseline. > >> I believe that is the key to maintaining the low pauses, is to keep >> most focus in young and avoid having to ever do much work in old. > > Thanks a lot for stepping in, > Thomas > From thomas.schatzl at oracle.com Sun Apr 16 16:26:53 2017 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Sun, 16 Apr 2017 18:26:53 +0200 Subject: JEP 291: Deprecate the Concurrent Mark Sweep (CMS) Garbage Collector In-Reply-To: References: <1492271820.9784.11.camel@oracle.com> Message-ID: <1492360013.5115.163.camel@oracle.com> Hi Ben, On Sun, 2017-04-16 at 12:38 +0100, Ben Evans wrote: > Hi Thomas, > > I'm very glad the community has been able to provide an example of an > experimental configuration that's able to meet your publicised claims > - and all it took was unlocking experimental options and several ? use of the experimental options is not required in this case. They may be convenient to use, but not necessary. The used experimental options are -XX:G1NewSizePercent -XX:G1MaxNewSizePercent and -XX:G1MixedGCCountTarget: *) -XX:G1NewSizePercent -XX:G1MaxNewSizePercent can be substitued by appropriate values for -XX:NewSize and -XX:MaxNewSize. I have seen people using these ones with other collectors for exactly the same purpose, i.e. keep young gen large. *) The only experimental option left is -XX:G1MixedGCLiveThresholdPercent, but this one's effect could be substituted by the product flag -XX:G1MixedGCCountTarget. The new and updated documentation explains the use of all these options in more detail [1]. So there is almost certainly no need at all to use experimental options in this case, neither in JDK 8u nor in JDK 9. This does not mean we think G1 is perfect: ideally it would meet the pause time requirement without any of these extra options. So we are working on CRs like?JDK-8159697?[6] to make G1 out-of-the-box experience even better in the future. In comparison point, CMS runs into unacceptable long pauses (Full GCs) in this workload. As for the other "unusual" product options: *) Setting the value of -XX:InitiatingHeapOccupancyPercent seems to be purely for throughput optimization purposes to keep young gen really big all the time. The old gen occupancy in the logs is never even close to being exhausted (like ~2g out of 10g). The default value of 45 should be sufficient. Also, beginning with JDK 9 G1 automatically calculates an optimal value for this flag like CMS. From our experience G1's and probably CMS's heuristics yield better results than an average person, achieving higher throughput at no other costs. It is certainly possible to improve upon these heuristics with both collectors, if so, the options are there to allow you to try. Some more notes about other unusual options: *) As for using TargetSurvivorRatio to keep objects in the young gen, I am not completely convinced that it actually makes a lot of difference. One could use either -XX:SurvivorRatio or -XX:+NeverTenure instead to keep objects longer or as long as possible in the survivor generation. At least I have seen -XX:SurvivorRatio?being used in CMS. *) -XX:G1HeapRegionSize seems to be the only one that seems specific to the application and G1 and may be required. It is a bit unusual to use this if the old gen occupancy is that low - but it may be provide some improvement. The other options are neither unusual nor specific to G1 (Xms==Xmx, AlwaysPreTouch, UseLargePages, ...). They are typical options you use when you want to tune for throughput for any collector. Please be aware that these comments are based on the very coarse logs provided without any deeper analysis, so I may be wrong. > months of tuning work! I do not see a difference between required tuning effort for CMS and G1, except that there may be more experience in the community with CMS. It may be harder for you (assuming you have been using CMS for years), but the argument also works the other way. As for learning to use G1, we significantly revised the official documentation for G1. It and the accompanying tuning guide for G1 seems to be significantly more comprehensive than the one for CMS has ever been now. This should provide anyone new or moving to G1 tuning a significant headstart. In the future there will (hopefully) be no more need for unexplained lists of magic CMS/G1 options from somewhere on the internet. As for actual time taken to tune an application, I am really not the best person to ask: in my experience, tuning G1 is much less painful than CMS, there are much less options to use that make a difference, and the initial out-of-box results are typically better. However my applications and requirements are probably different than what you are looking at. Please, if you have issues with G1 (or any other collector), join the hotspot-gc-use mailing list and contribute your experience. > However, if I'm reading your mail correctly, your point is that the > version of G1 that will be delivered & made default in Java 9 is > substantially different from anything that has been seen so far in > shipping versions of Java 8? The changes in JDK9 change the performance profile in regards to startup, footprint, throughput and latency. These metrics will be different particularly out-of-the-box than in JDK 8u. The reasons are evolutionary optimization (or sometimes only changing some default values more adapted to current applications). Please see the JavaOne G1 presentation for some more details [3]. The collector itself and its mechanics did not change at all. E.g. the current documentation (and tuning guide) for G1 except for minor details (like default values, maybe some option renaming) also applies to JDK 8. This seems natural for a change of any software from one major version to another, given that there have been more than two years of time between now and JDK 8u40 that JEP 248 [2] references [4]. These changes were also guided by feedback from the community, like making particularly time consuming tuning automatic (e.g. adaptive sizing of IHOP [5]) or others. We will continue making G1 perform better particularly out-of-the box (e.g. the mentioned parallel full gc). So I am likely correct to say that the performance profile of G1 in JDK 10 at its release will be different from anything seen in JDK 9 at its release again, substantially for some cases. I assume that there will be EA releases again for the community to test long before release though. > Is that correct? Oracle are planning to make default a GC which has > had, essentially, zero testing on actual production workloads? Making G1 default collector has different reasons than suggesting it as CMS replacement. It affects different users, and different applications. This has been discussed before, see the JEP 248 discussion on this mailing list. The "new" G1 has been available for testing by the community since the start of JDK 9 EA releases around three years ago. At least some Linux distros provide OpenJDK 9 packages for some time now. So anyone can grab a copy at any time, test their application on them, and provide feedback. We are always happy to help with issues. Internally, we have been continuously performance and regression testing G1 for all that time, adding tests and flushing out bugs cropping up. Some open source projects have made G1 default with JDK 8(u) already, or provide settings for using their project with G1. There have been no negative reports that were not fixed I am aware of from people using G1 switching from JDK 8 to JDK 9. I guess there will be some more reports when JDK 9 launches, but this does not seem anything unusual for such a complex piece of software. Products switching from JDK 8 to JDK 9 that use CMS will still be able to use CMS as before in JDK 9. Regardless of GC I recommend testing before going into production. What I am asking is, if you are using CMS, please give G1 a try with JDK 9 (or even JDK 8u) and contribute feedback. If you unsuccessfully tried G1 with JDK 8u, please give it another look, it may fit your needs with JDK 9. We are also of course always very happy hearing about success stories with G1 :) Thanks, ? Thomas [1] https://docs.oracle.com/javase/9/gctuning/garbage-first-garbage-col lector-tuning.htm#JSGCT-GUID-90E30ACA-8040-432E-B3A0-1E0440AB556A? (Please, if you have time, have a look and give feedback. It collects a lot of experience and feedback from the community but we are aware that it may need further improvements!) [2]?http://openjdk.java.net/jeps/248 [3]?https://oracle.rainfocus.com/scripts/catalog/oow16.jsp?event=javaon e&search=CON3889&search.event=javaone [4]?https://www.java.com/en/download/faq/release_dates.xml [5]?https://bugs.openjdk.java.net/browse/JDK-8136677 [6]?https://bugs.openjdk.java.net/browse/JDK-8159697 From stephen.felts at oracle.com Sun Apr 16 20:45:40 2017 From: stephen.felts at oracle.com (Stephen Felts) Date: Sun, 16 Apr 2017 13:45:40 -0700 (PDT) Subject: JEP 291: Deprecate the Concurrent Mark Sweep (CMS) Garbage Collector In-Reply-To: <1492360013.5115.163.camel@oracle.com> References: <1492271820.9784.11.camel@oracle.com> <1492360013.5115.163.camel@oracle.com> Message-ID: <240a4299-d84f-4812-9e73-5f5fe6eeac48@default> When we did testing of G1 with SpecEnterprise2010 on JDK8, we saw measurably lower performance.? While this is a known benchmark, most or our internal benchmarks also saw lower performance. Work was done by the JDK team to improve that.? Looking for the externally available bugs: ? https://bugs.openjdk.java.net/browse/JDK-8065281 Avoid G1 write barriers on newly allocated objects - did not make it into JDK 8. ? https://bugs.openjdk.java.net/browse/JDK-8020306 G1: Minor Collections are 2x longer than Throughput collections ?- I think this made it into JDK 8 u40.? If you can't see this bug, you might be able to see these related bugs. I see that some of these bugs are still open. ? Issue Links duplicates Bug - A problem which impairs or prevents the functions of the product.HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8022038"JDK-8022038 REGRESSION: G1 minor collections 2s longer than throughput collector Bug - A problem which impairs or prevents the functions of the product.HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8022038"JDK-8022038 REGRESSION: G1 minor collections 2s longer than throughput collector ? relates to Enhancement - nullHYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8027547"JDK-8027547 G1 should not push already forwarded objects into the object task queue but special case them Enhancement - nullHYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8027551"JDK-8027551 Add fast path checking whether an object is scavengable in g1 oop scan closures Enhancement - nullHYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8027761"JDK-8027761 Investigate fast-path for scanning only objects with references during gc Enhancement - nullHYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8027545"JDK-8027545 Improve object array chunking test in G1's copy_to_survivor_space Enhancement - nullHYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8030144"JDK-8030144 Class loader data graph scanning causes high termination time Enhancement - nullHYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8030860"JDK-8030860 Initial mark time should be anticipated in G1 young gen sizing Enhancement - nullHYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8040120"JDK-8040120 Long delays during GC pause in G1 in some situations Enhancement - nullHYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8034842"JDK-8034842 Parallelize the Free CSet phase in G1 Enhancement - nullHYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8027553"JDK-8027553 Change the in_cset_fast_test functionality to use the G1BiasedArray abstraction Enhancement - nullHYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8027559"JDK-8027559 Decrease code size and templatizing in G1ParCopyClosure::do_oop_work Enhancement - nullHYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8027295"JDK-8027295 Free CSet takes ~50% of young pause time Enhancement - nullHYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8027746"JDK-8027746 Remove do_gen_barrier template parameter in G1ParCopyClosure Enhancement - nullHYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8027554"JDK-8027554 Implicit in-heap check in G1CollectedHeap::in_cset_fast_test() not always required ? ? ? ? ? -----Original Message----- From: Thomas Schatzl Sent: Sunday, April 16, 2017 12:27 PM To: Ben Evans Cc: jdk9-dev at openjdk.java.net Subject: Re: JEP 291: Deprecate the Concurrent Mark Sweep (CMS) Garbage Collector ? Hi Ben, ? On Sun, 2017-04-16 at 12:38 +0100, Ben Evans wrote: > Hi Thomas, > > I'm very glad the community has been able to provide an example of an > experimental configuration that's able to meet your publicised claims > - and all it took was unlocking experimental options and several ? ? use of the experimental options is not required in this case. They may be convenient to use, but not necessary. ? The used experimental options are -XX:G1NewSizePercent -XX:G1MaxNewSizePercent and -XX:G1MixedGCCountTarget: ? *) -XX:G1NewSizePercent -XX:G1MaxNewSizePercent can be substitued by appropriate values for -XX:NewSize and -XX:MaxNewSize. I have seen people using these ones with other collectors for exactly the same purpose, i.e. keep young gen large. ? *) The only experimental option left is -XX:G1MixedGCLiveThresholdPercent, but this one's effect could be substituted by the product flag -XX:G1MixedGCCountTarget. ? The new and updated documentation explains the use of all these options in more detail [1]. ? So there is almost certainly no need at all to use experimental options in this case, neither in JDK 8u nor in JDK 9. ? This does not mean we think G1 is perfect: ideally it would meet the pause time requirement without any of these extra options. So we are working on CRs like?JDK-8159697?[6] to make G1 out-of-the-box experience even better in the future. ? In comparison point, CMS runs into unacceptable long pauses (Full GCs) in this workload. ? As for the other "unusual" product options: ? *) Setting the value of -XX:InitiatingHeapOccupancyPercent seems to be purely for throughput optimization purposes to keep young gen really big all the time. The old gen occupancy in the logs is never even close to being exhausted (like ~2g out of 10g). The default value of 45 should be sufficient. ? Also, beginning with JDK 9 G1 automatically calculates an optimal value for this flag like CMS. From our experience G1's and probably CMS's heuristics yield better results than an average person, achieving higher throughput at no other costs. ? It is certainly possible to improve upon these heuristics with both collectors, if so, the options are there to allow you to try. ? Some more notes about other unusual options: ? *) As for using TargetSurvivorRatio to keep objects in the young gen, I am not completely convinced that it actually makes a lot of difference. One could use either -XX:SurvivorRatio or -XX:+NeverTenure instead to keep objects longer or as long as possible in the survivor generation. At least I have seen -XX:SurvivorRatio?being used in CMS. ? *) -XX:G1HeapRegionSize seems to be the only one that seems specific to the application and G1 and may be required. It is a bit unusual to use this if the old gen occupancy is that low - but it may be provide some improvement. ? The other options are neither unusual nor specific to G1 (Xms==Xmx, AlwaysPreTouch, UseLargePages, ...). They are typical options you use when you want to tune for throughput for any collector. ? Please be aware that these comments are based on the very coarse logs provided without any deeper analysis, so I may be wrong. ? > months of tuning work! ? I do not see a difference between required tuning effort for CMS and G1, except that there may be more experience in the community with CMS. It may be harder for you (assuming you have been using CMS for years), but the argument also works the other way. ? As for learning to use G1, we significantly revised the official documentation for G1. It and the accompanying tuning guide for G1 seems to be significantly more comprehensive than the one for CMS has ever been now. This should provide anyone new or moving to G1 tuning a significant headstart. In the future there will (hopefully) be no more need for unexplained lists of magic CMS/G1 options from somewhere on the internet. ? As for actual time taken to tune an application, I am really not the best person to ask: in my experience, tuning G1 is much less painful than CMS, there are much less options to use that make a difference, and the initial out-of-box results are typically better. However my applications and requirements are probably different than what you are looking at. ? Please, if you have issues with G1 (or any other collector), join the hotspot-gc-use mailing list and contribute your experience. ? > However, if I'm reading your mail correctly, your point is that the > version of G1 that will be delivered & made default in Java 9 is > substantially different from anything that has been seen so far in > shipping versions of Java 8? ? The changes in JDK9 change the performance profile in regards to startup, footprint, throughput and latency. These metrics will be different particularly out-of-the-box than in JDK 8u. The reasons are evolutionary optimization (or sometimes only changing some default values more adapted to current applications). ? Please see the JavaOne G1 presentation for some more details [3]. ? The collector itself and its mechanics did not change at all. E.g. the current documentation (and tuning guide) for G1 except for minor details (like default values, maybe some option renaming) also applies to JDK 8. ? This seems natural for a change of any software from one major version to another, given that there have been more than two years of time between now and JDK 8u40 that JEP 248 [2] references [4]. ? These changes were also guided by feedback from the community, like making particularly time consuming tuning automatic (e.g. adaptive sizing of IHOP [5]) or others. ? We will continue making G1 perform better particularly out-of-the box (e.g. the mentioned parallel full gc). So I am likely correct to say that the performance profile of G1 in JDK 10 at its release will be different from anything seen in JDK 9 at its release again, substantially for some cases. I assume that there will be EA releases again for the community to test long before release though. ? > Is that correct? Oracle are planning to make default a GC which has > had, essentially, zero testing on actual production workloads? ? Making G1 default collector has different reasons than suggesting it as CMS replacement. It affects different users, and different applications. This has been discussed before, see the JEP 248 discussion on this mailing list. ? The "new" G1 has been available for testing by the community since the start of JDK 9 EA releases around three years ago. At least some Linux distros provide OpenJDK 9 packages for some time now. So anyone can grab a copy at any time, test their application on them, and provide feedback. We are always happy to help with issues. ? Internally, we have been continuously performance and regression testing G1 for all that time, adding tests and flushing out bugs cropping up. ? Some open source projects have made G1 default with JDK 8(u) already, or provide settings for using their project with G1. There have been no negative reports that were not fixed I am aware of from people using G1 switching from JDK 8 to JDK 9. I guess there will be some more reports when JDK 9 launches, but this does not seem anything unusual for such a complex piece of software. ? Products switching from JDK 8 to JDK 9 that use CMS will still be able to use CMS as before in JDK 9. Regardless of GC I recommend testing before going into production. ? What I am asking is, if you are using CMS, please give G1 a try with JDK 9 (or even JDK 8u) and contribute feedback. If you unsuccessfully tried G1 with JDK 8u, please give it another look, it may fit your needs with JDK 9. We are also of course always very happy hearing about success stories with G1 :) ? Thanks, ? Thomas ? [1] https://docs.oracle.com/javase/9/gctuning/garbage-first-garbage-col lector-tuning.htm#JSGCT-GUID-90E30ACA-8040-432E-B3A0-1E0440AB556A (Please, if you have time, have a look and give feedback. It collects a lot of experience and feedback from the community but we are aware that it may need further improvements!) [2]?http://openjdk.java.net/jeps/248 [3]?https://oracle.rainfocus.com/scripts/catalog/oow16.jsp?event=javaon e&search=CON3889&search.event=javaone [4]?https://www.java.com/en/download/faq/release_dates.xml [5]?https://bugs.openjdk.java.net/browse/JDK-8136677 [6]?https://bugs.openjdk.java.net/browse/JDK-8159697 ? From thomas.schatzl at oracle.com Sun Apr 16 22:42:28 2017 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Mon, 17 Apr 2017 00:42:28 +0200 Subject: JEP 291: Deprecate the Concurrent Mark Sweep (CMS) Garbage Collector In-Reply-To: <1492360013.5115.163.camel@oracle.com> References: <1492271820.9784.11.camel@oracle.com> <1492360013.5115.163.camel@oracle.com> Message-ID: <1492382548.5115.230.camel@oracle.com> Hi again, On Sun, 2017-04-16 at 18:26 +0200, Thomas Schatzl wrote: > > Please see the JavaOne G1 presentation for some more details [3]. [...] > [3]?https://oracle.rainfocus.com/scripts/catalog/oow16.jsp?event=java > one&search=CON3889&search.event=javaone ? of course I got the reference wrong, the one I meant is CON3815 [1]. Apologies. And in case you are curious about the scope of improvements of G1 JDK 9 vs. 8u on huge workloads, have a look at CON1516: "Java 9: The Quest for Very Large Heaps" [2]. This is an example with requirements and setup way beyond the typical application (we can call it "big toy-application" for this discussion), so its applicability to your workloads is of course rather questionable (I only mention it because when looking up the G1 JDK 9 presentation for JavaOne this one also showed up, I agree it is way too different to yours). However all of the changes to make this possible also change G1 behavior on much smaller heaps on much smaller machines significantly - but you have to trust me here that these changes are desirable :) As for testing, I think the last significant commit related to G1 performance for JDK 9 has been pushed to master mid-September last year [3], most of them months earlier. This means there has been opportunity for running JDK 9 on any (non-Oracle) actual production workloads with basically the final version of G1 by the community for seven months now for anyone, and contribute their experience. Thanks, ? Thomas [1]?https://oracle.rainfocus.com/scripts/catalog/oow16.jsp?event=javaon e&search=CON3815&search.event=javaone [2]?https://oracle.rainfocus.com/scripts/catalog/oow16.jsp?event=javaon e&search=CON1516&search.event=javaone [3] I think?https://bugs.openjdk.java.net/browse/JDK-8159422 From mark.reinhold at oracle.com Mon Apr 17 20:28:18 2017 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Mon, 17 Apr 2017 13:28:18 -0700 Subject: JEPs proposed to target JDK 9 (2017/4/4) In-Reply-To: <20170404142038.986268464@eggemoggin.niobe.net> References: <20170404142038.986268464@eggemoggin.niobe.net> Message-ID: <20170417132818.529233869@eggemoggin.niobe.net> 2017/4/4 14:20:38 -0700, mark.reinhold at oracle.com: > The following JEPs have been placed into the "Proposed to Target" state > by their owners after discussion and review: > > 291: Deprecate the Concurrent Mark Sweep (CMS) Garbage Collector > http://openjdk.java.net/jeps/291 > > 299: Reorganize Documentation > http://openjdk.java.net/jeps/299 > > Feedback on these proposals is more than welcome, as are reasoned > objections. If no such objections are raised by 23:00 UTC on Tuesday, > 11 April, or if they're raised and then satisfactorily answered, then > per the JEP 2.0 process proposal [1] I'll target these JEPs to JDK 9. Regarding JEP 291, I've seen a few expressions of interest by people who could plausibly take on the maintainership of CMS but no firm plan as yet, so I've targeted this JEP to JDK 9. As I wrote earlier, if someone steps up later on then CMS can be un-deprecated at that time. I've seen no comments on JEP 299, so I've targeted that to JDK 9 also. - Mark From chenyt.cs.sjtu at gmail.com Tue Apr 18 01:14:32 2017 From: chenyt.cs.sjtu at gmail.com (Yuting Chen) Date: Mon, 17 Apr 2017 18:14:32 -0700 Subject: aot compiler halts when there exists an infinite loop in clinit() Message-ID: Hi, I recently met a problem: when I tried to compile a class whose clinit method contains an infinite loop, the aotc waits and fails to response.... It seems that the aotc performs some static analysis before the compilation, while the analysis may not stop (when an infinite loop is there). The bytecode is shown as follows: public class Vector1 minor version: 0 major version: 52 flags: ACC_PUBLIC, ACC_SUPER Constant pool: #1 = Utf8 Vector1 #2 = Class #1 // Vector1 #3 = Utf8 java/lang/Object #4 = Class #3 // java/lang/Object #5 = Utf8 serialVersionUID #6 = Utf8 J #7 = Long -2767605614048989439l #9 = Utf8 #10 = Utf8 ()V #11 = NameAndType #5:#6 // serialVersionUID:J #12 = Fieldref #2.#11 // Vector1.serialVersionUID:J #13 = Utf8 main #14 = Utf8 ([Ljava/lang/String;)V #15 = Utf8 ConstantValue #16 = Utf8 Code #17 = Utf8 StackMapTable { public static {}; descriptor: ()V flags: ACC_PUBLIC, ACC_STATIC Code: stack=2, locals=0, args_size=0 0: ldc2_w #7 // long -2767605614048989439l 3: putstatic #12 // Field serialVersionUID:J 6: iconst_1 7: iconst_m1 8: iadd 9: ifge 0 12: return StackMapTable: number_of_entries = 1 frame_type = 0 /* same */ public static void main(java.lang.String[]); descriptor: ([Ljava/lang/String;)V flags: ACC_PUBLIC, ACC_STATIC Code: stack=0, locals=1, args_size=1 0: return } From chenyt.cs.sjtu at gmail.com Tue Apr 18 01:43:10 2017 From: chenyt.cs.sjtu at gmail.com (Yuting Chen) Date: Mon, 17 Apr 2017 18:43:10 -0700 Subject: aot compiler halts when there exists an infinite loop in clinit() In-Reply-To: References: Message-ID: If I moved the infinite loop to any other method (e.g., main), the class can then be compiled. I guess jaotc runs clinit when it compiles clinit. On Mon, Apr 17, 2017 at 6:14 PM, Yuting Chen wrote: > Hi, I recently met a problem: when I tried to compile a class whose > clinit method contains an infinite loop, the aotc waits and fails to > response.... > > It seems that the aotc performs some static analysis before the > compilation, while the analysis may not stop (when an infinite loop is > there). > > The bytecode is shown as follows: > > public class Vector1 > minor version: 0 > major version: 52 > flags: ACC_PUBLIC, ACC_SUPER > Constant pool: > #1 = Utf8 Vector1 > #2 = Class #1 // Vector1 > #3 = Utf8 java/lang/Object > #4 = Class #3 // java/lang/Object > #5 = Utf8 serialVersionUID > #6 = Utf8 J > #7 = Long -2767605614048989439l > #9 = Utf8 > #10 = Utf8 ()V > #11 = NameAndType #5:#6 // serialVersionUID:J > #12 = Fieldref #2.#11 // Vector1.serialVersionUID:J > #13 = Utf8 main > #14 = Utf8 ([Ljava/lang/String;)V > #15 = Utf8 ConstantValue > #16 = Utf8 Code > #17 = Utf8 StackMapTable > { > public static {}; > descriptor: ()V > flags: ACC_PUBLIC, ACC_STATIC > Code: > stack=2, locals=0, args_size=0 > 0: ldc2_w #7 // long -2767605614048989439l > 3: putstatic #12 // Field serialVersionUID:J > 6: iconst_1 > 7: iconst_m1 > 8: iadd > 9: ifge 0 > 12: return > StackMapTable: number_of_entries = 1 > frame_type = 0 /* same */ > > public static void main(java.lang.String[]); > descriptor: ([Ljava/lang/String;)V > flags: ACC_PUBLIC, ACC_STATIC > Code: > stack=0, locals=1, args_size=1 > 0: return > } From david.holmes at oracle.com Tue Apr 18 02:16:37 2017 From: david.holmes at oracle.com (David Holmes) Date: Tue, 18 Apr 2017 12:16:37 +1000 Subject: aot compiler halts when there exists an infinite loop in clinit() In-Reply-To: References: Message-ID: <43aed67c-27f7-bbbd-25b3-194a034ff029@oracle.com> Redirecting to hotspot-compiler-dev, please do not reply to jdk9-dev. Thanks, David On 18/04/2017 11:43 AM, Yuting Chen wrote: > If I moved the infinite loop to any other method (e.g., main), the > class can then be compiled. I guess jaotc runs clinit when it compiles > clinit. > > On Mon, Apr 17, 2017 at 6:14 PM, Yuting Chen wrote: >> Hi, I recently met a problem: when I tried to compile a class whose >> clinit method contains an infinite loop, the aotc waits and fails to >> response.... >> >> It seems that the aotc performs some static analysis before the >> compilation, while the analysis may not stop (when an infinite loop is >> there). >> >> The bytecode is shown as follows: >> >> public class Vector1 >> minor version: 0 >> major version: 52 >> flags: ACC_PUBLIC, ACC_SUPER >> Constant pool: >> #1 = Utf8 Vector1 >> #2 = Class #1 // Vector1 >> #3 = Utf8 java/lang/Object >> #4 = Class #3 // java/lang/Object >> #5 = Utf8 serialVersionUID >> #6 = Utf8 J >> #7 = Long -2767605614048989439l >> #9 = Utf8 >> #10 = Utf8 ()V >> #11 = NameAndType #5:#6 // serialVersionUID:J >> #12 = Fieldref #2.#11 // Vector1.serialVersionUID:J >> #13 = Utf8 main >> #14 = Utf8 ([Ljava/lang/String;)V >> #15 = Utf8 ConstantValue >> #16 = Utf8 Code >> #17 = Utf8 StackMapTable >> { >> public static {}; >> descriptor: ()V >> flags: ACC_PUBLIC, ACC_STATIC >> Code: >> stack=2, locals=0, args_size=0 >> 0: ldc2_w #7 // long -2767605614048989439l >> 3: putstatic #12 // Field serialVersionUID:J >> 6: iconst_1 >> 7: iconst_m1 >> 8: iadd >> 9: ifge 0 >> 12: return >> StackMapTable: number_of_entries = 1 >> frame_type = 0 /* same */ >> >> public static void main(java.lang.String[]); >> descriptor: ([Ljava/lang/String;)V >> flags: ACC_PUBLIC, ACC_STATIC >> Code: >> stack=0, locals=1, args_size=1 >> 0: return >> } From volker.simonis at gmail.com Tue Apr 18 13:03:18 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 18 Apr 2017 15:03:18 +0200 Subject: Result: New JDK 9/10 Reviewer: Thomas Stuefe Message-ID: Voting for Thomas Stuefe [1] is now closed. Yes: 20 Veto: 0 Abstain: 0 According to the Bylaws definition of Three-Vote Consensus, this is sufficient to approve the nomination. Regards, Volker [1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2017-March/thread.html#5639 From volker.simonis at gmail.com Tue Apr 18 13:03:23 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 18 Apr 2017 15:03:23 +0200 Subject: Result: New JDK 9/10 Reviewer: Martin Doerr Message-ID: Voting for Martin Doerr [1] is now closed. Yes: 21 Veto: 0 Abstain: 0 According to the Bylaws definition of Three-Vote Consensus, this is sufficient to approve the nomination. Regards, Volker [1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2017-March/thread.html#5640 From peter.levart at gmail.com Wed Apr 19 09:23:24 2017 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 19 Apr 2017 11:23:24 +0200 Subject: aot compiler halts when there exists an infinite loop in clinit() In-Reply-To: References: Message-ID: <262aad70-0c88-9518-9877-b462d8668a84@gmail.com> Assuming your hunch is correct, I would call this a feature, not a bug. Isn't it better when compilation of a program loops infinitely than when the program loops infinitely at runtime? :-) Regards, Peter On 04/18/2017 03:14 AM, Yuting Chen wrote: > Hi, I recently met a problem: when I tried to compile a class whose > clinit method contains an infinite loop, the aotc waits and fails to > response.... > > It seems that the aotc performs some static analysis before the > compilation, while the analysis may not stop (when an infinite loop is > there). > > The bytecode is shown as follows: > > public class Vector1 > minor version: 0 > major version: 52 > flags: ACC_PUBLIC, ACC_SUPER > Constant pool: > #1 = Utf8 Vector1 > #2 = Class #1 // Vector1 > #3 = Utf8 java/lang/Object > #4 = Class #3 // java/lang/Object > #5 = Utf8 serialVersionUID > #6 = Utf8 J > #7 = Long -2767605614048989439l > #9 = Utf8 > #10 = Utf8 ()V > #11 = NameAndType #5:#6 // serialVersionUID:J > #12 = Fieldref #2.#11 // Vector1.serialVersionUID:J > #13 = Utf8 main > #14 = Utf8 ([Ljava/lang/String;)V > #15 = Utf8 ConstantValue > #16 = Utf8 Code > #17 = Utf8 StackMapTable > { > public static {}; > descriptor: ()V > flags: ACC_PUBLIC, ACC_STATIC > Code: > stack=2, locals=0, args_size=0 > 0: ldc2_w #7 // long -2767605614048989439l > 3: putstatic #12 // Field serialVersionUID:J > 6: iconst_1 > 7: iconst_m1 > 8: iadd > 9: ifge 0 > 12: return > StackMapTable: number_of_entries = 1 > frame_type = 0 /* same */ > > public static void main(java.lang.String[]); > descriptor: ([Ljava/lang/String;)V > flags: ACC_PUBLIC, ACC_STATIC > Code: > stack=0, locals=1, args_size=1 > 0: return > } From chenyt.cs.sjtu at gmail.com Wed Apr 19 16:47:26 2017 From: chenyt.cs.sjtu at gmail.com (Yuting Chen) Date: Wed, 19 Apr 2017 09:47:26 -0700 Subject: aot compiler halts when there exists an infinite loop in clinit() In-Reply-To: <262aad70-0c88-9518-9877-b462d8668a84@gmail.com> References: <262aad70-0c88-9518-9877-b462d8668a84@gmail.com> Message-ID: The compiler can itself be a jvm, :) I'd expect that some timeout messages will be reported (a quick patch?). I compiled some pieces of bytecode and waited for the whole night... Regards, Yuting On Wed, Apr 19, 2017 at 2:23 AM, Peter Levart wrote: > > Assuming your hunch is correct, I would call this a feature, not a bug. > Isn't it better when compilation of a program loops infinitely than when the > program loops infinitely at runtime? :-) > > > Regards, Peter > > > On 04/18/2017 03:14 AM, Yuting Chen wrote: >> >> Hi, I recently met a problem: when I tried to compile a class whose >> clinit method contains an infinite loop, the aotc waits and fails to >> response.... >> >> It seems that the aotc performs some static analysis before the >> compilation, while the analysis may not stop (when an infinite loop is >> there). >> >> The bytecode is shown as follows: >> >> public class Vector1 >> minor version: 0 >> major version: 52 >> flags: ACC_PUBLIC, ACC_SUPER >> Constant pool: >> #1 = Utf8 Vector1 >> #2 = Class #1 // Vector1 >> #3 = Utf8 java/lang/Object >> #4 = Class #3 // java/lang/Object >> #5 = Utf8 serialVersionUID >> #6 = Utf8 J >> #7 = Long -2767605614048989439l >> #9 = Utf8 >> #10 = Utf8 ()V >> #11 = NameAndType #5:#6 // serialVersionUID:J >> #12 = Fieldref #2.#11 // Vector1.serialVersionUID:J >> #13 = Utf8 main >> #14 = Utf8 ([Ljava/lang/String;)V >> #15 = Utf8 ConstantValue >> #16 = Utf8 Code >> #17 = Utf8 StackMapTable >> { >> public static {}; >> descriptor: ()V >> flags: ACC_PUBLIC, ACC_STATIC >> Code: >> stack=2, locals=0, args_size=0 >> 0: ldc2_w #7 // long >> -2767605614048989439l >> 3: putstatic #12 // Field serialVersionUID:J >> 6: iconst_1 >> 7: iconst_m1 >> 8: iadd >> 9: ifge 0 >> 12: return >> StackMapTable: number_of_entries = 1 >> frame_type = 0 /* same */ >> >> public static void main(java.lang.String[]); >> descriptor: ([Ljava/lang/String;)V >> flags: ACC_PUBLIC, ACC_STATIC >> Code: >> stack=0, locals=1, args_size=1 >> 0: return >> } > > From vladimir.kozlov at oracle.com Wed Apr 19 16:59:02 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 19 Apr 2017 09:59:02 -0700 Subject: aot compiler halts when there exists an infinite loop in clinit() In-Reply-To: References: <262aad70-0c88-9518-9877-b462d8668a84@gmail.com> Message-ID: Graal do report it in some cases (JDK-8178796): Error: Failed compilation: compiler.calls.common.InvokeSpecial.caller()V: org.graalvm.compiler.common.RetryableBailoutException: Compilation exceeded 300 seconds during CFG traversal But timeout in may be hard to catch since it is done in JVM runtime and not in compiler. Also I don't know if we should spend time on your case. If an application depends on such class it will never be able to execute. Should we care about such case? Vladimir On 4/19/17 9:47 AM, Yuting Chen wrote: > The compiler can itself be a jvm, :) > > I'd expect that some timeout messages will be reported (a quick > patch?). I compiled some pieces of bytecode and waited for the whole > night... > > Regards, > Yuting > > On Wed, Apr 19, 2017 at 2:23 AM, Peter Levart wrote: >> >> Assuming your hunch is correct, I would call this a feature, not a bug. >> Isn't it better when compilation of a program loops infinitely than when the >> program loops infinitely at runtime? :-) >> >> >> Regards, Peter >> >> >> On 04/18/2017 03:14 AM, Yuting Chen wrote: >>> >>> Hi, I recently met a problem: when I tried to compile a class whose >>> clinit method contains an infinite loop, the aotc waits and fails to >>> response.... >>> >>> It seems that the aotc performs some static analysis before the >>> compilation, while the analysis may not stop (when an infinite loop is >>> there). >>> >>> The bytecode is shown as follows: >>> >>> public class Vector1 >>> minor version: 0 >>> major version: 52 >>> flags: ACC_PUBLIC, ACC_SUPER >>> Constant pool: >>> #1 = Utf8 Vector1 >>> #2 = Class #1 // Vector1 >>> #3 = Utf8 java/lang/Object >>> #4 = Class #3 // java/lang/Object >>> #5 = Utf8 serialVersionUID >>> #6 = Utf8 J >>> #7 = Long -2767605614048989439l >>> #9 = Utf8 >>> #10 = Utf8 ()V >>> #11 = NameAndType #5:#6 // serialVersionUID:J >>> #12 = Fieldref #2.#11 // Vector1.serialVersionUID:J >>> #13 = Utf8 main >>> #14 = Utf8 ([Ljava/lang/String;)V >>> #15 = Utf8 ConstantValue >>> #16 = Utf8 Code >>> #17 = Utf8 StackMapTable >>> { >>> public static {}; >>> descriptor: ()V >>> flags: ACC_PUBLIC, ACC_STATIC >>> Code: >>> stack=2, locals=0, args_size=0 >>> 0: ldc2_w #7 // long >>> -2767605614048989439l >>> 3: putstatic #12 // Field serialVersionUID:J >>> 6: iconst_1 >>> 7: iconst_m1 >>> 8: iadd >>> 9: ifge 0 >>> 12: return >>> StackMapTable: number_of_entries = 1 >>> frame_type = 0 /* same */ >>> >>> public static void main(java.lang.String[]); >>> descriptor: ([Ljava/lang/String;)V >>> flags: ACC_PUBLIC, ACC_STATIC >>> Code: >>> stack=0, locals=1, args_size=1 >>> 0: return >>> } >> >> From lana.steuck at oracle.com Wed Apr 19 21:13:32 2017 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 19 Apr 2017 21:13:32 GMT Subject: jdk9-b166: dev Message-ID: <201704192113.v3JLDWEH017229@scaaa563.us.oracle.com> http://hg.openjdk.java.net/jdk9/jdk9/rev/ba5b16c9c6d8 http://hg.openjdk.java.net/jdk9/jdk9/nashorn/rev/5b2e7b2101c0 http://hg.openjdk.java.net/jdk9/jdk9/langtools/rev/2a8b403a6233 http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/5d2b48f1f0a3 http://hg.openjdk.java.net/jdk9/jdk9/jaxws/rev/b1f30c27367b http://hg.openjdk.java.net/jdk9/jdk9/jaxp/rev/8d3febd5c9d8 http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/560d7aa083a2 http://hg.openjdk.java.net/jdk9/jdk9/corba/rev/934c18145915 --- All the fixes will be tested during promotion (no PIT testing at this point): List of all fixes: =================== JDK-6574989 client-libs TEST_BUG: javax/sound/sampled/Clip/bug5070081.java fails sometimes JDK-8164469 client-libs [TEST_BUG] Unity, java/awt/MouseInfo/JContainerMousePositionTest.java JDK-8167102 client-libs [macosx] PrintRequestAttributeSet breaks page size set using PageForma JDK-8176490 client-libs [macosx] Sometimes NSWindow.isZoomed hangs JDK-8176544 client-libs Compilation error in plaf.metal.MetalBumps.Test6657026 JDK-8177137 client-libs 8175293 breaks Windows build on VS 2010 JDK-8177386 client-libs [TESTBUG] The "Undo" menu item in the context menu is disable JDK-8177450 client-libs javax.swing.text.html.parser.Parser parseScript ignores a character af JDK-8177461 client-libs Wrong references are used in the javadoc in the java.desktop module JDK-8177560 client-libs @headful key can be removed from the tests for JavaSound JDK-8177625 client-libs apple.laf.JRSUIConstants.getConstantName(int) checks for THUMB_START t JDK-8177672 client-libs DataFlavor.imageFlavor is null when the java.desktop module is not res JDK-8177766 client-libs [TEST_BUG] JPopupMenu tests fails intermittently JDK-8158168 core-libs Missing bounds checks for some String intrinsics JDK-8177314 core-libs java VM fails to start with a Japanese ShiftJIS locale JDK-8177536 core-libs Avoid Apple Peer-to-Peer interfaces in networking tests JDK-8177682 core-libs Suppress removal warning for System.runFinalizersOnExit JDK-8177969 core-libs Faster FilePermission::implies by avoiding the use of Path::relativize JDK-8178147 core-libs Race conditions in timeout handling code in http/2 incubator client JDK-8178347 core-libs Process and ProcessHandle getPid method name inconsistency JDK-8178783 core-libs Java_sun_nio_ch_EPoll_close0 definition, but no sun.nio.ch.EPoll.close JDK-8178840 core-libs Adds FieldSetAccessibleTest.java and VerifyJimage.java to ProblemList JDK-8164390 core-svc Provide a javadoc descriptions for jdk.attach, jdk.jvmstat, jdk.manag JDK-8178447 core-svc Remove link from JavaDoc to Dev guide JDK-8177684 deploy Suppress lint removal warnings in AppletSecurity JDK-8135161 hotspot Missing commas in copyright notices JDK-8176887 hotspot AOT: SIGSEGV in AOTCodeHeap::next when using specific configuration JDK-8178119 hotspot [JVMCI] when rethrowing exceptions at deopt the exception must be fetc JDK-8178731 hotspot compiler/ciReplay/SABase.java does not compile JDK-8176271 infrastructure Still unable to build JDK 9 on some *7 sparcs JDK-8177553 infrastructure Address removal lint warnings in the JDK build JDK-8177822 infrastructure Move closed jib configuration for arm platforms to open JDK-8177723 other-libs Suppress lint removal warning in java.se.ee and jdk.unsupported JDK-8177683 security-libs Suppress lint removal warnings in jdk.security and jdk.policytool JDK-8177784 security-libs Use CounterMode intrinsic for AES/GCM JDK-8178083 security-libs Remove intermittent key from java/security/SignedObject/Chain.java JDK-8178795 security-libs krb5 Basic.java test should be basic JDK-8161295 tools javac, cleanup use of ModuleTestBase JDK-8169971 tools JLinkMultiReleaseJarTest.java fails intermittently at the final clean JDK-8175823 tools doclet crashes when documenting a single class in a module. JDK-8176801 tools tools/javac/platform/PlatformProviderTest.java sensitive to warnings s JDK-8178023 tools jshell tool: crash with ugly message on attempt to add non-existant mo JDK-8178067 tools support for @uses/@provides tags is broken JDK-8178414 tools T8177933.java fails even after fix for JDK-8178283 JDK-8178426 tools Extra } is coming in the javadoc of Taglet.toString() API JDK-8178493 tools StandardJavaFileManager: Clarify/document the use of IllegalStateExcep JDK-8178509 tools MODULE_SOURCE_PATH: Implement missing methods JDK-8178520 tools jshell tool: /help /save -- incorrect description of /save -start JDK-8178686 tools Fix incorrect bug id in test. From ioi.lam at oracle.com Wed Apr 19 23:17:24 2017 From: ioi.lam at oracle.com (Ioi Lam) Date: Thu, 20 Apr 2017 07:17:24 +0800 Subject: aot compiler halts when there exists an infinite loop in clinit() In-Reply-To: References: <262aad70-0c88-9518-9877-b462d8668a84@gmail.com> Message-ID: <1D0328D6-11E3-4E3B-B888-2C2140CF9EFC@oracle.com> Does AOT run the class initializers during compilation? What if the class initializer has undesirable side effects such as calling System.exit or delete files in the current directory, etc? Ioi > Vladimir Kozlov ? 2017?4?20? ??12:59 ??? > > Graal do report it in some cases (JDK-8178796): > > Error: Failed compilation: compiler.calls.common.InvokeSpecial.caller()V: org.graalvm.compiler.common.RetryableBailoutException: Compilation exceeded 300 seconds during CFG traversal > > But timeout in may be hard to catch since it is done in JVM runtime and not in compiler. > > Also I don't know if we should spend time on your case. If an application depends on such class it will never be able to execute. Should we care about such case? > > Vladimir > >> On 4/19/17 9:47 AM, Yuting Chen wrote: >> The compiler can itself be a jvm, :) >> >> I'd expect that some timeout messages will be reported (a quick >> patch?). I compiled some pieces of bytecode and waited for the whole >> night... >> >> Regards, >> Yuting >> >>> On Wed, Apr 19, 2017 at 2:23 AM, Peter Levart wrote: >>> >>> Assuming your hunch is correct, I would call this a feature, not a bug. >>> Isn't it better when compilation of a program loops infinitely than when the >>> program loops infinitely at runtime? :-) >>> >>> >>> Regards, Peter >>> >>> >>>> On 04/18/2017 03:14 AM, Yuting Chen wrote: >>>> >>>> Hi, I recently met a problem: when I tried to compile a class whose >>>> clinit method contains an infinite loop, the aotc waits and fails to >>>> response.... >>>> >>>> It seems that the aotc performs some static analysis before the >>>> compilation, while the analysis may not stop (when an infinite loop is >>>> there). >>>> >>>> The bytecode is shown as follows: >>>> >>>> public class Vector1 >>>> minor version: 0 >>>> major version: 52 >>>> flags: ACC_PUBLIC, ACC_SUPER >>>> Constant pool: >>>> #1 = Utf8 Vector1 >>>> #2 = Class #1 // Vector1 >>>> #3 = Utf8 java/lang/Object >>>> #4 = Class #3 // java/lang/Object >>>> #5 = Utf8 serialVersionUID >>>> #6 = Utf8 J >>>> #7 = Long -2767605614048989439l >>>> #9 = Utf8 >>>> #10 = Utf8 ()V >>>> #11 = NameAndType #5:#6 // serialVersionUID:J >>>> #12 = Fieldref #2.#11 // Vector1.serialVersionUID:J >>>> #13 = Utf8 main >>>> #14 = Utf8 ([Ljava/lang/String;)V >>>> #15 = Utf8 ConstantValue >>>> #16 = Utf8 Code >>>> #17 = Utf8 StackMapTable >>>> { >>>> public static {}; >>>> descriptor: ()V >>>> flags: ACC_PUBLIC, ACC_STATIC >>>> Code: >>>> stack=2, locals=0, args_size=0 >>>> 0: ldc2_w #7 // long >>>> -2767605614048989439l >>>> 3: putstatic #12 // Field serialVersionUID:J >>>> 6: iconst_1 >>>> 7: iconst_m1 >>>> 8: iadd >>>> 9: ifge 0 >>>> 12: return >>>> StackMapTable: number_of_entries = 1 >>>> frame_type = 0 /* same */ >>>> >>>> public static void main(java.lang.String[]); >>>> descriptor: ([Ljava/lang/String;)V >>>> flags: ACC_PUBLIC, ACC_STATIC >>>> Code: >>>> stack=0, locals=1, args_size=1 >>>> 0: return >>>> } >>> >>> From james.laskey at oracle.com Thu Apr 20 20:11:11 2017 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Thu, 20 Apr 2017 17:11:11 -0300 Subject: CFV: New JDK 9/10 Committer: Srinivas Dama Message-ID: <6E354E60-2931-452B-BADE-381486501B31@oracle.com> I hereby nominate Srinivas Dama to JDK 9 and JDK 10 Committer. Srini is part of the Langtools team since August 2015 and has made many contributions to JDK 9. I have included 8 of the the most significant change sets. Votes are due by May 5, 2017. Only current JDK 9/10 Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [2]. ? Jim [1] http://openjdk.java.net/census [2] http://openjdk.java.net/bylaws#lazy-consensus Contributions 8138906: Test test/script/trusted/JDK-8087292.js intermittently fails. https://bugs.openjdk.java.net/browse/JDK-8138906 http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/9937077e48f1 8156743: ES6 for..of should work for Java Maps and Sets https://bugs.openjdk.java.net/browse/JDK-8156743 http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/4561f9afd9bd 8144113: Implement new tests to cover jjs functionality https://bugs.openjdk.java.net/browse/JDK-8144113 http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/086c19a36be6 8147591: Revisit Collection.toArray(new T[size]) calls in nashorn and dynalink code https://bugs.openjdk.java.net/browse/JDK-8147591 http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/0da44ab8c417 8147613: enable jjs tests on Windows https://bugs.openjdk.java.net/browse/JDK-8147613 http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/25b13597ea73 8156615: Catch parameter can be a BindingPattern in ES6 mode https://bugs.openjdk.java.net/browse/JDK-8156615 http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/4a68dd740be8 8139255: javac reports "cannot override" messages instead of "cannot hide" messages for static methods https://bugs.openjdk.java.net/browse/JDK-8139255 http://hg.openjdk.java.net/jdk9/dev/langtools/rev/fdfaa0e5c8c0 8134304: NPE in initialization of OptimisticTypesPersistence https://bugs.openjdk.java.net/browse/JDK-8134304 http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/3487086f145a From sundararajan.athijegannathan at oracle.com Fri Apr 21 02:59:16 2017 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Fri, 21 Apr 2017 08:29:16 +0530 Subject: CFV: New JDK 9/10 Committer: Srinivas Dama In-Reply-To: <6E354E60-2931-452B-BADE-381486501B31@oracle.com> References: <6E354E60-2931-452B-BADE-381486501B31@oracle.com> Message-ID: <58F97584.4020208@oracle.com> Vote: yes -Sundar On 21/04/17, 1:41 AM, Jim Laskey (Oracle) wrote: > I hereby nominate Srinivas Dama to JDK 9 and JDK 10 Committer. > > Srini is part of the Langtools team since August 2015 and has made many contributions to JDK 9. > I have included 8 of the the most significant change sets. > > Votes are due by May 5, 2017. > > Only current JDK 9/10 Committers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > ? Jim > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/bylaws#lazy-consensus > > > Contributions > > 8138906: Test test/script/trusted/JDK-8087292.js intermittently fails. > https://bugs.openjdk.java.net/browse/JDK-8138906 > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/9937077e48f1 > > 8156743: ES6 for..of should work for Java Maps and Sets > https://bugs.openjdk.java.net/browse/JDK-8156743 > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/4561f9afd9bd > > 8144113: Implement new tests to cover jjs functionality > https://bugs.openjdk.java.net/browse/JDK-8144113 > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/086c19a36be6 > > 8147591: Revisit Collection.toArray(new T[size]) calls in nashorn and dynalink code > https://bugs.openjdk.java.net/browse/JDK-8147591 > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/0da44ab8c417 > > 8147613: enable jjs tests on Windows > https://bugs.openjdk.java.net/browse/JDK-8147613 > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/25b13597ea73 > > 8156615: Catch parameter can be a BindingPattern in ES6 mode > https://bugs.openjdk.java.net/browse/JDK-8156615 > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/4a68dd740be8 > > 8139255: javac reports "cannot override" messages instead of "cannot hide" messages for static methods > https://bugs.openjdk.java.net/browse/JDK-8139255 > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/fdfaa0e5c8c0 > > 8134304: NPE in initialization of OptimisticTypesPersistence > https://bugs.openjdk.java.net/browse/JDK-8134304 > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/3487086f145a > From jamsheed.c.m at oracle.com Fri Apr 21 03:00:13 2017 From: jamsheed.c.m at oracle.com (Jamsheed C m) Date: Fri, 21 Apr 2017 08:30:13 +0530 Subject: CFV: New JDK 9/10 Committer: Srinivas Dama In-Reply-To: <6E354E60-2931-452B-BADE-381486501B31@oracle.com> References: <6E354E60-2931-452B-BADE-381486501B31@oracle.com> Message-ID: <891eb333-cdf5-2c56-a612-391e2606180d@oracle.com> Vote: Yes Best Regards, Jamsheed From rahul.v.raghavan at oracle.com Fri Apr 21 03:22:15 2017 From: rahul.v.raghavan at oracle.com (Rahul Raghavan) Date: Thu, 20 Apr 2017 20:22:15 -0700 (PDT) Subject: CFV: New JDK 9/10 Committer: Srinivas Dama In-Reply-To: <6E354E60-2931-452B-BADE-381486501B31@oracle.com> References: <6E354E60-2931-452B-BADE-381486501B31@oracle.com> Message-ID: <933edd88-ef04-44fd-b0a6-db76915f48b8@default> Vote: yes -Rahul > -----Original Message----- > From: Jim Laskey (Oracle) > Sent: Friday, April 21, 2017 1:41 AM > To: jdk9-dev > Subject: CFV: New JDK 9/10 Committer: Srinivas Dama > > I hereby nominate Srinivas Dama to JDK 9 and JDK 10 Committer. > > Srini is part of the Langtools team since August 2015 and has made many contributions to JDK 9. > I have included 8 of the the most significant change sets. > > Votes are due by May 5, 2017. > > Only current JDK 9/10 Committers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > ? Jim > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/bylaws#lazy-consensus > > > Contributions > > 8138906: Test test/script/trusted/JDK-8087292.js intermittently fails. > https://bugs.openjdk.java.net/browse/JDK-8138906 > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/9937077e48f1 > > 8156743: ES6 for..of should work for Java Maps and Sets > https://bugs.openjdk.java.net/browse/JDK-8156743 > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/4561f9afd9bd > > 8144113: Implement new tests to cover jjs functionality > https://bugs.openjdk.java.net/browse/JDK-8144113 > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/086c19a36be6 > > 8147591: Revisit Collection.toArray(new T[size]) calls in nashorn and dynalink code > https://bugs.openjdk.java.net/browse/JDK-8147591 > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/0da44ab8c417 > > 8147613: enable jjs tests on Windows > https://bugs.openjdk.java.net/browse/JDK-8147613 > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/25b13597ea73 > > 8156615: Catch parameter can be a BindingPattern in ES6 mode > https://bugs.openjdk.java.net/browse/JDK-8156615 > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/4a68dd740be8 > > 8139255: javac reports "cannot override" messages instead of "cannot hide" messages for static methods > https://bugs.openjdk.java.net/browse/JDK-8139255 > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/fdfaa0e5c8c0 > > 8134304: NPE in initialization of OptimisticTypesPersistence > https://bugs.openjdk.java.net/browse/JDK-8134304 > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/3487086f145a > From vyom.tewari at oracle.com Fri Apr 21 05:23:06 2017 From: vyom.tewari at oracle.com (Vyom Tewari) Date: Fri, 21 Apr 2017 10:53:06 +0530 Subject: CFV: New JDK 9/10 Committer: Srinivas Dama In-Reply-To: <6E354E60-2931-452B-BADE-381486501B31@oracle.com> References: <6E354E60-2931-452B-BADE-381486501B31@oracle.com> Message-ID: <4e8835a7-3383-c08a-1fe8-9ff09ddfc4d7@oracle.com> Vote: yes Vyom On Friday 21 April 2017 01:41 AM, Jim Laskey (Oracle) wrote: > I hereby nominate Srinivas Dama to JDK 9 and JDK 10 Committer. > > Srini is part of the Langtools team since August 2015 and has made many contributions to JDK 9. > I have included 8 of the the most significant change sets. > > Votes are due by May 5, 2017. > > Only current JDK 9/10 Committers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > ? Jim > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/bylaws#lazy-consensus > > > Contributions > > 8138906: Test test/script/trusted/JDK-8087292.js intermittently fails. > https://bugs.openjdk.java.net/browse/JDK-8138906 > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/9937077e48f1 > > 8156743: ES6 for..of should work for Java Maps and Sets > https://bugs.openjdk.java.net/browse/JDK-8156743 > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/4561f9afd9bd > > 8144113: Implement new tests to cover jjs functionality > https://bugs.openjdk.java.net/browse/JDK-8144113 > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/086c19a36be6 > > 8147591: Revisit Collection.toArray(new T[size]) calls in nashorn and dynalink code > https://bugs.openjdk.java.net/browse/JDK-8147591 > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/0da44ab8c417 > > 8147613: enable jjs tests on Windows > https://bugs.openjdk.java.net/browse/JDK-8147613 > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/25b13597ea73 > > 8156615: Catch parameter can be a BindingPattern in ES6 mode > https://bugs.openjdk.java.net/browse/JDK-8156615 > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/4a68dd740be8 > > 8139255: javac reports "cannot override" messages instead of "cannot hide" messages for static methods > https://bugs.openjdk.java.net/browse/JDK-8139255 > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/fdfaa0e5c8c0 > > 8134304: NPE in initialization of OptimisticTypesPersistence > https://bugs.openjdk.java.net/browse/JDK-8134304 > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/3487086f145a > From harsha.wardhana.b at oracle.com Fri Apr 21 05:39:10 2017 From: harsha.wardhana.b at oracle.com (Harsha Wardhana B) Date: Fri, 21 Apr 2017 11:09:10 +0530 Subject: CFV: New JDK 9/10 Committer: Srinivas Dama In-Reply-To: <6E354E60-2931-452B-BADE-381486501B31@oracle.com> References: <6E354E60-2931-452B-BADE-381486501B31@oracle.com> Message-ID: <8f4df80a-1dd5-aa78-9571-491e630745fd@oracle.com> Vote: yes -Harsha On Friday 21 April 2017 01:41 AM, Jim Laskey (Oracle) wrote: > I hereby nominate Srinivas Dama to JDK 9 and JDK 10 Committer. > > Srini is part of the Langtools team since August 2015 and has made many contributions to JDK 9. > I have included 8 of the the most significant change sets. > > Votes are due by May 5, 2017. > > Only current JDK 9/10 Committers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > ? Jim > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/bylaws#lazy-consensus > > > Contributions > > 8138906: Test test/script/trusted/JDK-8087292.js intermittently fails. > https://bugs.openjdk.java.net/browse/JDK-8138906 > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/9937077e48f1 > > 8156743: ES6 for..of should work for Java Maps and Sets > https://bugs.openjdk.java.net/browse/JDK-8156743 > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/4561f9afd9bd > > 8144113: Implement new tests to cover jjs functionality > https://bugs.openjdk.java.net/browse/JDK-8144113 > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/086c19a36be6 > > 8147591: Revisit Collection.toArray(new T[size]) calls in nashorn and dynalink code > https://bugs.openjdk.java.net/browse/JDK-8147591 > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/0da44ab8c417 > > 8147613: enable jjs tests on Windows > https://bugs.openjdk.java.net/browse/JDK-8147613 > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/25b13597ea73 > > 8156615: Catch parameter can be a BindingPattern in ES6 mode > https://bugs.openjdk.java.net/browse/JDK-8156615 > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/4a68dd740be8 > > 8139255: javac reports "cannot override" messages instead of "cannot hide" messages for static methods > https://bugs.openjdk.java.net/browse/JDK-8139255 > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/fdfaa0e5c8c0 > > 8134304: NPE in initialization of OptimisticTypesPersistence > https://bugs.openjdk.java.net/browse/JDK-8134304 > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/3487086f145a > From nishit.jain at oracle.com Fri Apr 21 05:43:58 2017 From: nishit.jain at oracle.com (Nishit Jain) Date: Fri, 21 Apr 2017 11:13:58 +0530 Subject: CFV: New JDK 9/10 Committer: Srinivas Dama In-Reply-To: <6E354E60-2931-452B-BADE-381486501B31@oracle.com> References: <6E354E60-2931-452B-BADE-381486501B31@oracle.com> Message-ID: <5aab5d6d-f612-23ff-2280-e04f51c57d1a@oracle.com> Vote: Yes -Nishit Jain On 21-04-2017 01:41, Jim Laskey (Oracle) wrote: > I hereby nominate Srinivas Dama to JDK 9 and JDK 10 Committer. > > Srini is part of the Langtools team since August 2015 and has made many contributions to JDK 9. > I have included 8 of the the most significant change sets. > > Votes are due by May 5, 2017. > > Only current JDK 9/10 Committers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > ? Jim > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/bylaws#lazy-consensus > > > Contributions > > 8138906: Test test/script/trusted/JDK-8087292.js intermittently fails. > https://bugs.openjdk.java.net/browse/JDK-8138906 > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/9937077e48f1 > > 8156743: ES6 for..of should work for Java Maps and Sets > https://bugs.openjdk.java.net/browse/JDK-8156743 > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/4561f9afd9bd > > 8144113: Implement new tests to cover jjs functionality > https://bugs.openjdk.java.net/browse/JDK-8144113 > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/086c19a36be6 > > 8147591: Revisit Collection.toArray(new T[size]) calls in nashorn and dynalink code > https://bugs.openjdk.java.net/browse/JDK-8147591 > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/0da44ab8c417 > > 8147613: enable jjs tests on Windows > https://bugs.openjdk.java.net/browse/JDK-8147613 > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/25b13597ea73 > > 8156615: Catch parameter can be a BindingPattern in ES6 mode > https://bugs.openjdk.java.net/browse/JDK-8156615 > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/4a68dd740be8 > > 8139255: javac reports "cannot override" messages instead of "cannot hide" messages for static methods > https://bugs.openjdk.java.net/browse/JDK-8139255 > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/fdfaa0e5c8c0 > > 8134304: NPE in initialization of OptimisticTypesPersistence > https://bugs.openjdk.java.net/browse/JDK-8134304 > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/3487086f145a > From tobias.hartmann at oracle.com Fri Apr 21 07:46:24 2017 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Fri, 21 Apr 2017 09:46:24 +0200 Subject: CFV: New JDK 9/10 Committer: Srinivas Dama In-Reply-To: <6E354E60-2931-452B-BADE-381486501B31@oracle.com> References: <6E354E60-2931-452B-BADE-381486501B31@oracle.com> Message-ID: <6a356672-1323-2692-6611-00c951d6b16f@oracle.com> Vote: yes On 20.04.2017 22:11, Jim Laskey (Oracle) wrote: > I hereby nominate Srinivas Dama to JDK 9 and JDK 10 Committer. > > Srini is part of the Langtools team since August 2015 and has made many contributions to JDK 9. > I have included 8 of the the most significant change sets. > > Votes are due by May 5, 2017. > > Only current JDK 9/10 Committers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > ? Jim > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/bylaws#lazy-consensus > > > Contributions > > 8138906: Test test/script/trusted/JDK-8087292.js intermittently fails. > https://bugs.openjdk.java.net/browse/JDK-8138906 > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/9937077e48f1 > > 8156743: ES6 for..of should work for Java Maps and Sets > https://bugs.openjdk.java.net/browse/JDK-8156743 > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/4561f9afd9bd > > 8144113: Implement new tests to cover jjs functionality > https://bugs.openjdk.java.net/browse/JDK-8144113 > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/086c19a36be6 > > 8147591: Revisit Collection.toArray(new T[size]) calls in nashorn and dynalink code > https://bugs.openjdk.java.net/browse/JDK-8147591 > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/0da44ab8c417 > > 8147613: enable jjs tests on Windows > https://bugs.openjdk.java.net/browse/JDK-8147613 > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/25b13597ea73 > > 8156615: Catch parameter can be a BindingPattern in ES6 mode > https://bugs.openjdk.java.net/browse/JDK-8156615 > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/4a68dd740be8 > > 8139255: javac reports "cannot override" messages instead of "cannot hide" messages for static methods > https://bugs.openjdk.java.net/browse/JDK-8139255 > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/fdfaa0e5c8c0 > > 8134304: NPE in initialization of OptimisticTypesPersistence > https://bugs.openjdk.java.net/browse/JDK-8134304 > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/3487086f145a > From zoltan.majo at oracle.com Fri Apr 21 08:20:43 2017 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Fri, 21 Apr 2017 10:20:43 +0200 Subject: CFV: New JDK 9/10 Committer: Srinivas Dama In-Reply-To: <6E354E60-2931-452B-BADE-381486501B31@oracle.com> References: <6E354E60-2931-452B-BADE-381486501B31@oracle.com> Message-ID: Vote: yes. Best regards, Zoltan On 04/20/2017 10:11 PM, Jim Laskey (Oracle) wrote: > I hereby nominate Srinivas Dama to JDK 9 and JDK 10 Committer. > > Srini is part of the Langtools team since August 2015 and has made many contributions to JDK 9. > I have included 8 of the the most significant change sets. > > Votes are due by May 5, 2017. > > Only current JDK 9/10 Committers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > ? Jim > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/bylaws#lazy-consensus > > > Contributions > > 8138906: Test test/script/trusted/JDK-8087292.js intermittently fails. > https://bugs.openjdk.java.net/browse/JDK-8138906 > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/9937077e48f1 > > 8156743: ES6 for..of should work for Java Maps and Sets > https://bugs.openjdk.java.net/browse/JDK-8156743 > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/4561f9afd9bd > > 8144113: Implement new tests to cover jjs functionality > https://bugs.openjdk.java.net/browse/JDK-8144113 > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/086c19a36be6 > > 8147591: Revisit Collection.toArray(new T[size]) calls in nashorn and dynalink code > https://bugs.openjdk.java.net/browse/JDK-8147591 > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/0da44ab8c417 > > 8147613: enable jjs tests on Windows > https://bugs.openjdk.java.net/browse/JDK-8147613 > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/25b13597ea73 > > 8156615: Catch parameter can be a BindingPattern in ES6 mode > https://bugs.openjdk.java.net/browse/JDK-8156615 > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/4a68dd740be8 > > 8139255: javac reports "cannot override" messages instead of "cannot hide" messages for static methods > https://bugs.openjdk.java.net/browse/JDK-8139255 > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/fdfaa0e5c8c0 > > 8134304: NPE in initialization of OptimisticTypesPersistence > https://bugs.openjdk.java.net/browse/JDK-8134304 > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/3487086f145a > From jini.george at oracle.com Fri Apr 21 10:38:42 2017 From: jini.george at oracle.com (Jini George) Date: Fri, 21 Apr 2017 16:08:42 +0530 Subject: CFV: New JDK 9/10 Committer: Srinivas Dama In-Reply-To: <6E354E60-2931-452B-BADE-381486501B31@oracle.com> References: <6E354E60-2931-452B-BADE-381486501B31@oracle.com> Message-ID: <590c82d3-4cf1-3d4a-2ee8-2bfbfb1a2c0b@oracle.com> Vote: yes - Jini On 4/21/2017 1:41 AM, Jim Laskey (Oracle) wrote: > I hereby nominate Srinivas Dama to JDK 9 and JDK 10 Committer. > > Srini is part of the Langtools team since August 2015 and has made many contributions to JDK 9. > I have included 8 of the the most significant change sets. > > Votes are due by May 5, 2017. > > Only current JDK 9/10 Committers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > ? Jim > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/bylaws#lazy-consensus > > > Contributions > > 8138906: Test test/script/trusted/JDK-8087292.js intermittently fails. > https://bugs.openjdk.java.net/browse/JDK-8138906 > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/9937077e48f1 > > 8156743: ES6 for..of should work for Java Maps and Sets > https://bugs.openjdk.java.net/browse/JDK-8156743 > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/4561f9afd9bd > > 8144113: Implement new tests to cover jjs functionality > https://bugs.openjdk.java.net/browse/JDK-8144113 > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/086c19a36be6 > > 8147591: Revisit Collection.toArray(new T[size]) calls in nashorn and dynalink code > https://bugs.openjdk.java.net/browse/JDK-8147591 > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/0da44ab8c417 > > 8147613: enable jjs tests on Windows > https://bugs.openjdk.java.net/browse/JDK-8147613 > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/25b13597ea73 > > 8156615: Catch parameter can be a BindingPattern in ES6 mode > https://bugs.openjdk.java.net/browse/JDK-8156615 > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/4a68dd740be8 > > 8139255: javac reports "cannot override" messages instead of "cannot hide" messages for static methods > https://bugs.openjdk.java.net/browse/JDK-8139255 > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/fdfaa0e5c8c0 > > 8134304: NPE in initialization of OptimisticTypesPersistence > https://bugs.openjdk.java.net/browse/JDK-8134304 > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/3487086f145a > From serguei.spitsyn at oracle.com Fri Apr 21 16:35:51 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 21 Apr 2017 09:35:51 -0700 Subject: CFV: New JDK 9/10 Committer: Srinivas Dama In-Reply-To: <6E354E60-2931-452B-BADE-381486501B31@oracle.com> References: <6E354E60-2931-452B-BADE-381486501B31@oracle.com> Message-ID: <9bdcf4c0-28fa-0318-0b5d-1da8797cf631@oracle.com> Vote: yes From lana.steuck at oracle.com Wed Apr 26 21:59:19 2017 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 26 Apr 2017 21:59:19 GMT Subject: jdk9-b167: dev Message-ID: <201704262159.v3QLxJ6l022393@scaaa563.us.oracle.com> http://hg.openjdk.java.net/jdk9/jdk9/rev/35017c286513 http://hg.openjdk.java.net/jdk9/jdk9/nashorn/rev/e118c818dbf8 http://hg.openjdk.java.net/jdk9/jdk9/langtools/rev/f260f1a2acf6 http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/7828aedcb525 http://hg.openjdk.java.net/jdk9/jdk9/jaxws/rev/1c610f1b4097 http://hg.openjdk.java.net/jdk9/jdk9/jaxp/rev/646567dcfa64 http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/1ca7ed1b17b5 http://hg.openjdk.java.net/jdk9/jdk9/corba/rev/43de67f51801 --- All the fixes will be tested during promotion (no PIT testing at this point): List of all fixes: =================== JDK-6479801 client-libs java.awt.font.LineBreakMeasurer code incorrect JDK-8076249 client-libs NPE in AccessBridge while editing JList model JDK-8081454 client-libs [TESTBUG]Some java/awt/Mixing tests fail in OEL 7 only JDK-8081478 client-libs [TESTBUG] Test javax/swing/plaf/synth/SynthButtonUI/6276188/bug6276188 JDK-8142534 client-libs [TEST_BUG] Test javax/swing/JMenu/8072900/WrongSelectionOnMouseOver.ja JDK-8142540 client-libs [TEST_BUG] Test sun/awt/dnd/8024061/bug8024061.java fails on ubuntu JDK-8173801 client-libs Remove non-client demos and samples. JDK-8177919 client-libs java.awt.Desktop.setDefaultMenuBar???() should be specified to throw I JDK-8178457 client-libs Remove link to 2D guide from Line2D javadoc JDK-8178685 client-libs Update links to guide in javax sound package javadoc JDK-8178708 client-libs Regtest failure: java/awt/Color/LoadProfileWithSM.java JDK-8160954 core-libs (spec) Runtime.Version regex and $PRE/$OPT issues JDK-8167981 core-libs Optional: add notes explaining intended use JDK-8174171 core-libs Move spliterator testing of BitSet into big memory tests BitSetStreamT JDK-8177738 core-libs Runtime.Version must be a value-based class JDK-8177789 core-libs fix collections framework links to point to java.util package doc JDK-8178315 core-libs nashorn ant build failure with @moduleGraph javadoc tag JDK-8178726 core-libs Can't load classes from classpath if it is a UNC share JDK-8178823 core-libs Unable to initialize HijrahCalendar: Hijrah-umalqura when running with JDK-8178832 core-libs (ref) jdk.lang.ref.disableClearBeforeEnqueue property is ignored JDK-8178915 core-libs Minor update to the PooledConnection javadoc JDK-8178916 core-libs Update annotation processing API for terminology changes in modules JDK-8178954 core-libs jjs uses wrong javadoc base URL JDK-8178047 hotspot Aliasing problem with raw memory accesses JDK-8178723 hotspot Workaround for failure of CRC32C intrinsic on x86 machines without CLM JDK-8179013 hotspot Deprecate the Concurrent Mark Sweep (CMS) Garbage Collector JDK-8172312 infrastructure Update docs target and image for new combined docs JDK-8175036 infrastructure All API docs should be built for HTML 5 JDK-8176785 infrastructure Add build support to generate PNG file from .dot file JDK-8178037 infrastructure Move information from jdi-overview.html into jdk.jdi module-info.java JDK-8178038 infrastructure Copy jdwp-protocol.html to proper location JDK-8178039 infrastructure Copy jvmti.html to proper location JDK-8178316 infrastructure Add JVM-MANAGEMENT-MIB.mib to jdk/src/java.management/share/specs/ JDK-8178438 infrastructure Info-privileged.plist claims launchers to be "OpenJDK 7 Command" JDK-8178965 infrastructure Second part of JDK-8176785 JDK-8179022 infrastructure Add serialization spec as markdown JDK-8179035 infrastructure Include tool modules in unified docs JDK-8178145 install [windows] Incorrect location of src.zip (should be lib/src.zip, is