From staffan.larsen at oracle.com Wed Jun 1 06:15:00 2016 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 1 Jun 2016 08:15:00 +0200 Subject: CFV: New JDK 9 Reviewer: Michael Haupt In-Reply-To: References: Message-ID: Vote: yes > On 31 maj 2016, at 17:52, Jim Laskey (Oracle) wrote: > > I hereby nominate Michael Haupt to JDK 9 Reviewer. > > Michael is a member to the Nashorn team; his focus is on dynamic language implementations. He also collaborates with the Valhalla project for value types. Prior to joining Nashorn, Michael worked briefly in the HotSpot compiler team. He has been an Oracle employee since 2011, which is when he joined the Virtual Machine Research Group at Oracle Labs, where he has worked on the Maxine meta-circular JVM and on dynamic language implementations. He used to be the tech lead of the FastR project, a high-performance Java-based implementation of the R programming language. Michael has also contributed to the Invokedynamic infrastructure in the past. > > Votes are due by June 15, 2016 > > Only current JDK9 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]. > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > > Michael?s contributions: > > === JDK 9 > > *** JSR 292 > > changeset: 14592:80f1fb052dee > user: mhaupt > date: Tue May 24 09:13:47 2016 +0200 > summary: 8157590: MethodHandles.arrayLength() lacks @since tag, implementation throws wrong exception > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/80f1fb052dee > > changeset: 14495:fd39cefc5c8f > user: mhaupt > date: Wed May 18 10:42:29 2016 +0200 > summary: 8156915: introduce MethodHandle factory for array length > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/fd39cefc5c8f > > changeset: 14301:c0e1a94f27f5 > user: mhaupt > date: Wed Apr 27 20:18:49 2016 +0200 > summary: 8155106: MHs.Lookup.findConstructor returns handles for array classes > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/c0e1a94f27f5 > > changeset: 14298:5a48729a7eb6 > user: mhaupt > date: Wed Apr 27 15:01:21 2016 +0200 > summary: 8155214: java/lang/invoke/PermuteArgsTest.java fails due to exhausted code cache > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/5a48729a7eb6 > > changeset: 14276:e8217d94b72e > user: mhaupt > date: Fri Apr 22 15:05:54 2016 +0200 > summary: 8154754: MethodHandles.countedLoop errors in deriving loop arguments, result type, and local state > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/e8217d94b72e > > changeset: 14275:14065c26ea1a > user: mhaupt > date: Fri Apr 22 15:05:26 2016 +0200 > summary: 8154751: MethodHandles.countedLoop does not accept empty bodies > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/14065c26ea1a > > changeset: 14274:beac9a439d0f > user: mhaupt > date: Fri Apr 22 13:36:22 2016 +0200 > summary: 8152667: MHs.iteratedLoop(...) throws unexpected WMTE, disallows Iterator subclasses, generates inconsistent loop result type > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/beac9a439d0f > > changeset: 14210:214c1ee32e00 > user: mhaupt > date: Tue Apr 19 14:39:35 2016 +0200 > summary: 8150956: j.l.i.MethodHandles.whileLoop(...) and .iteratedLoop(...) throw unexpected exceptions in the case of 'init' return type is void > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/214c1ee32e00 > > changeset: 14169:210cce63ef9c > user: mhaupt > date: Thu Apr 14 15:18:42 2016 +0200 > summary: 8150824: Exceptions when omitting trailing arguments in cleanup > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/210cce63ef9c > > changeset: 14152:fe806038ae74 > user: mhaupt > date: Wed Apr 13 09:20:22 2016 +0200 > summary: 8153637: MethodHandles.countedLoop/3 initialises loop counter to 1 instead of 0 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/fe806038ae74 > > changeset: 13903:d14f551f4d52 > user: mhaupt > date: Mon Mar 14 08:10:44 2016 +0100 > summary: 8151778: TestLookup.java fails after push of JDK-8150782 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/d14f551f4d52 > > changeset: 13902:25e8c082d7ef > user: mhaupt > date: Sun Mar 13 20:26:29 2016 +0100 > summary: 8150782: findClass / accessClass throw unexpected exceptions > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/25e8c082d7ef > > changeset: 13805:e941d983c8e4 > user: mhaupt > date: Thu Mar 03 14:29:00 2016 +0100 > summary: 8150957: j.l.i.MethodHandles.whileLoop(...) fails with IOOBE in the case init is null, step and pred have parameters > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/e941d983c8e4 > > changeset: 13799:c48cb760984f > user: mhaupt > date: Wed Mar 02 20:36:00 2016 +0100 > summary: 8150832: split T8139885 into several tests by functionality > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/c48cb760984f > > changeset: 13798:a24ddbbc4beb > user: mhaupt > date: Wed Mar 02 20:16:11 2016 +0100 > summary: 8150635: j.l.i.MethodHandles.loop(...) throws IndexOutOfBoundsException > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/a24ddbbc4beb > > changeset: 13796:8c2194ad4ca3 > user: mhaupt > date: Wed Mar 02 14:15:15 2016 +0100 > summary: 8150953: j.l.i.MethodHandles: example section in whileLoop(...) provides example for doWhileLoop > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/8c2194ad4ca3 > > changeset: 13790:42794e648cfe > user: mhaupt > date: Mon Feb 29 14:16:20 2016 +0100 > summary: 8150825: MethodHandles.tryFinally throws IndexOutOfBoundsException for non-conforming parameter lists > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/42794e648cfe > > changeset: 13767:9d536355b828 > user: mhaupt > date: Tue Feb 23 09:49:04 2016 +0100 > summary: 8143410: augment pseudo-code descriptions in MethodHandles API > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/9d536355b828 > > changeset: 13765:4d1292a702b8 > user: mhaupt > date: Tue Feb 23 07:17:54 2016 +0100 > summary: 8150360: augment/correct MethodHandle API documentation > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/4d1292a702b8 > > changeset: 13474:1de1a321ea87 > user: mhaupt > date: Wed Dec 09 11:02:54 2015 +0000 > summary: 8081512: Remove sun.invoke.anon classes, or move / co-locate them with tests > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/1de1a321ea87 > > changeset: 13458:f5d02fbd8095 > user: mhaupt > date: Thu Jan 14 13:53:13 2016 +0100 > summary: 8147078: MethodHandles.catchException does not enforce Throwable subtype > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/f5d02fbd8095 > > changeset: 13443:5be075daee3a > user: mhaupt > date: Mon Jan 11 17:19:16 2016 +0100 > summary: 8146786: [TESTBUG] straighten out testability for several issues > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/5be075daee3a > > changeset: 13255:4d010a9bd0d9 > user: mhaupt > date: Thu Dec 03 15:36:20 2015 +0100 > summary: 8143343: add JEP 274 Javadoc tests to JavaDocExamplesTest > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/4d010a9bd0d9 > > changeset: 13254:d41609429f2e > user: mhaupt > date: Thu Dec 03 15:34:39 2015 +0100 > summary: 8072844: Use more efficient LambdaForm type representation > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/d41609429f2e > > changeset: 13176:33c6cca30255 > user: mhaupt > date: Wed Dec 02 10:59:03 2015 +0100 > summary: 8076596: BytecodeDescriptor.parseMethod doesn't work during bootstrapping > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/33c6cca30255 > > changeset: 13124:ff8ce38663d9 > user: mhaupt > date: Wed Nov 25 09:23:07 2015 +0100 > summary: 8143798: jck failures: api/java_lang/invoke/MethodHandle/index_MethodsTests[asSpreaderWMTE]: java.lang.VerifyError: Bad type on operand stack > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/ff8ce38663d9 > > changeset: 13109:957e4e29ff28 > user: mhaupt > date: Fri Nov 20 15:34:12 2015 +0100 > summary: 8139885: implement JEP 274: enhanced method handles > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/957e4e29ff28 > > changeset: 12962:0f6c981f1cbf > user: mhaupt > date: Tue Oct 27 09:09:37 2015 +0100 > summary: 8136967: revert all changes applied to obtain information about 8131129 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/0f6c981f1cbf > > changeset: 12789:69f78bcd65f8 > user: mhaupt > date: Wed Sep 23 08:43:51 2015 +0200 > summary: 8136931: more fine-grained condition checking for BMH species creation > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/69f78bcd65f8 > > changeset: 12415:2919a03653a8 > user: mhaupt > date: Fri Jul 17 08:10:41 2015 +0200 > summary: 8062543: Replace uses of MethodHandleImpl.castReference with Class.cast > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/2919a03653a8 > > changeset: 8369:465e5b2bb615 > user: acorn > date: Fri May 08 14:00:24 2015 -0400 > summary: 8030680: 292 cleanup from default method code assessment > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/465e5b2bb615 > > changeset: 11850:e0ac3e9decb0 > user: mhaupt > date: Tue Apr 14 18:26:01 2015 +0300 > summary: 8033465: JSR292: InvokerBytecodeGenerator: convert a check for REF_invokeVirtual on an interface into an assert > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/e0ac3e9decb0 > > changeset: 5688:050116960e99 > user: twisti > date: Tue Jul 24 10:47:44 2012 -0700 > summary: 7023639: JSR 292 method handle invocation needs a fast path for compiled code > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/050116960e99 > > *** nashorn > > changeset: 1699:141d0cf2c12e > user: mhaupt > date: Fri May 20 16:02:36 2016 +0200 > summary: 8157444: exclude jjs shebang handling test from runs > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/141d0cf2c12e > > changeset: 1692:7099f590cdec > user: mhaupt > date: Wed May 18 17:37:34 2016 +0200 > summary: 8157250: BeanLinker assumes fixed array type linkage > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/7099f590cdec > > changeset: 1690:c187d75b77aa > user: mhaupt > date: Wed May 18 12:07:54 2016 +0200 > summary: 8157225: adopt method handle for array length getter in BeanLinker > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/c187d75b77aa > > changeset: 1663:ba21793a0e48 > user: mhaupt > date: Mon Apr 11 18:10:30 2016 +0200 > summary: 8137149: add tests for issues closed during Nashorn issue cleanup > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/ba21793a0e48 > > changeset: 1637:11811302fe75 > user: mhaupt > date: Wed Mar 09 15:15:29 2016 +0100 > summary: 8151518: relax test requirements to reduce dependency on directory contents > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/11811302fe75 > > changeset: 1636:f27bb66ac9d3 > user: mhaupt > date: Wed Mar 09 13:24:01 2016 +0100 > summary: 8151291: $EXEC yields "unknown command" on Cygwin > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/f27bb66ac9d3 > > changeset: 1633:58409eff7e3e > user: mhaupt > date: Mon Feb 29 09:49:46 2016 +0100 > summary: 8150814: correct package declaration in Nashorn test > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/58409eff7e3e > > changeset: 1626:221378857767 > user: mhaupt > date: Tue Feb 16 15:34:27 2016 +0100 > summary: 8148140: arguments are handled differently in apply for JS functions and AbstractJSObjects > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/221378857767 > > changeset: 1624:cfb316745693 > user: mhaupt > date: Fri Feb 12 17:00:54 2016 +0100 > summary: 8149744: fix testng.jar delivery in Nashorn build.xml > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/cfb316745693 > > changeset: 1619:7ac82655d829 > user: mhaupt > date: Tue Feb 09 14:14:06 2016 +0100 > summary: 8149462: revert changes for 8149186 > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/7ac82655d829 > > changeset: 1618:4e9749cc32f1 > user: mhaupt > date: Mon Feb 08 17:43:02 2016 +0100 > summary: 8149334: JSON.parse(JSON.stringify([])).push(10) creates an array containing two elements > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/4e9749cc32f1 > > changeset: 1611:0da44ab8c417 > user: mhaupt > date: Thu Jan 28 11:20:44 2016 +0100 > summary: 8147591: Revisit Collection.toArray(new T[size]) calls in nashorn and dynalink code > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/0da44ab8c417 > > changeset: 1607:b3c945675e8c > user: mhaupt > date: Fri Jan 22 11:12:26 2016 +0100 > summary: 8134933: re-enable LambdaFormEditor assertions in Nashorn testing > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/b3c945675e8c > > changeset: 1602:086c19a36be6 > user: mhaupt > date: Wed Jan 20 09:56:29 2016 +0100 > summary: 8144113: enable jjs testing > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/086c19a36be6 > > changeset: 1601:981b353f2f75 > user: mhaupt > date: Mon Jan 18 11:31:43 2016 +0100 > summary: 8145305: fix Nashorn shebang handling on Cygwin > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/981b353f2f75 > > changeset: 1594:0f21903deef8 > user: mhaupt > date: Thu Jan 14 10:55:26 2016 +0100 > summary: 8036977: Make process singleton options to be context wide > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/0f21903deef8 > > changeset: 1568:5fed6b47d01a > user: mhaupt > date: Mon Dec 14 14:02:59 2015 +0100 > summary: 8144221: fix Nashorn shebang argument handling on Mac/Linux > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/5fed6b47d01a > > changeset: 1525:d98fe27f6ba9 > user: mhaupt > date: Thu Nov 26 12:01:41 2015 +0100 > summary: 8143642: Nashorn shebang argument handling is broken > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/d98fe27f6ba9 > > changeset: 1520:d2eb81e4ddc8 > user: mhaupt > date: Thu Nov 19 11:28:34 2015 +0100 > summary: 8143297: Nashorn compilation time reported in nanoseconds > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/d2eb81e4ddc8 > > changeset: 1488:1ceda730b9a3 > user: mhaupt > date: Thu Oct 29 11:37:48 2015 +0100 > summary: 8140759: add ES6 template literal test > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/1ceda730b9a3 > > changeset: 1487:6d9a3ef84ebf > user: mhaupt > date: Wed Oct 28 10:54:05 2015 +0100 > summary: 8134941: Implement ES6 template literal support > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/6d9a3ef84ebf > > changeset: 1462:6c6df82265f0 > user: mhaupt > date: Mon Oct 12 13:36:41 2015 +0200 > summary: 8139266: add JSAdapter example with fallthrough > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/6c6df82265f0 > > changeset: 1456:446625d6e8cc > user: mhaupt > date: Wed Oct 07 15:02:15 2015 +0200 > summary: 8139047: add test for JSAdapter __getIds__ > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/446625d6e8cc > > changeset: 1455:11b48db399bf > user: mhaupt > date: Wed Oct 07 14:00:45 2015 +0200 > summary: 8139038: cleanup and documentation around JSAdapter > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/11b48db399bf > > changeset: 1392:d61744c0d1d2 > user: mhaupt > date: Wed Aug 26 13:11:35 2015 +0200 > summary: 8134484: disallow backquotes as heredoc end marker delimiters > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/d61744c0d1d2 > > changeset: 1391:5efd65e18b71 > user: mhaupt > date: Wed Aug 26 09:59:29 2015 +0200 > summary: 8073613: Here documents: how to avoid string interpolation? > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/5efd65e18b71 > > changeset: 1379:6060f7652a28 > user: mhaupt > date: Tue Aug 18 09:13:46 2015 -0700 > summary: 8077168: CodeStoreAndPathTest.java fails in jtreg mode on Mac > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/6060f7652a28 > > changeset: 1363:9fddd7695ded > user: mhaupt > date: Mon Jul 27 09:42:09 2015 +0200 > summary: 8132305: fix incorrect title assignment in Nashorn JavaFX samples > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/9fddd7695ded > > changeset: 1360:b27730a502c3 > user: mhaupt > date: Wed Jul 22 09:28:28 2015 +0200 > summary: 8131142: late-bind check for testng.jar presence in Nashorn test execution > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/b27730a502c3 > > changeset: 1352:3fe85fdf1651 > user: mhaupt > date: Fri Jul 10 08:42:35 2015 +0200 > summary: 8130862: let hg ignore TestNG ZIP file in Nashorn test library directory > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/3fe85fdf1651 > > changeset: 1342:becb3bb6a422 > user: mhaupt > date: Thu Jul 02 11:20:47 2015 +0200 > summary: 8130307: improve Nashorn Javadoc target > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/becb3bb6a422 > > changeset: 1341:6eca661ddf79 > user: mhaupt > date: Thu Jul 02 11:09:20 2015 +0200 > summary: 8130306: enable running Nashorn test on Windows > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/6eca661ddf79 > > changeset: 1339:d95394322204 > user: mhaupt > date: Wed Jul 01 16:26:25 2015 +0200 > summary: 8130127: streamline input parameter of Nashorn scripting $EXEC function > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/d95394322204 > > changeset: 1313:a24cb0bf79bc > user: mhaupt > date: Tue Jun 09 09:27:02 2015 +0200 > summary: 8080490: add $EXECV command to Nashorn scripting mode > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/a24cb0bf79bc > > changeset: 1311:d1689c1df3aa > user: mhaupt > date: Mon Jun 08 10:28:04 2015 +0200 > summary: 8085885: address Javadoc warnings in Nashorn source code > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/d1689c1df3aa > > changeset: 1307:0eeaadd17fff > user: mhaupt > date: Fri Jun 05 12:38:53 2015 +0200 > summary: 8080087: Nashorn $ENV.PWD is originally undefined > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/0eeaadd17fff > > changeset: 1301:10553f87f3e7 > user: mhaupt > date: Tue Jun 02 17:08:13 2015 +0200 > summary: 8081696: reduce dependency of Nashorn tests on external components > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/10553f87f3e7 > > changeset: 1300:14ec7d7af490 > user: mhaupt > date: Tue Jun 02 14:35:03 2015 +0200 > summary: 8080275: transparently download testng.jar for Nashorn testing > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/14ec7d7af490 > > changeset: 1299:078107e0651f > user: mhaupt > date: Tue Jun 02 14:34:37 2015 +0200 > summary: 8081668: fix Nashorn ant externals command > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/078107e0651f > > changeset: 1298:0d4841f2c800 > user: mhaupt > date: Tue Jun 02 10:40:19 2015 +0200 > summary: 8081604: rename ScriptingFunctions.tokenizeCommandLine > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/0d4841f2c800 > > changeset: 1297:776551a5b3a2 > user: mhaupt > date: Tue Jun 02 10:40:10 2015 +0200 > summary: 8081603: erroneous dot file generated from Nashorn --print-code > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/776551a5b3a2 > > changeset: 1279:71d7a37e6dfb > user: mhaupt > date: Fri May 15 16:36:25 2015 +0200 > summary: 8049300: jjs scripting: need way to quote $EXEC command arguments to protect spaces > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/71d7a37e6dfb > > changeset: 1277:4dc7eb763139 > user: mhaupt > date: Fri May 15 10:21:48 2015 +0200 > summary: 8080471: fix usage of replace and file separator in Nashorn tests > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/4dc7eb763139 > > changeset: 1271:063ed2f959e4 > user: mhaupt > date: Wed May 13 15:41:46 2015 +0200 > summary: 8080286: use path separator setting consistently in Nashorn project properties > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/063ed2f959e4 > > *** hotspot > > changeset: 8796:6ad64d95053d > user: mhaupt > date: Wed Mar 18 16:16:30 2015 +0100 > summary: 8004073: Implement C2 Ideal node specific dump() method > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/6ad64d95053d > > changeset: 8690:0fb7705845de > user: mhaupt > date: Tue Mar 31 21:46:44 2015 +0200 > summary: 6900757: minor bug fixes to LogCompilation tool > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/0fb7705845de > > changeset: 8345:d3413c4fee16 > parent: 8343:67729f5f33c4 > user: mhaupt > date: Tue May 05 13:06:10 2015 +0200 > summary: 8075492: adopt recent IGV > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/d3413c4fee16 > > changeset: 8208:6c4ca18a0666 > user: mhaupt > date: Tue Apr 14 18:16:10 2015 +0300 > summary: 8076461: JSR292: remove unused native and constants > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/6c4ca18a0666 > > > From volker.simonis at gmail.com Wed Jun 1 07:05:09 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 1 Jun 2016 09:05:09 +0200 Subject: CFV: New JDK 9 Reviewer: Michael Haupt In-Reply-To: References: Message-ID: Vote: yes On Tue, May 31, 2016 at 5:52 PM, Jim Laskey wrote: > I hereby nominate Michael Haupt to JDK 9 Reviewer. > > Michael is a member to the Nashorn team; his focus is on dynamic language implementations. He also collaborates with the Valhalla project for value types. Prior to joining Nashorn, Michael worked briefly in the HotSpot compiler team. He has been an Oracle employee since 2011, which is when he joined the Virtual Machine Research Group at Oracle Labs, where he has worked on the Maxine meta-circular JVM and on dynamic language implementations. He used to be the tech lead of the FastR project, a high-performance Java-based implementation of the R programming language. Michael has also contributed to the Invokedynamic infrastructure in the past. > > Votes are due by June 15, 2016 > > Only current JDK9 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]. > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > > Michael?s contributions: > > === JDK 9 > > *** JSR 292 > > changeset: 14592:80f1fb052dee > user: mhaupt > date: Tue May 24 09:13:47 2016 +0200 > summary: 8157590: MethodHandles.arrayLength() lacks @since tag, implementation throws wrong exception > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/80f1fb052dee > > changeset: 14495:fd39cefc5c8f > user: mhaupt > date: Wed May 18 10:42:29 2016 +0200 > summary: 8156915: introduce MethodHandle factory for array length > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/fd39cefc5c8f > > changeset: 14301:c0e1a94f27f5 > user: mhaupt > date: Wed Apr 27 20:18:49 2016 +0200 > summary: 8155106: MHs.Lookup.findConstructor returns handles for array classes > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/c0e1a94f27f5 > > changeset: 14298:5a48729a7eb6 > user: mhaupt > date: Wed Apr 27 15:01:21 2016 +0200 > summary: 8155214: java/lang/invoke/PermuteArgsTest.java fails due to exhausted code cache > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/5a48729a7eb6 > > changeset: 14276:e8217d94b72e > user: mhaupt > date: Fri Apr 22 15:05:54 2016 +0200 > summary: 8154754: MethodHandles.countedLoop errors in deriving loop arguments, result type, and local state > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/e8217d94b72e > > changeset: 14275:14065c26ea1a > user: mhaupt > date: Fri Apr 22 15:05:26 2016 +0200 > summary: 8154751: MethodHandles.countedLoop does not accept empty bodies > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/14065c26ea1a > > changeset: 14274:beac9a439d0f > user: mhaupt > date: Fri Apr 22 13:36:22 2016 +0200 > summary: 8152667: MHs.iteratedLoop(...) throws unexpected WMTE, disallows Iterator subclasses, generates inconsistent loop result type > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/beac9a439d0f > > changeset: 14210:214c1ee32e00 > user: mhaupt > date: Tue Apr 19 14:39:35 2016 +0200 > summary: 8150956: j.l.i.MethodHandles.whileLoop(...) and .iteratedLoop(...) throw unexpected exceptions in the case of 'init' return type is void > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/214c1ee32e00 > > changeset: 14169:210cce63ef9c > user: mhaupt > date: Thu Apr 14 15:18:42 2016 +0200 > summary: 8150824: Exceptions when omitting trailing arguments in cleanup > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/210cce63ef9c > > changeset: 14152:fe806038ae74 > user: mhaupt > date: Wed Apr 13 09:20:22 2016 +0200 > summary: 8153637: MethodHandles.countedLoop/3 initialises loop counter to 1 instead of 0 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/fe806038ae74 > > changeset: 13903:d14f551f4d52 > user: mhaupt > date: Mon Mar 14 08:10:44 2016 +0100 > summary: 8151778: TestLookup.java fails after push of JDK-8150782 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/d14f551f4d52 > > changeset: 13902:25e8c082d7ef > user: mhaupt > date: Sun Mar 13 20:26:29 2016 +0100 > summary: 8150782: findClass / accessClass throw unexpected exceptions > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/25e8c082d7ef > > changeset: 13805:e941d983c8e4 > user: mhaupt > date: Thu Mar 03 14:29:00 2016 +0100 > summary: 8150957: j.l.i.MethodHandles.whileLoop(...) fails with IOOBE in the case init is null, step and pred have parameters > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/e941d983c8e4 > > changeset: 13799:c48cb760984f > user: mhaupt > date: Wed Mar 02 20:36:00 2016 +0100 > summary: 8150832: split T8139885 into several tests by functionality > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/c48cb760984f > > changeset: 13798:a24ddbbc4beb > user: mhaupt > date: Wed Mar 02 20:16:11 2016 +0100 > summary: 8150635: j.l.i.MethodHandles.loop(...) throws IndexOutOfBoundsException > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/a24ddbbc4beb > > changeset: 13796:8c2194ad4ca3 > user: mhaupt > date: Wed Mar 02 14:15:15 2016 +0100 > summary: 8150953: j.l.i.MethodHandles: example section in whileLoop(...) provides example for doWhileLoop > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/8c2194ad4ca3 > > changeset: 13790:42794e648cfe > user: mhaupt > date: Mon Feb 29 14:16:20 2016 +0100 > summary: 8150825: MethodHandles.tryFinally throws IndexOutOfBoundsException for non-conforming parameter lists > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/42794e648cfe > > changeset: 13767:9d536355b828 > user: mhaupt > date: Tue Feb 23 09:49:04 2016 +0100 > summary: 8143410: augment pseudo-code descriptions in MethodHandles API > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/9d536355b828 > > changeset: 13765:4d1292a702b8 > user: mhaupt > date: Tue Feb 23 07:17:54 2016 +0100 > summary: 8150360: augment/correct MethodHandle API documentation > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/4d1292a702b8 > > changeset: 13474:1de1a321ea87 > user: mhaupt > date: Wed Dec 09 11:02:54 2015 +0000 > summary: 8081512: Remove sun.invoke.anon classes, or move / co-locate them with tests > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/1de1a321ea87 > > changeset: 13458:f5d02fbd8095 > user: mhaupt > date: Thu Jan 14 13:53:13 2016 +0100 > summary: 8147078: MethodHandles.catchException does not enforce Throwable subtype > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/f5d02fbd8095 > > changeset: 13443:5be075daee3a > user: mhaupt > date: Mon Jan 11 17:19:16 2016 +0100 > summary: 8146786: [TESTBUG] straighten out testability for several issues > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/5be075daee3a > > changeset: 13255:4d010a9bd0d9 > user: mhaupt > date: Thu Dec 03 15:36:20 2015 +0100 > summary: 8143343: add JEP 274 Javadoc tests to JavaDocExamplesTest > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/4d010a9bd0d9 > > changeset: 13254:d41609429f2e > user: mhaupt > date: Thu Dec 03 15:34:39 2015 +0100 > summary: 8072844: Use more efficient LambdaForm type representation > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/d41609429f2e > > changeset: 13176:33c6cca30255 > user: mhaupt > date: Wed Dec 02 10:59:03 2015 +0100 > summary: 8076596: BytecodeDescriptor.parseMethod doesn't work during bootstrapping > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/33c6cca30255 > > changeset: 13124:ff8ce38663d9 > user: mhaupt > date: Wed Nov 25 09:23:07 2015 +0100 > summary: 8143798: jck failures: api/java_lang/invoke/MethodHandle/index_MethodsTests[asSpreaderWMTE]: java.lang.VerifyError: Bad type on operand stack > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/ff8ce38663d9 > > changeset: 13109:957e4e29ff28 > user: mhaupt > date: Fri Nov 20 15:34:12 2015 +0100 > summary: 8139885: implement JEP 274: enhanced method handles > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/957e4e29ff28 > > changeset: 12962:0f6c981f1cbf > user: mhaupt > date: Tue Oct 27 09:09:37 2015 +0100 > summary: 8136967: revert all changes applied to obtain information about 8131129 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/0f6c981f1cbf > > changeset: 12789:69f78bcd65f8 > user: mhaupt > date: Wed Sep 23 08:43:51 2015 +0200 > summary: 8136931: more fine-grained condition checking for BMH species creation > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/69f78bcd65f8 > > changeset: 12415:2919a03653a8 > user: mhaupt > date: Fri Jul 17 08:10:41 2015 +0200 > summary: 8062543: Replace uses of MethodHandleImpl.castReference with Class.cast > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/2919a03653a8 > > changeset: 8369:465e5b2bb615 > user: acorn > date: Fri May 08 14:00:24 2015 -0400 > summary: 8030680: 292 cleanup from default method code assessment > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/465e5b2bb615 > > changeset: 11850:e0ac3e9decb0 > user: mhaupt > date: Tue Apr 14 18:26:01 2015 +0300 > summary: 8033465: JSR292: InvokerBytecodeGenerator: convert a check for REF_invokeVirtual on an interface into an assert > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/e0ac3e9decb0 > > changeset: 5688:050116960e99 > user: twisti > date: Tue Jul 24 10:47:44 2012 -0700 > summary: 7023639: JSR 292 method handle invocation needs a fast path for compiled code > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/050116960e99 > > *** nashorn > > changeset: 1699:141d0cf2c12e > user: mhaupt > date: Fri May 20 16:02:36 2016 +0200 > summary: 8157444: exclude jjs shebang handling test from runs > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/141d0cf2c12e > > changeset: 1692:7099f590cdec > user: mhaupt > date: Wed May 18 17:37:34 2016 +0200 > summary: 8157250: BeanLinker assumes fixed array type linkage > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/7099f590cdec > > changeset: 1690:c187d75b77aa > user: mhaupt > date: Wed May 18 12:07:54 2016 +0200 > summary: 8157225: adopt method handle for array length getter in BeanLinker > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/c187d75b77aa > > changeset: 1663:ba21793a0e48 > user: mhaupt > date: Mon Apr 11 18:10:30 2016 +0200 > summary: 8137149: add tests for issues closed during Nashorn issue cleanup > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/ba21793a0e48 > > changeset: 1637:11811302fe75 > user: mhaupt > date: Wed Mar 09 15:15:29 2016 +0100 > summary: 8151518: relax test requirements to reduce dependency on directory contents > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/11811302fe75 > > changeset: 1636:f27bb66ac9d3 > user: mhaupt > date: Wed Mar 09 13:24:01 2016 +0100 > summary: 8151291: $EXEC yields "unknown command" on Cygwin > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/f27bb66ac9d3 > > changeset: 1633:58409eff7e3e > user: mhaupt > date: Mon Feb 29 09:49:46 2016 +0100 > summary: 8150814: correct package declaration in Nashorn test > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/58409eff7e3e > > changeset: 1626:221378857767 > user: mhaupt > date: Tue Feb 16 15:34:27 2016 +0100 > summary: 8148140: arguments are handled differently in apply for JS functions and AbstractJSObjects > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/221378857767 > > changeset: 1624:cfb316745693 > user: mhaupt > date: Fri Feb 12 17:00:54 2016 +0100 > summary: 8149744: fix testng.jar delivery in Nashorn build.xml > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/cfb316745693 > > changeset: 1619:7ac82655d829 > user: mhaupt > date: Tue Feb 09 14:14:06 2016 +0100 > summary: 8149462: revert changes for 8149186 > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/7ac82655d829 > > changeset: 1618:4e9749cc32f1 > user: mhaupt > date: Mon Feb 08 17:43:02 2016 +0100 > summary: 8149334: JSON.parse(JSON.stringify([])).push(10) creates an array containing two elements > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/4e9749cc32f1 > > changeset: 1611:0da44ab8c417 > user: mhaupt > date: Thu Jan 28 11:20:44 2016 +0100 > summary: 8147591: Revisit Collection.toArray(new T[size]) calls in nashorn and dynalink code > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/0da44ab8c417 > > changeset: 1607:b3c945675e8c > user: mhaupt > date: Fri Jan 22 11:12:26 2016 +0100 > summary: 8134933: re-enable LambdaFormEditor assertions in Nashorn testing > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/b3c945675e8c > > changeset: 1602:086c19a36be6 > user: mhaupt > date: Wed Jan 20 09:56:29 2016 +0100 > summary: 8144113: enable jjs testing > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/086c19a36be6 > > changeset: 1601:981b353f2f75 > user: mhaupt > date: Mon Jan 18 11:31:43 2016 +0100 > summary: 8145305: fix Nashorn shebang handling on Cygwin > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/981b353f2f75 > > changeset: 1594:0f21903deef8 > user: mhaupt > date: Thu Jan 14 10:55:26 2016 +0100 > summary: 8036977: Make process singleton options to be context wide > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/0f21903deef8 > > changeset: 1568:5fed6b47d01a > user: mhaupt > date: Mon Dec 14 14:02:59 2015 +0100 > summary: 8144221: fix Nashorn shebang argument handling on Mac/Linux > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/5fed6b47d01a > > changeset: 1525:d98fe27f6ba9 > user: mhaupt > date: Thu Nov 26 12:01:41 2015 +0100 > summary: 8143642: Nashorn shebang argument handling is broken > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/d98fe27f6ba9 > > changeset: 1520:d2eb81e4ddc8 > user: mhaupt > date: Thu Nov 19 11:28:34 2015 +0100 > summary: 8143297: Nashorn compilation time reported in nanoseconds > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/d2eb81e4ddc8 > > changeset: 1488:1ceda730b9a3 > user: mhaupt > date: Thu Oct 29 11:37:48 2015 +0100 > summary: 8140759: add ES6 template literal test > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/1ceda730b9a3 > > changeset: 1487:6d9a3ef84ebf > user: mhaupt > date: Wed Oct 28 10:54:05 2015 +0100 > summary: 8134941: Implement ES6 template literal support > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/6d9a3ef84ebf > > changeset: 1462:6c6df82265f0 > user: mhaupt > date: Mon Oct 12 13:36:41 2015 +0200 > summary: 8139266: add JSAdapter example with fallthrough > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/6c6df82265f0 > > changeset: 1456:446625d6e8cc > user: mhaupt > date: Wed Oct 07 15:02:15 2015 +0200 > summary: 8139047: add test for JSAdapter __getIds__ > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/446625d6e8cc > > changeset: 1455:11b48db399bf > user: mhaupt > date: Wed Oct 07 14:00:45 2015 +0200 > summary: 8139038: cleanup and documentation around JSAdapter > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/11b48db399bf > > changeset: 1392:d61744c0d1d2 > user: mhaupt > date: Wed Aug 26 13:11:35 2015 +0200 > summary: 8134484: disallow backquotes as heredoc end marker delimiters > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/d61744c0d1d2 > > changeset: 1391:5efd65e18b71 > user: mhaupt > date: Wed Aug 26 09:59:29 2015 +0200 > summary: 8073613: Here documents: how to avoid string interpolation? > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/5efd65e18b71 > > changeset: 1379:6060f7652a28 > user: mhaupt > date: Tue Aug 18 09:13:46 2015 -0700 > summary: 8077168: CodeStoreAndPathTest.java fails in jtreg mode on Mac > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/6060f7652a28 > > changeset: 1363:9fddd7695ded > user: mhaupt > date: Mon Jul 27 09:42:09 2015 +0200 > summary: 8132305: fix incorrect title assignment in Nashorn JavaFX samples > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/9fddd7695ded > > changeset: 1360:b27730a502c3 > user: mhaupt > date: Wed Jul 22 09:28:28 2015 +0200 > summary: 8131142: late-bind check for testng.jar presence in Nashorn test execution > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/b27730a502c3 > > changeset: 1352:3fe85fdf1651 > user: mhaupt > date: Fri Jul 10 08:42:35 2015 +0200 > summary: 8130862: let hg ignore TestNG ZIP file in Nashorn test library directory > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/3fe85fdf1651 > > changeset: 1342:becb3bb6a422 > user: mhaupt > date: Thu Jul 02 11:20:47 2015 +0200 > summary: 8130307: improve Nashorn Javadoc target > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/becb3bb6a422 > > changeset: 1341:6eca661ddf79 > user: mhaupt > date: Thu Jul 02 11:09:20 2015 +0200 > summary: 8130306: enable running Nashorn test on Windows > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/6eca661ddf79 > > changeset: 1339:d95394322204 > user: mhaupt > date: Wed Jul 01 16:26:25 2015 +0200 > summary: 8130127: streamline input parameter of Nashorn scripting $EXEC function > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/d95394322204 > > changeset: 1313:a24cb0bf79bc > user: mhaupt > date: Tue Jun 09 09:27:02 2015 +0200 > summary: 8080490: add $EXECV command to Nashorn scripting mode > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/a24cb0bf79bc > > changeset: 1311:d1689c1df3aa > user: mhaupt > date: Mon Jun 08 10:28:04 2015 +0200 > summary: 8085885: address Javadoc warnings in Nashorn source code > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/d1689c1df3aa > > changeset: 1307:0eeaadd17fff > user: mhaupt > date: Fri Jun 05 12:38:53 2015 +0200 > summary: 8080087: Nashorn $ENV.PWD is originally undefined > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/0eeaadd17fff > > changeset: 1301:10553f87f3e7 > user: mhaupt > date: Tue Jun 02 17:08:13 2015 +0200 > summary: 8081696: reduce dependency of Nashorn tests on external components > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/10553f87f3e7 > > changeset: 1300:14ec7d7af490 > user: mhaupt > date: Tue Jun 02 14:35:03 2015 +0200 > summary: 8080275: transparently download testng.jar for Nashorn testing > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/14ec7d7af490 > > changeset: 1299:078107e0651f > user: mhaupt > date: Tue Jun 02 14:34:37 2015 +0200 > summary: 8081668: fix Nashorn ant externals command > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/078107e0651f > > changeset: 1298:0d4841f2c800 > user: mhaupt > date: Tue Jun 02 10:40:19 2015 +0200 > summary: 8081604: rename ScriptingFunctions.tokenizeCommandLine > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/0d4841f2c800 > > changeset: 1297:776551a5b3a2 > user: mhaupt > date: Tue Jun 02 10:40:10 2015 +0200 > summary: 8081603: erroneous dot file generated from Nashorn --print-code > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/776551a5b3a2 > > changeset: 1279:71d7a37e6dfb > user: mhaupt > date: Fri May 15 16:36:25 2015 +0200 > summary: 8049300: jjs scripting: need way to quote $EXEC command arguments to protect spaces > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/71d7a37e6dfb > > changeset: 1277:4dc7eb763139 > user: mhaupt > date: Fri May 15 10:21:48 2015 +0200 > summary: 8080471: fix usage of replace and file separator in Nashorn tests > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/4dc7eb763139 > > changeset: 1271:063ed2f959e4 > user: mhaupt > date: Wed May 13 15:41:46 2015 +0200 > summary: 8080286: use path separator setting consistently in Nashorn project properties > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/063ed2f959e4 > > *** hotspot > > changeset: 8796:6ad64d95053d > user: mhaupt > date: Wed Mar 18 16:16:30 2015 +0100 > summary: 8004073: Implement C2 Ideal node specific dump() method > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/6ad64d95053d > > changeset: 8690:0fb7705845de > user: mhaupt > date: Tue Mar 31 21:46:44 2015 +0200 > summary: 6900757: minor bug fixes to LogCompilation tool > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/0fb7705845de > > changeset: 8345:d3413c4fee16 > parent: 8343:67729f5f33c4 > user: mhaupt > date: Tue May 05 13:06:10 2015 +0200 > summary: 8075492: adopt recent IGV > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/d3413c4fee16 > > changeset: 8208:6c4ca18a0666 > user: mhaupt > date: Tue Apr 14 18:16:10 2015 +0300 > summary: 8076461: JSR292: remove unused native and constants > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/6c4ca18a0666 > > > From hannes.wallnoefer at oracle.com Wed Jun 1 08:52:56 2016 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Wed, 1 Jun 2016 10:52:56 +0200 Subject: CFV: New JDK 9 Reviewer: Michael Haupt In-Reply-To: References: Message-ID: <574EA268.6080407@oracle.com> Vote: yes Am 2016-05-31 um 17:52 schrieb Jim Laskey (Oracle): > I hereby nominate Michael Haupt to JDK 9 Reviewer. > From paul.sandoz at oracle.com Wed Jun 1 15:24:14 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 1 Jun 2016 17:24:14 +0200 Subject: RFR 8158039 VarHandle float/double field/array access should support CAS/set/add atomics Message-ID: <23FAF71F-F8B9-4AD6-9BF3-896795540788@oracle.com> (Please note this work is or will be covered with FC exception) Hi, Please review the VarHandles/Unsafe support for atomic ops on double/float fields/arrays. http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8158039-float-double-field-array-cas.jdk/webrev/ http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8158039-float-double-field-array-cas.hotspot/webrev/ These patches are based on those of for sub-word CAS https://bugs.openjdk.java.net/browse/JDK-8157726 http://cr.openjdk.java.net/~shade/8157726/webrev.hs.03/ http://cr.openjdk.java.net/~shade/8157726/webrev.jdk.03/ And the two patches combined expand the support of fields/arrays. New float/double CAS methods are added to Unsafe that defer to int/long equivalents. Then the other atomic methods are built from weak CAS loops. No changes are required to HotSpot, but changes are required to the Unsafe tests in the hotspot repository. In general the changes to VHs and tests are minimal since it is triggered from changes to the generating scripts that now include float/double into the CAS category. There are some minor specification changes and a CCC has been initiated. JPRT tests results show no relevant failures for hotspot and core test sets. Thanks, Paul. From aleksey.shipilev at oracle.com Wed Jun 1 17:55:42 2016 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Wed, 1 Jun 2016 20:55:42 +0300 Subject: RFR 8158039 VarHandle float/double field/array access should support CAS/set/add atomics In-Reply-To: <23FAF71F-F8B9-4AD6-9BF3-896795540788@oracle.com> References: <23FAF71F-F8B9-4AD6-9BF3-896795540788@oracle.com> Message-ID: <574F219E.40109@oracle.com> On 06/01/2016 06:24 PM, Paul Sandoz wrote: > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8158039-float-double-field-array-cas.jdk/webrev/ > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8158039-float-double-field-array-cas.hotspot/webrev/ These look good. Thanks, -Aleksey From john.r.rose at oracle.com Wed Jun 1 18:04:38 2016 From: john.r.rose at oracle.com (John Rose) Date: Wed, 1 Jun 2016 11:04:38 -0700 Subject: CFV: New JDK 9 Reviewer: Michael Haupt In-Reply-To: References: Message-ID: Vote: yes ? John > On May 31, 2016, at 8:52 AM, Jim Laskey (Oracle) wrote: > > I hereby nominate Michael Haupt to JDK 9 Reviewer. From lana.steuck at oracle.com Wed Jun 1 19:13:55 2016 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 1 Jun 2016 19:13:55 GMT Subject: jdk9-b121: dev Message-ID: <201606011913.u51JDt0B002468@scaaa563.us.oracle.com> http://hg.openjdk.java.net/jdk9/jdk9/rev/cae471d3b877 http://hg.openjdk.java.net/jdk9/jdk9/nashorn/rev/5992041b0794 http://hg.openjdk.java.net/jdk9/jdk9/langtools/rev/095bd53bdd1e http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/ee29aaab5889 http://hg.openjdk.java.net/jdk9/jdk9/jaxws/rev/fb771fa3a986 http://hg.openjdk.java.net/jdk9/jdk9/jaxp/rev/a265b8116058 http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/7e293105dbb0 http://hg.openjdk.java.net/jdk9/jdk9/corba/rev/9a5fc5a27560 --- All the fixes will be tested during promotion (no PIT testing at this point): List of all fixes: =================== JDK-6961865 core-libs javadoc for Boolean.valueOf(String) with null argument not clearly spe JDK-8016521 core-libs InetAddress should not always re-order addresses returned from name se JDK-8032230 core-libs Enhance javax.a.p.RoundEnvironment after repeating annotations JDK-8033812 core-libs javadoc for java.lang.annotation.ElementType needs minor correction JDK-8039565 core-libs Remove test exclusion for java/util/ResourceBundle/RestrictedBundleTes JDK-8133977 core-libs add specification for serialized forms JDK-8136933 core-libs Additional tests for Solaris SO_FLOW_SLA socket option in JDK 9 JDK-8139956 core-libs (zipfs) ZipPath does not produce correct empty path on relativize() JDK-8146389 core-libs java/util/logging/XMLFormatterDate.java fails during year switch JDK-8146754 core-libs (zipfs) ZipPath.relativize() returns wrong result for path ending with JDK-8147539 core-libs (zipfs) ZipPath should throw ProviderMismatchException when invoking r JDK-8151904 core-libs test/java/lang/StackWalker/VerifyStackTrace.java needs to handle updat JDK-8153248 core-libs (zipfs) ZipPath#getFileName( ) returns inconsistent result JDK-8153768 core-libs Miscellaneous changes imported from jsr166 CVS 2016-05 JDK-8156142 core-libs ModuleReader instances don't always throw NPE for passed null args JDK-8156143 core-libs Module.getResourceAsStream throws unspecified SecurityException with m JDK-8156718 core-libs Need tests for IsoFields getFrom for unsupported non-Iso Temporal fiel JDK-8157633 core-libs Fix module dependencies for /com/* tests JDK-8157635 core-libs Fix module dependencies for /sun/* tests JDK-8157680 core-libs Callback parameter of any JS builtin implementation should accept any JDK-8157724 core-libs Improve javadoc tag usage in java.math JDK-8157783 core-libs Fix module dependencies for /jdk/* tests JDK-8157789 core-libs Nashorn sample/test.js should not use undocumented System property JDK-8157811 core-libs Additional minor fixes and cleanups in Networking native code JDK-8157813 core-libs Remove sun/rmi/transport/proxy/EagerHttpFallback.java from ProblemList JDK-8157819 core-libs TypeError when a java.util.Comparator object is invoked as a function JDK-8157825 core-libs Remove JDK 9 specific methods from sun.misc.Unsafe JDK-8157877 core-libs Clean up StackWalker permission checks JDK-8157964 core-libs Static build of libzip is missing JNI_OnLoad_zip entry point JDK-8157986 core-libs Runtime support for javac to determine arguments to the runtime enviro JDK-8157996 core-libs Unneeded import in lib/testlibrary/jdk/testlibrary/SimpleSSLContext.ja JDK-8157997 core-libs Reverting a push with wrong id JDK-8152207 hotspot Perform array bound checks while getting a length of bytecode instruct JDK-8157336 infrastructure Generation of classlists at build time should be configurable JDK-8157895 infrastructure langtools launcher.sh-template script is broken JDK-8137255 security-libs sun/security/provider/NSASuiteB/TestDSAGenParameterSpec.java timeouts JDK-8154005 security-libs Add algorithm constraint that specifies the restriction date JDK-8049896 tools Clean up (Basic)JavacTask.getTypeMirror JDK-8080883 tools JShell tool: tool does not report errors if -startup and -nostartup fl JDK-8139872 tools JShell tests: EditorPadTest failing on headless JDK-8141415 tools JShell: wrap erroneous with one-liner comment-outed imports JDK-8152360 tools deprecate javah JDK-8152785 tools Remove javac -XDnoModules JDK-8154052 tools Java compiler error displays line from the wrong file JDK-8156209 tools Add argument checks to BasicImageReader calls JDK-8156962 tools javac should support options specified in _JAVAC_OPTIONS JDK-8157261 tools jshell tool: truncation for expressions is not consistent JDK-8157606 tools deprecate com.sun.javadoc API JDK-8157608 tools deprecate old entry points for javadoc tool JDK-8157663 tools Remove tools/jimage/JImageTest.java from ProblemList.txt JDK-8157801 tools spurious > character in the javadoc comment for ModuleEntry.java JDK-8157917 tools JShell: shutdown could cause remote JDWP errors to be visible to users JDK-8157918 tools JShell tests: StartOptionTest displays insufficient information to dia JDK-8157931 tools jdk/internal/jrtfs/Basic.java fails with exploded builds JDK-8157953 tools JShell tests: reenable ToolBasicTest JDK-8158061 tools Additional argument checks to BasicImageReader calls From david.holmes at oracle.com Thu Jun 2 07:13:05 2016 From: david.holmes at oracle.com (David Holmes) Date: Thu, 2 Jun 2016 17:13:05 +1000 Subject: RFR 8158039 VarHandle float/double field/array access should support CAS/set/add atomics In-Reply-To: <23FAF71F-F8B9-4AD6-9BF3-896795540788@oracle.com> References: <23FAF71F-F8B9-4AD6-9BF3-896795540788@oracle.com> Message-ID: <6ed640e8-f581-e81d-3e77-ef47405f9618@oracle.com> On 2/06/2016 1:24 AM, Paul Sandoz wrote: > (Please note this work is or will be covered with FC exception) > > Hi, > > Please review the VarHandles/Unsafe support for atomic ops on double/float fields/arrays. I think this is misguided. If the user wants CAS for float/double they can do the conversion to int/long in a context where they know that conversion makes sense and where they can deal with NaNs appropriately. At a minimum the fact this deals with raw bit patterns not semantic values needs to be exposed somehow. ie the handling of NaN needs to be explicit. David ----- > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8158039-float-double-field-array-cas.jdk/webrev/ > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8158039-float-double-field-array-cas.hotspot/webrev/ > > These patches are based on those of for sub-word CAS > > https://bugs.openjdk.java.net/browse/JDK-8157726 > http://cr.openjdk.java.net/~shade/8157726/webrev.hs.03/ > http://cr.openjdk.java.net/~shade/8157726/webrev.jdk.03/ > > And the two patches combined expand the support of fields/arrays. > > > New float/double CAS methods are added to Unsafe that defer to int/long equivalents. Then the other atomic methods are built from weak CAS loops. > > No changes are required to HotSpot, but changes are required to the Unsafe tests in the hotspot repository. > > In general the changes to VHs and tests are minimal since it is triggered from changes to the generating scripts that now include float/double into the CAS category. > > There are some minor specification changes and a CCC has been initiated. > > JPRT tests results show no relevant failures for hotspot and core test sets. > > Thanks, > Paul. > From zoltan.majo at oracle.com Thu Jun 2 07:17:39 2016 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Thu, 2 Jun 2016 09:17:39 +0200 Subject: CFV: New JDK 9 Reviewer: Michael Haupt In-Reply-To: References: Message-ID: <574FDD93.6020000@oracle.com> Vote: Yes. Best regards, Zoltan On 05/31/2016 05:52 PM, Jim Laskey (Oracle) wrote: > I hereby nominate Michael Haupt to JDK 9 Reviewer. > > Michael is a member to the Nashorn team; his focus is on dynamic language implementations. He also collaborates with the Valhalla project for value types. Prior to joining Nashorn, Michael worked briefly in the HotSpot compiler team. He has been an Oracle employee since 2011, which is when he joined the Virtual Machine Research Group at Oracle Labs, where he has worked on the Maxine meta-circular JVM and on dynamic language implementations. He used to be the tech lead of the FastR project, a high-performance Java-based implementation of the R programming language. Michael has also contributed to the Invokedynamic infrastructure in the past. > > Votes are due by June 15, 2016 > > Only current JDK9 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]. > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > > Michael?s contributions: > > === JDK 9 > > *** JSR 292 > > changeset: 14592:80f1fb052dee > user: mhaupt > date: Tue May 24 09:13:47 2016 +0200 > summary: 8157590: MethodHandles.arrayLength() lacks @since tag, implementation throws wrong exception > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/80f1fb052dee > > changeset: 14495:fd39cefc5c8f > user: mhaupt > date: Wed May 18 10:42:29 2016 +0200 > summary: 8156915: introduce MethodHandle factory for array length > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/fd39cefc5c8f > > changeset: 14301:c0e1a94f27f5 > user: mhaupt > date: Wed Apr 27 20:18:49 2016 +0200 > summary: 8155106: MHs.Lookup.findConstructor returns handles for array classes > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/c0e1a94f27f5 > > changeset: 14298:5a48729a7eb6 > user: mhaupt > date: Wed Apr 27 15:01:21 2016 +0200 > summary: 8155214: java/lang/invoke/PermuteArgsTest.java fails due to exhausted code cache > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/5a48729a7eb6 > > changeset: 14276:e8217d94b72e > user: mhaupt > date: Fri Apr 22 15:05:54 2016 +0200 > summary: 8154754: MethodHandles.countedLoop errors in deriving loop arguments, result type, and local state > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/e8217d94b72e > > changeset: 14275:14065c26ea1a > user: mhaupt > date: Fri Apr 22 15:05:26 2016 +0200 > summary: 8154751: MethodHandles.countedLoop does not accept empty bodies > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/14065c26ea1a > > changeset: 14274:beac9a439d0f > user: mhaupt > date: Fri Apr 22 13:36:22 2016 +0200 > summary: 8152667: MHs.iteratedLoop(...) throws unexpected WMTE, disallows Iterator subclasses, generates inconsistent loop result type > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/beac9a439d0f > > changeset: 14210:214c1ee32e00 > user: mhaupt > date: Tue Apr 19 14:39:35 2016 +0200 > summary: 8150956: j.l.i.MethodHandles.whileLoop(...) and .iteratedLoop(...) throw unexpected exceptions in the case of 'init' return type is void > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/214c1ee32e00 > > changeset: 14169:210cce63ef9c > user: mhaupt > date: Thu Apr 14 15:18:42 2016 +0200 > summary: 8150824: Exceptions when omitting trailing arguments in cleanup > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/210cce63ef9c > > changeset: 14152:fe806038ae74 > user: mhaupt > date: Wed Apr 13 09:20:22 2016 +0200 > summary: 8153637: MethodHandles.countedLoop/3 initialises loop counter to 1 instead of 0 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/fe806038ae74 > > changeset: 13903:d14f551f4d52 > user: mhaupt > date: Mon Mar 14 08:10:44 2016 +0100 > summary: 8151778: TestLookup.java fails after push of JDK-8150782 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/d14f551f4d52 > > changeset: 13902:25e8c082d7ef > user: mhaupt > date: Sun Mar 13 20:26:29 2016 +0100 > summary: 8150782: findClass / accessClass throw unexpected exceptions > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/25e8c082d7ef > > changeset: 13805:e941d983c8e4 > user: mhaupt > date: Thu Mar 03 14:29:00 2016 +0100 > summary: 8150957: j.l.i.MethodHandles.whileLoop(...) fails with IOOBE in the case init is null, step and pred have parameters > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/e941d983c8e4 > > changeset: 13799:c48cb760984f > user: mhaupt > date: Wed Mar 02 20:36:00 2016 +0100 > summary: 8150832: split T8139885 into several tests by functionality > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/c48cb760984f > > changeset: 13798:a24ddbbc4beb > user: mhaupt > date: Wed Mar 02 20:16:11 2016 +0100 > summary: 8150635: j.l.i.MethodHandles.loop(...) throws IndexOutOfBoundsException > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/a24ddbbc4beb > > changeset: 13796:8c2194ad4ca3 > user: mhaupt > date: Wed Mar 02 14:15:15 2016 +0100 > summary: 8150953: j.l.i.MethodHandles: example section in whileLoop(...) provides example for doWhileLoop > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/8c2194ad4ca3 > > changeset: 13790:42794e648cfe > user: mhaupt > date: Mon Feb 29 14:16:20 2016 +0100 > summary: 8150825: MethodHandles.tryFinally throws IndexOutOfBoundsException for non-conforming parameter lists > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/42794e648cfe > > changeset: 13767:9d536355b828 > user: mhaupt > date: Tue Feb 23 09:49:04 2016 +0100 > summary: 8143410: augment pseudo-code descriptions in MethodHandles API > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/9d536355b828 > > changeset: 13765:4d1292a702b8 > user: mhaupt > date: Tue Feb 23 07:17:54 2016 +0100 > summary: 8150360: augment/correct MethodHandle API documentation > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/4d1292a702b8 > > changeset: 13474:1de1a321ea87 > user: mhaupt > date: Wed Dec 09 11:02:54 2015 +0000 > summary: 8081512: Remove sun.invoke.anon classes, or move / co-locate them with tests > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/1de1a321ea87 > > changeset: 13458:f5d02fbd8095 > user: mhaupt > date: Thu Jan 14 13:53:13 2016 +0100 > summary: 8147078: MethodHandles.catchException does not enforce Throwable subtype > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/f5d02fbd8095 > > changeset: 13443:5be075daee3a > user: mhaupt > date: Mon Jan 11 17:19:16 2016 +0100 > summary: 8146786: [TESTBUG] straighten out testability for several issues > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/5be075daee3a > > changeset: 13255:4d010a9bd0d9 > user: mhaupt > date: Thu Dec 03 15:36:20 2015 +0100 > summary: 8143343: add JEP 274 Javadoc tests to JavaDocExamplesTest > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/4d010a9bd0d9 > > changeset: 13254:d41609429f2e > user: mhaupt > date: Thu Dec 03 15:34:39 2015 +0100 > summary: 8072844: Use more efficient LambdaForm type representation > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/d41609429f2e > > changeset: 13176:33c6cca30255 > user: mhaupt > date: Wed Dec 02 10:59:03 2015 +0100 > summary: 8076596: BytecodeDescriptor.parseMethod doesn't work during bootstrapping > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/33c6cca30255 > > changeset: 13124:ff8ce38663d9 > user: mhaupt > date: Wed Nov 25 09:23:07 2015 +0100 > summary: 8143798: jck failures: api/java_lang/invoke/MethodHandle/index_MethodsTests[asSpreaderWMTE]: java.lang.VerifyError: Bad type on operand stack > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/ff8ce38663d9 > > changeset: 13109:957e4e29ff28 > user: mhaupt > date: Fri Nov 20 15:34:12 2015 +0100 > summary: 8139885: implement JEP 274: enhanced method handles > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/957e4e29ff28 > > changeset: 12962:0f6c981f1cbf > user: mhaupt > date: Tue Oct 27 09:09:37 2015 +0100 > summary: 8136967: revert all changes applied to obtain information about 8131129 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/0f6c981f1cbf > > changeset: 12789:69f78bcd65f8 > user: mhaupt > date: Wed Sep 23 08:43:51 2015 +0200 > summary: 8136931: more fine-grained condition checking for BMH species creation > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/69f78bcd65f8 > > changeset: 12415:2919a03653a8 > user: mhaupt > date: Fri Jul 17 08:10:41 2015 +0200 > summary: 8062543: Replace uses of MethodHandleImpl.castReference with Class.cast > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/2919a03653a8 > > changeset: 8369:465e5b2bb615 > user: acorn > date: Fri May 08 14:00:24 2015 -0400 > summary: 8030680: 292 cleanup from default method code assessment > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/465e5b2bb615 > > changeset: 11850:e0ac3e9decb0 > user: mhaupt > date: Tue Apr 14 18:26:01 2015 +0300 > summary: 8033465: JSR292: InvokerBytecodeGenerator: convert a check for REF_invokeVirtual on an interface into an assert > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/e0ac3e9decb0 > > changeset: 5688:050116960e99 > user: twisti > date: Tue Jul 24 10:47:44 2012 -0700 > summary: 7023639: JSR 292 method handle invocation needs a fast path for compiled code > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/050116960e99 > > *** nashorn > > changeset: 1699:141d0cf2c12e > user: mhaupt > date: Fri May 20 16:02:36 2016 +0200 > summary: 8157444: exclude jjs shebang handling test from runs > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/141d0cf2c12e > > changeset: 1692:7099f590cdec > user: mhaupt > date: Wed May 18 17:37:34 2016 +0200 > summary: 8157250: BeanLinker assumes fixed array type linkage > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/7099f590cdec > > changeset: 1690:c187d75b77aa > user: mhaupt > date: Wed May 18 12:07:54 2016 +0200 > summary: 8157225: adopt method handle for array length getter in BeanLinker > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/c187d75b77aa > > changeset: 1663:ba21793a0e48 > user: mhaupt > date: Mon Apr 11 18:10:30 2016 +0200 > summary: 8137149: add tests for issues closed during Nashorn issue cleanup > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/ba21793a0e48 > > changeset: 1637:11811302fe75 > user: mhaupt > date: Wed Mar 09 15:15:29 2016 +0100 > summary: 8151518: relax test requirements to reduce dependency on directory contents > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/11811302fe75 > > changeset: 1636:f27bb66ac9d3 > user: mhaupt > date: Wed Mar 09 13:24:01 2016 +0100 > summary: 8151291: $EXEC yields "unknown command" on Cygwin > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/f27bb66ac9d3 > > changeset: 1633:58409eff7e3e > user: mhaupt > date: Mon Feb 29 09:49:46 2016 +0100 > summary: 8150814: correct package declaration in Nashorn test > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/58409eff7e3e > > changeset: 1626:221378857767 > user: mhaupt > date: Tue Feb 16 15:34:27 2016 +0100 > summary: 8148140: arguments are handled differently in apply for JS functions and AbstractJSObjects > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/221378857767 > > changeset: 1624:cfb316745693 > user: mhaupt > date: Fri Feb 12 17:00:54 2016 +0100 > summary: 8149744: fix testng.jar delivery in Nashorn build.xml > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/cfb316745693 > > changeset: 1619:7ac82655d829 > user: mhaupt > date: Tue Feb 09 14:14:06 2016 +0100 > summary: 8149462: revert changes for 8149186 > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/7ac82655d829 > > changeset: 1618:4e9749cc32f1 > user: mhaupt > date: Mon Feb 08 17:43:02 2016 +0100 > summary: 8149334: JSON.parse(JSON.stringify([])).push(10) creates an array containing two elements > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/4e9749cc32f1 > > changeset: 1611:0da44ab8c417 > user: mhaupt > date: Thu Jan 28 11:20:44 2016 +0100 > summary: 8147591: Revisit Collection.toArray(new T[size]) calls in nashorn and dynalink code > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/0da44ab8c417 > > changeset: 1607:b3c945675e8c > user: mhaupt > date: Fri Jan 22 11:12:26 2016 +0100 > summary: 8134933: re-enable LambdaFormEditor assertions in Nashorn testing > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/b3c945675e8c > > changeset: 1602:086c19a36be6 > user: mhaupt > date: Wed Jan 20 09:56:29 2016 +0100 > summary: 8144113: enable jjs testing > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/086c19a36be6 > > changeset: 1601:981b353f2f75 > user: mhaupt > date: Mon Jan 18 11:31:43 2016 +0100 > summary: 8145305: fix Nashorn shebang handling on Cygwin > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/981b353f2f75 > > changeset: 1594:0f21903deef8 > user: mhaupt > date: Thu Jan 14 10:55:26 2016 +0100 > summary: 8036977: Make process singleton options to be context wide > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/0f21903deef8 > > changeset: 1568:5fed6b47d01a > user: mhaupt > date: Mon Dec 14 14:02:59 2015 +0100 > summary: 8144221: fix Nashorn shebang argument handling on Mac/Linux > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/5fed6b47d01a > > changeset: 1525:d98fe27f6ba9 > user: mhaupt > date: Thu Nov 26 12:01:41 2015 +0100 > summary: 8143642: Nashorn shebang argument handling is broken > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/d98fe27f6ba9 > > changeset: 1520:d2eb81e4ddc8 > user: mhaupt > date: Thu Nov 19 11:28:34 2015 +0100 > summary: 8143297: Nashorn compilation time reported in nanoseconds > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/d2eb81e4ddc8 > > changeset: 1488:1ceda730b9a3 > user: mhaupt > date: Thu Oct 29 11:37:48 2015 +0100 > summary: 8140759: add ES6 template literal test > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/1ceda730b9a3 > > changeset: 1487:6d9a3ef84ebf > user: mhaupt > date: Wed Oct 28 10:54:05 2015 +0100 > summary: 8134941: Implement ES6 template literal support > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/6d9a3ef84ebf > > changeset: 1462:6c6df82265f0 > user: mhaupt > date: Mon Oct 12 13:36:41 2015 +0200 > summary: 8139266: add JSAdapter example with fallthrough > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/6c6df82265f0 > > changeset: 1456:446625d6e8cc > user: mhaupt > date: Wed Oct 07 15:02:15 2015 +0200 > summary: 8139047: add test for JSAdapter __getIds__ > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/446625d6e8cc > > changeset: 1455:11b48db399bf > user: mhaupt > date: Wed Oct 07 14:00:45 2015 +0200 > summary: 8139038: cleanup and documentation around JSAdapter > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/11b48db399bf > > changeset: 1392:d61744c0d1d2 > user: mhaupt > date: Wed Aug 26 13:11:35 2015 +0200 > summary: 8134484: disallow backquotes as heredoc end marker delimiters > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/d61744c0d1d2 > > changeset: 1391:5efd65e18b71 > user: mhaupt > date: Wed Aug 26 09:59:29 2015 +0200 > summary: 8073613: Here documents: how to avoid string interpolation? > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/5efd65e18b71 > > changeset: 1379:6060f7652a28 > user: mhaupt > date: Tue Aug 18 09:13:46 2015 -0700 > summary: 8077168: CodeStoreAndPathTest.java fails in jtreg mode on Mac > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/6060f7652a28 > > changeset: 1363:9fddd7695ded > user: mhaupt > date: Mon Jul 27 09:42:09 2015 +0200 > summary: 8132305: fix incorrect title assignment in Nashorn JavaFX samples > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/9fddd7695ded > > changeset: 1360:b27730a502c3 > user: mhaupt > date: Wed Jul 22 09:28:28 2015 +0200 > summary: 8131142: late-bind check for testng.jar presence in Nashorn test execution > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/b27730a502c3 > > changeset: 1352:3fe85fdf1651 > user: mhaupt > date: Fri Jul 10 08:42:35 2015 +0200 > summary: 8130862: let hg ignore TestNG ZIP file in Nashorn test library directory > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/3fe85fdf1651 > > changeset: 1342:becb3bb6a422 > user: mhaupt > date: Thu Jul 02 11:20:47 2015 +0200 > summary: 8130307: improve Nashorn Javadoc target > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/becb3bb6a422 > > changeset: 1341:6eca661ddf79 > user: mhaupt > date: Thu Jul 02 11:09:20 2015 +0200 > summary: 8130306: enable running Nashorn test on Windows > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/6eca661ddf79 > > changeset: 1339:d95394322204 > user: mhaupt > date: Wed Jul 01 16:26:25 2015 +0200 > summary: 8130127: streamline input parameter of Nashorn scripting $EXEC function > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/d95394322204 > > changeset: 1313:a24cb0bf79bc > user: mhaupt > date: Tue Jun 09 09:27:02 2015 +0200 > summary: 8080490: add $EXECV command to Nashorn scripting mode > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/a24cb0bf79bc > > changeset: 1311:d1689c1df3aa > user: mhaupt > date: Mon Jun 08 10:28:04 2015 +0200 > summary: 8085885: address Javadoc warnings in Nashorn source code > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/d1689c1df3aa > > changeset: 1307:0eeaadd17fff > user: mhaupt > date: Fri Jun 05 12:38:53 2015 +0200 > summary: 8080087: Nashorn $ENV.PWD is originally undefined > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/0eeaadd17fff > > changeset: 1301:10553f87f3e7 > user: mhaupt > date: Tue Jun 02 17:08:13 2015 +0200 > summary: 8081696: reduce dependency of Nashorn tests on external components > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/10553f87f3e7 > > changeset: 1300:14ec7d7af490 > user: mhaupt > date: Tue Jun 02 14:35:03 2015 +0200 > summary: 8080275: transparently download testng.jar for Nashorn testing > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/14ec7d7af490 > > changeset: 1299:078107e0651f > user: mhaupt > date: Tue Jun 02 14:34:37 2015 +0200 > summary: 8081668: fix Nashorn ant externals command > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/078107e0651f > > changeset: 1298:0d4841f2c800 > user: mhaupt > date: Tue Jun 02 10:40:19 2015 +0200 > summary: 8081604: rename ScriptingFunctions.tokenizeCommandLine > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/0d4841f2c800 > > changeset: 1297:776551a5b3a2 > user: mhaupt > date: Tue Jun 02 10:40:10 2015 +0200 > summary: 8081603: erroneous dot file generated from Nashorn --print-code > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/776551a5b3a2 > > changeset: 1279:71d7a37e6dfb > user: mhaupt > date: Fri May 15 16:36:25 2015 +0200 > summary: 8049300: jjs scripting: need way to quote $EXEC command arguments to protect spaces > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/71d7a37e6dfb > > changeset: 1277:4dc7eb763139 > user: mhaupt > date: Fri May 15 10:21:48 2015 +0200 > summary: 8080471: fix usage of replace and file separator in Nashorn tests > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/4dc7eb763139 > > changeset: 1271:063ed2f959e4 > user: mhaupt > date: Wed May 13 15:41:46 2015 +0200 > summary: 8080286: use path separator setting consistently in Nashorn project properties > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/063ed2f959e4 > > *** hotspot > > changeset: 8796:6ad64d95053d > user: mhaupt > date: Wed Mar 18 16:16:30 2015 +0100 > summary: 8004073: Implement C2 Ideal node specific dump() method > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/6ad64d95053d > > changeset: 8690:0fb7705845de > user: mhaupt > date: Tue Mar 31 21:46:44 2015 +0200 > summary: 6900757: minor bug fixes to LogCompilation tool > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/0fb7705845de > > changeset: 8345:d3413c4fee16 > parent: 8343:67729f5f33c4 > user: mhaupt > date: Tue May 05 13:06:10 2015 +0200 > summary: 8075492: adopt recent IGV > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/d3413c4fee16 > > changeset: 8208:6c4ca18a0666 > user: mhaupt > date: Tue Apr 14 18:16:10 2015 +0300 > summary: 8076461: JSR292: remove unused native and constants > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/6c4ca18a0666 > > > From paul.sandoz at oracle.com Thu Jun 2 08:34:00 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 2 Jun 2016 10:34:00 +0200 Subject: RFR 8158039 VarHandle float/double field/array access should support CAS/set/add atomics In-Reply-To: <6ed640e8-f581-e81d-3e77-ef47405f9618@oracle.com> References: <23FAF71F-F8B9-4AD6-9BF3-896795540788@oracle.com> <6ed640e8-f581-e81d-3e77-ef47405f9618@oracle.com> Message-ID: > On 2 Jun 2016, at 09:13, David Holmes wrote: > > On 2/06/2016 1:24 AM, Paul Sandoz wrote: >> (Please note this work is or will be covered with FC exception) >> >> Hi, >> >> Please review the VarHandles/Unsafe support for atomic ops on double/float fields/arrays. > > I think this is misguided. If the user wants CAS for float/double they can do the conversion to int/long in a context where they know that conversion makes sense and where they can deal with NaNs appropriately. > I would still like to support some clearly defined default behaviour if at all possible, since this is not easy to get right so we can add some value here. The user can use int/long if that behaviour is not suitable. > At a minimum the fact this deals with raw bit patterns not semantic values needs to be exposed somehow. ie the handling of NaN needs to be explicit. > Yes, it?s multiple NaN values that collapse to a single NaN value. It would be good if our resident floating point expert Mr. Joe Darcy could chime in this respect. On Float.intBitsToFloat: *

Note that this method may not be able to return a * {@code float} NaN with exactly same bit pattern as the * {@code int} argument. IEEE 754 distinguishes between two * kinds of NaNs, quiet NaNs and signaling NaNs. The * differences between the two kinds of NaN are generally not * visible in Java. Arithmetic operations on signaling NaNs turn * them into quiet NaNs with a different, but often similar, bit * pattern. However, on some processors merely copying a * signaling NaN also performs that conversion. In particular, * copying a signaling NaN to return it to the calling method may * perform this conversion. So {@code intBitsToFloat} may * not be able to return a {@code float} with a signaling NaN * bit pattern. Consequently, for some {@code int} values, * {@code floatToRawIntBits(intBitsToFloat(start))} may * not equal {@code start}. Moreover, which * particular bit patterns represent signaling NaNs is platform * dependent; although all NaN bit patterns, quiet or signaling, * must be in the NaN range identified above. I am concerned that the CAS loops could in some cases loop without termination: @ForceInline public final float getAndAddFloat(Object o, long offset, float delta) { float v; do { v = getFloatVolatile(o, offset); } while (!weakCompareAndSwapFloatVolatile(o, offset, v, v + delta)); return v; } I think this should be: @ForceInline public final float getAndAddFloat(Object o, long offset, float delta) { int expectedBits; float v; do { expectedBits = getIntVolatile(o, offset); v = Float.intBitsToFloat(bits); // May not preserve a NaN value with the same bit pattern as expectedBits } while (!weakCompareAndSwapIntVolatile(o, offset, expectedBits, Float.floatToRawIntBits(v + delta))); return v; } and likewise for the atomic get-and-set methods. Paul. > David > ----- > >> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8158039-float-double-field-array-cas.jdk/webrev/ >> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8158039-float-double-field-array-cas.hotspot/webrev/ >> >> These patches are based on those of for sub-word CAS >> >> https://bugs.openjdk.java.net/browse/JDK-8157726 >> http://cr.openjdk.java.net/~shade/8157726/webrev.hs.03/ >> http://cr.openjdk.java.net/~shade/8157726/webrev.jdk.03/ >> >> And the two patches combined expand the support of fields/arrays. >> >> >> New float/double CAS methods are added to Unsafe that defer to int/long equivalents. Then the other atomic methods are built from weak CAS loops. >> >> No changes are required to HotSpot, but changes are required to the Unsafe tests in the hotspot repository. >> >> In general the changes to VHs and tests are minimal since it is triggered from changes to the generating scripts that now include float/double into the CAS category. >> >> There are some minor specification changes and a CCC has been initiated. >> >> JPRT tests results show no relevant failures for hotspot and core test sets. >> >> Thanks, >> Paul. >> From dl at cs.oswego.edu Thu Jun 2 12:08:34 2016 From: dl at cs.oswego.edu (Doug Lea) Date: Thu, 2 Jun 2016 08:08:34 -0400 Subject: RFR 8158039 VarHandle float/double field/array access should support CAS/set/add atomics In-Reply-To: References: <23FAF71F-F8B9-4AD6-9BF3-896795540788@oracle.com> <6ed640e8-f581-e81d-3e77-ef47405f9618@oracle.com> Message-ID: <575021C2.7070509@cs.oswego.edu> On 06/02/2016 04:34 AM, Paul Sandoz wrote: > > I am concerned that the CAS loops could in some cases loop without termination: > > @ForceInline > public final float getAndAddFloat(Object o, long offset, float delta) { > float v; > do { > v = getFloatVolatile(o, offset); > } while (!weakCompareAndSwapFloatVolatile(o, offset, v, v + delta)); > return v; > } > Yes. This is why we did not introduce Atomic{Float, Double} in java.util.concurrent.atomic, but instead tell people to use intBitsToFloat etc if that's what they intend (see http://docs.oracle.com/javase/8/docs/api/java/util/concurrent/atomic/package-summary.html) People (apparently including you :-) argue that this is too pedantic though. The standard way suggested in docs is almost always what people want, so could be used, so long as it is carefully spelled out so that when people do hit multiple NaN problems and the like, at least they can find an explanation. > > I think this should be: > > @ForceInline > public final float getAndAddFloat(Object o, long offset, float delta) { > int expectedBits; > float v; > do { > expectedBits = getIntVolatile(o, offset); > v = Float.intBitsToFloat(bits); // May not preserve a NaN value with the same bit pattern as expectedBits > } while (!weakCompareAndSwapIntVolatile(o, offset, expectedBits, Float.floatToRawIntBits(v + delta))); > return v; > } > From martinrb at google.com Thu Jun 2 12:41:35 2016 From: martinrb at google.com (Martin Buchholz) Date: Thu, 2 Jun 2016 05:41:35 -0700 Subject: RFR 8158039 VarHandle float/double field/array access should support CAS/set/add atomics In-Reply-To: <575021C2.7070509@cs.oswego.edu> References: <23FAF71F-F8B9-4AD6-9BF3-896795540788@oracle.com> <6ed640e8-f581-e81d-3e77-ef47405f9618@oracle.com> <575021C2.7070509@cs.oswego.edu> Message-ID: You can find an AtomicDouble in jsr166 CVS http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/jsr166e/extra/AtomicDouble.java?view=markup and in guava https://github.com/google/guava/blob/master/guava/src/com/google/common/util/concurrent/AtomicDouble.java I'm still in favor of putting it in openjdk. On Thu, Jun 2, 2016 at 5:08 AM, Doug Lea

wrote: > On 06/02/2016 04:34 AM, Paul Sandoz wrote: >> >> >> I am concerned that the CAS loops could in some cases loop without >> termination: >> >> @ForceInline >> public final float getAndAddFloat(Object o, long offset, float delta) { >> float v; >> do { >> v = getFloatVolatile(o, offset); >> } while (!weakCompareAndSwapFloatVolatile(o, offset, v, v + delta)); >> return v; >> } >> > > Yes. This is why we did not introduce Atomic{Float, Double} in > java.util.concurrent.atomic, but instead tell people to > use intBitsToFloat etc if that's what they intend (see > http://docs.oracle.com/javase/8/docs/api/java/util/concurrent/atomic/package-summary.html) > > People (apparently including you :-) argue that this is too pedantic > though. The standard way suggested in docs is almost always what > people want, so could be used, so long as it is carefully spelled > out so that when people do hit multiple NaN problems and the like, > at least they can find an explanation. > > > >> >> I think this should be: >> >> @ForceInline >> public final float getAndAddFloat(Object o, long offset, float delta) { >> int expectedBits; >> float v; >> do { >> expectedBits = getIntVolatile(o, offset); >> v = Float.intBitsToFloat(bits); // May not preserve a NaN value >> with the same bit pattern as expectedBits >> } while (!weakCompareAndSwapIntVolatile(o, offset, expectedBits, >> Float.floatToRawIntBits(v + delta))); >> return v; >> } >> > From vladimir.x.ivanov at oracle.com Thu Jun 2 12:55:38 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Thu, 2 Jun 2016 15:55:38 +0300 Subject: RFR 8158039 VarHandle float/double field/array access should support CAS/set/add atomics In-Reply-To: References: <23FAF71F-F8B9-4AD6-9BF3-896795540788@oracle.com> <6ed640e8-f581-e81d-3e77-ef47405f9618@oracle.com> Message-ID: Paul, Leaving practicality aspect of float/double API aside... > I am concerned that the CAS loops could in some cases loop without termination: Can you elaborate? I don't see how it is possible with the proposed patch. Unless getFloatVolatile() or weakCompareAndSwapFloatVolatile() change the original value, it should not happen. And both functions preserve float value bits intact: + @ForceInline + public final boolean weakCompareAndSwapFloatVolatile(Object o, long offset, + float expected, + float x) { + return weakCompareAndSwapIntVolatile(o, offset, + Float.floatToRawIntBits(expected), + Float.floatToRawIntBits(x)); + } Float.floatToRawIntBits() makes it safe, but with Float.intBitsToFloat() used infinite looping can happen for NaNs. Best regards, Vladimir Ivanov > > @ForceInline > public final float getAndAddFloat(Object o, long offset, float delta) { > float v; > do { > v = getFloatVolatile(o, offset); > } while (!weakCompareAndSwapFloatVolatile(o, offset, v, v + delta)); > return v; > } > > > I think this should be: > > @ForceInline > public final float getAndAddFloat(Object o, long offset, float delta) { > int expectedBits; > float v; > do { > expectedBits = getIntVolatile(o, offset); > v = Float.intBitsToFloat(bits); // May not preserve a NaN value with the same bit pattern as expectedBits > } while (!weakCompareAndSwapIntVolatile(o, offset, expectedBits, Float.floatToRawIntBits(v + delta))); > return v; > } > > and likewise for the atomic get-and-set methods. > > Paul. > >> David >> ----- >> >>> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8158039-float-double-field-array-cas.jdk/webrev/ >>> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8158039-float-double-field-array-cas.hotspot/webrev/ >>> >>> These patches are based on those of for sub-word CAS >>> >>> https://bugs.openjdk.java.net/browse/JDK-8157726 >>> http://cr.openjdk.java.net/~shade/8157726/webrev.hs.03/ >>> http://cr.openjdk.java.net/~shade/8157726/webrev.jdk.03/ >>> >>> And the two patches combined expand the support of fields/arrays. >>> >>> >>> New float/double CAS methods are added to Unsafe that defer to int/long equivalents. Then the other atomic methods are built from weak CAS loops. >>> >>> No changes are required to HotSpot, but changes are required to the Unsafe tests in the hotspot repository. >>> >>> In general the changes to VHs and tests are minimal since it is triggered from changes to the generating scripts that now include float/double into the CAS category. >>> >>> There are some minor specification changes and a CCC has been initiated. >>> >>> JPRT tests results show no relevant failures for hotspot and core test sets. >>> >>> Thanks, >>> Paul. >>> > From paul.sandoz at oracle.com Thu Jun 2 15:25:48 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 2 Jun 2016 17:25:48 +0200 Subject: RFR 8158039 VarHandle float/double field/array access should support CAS/set/add atomics In-Reply-To: References: <23FAF71F-F8B9-4AD6-9BF3-896795540788@oracle.com> <6ed640e8-f581-e81d-3e77-ef47405f9618@oracle.com> Message-ID: <89EC54E9-2BC1-4994-BF72-99FC20F9729C@oracle.com> > On 2 Jun 2016, at 14:55, Vladimir Ivanov wrote: > > Paul, > > Leaving practicality aspect of float/double API aside... > >> I am concerned that the CAS loops could in some cases loop without termination: > > Can you elaborate? I don't see how it is possible with the proposed patch. > The key aspect is in the JavaDoc snippet in my previous email. > On Float.intBitsToFloat: > > *

Note that this method may not be able to return a > * {@code float} NaN with exactly same bit pattern as the > * {@code int} argument. IEEE 754 distinguishes between two > * kinds of NaNs, quiet NaNs and signaling NaNs. The > * differences between the two kinds of NaN are generally not > * visible in Java. Arithmetic operations on signaling NaNs turn > * them into quiet NaNs with a different, but often similar, bit > * pattern. However, on some processors merely copying a > * signaling NaN also performs that conversion. In particular, > * copying a signaling NaN to return it to the calling method may > * perform this conversion. So {@code intBitsToFloat} may > * not be able to return a {@code float} with a signaling NaN > * bit pattern. Consequently, for some {@code int} values, > * {@code floatToRawIntBits(intBitsToFloat(start))} may > * not equal {@code start}. Moreover, which > * particular bit patterns represent signaling NaNs is platform > * dependent; although all NaN bit patterns, quiet or signaling, > * must be in the NaN range identified above. > I dunno if it can happen on x86 [*], but from reading the above I presume it could theoretically happen on some other hardware (what exactly i do not know). Note that the loaded float value is passed to the weakCompareAndSwapFloatVolatile method as an argument. IIUC that might trigger the conversion from a signalling NaN to a quiet NaN, subtly changing the bits of the expected value that was loaded. Paul. [*] Here is a simple program to induce a different on x86 (at least on my machine). To induce that i am adding 0.0f to the float value. public class AllTheNaNs { public static void main(String[] args) { for (long bits = 0x7f800001; bits <= 0x7fffffff; bits++) { testBits((int) bits); } for (long bits = 0xff800001; bits <= 0xffffffff; bits++) { testBits((int) bits); } } static void testBits(int vbits) { float v = Float.intBitsToFloat(vbits); assert Float.isNaN(v); float vv = id(v); assert Float.isNaN(vv); int vvbits = Float.floatToRawIntBits(vv); if (vvbits != vbits) { System.out.println(Integer.toHexString(vbits) + " " + Integer.toHexString(vvbits) + " " + Float.valueOf(v).equals(Float.valueOf(vv)) + " " + Float.compare(v, vv)); } } static float id(float f) { return f + 0.0f; } } > Unless getFloatVolatile() or weakCompareAndSwapFloatVolatile() change the original value, it should not happen. And both functions preserve float value bits intact: > > + @ForceInline > + public final boolean weakCompareAndSwapFloatVolatile(Object o, long offset, > + float expected, > + float x) { > + return weakCompareAndSwapIntVolatile(o, offset, > + Float.floatToRawIntBits(expected), > + Float.floatToRawIntBits(x)); > + } > > Float.floatToRawIntBits() makes it safe, but with Float.intBitsToFloat() used infinite looping can happen for NaNs. > > Best regards, > Vladimir Ivanov > From paul.sandoz at oracle.com Thu Jun 2 15:29:58 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 2 Jun 2016 17:29:58 +0200 Subject: RFR 8158039 VarHandle float/double field/array access should support CAS/set/add atomics In-Reply-To: References: <23FAF71F-F8B9-4AD6-9BF3-896795540788@oracle.com> <6ed640e8-f581-e81d-3e77-ef47405f9618@oracle.com> <575021C2.7070509@cs.oswego.edu> Message-ID: > On 2 Jun 2016, at 14:41, Martin Buchholz wrote: > > You can find an AtomicDouble in jsr166 CVS > http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/jsr166e/extra/AtomicDouble.java?view=markup > and in guava > https://github.com/google/guava/blob/master/guava/src/com/google/common/util/concurrent/AtomicDouble.java > > I'm still in favor of putting it in openjdk. > Thanks, that is helpful. What pushed me over the edge in favour was the support for sub-word CAS. The float/double types are lonely and want to join the club as fully signed up members :-) I will produce another patch with fixes and better docs. Thanks, Paul. From martinrb at google.com Thu Jun 2 17:56:12 2016 From: martinrb at google.com (Martin Buchholz) Date: Thu, 2 Jun 2016 10:56:12 -0700 Subject: RFR 8158039 VarHandle float/double field/array access should support CAS/set/add atomics In-Reply-To: References: <23FAF71F-F8B9-4AD6-9BF3-896795540788@oracle.com> <6ed640e8-f581-e81d-3e77-ef47405f9618@oracle.com> <575021C2.7070509@cs.oswego.edu> Message-ID: I don't see any way that AtomicDouble could get into trouble with floating point weirdness. Users cannot provide arbitrary long bit patterns; they have to provide an actual java double. It encapsulates the existing advice of transforming double to long. I suppose someone could do atomicDouble.CAS(NaN, 1) and fail because we're storing a DIFFERENT NaN, but we have little sympathy. It's possible to collapse all the NaNs into the One True NaN on input, but I don't recommend it. On Thu, Jun 2, 2016 at 8:29 AM, Paul Sandoz wrote: > >> On 2 Jun 2016, at 14:41, Martin Buchholz wrote: >> >> You can find an AtomicDouble in jsr166 CVS >> http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/jsr166e/extra/AtomicDouble.java?view=markup >> and in guava >> https://github.com/google/guava/blob/master/guava/src/com/google/common/util/concurrent/AtomicDouble.java >> >> I'm still in favor of putting it in openjdk. >> > > Thanks, that is helpful. > > What pushed me over the edge in favour was the support for sub-word CAS. The float/double types are lonely and want to join the club as fully signed up members :-) > > I will produce another patch with fixes and better docs. > > Thanks, > Paul. From timo.kinnunen at gmail.com Thu Jun 2 18:19:50 2016 From: timo.kinnunen at gmail.com (timo.kinnunen at gmail.com) Date: Thu, 2 Jun 2016 20:19:50 +0200 Subject: RFR 8158039 VarHandle float/double field/array access shouldsupport CAS/set/add atomics In-Reply-To: <89EC54E9-2BC1-4994-BF72-99FC20F9729C@oracle.com> References: <23FAF71F-F8B9-4AD6-9BF3-896795540788@oracle.com> <6ed640e8-f581-e81d-3e77-ef47405f9618@oracle.com> <89EC54E9-2BC1-4994-BF72-99FC20F9729C@oracle.com> Message-ID: <575078c8.45271c0a.7e9a9.ffffebf5@mx.google.com> Hi, Regarding x86, I can induce an infinite loop in getAndAddFloat on my computer if I simulate getFloatVolatile with the following implementation: static float getFloatVolatile(Object o, long offset) { return -0.0f + Float.intBitsToFloat(((int[]) o)[(int) offset]); } Note the added sum with -0.0f. This simulates the case where storing or subsequently reading a local variable changes the NaN value. With this implementation the first (largest) NaN to hang is 0xffbfffff. Some other curiosities: Adding -0.0 leaves all non-NaN floats with identical raw bits, including the negative zero. This isn?t the case if positive zero is used. When positive zero was used every non-NaN except negative zero remained same. This method changes 8,388,606 of the NaNs and leaves 8,388,608 the same. -- Have a nice day, Timo Sent from Mail for Windows 10 From: Paul Sandoz Sent: Thursday, June 2, 2016 17:26 To: Vladimir Ivanov Cc: jdk9-dev; hotspot-dev developers Subject: Re: RFR 8158039 VarHandle float/double field/array access shouldsupport CAS/set/add atomics > On 2 Jun 2016, at 14:55, Vladimir Ivanov wrote: > > Paul, > > Leaving practicality aspect of float/double API aside... > >> I am concerned that the CAS loops could in some cases loop without termination: > > Can you elaborate? I don't see how it is possible with the proposed patch. > The key aspect is in the JavaDoc snippet in my previous email. > On Float.intBitsToFloat: > > *

Note that this method may not be able to return a > * {@code float} NaN with exactly same bit pattern as the > * {@code int} argument. IEEE 754 distinguishes between two > * kinds of NaNs, quiet NaNs and signaling NaNs. The > * differences between the two kinds of NaN are generally not > * visible in Java. Arithmetic operations on signaling NaNs turn > * them into quiet NaNs with a different, but often similar, bit > * pattern. However, on some processors merely copying a > * signaling NaN also performs that conversion. In particular, > * copying a signaling NaN to return it to the calling method may > * perform this conversion. So {@code intBitsToFloat} may > * not be able to return a {@code float} with a signaling NaN > * bit pattern. Consequently, for some {@code int} values, > * {@code floatToRawIntBits(intBitsToFloat(start))} may > * not equal {@code start}. Moreover, which > * particular bit patterns represent signaling NaNs is platform > * dependent; although all NaN bit patterns, quiet or signaling, > * must be in the NaN range identified above. > I dunno if it can happen on x86 [*], but from reading the above I presume it could theoretically happen on some other hardware (what exactly i do not know). Note that the loaded float value is passed to the weakCompareAndSwapFloatVolatile method as an argument. IIUC that might trigger the conversion from a signalling NaN to a quiet NaN, subtly changing the bits of the expected value that was loaded. Paul. [*] Here is a simple program to induce a different on x86 (at least on my machine). To induce that i am adding 0.0f to the float value. public class AllTheNaNs { public static void main(String[] args) { for (long bits = 0x7f800001; bits <= 0x7fffffff; bits++) { testBits((int) bits); } for (long bits = 0xff800001; bits <= 0xffffffff; bits++) { testBits((int) bits); } } static void testBits(int vbits) { float v = Float.intBitsToFloat(vbits); assert Float.isNaN(v); float vv = id(v); assert Float.isNaN(vv); int vvbits = Float.floatToRawIntBits(vv); if (vvbits != vbits) { System.out.println(Integer.toHexString(vbits) + " " + Integer.toHexString(vvbits) + " " + Float.valueOf(v).equals(Float.valueOf(vv)) + " " + Float.compare(v, vv)); } } static float id(float f) { return f + 0.0f; } } > Unless getFloatVolatile() or weakCompareAndSwapFloatVolatile() change the original value, it should not happen. And both functions preserve float value bits intact: > > + @ForceInline > + public final boolean weakCompareAndSwapFloatVolatile(Object o, long offset, > + float expected, > + float x) { > + return weakCompareAndSwapIntVolatile(o, offset, > + Float.floatToRawIntBits(expected), > + Float.floatToRawIntBits(x)); > + } > > Float.floatToRawIntBits() makes it safe, but with Float.intBitsToFloat() used infinite looping can happen for NaNs. > > Best regards, > Vladimir Ivanov > From Roger.Riggs at Oracle.com Mon Jun 6 13:55:07 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Mon, 6 Jun 2016 09:55:07 -0400 Subject: CFV: New JDK 9 Committer: Felix Yang In-Reply-To: <2b16fc92-ae12-3bf7-fbac-3b13d96a6757@oracle.com> References: <2b16fc92-ae12-3bf7-fbac-3b13d96a6757@oracle.com> Message-ID: <75ca884a-fa55-2cce-fdee-3ce8d8527dab@Oracle.com> I hereby nominate Felix Yang (xiaofeya) to JDK 9 Committer. Felix Yang is a leading engineer in Corelibs SQE team, he has been testing Java for more than 5 years. He spent the first 3 years developing tests for Java install (JDS), then moved to Corelibs SQE team in 2014 to develop tests for Oracle Java features. In the past year, he has been fixing test bugs and developing new tests for Jigsaw and other JDK 9 features. He has 18 contributions to OpenJDK[3], most significantly [4] Votes are due by June 20th, 2016.|| || Only current JDK 9 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].|| || Roger Riggs [1] http://openjdk.java.net/census [2] http://openjdk.java.net/projects/#committer-vote [3] http://hg.openjdk.java.net/jdk9/jdk9/jdk/log?revcount=2000&rev=felix.yang [4] 8078812: Test RMI with client and servers as modules http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/3785e222a8d0 8157931: jdk/internal/jrtfs/Basic.java fails with exploded builds http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/d8d6c5e0def5 8154543: NetworkInterfaceStreamTest.java fails intermittently after JDK-8146758 http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/dd6af52fc8aa 8141609: Need test for jrtfs that runs on JDK 8 to target a JDK 9 image http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/81b03502e5e7 8151352: jdk/test/sample fails with "effective library path is outside the test suite" http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/dbb0fd7f2a2b 8133704: java/net/DatagramSocket/SetDatagramSocketImplFactory/ADatagramSocket.java may fail with address already in use http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/f746a5e4a0f6 8140472: java/net/ipv6tests/TcpTest.java failed intermittently with java.net.BindException: Address already in use: NET_Bind http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/af7720682024 8130394: DatagramChannel tests need to be hardended to ignore stray datagrams http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/426582cc6ad0 8061442: Update jdk/tools tests to remove check for the "jre" directory http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/ab9c56c997e3 8048052: Permission tests for setFactory http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/d877cbb8e2a2 8043836: Need new tests for AES cipher http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/f63d1bbae1b9 From sundararajan.athijegannathan at oracle.com Mon Jun 6 13:56:12 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Mon, 6 Jun 2016 19:26:12 +0530 Subject: CFV: New JDK 9 Committer: Felix Yang In-Reply-To: <75ca884a-fa55-2cce-fdee-3ce8d8527dab@Oracle.com> References: <2b16fc92-ae12-3bf7-fbac-3b13d96a6757@oracle.com> <75ca884a-fa55-2cce-fdee-3ce8d8527dab@Oracle.com> Message-ID: <9bf1c989-eda6-bb08-d116-4e060f52ce62@oracle.com> Vote: yes -Sundar On 6/6/2016 7:25 PM, Roger Riggs wrote: > I hereby nominate Felix Yang (xiaofeya) to JDK 9 Committer. > > Felix Yang is a leading engineer in Corelibs SQE team, he has been > testing Java for more than 5 years. > He spent the first 3 years developing tests for Java install (JDS), > then moved to Corelibs SQE team in 2014 > to develop tests for Oracle Java features. > In the past year, he has been fixing test bugs and developing new > tests for Jigsaw and other JDK 9 features. > > He has 18 contributions to OpenJDK[3], most significantly [4] > > Votes are due by June 20th, 2016.|| > || > Only current JDK 9 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].|| > || > > Roger Riggs > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] > http://hg.openjdk.java.net/jdk9/jdk9/jdk/log?revcount=2000&rev=felix.yang > [4] > 8078812: Test RMI with client and servers as modules > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/3785e222a8d0 > 8157931: jdk/internal/jrtfs/Basic.java fails with exploded builds > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/d8d6c5e0def5 > 8154543: NetworkInterfaceStreamTest.java fails intermittently after > JDK-8146758 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/dd6af52fc8aa > 8141609: Need test for jrtfs that runs on JDK 8 to target a JDK 9 image > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/81b03502e5e7 > 8151352: jdk/test/sample fails with "effective library path is outside > the test suite" > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/dbb0fd7f2a2b > 8133704: > java/net/DatagramSocket/SetDatagramSocketImplFactory/ADatagramSocket.java > may fail with address already in use > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/f746a5e4a0f6 > 8140472: java/net/ipv6tests/TcpTest.java failed intermittently with > java.net.BindException: Address already in use: NET_Bind > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/af7720682024 > 8130394: DatagramChannel tests need to be hardended to ignore stray > datagrams > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/426582cc6ad0 > 8061442: Update jdk/tools tests to remove check for the "jre" directory > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/ab9c56c997e3 > 8048052: Permission tests for setFactory > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/d877cbb8e2a2 > 8043836: Need new tests for AES cipher > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/f63d1bbae1b9 > From jennifer.zuo at oracle.com Mon Jun 6 14:04:21 2016 From: jennifer.zuo at oracle.com (Jennifer Zuo) Date: Mon, 6 Jun 2016 10:04:21 -0400 Subject: CFV: New JDK 9 Committer: Felix Yang In-Reply-To: <9bf1c989-eda6-bb08-d116-4e060f52ce62@oracle.com> References: <2b16fc92-ae12-3bf7-fbac-3b13d96a6757@oracle.com> <75ca884a-fa55-2cce-fdee-3ce8d8527dab@Oracle.com> <9bf1c989-eda6-bb08-d116-4e060f52ce62@oracle.com> Message-ID: <575582E5.2090900@oracle.com> Vote: yes Jennifer On 6/6/2016 9:56 AM, Sundararajan Athijegannathan wrote: > Vote: yes > > -Sundar > > > On 6/6/2016 7:25 PM, Roger Riggs wrote: >> I hereby nominate Felix Yang (xiaofeya) to JDK 9 Committer. >> >> Felix Yang is a leading engineer in Corelibs SQE team, he has been >> testing Java for more than 5 years. >> He spent the first 3 years developing tests for Java install (JDS), >> then moved to Corelibs SQE team in 2014 >> to develop tests for Oracle Java features. >> In the past year, he has been fixing test bugs and developing new >> tests for Jigsaw and other JDK 9 features. >> >> He has 18 contributions to OpenJDK[3], most significantly [4] >> >> Votes are due by June 20th, 2016.|| >> || >> Only current JDK 9 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].|| >> || >> >> Roger Riggs >> >> [1] http://openjdk.java.net/census >> [2] http://openjdk.java.net/projects/#committer-vote >> [3] >> http://hg.openjdk.java.net/jdk9/jdk9/jdk/log?revcount=2000&rev=felix.yang >> [4] >> 8078812: Test RMI with client and servers as modules >> http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/3785e222a8d0 >> 8157931: jdk/internal/jrtfs/Basic.java fails with exploded builds >> http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/d8d6c5e0def5 >> 8154543: NetworkInterfaceStreamTest.java fails intermittently after >> JDK-8146758 >> http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/dd6af52fc8aa >> 8141609: Need test for jrtfs that runs on JDK 8 to target a JDK 9 image >> http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/81b03502e5e7 >> 8151352: jdk/test/sample fails with "effective library path is outside >> the test suite" >> http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/dbb0fd7f2a2b >> 8133704: >> java/net/DatagramSocket/SetDatagramSocketImplFactory/ADatagramSocket.java >> may fail with address already in use >> http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/f746a5e4a0f6 >> 8140472: java/net/ipv6tests/TcpTest.java failed intermittently with >> java.net.BindException: Address already in use: NET_Bind >> http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/af7720682024 >> 8130394: DatagramChannel tests need to be hardended to ignore stray >> datagrams >> http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/426582cc6ad0 >> 8061442: Update jdk/tools tests to remove check for the "jre" directory >> http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/ab9c56c997e3 >> 8048052: Permission tests for setFactory >> http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/d877cbb8e2a2 >> 8043836: Need new tests for AES cipher >> http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/f63d1bbae1b9 >> From xuelei.fan at oracle.com Mon Jun 6 14:24:46 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 6 Jun 2016 22:24:46 +0800 Subject: CFV: New JDK 9 Committer: Felix Yang In-Reply-To: <75ca884a-fa55-2cce-fdee-3ce8d8527dab@Oracle.com> References: <2b16fc92-ae12-3bf7-fbac-3b13d96a6757@oracle.com> <75ca884a-fa55-2cce-fdee-3ce8d8527dab@Oracle.com> Message-ID: Vote: Yes. Xuelei On 6/6/2016 9:55 PM, Roger Riggs wrote: > I hereby nominate Felix Yang (xiaofeya) to JDK 9 Committer. > > Felix Yang is a leading engineer in Corelibs SQE team, he has been > testing Java for more than 5 years. > He spent the first 3 years developing tests for Java install (JDS), then > moved to Corelibs SQE team in 2014 > to develop tests for Oracle Java features. > In the past year, he has been fixing test bugs and developing new tests > for Jigsaw and other JDK 9 features. > > He has 18 contributions to OpenJDK[3], most significantly [4] > > Votes are due by June 20th, 2016.|| > || > Only current JDK 9 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].|| > || > > Roger Riggs > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] > http://hg.openjdk.java.net/jdk9/jdk9/jdk/log?revcount=2000&rev=felix.yang > [4] > 8078812: Test RMI with client and servers as modules > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/3785e222a8d0 > 8157931: jdk/internal/jrtfs/Basic.java fails with exploded builds > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/d8d6c5e0def5 > 8154543: NetworkInterfaceStreamTest.java fails intermittently after > JDK-8146758 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/dd6af52fc8aa > 8141609: Need test for jrtfs that runs on JDK 8 to target a JDK 9 image > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/81b03502e5e7 > 8151352: jdk/test/sample fails with "effective library path is outside > the test suite" > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/dbb0fd7f2a2b > 8133704: > java/net/DatagramSocket/SetDatagramSocketImplFactory/ADatagramSocket.java may > fail with address already in use > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/f746a5e4a0f6 > 8140472: java/net/ipv6tests/TcpTest.java failed intermittently with > java.net.BindException: Address already in use: NET_Bind > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/af7720682024 > 8130394: DatagramChannel tests need to be hardended to ignore stray > datagrams > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/426582cc6ad0 > 8061442: Update jdk/tools tests to remove check for the "jre" directory > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/ab9c56c997e3 > 8048052: Permission tests for setFactory > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/d877cbb8e2a2 > 8043836: Need new tests for AES cipher > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/f63d1bbae1b9 > From michael.haupt at oracle.com Mon Jun 6 15:43:15 2016 From: michael.haupt at oracle.com (Michael Haupt) Date: Mon, 6 Jun 2016 17:43:15 +0200 Subject: CFV: New JDK 9 Committer: Felix Yang In-Reply-To: <75ca884a-fa55-2cce-fdee-3ce8d8527dab@Oracle.com> References: <2b16fc92-ae12-3bf7-fbac-3b13d96a6757@oracle.com> <75ca884a-fa55-2cce-fdee-3ce8d8527dab@Oracle.com> Message-ID: <13CFC29E-E075-4516-B9EB-189E063313E0@oracle.com> Vote: yes. Best, Michael > Am 06.06.2016 um 15:55 schrieb Roger Riggs : > I hereby nominate Felix Yang (xiaofeya) to JDK 9 Committer. -- Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331 200 7561 Oracle Java Platform Group | LangTools Team | Nashorn Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstra?e 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From stuart.marks at oracle.com Mon Jun 6 18:16:15 2016 From: stuart.marks at oracle.com (Stuart Marks) Date: Mon, 6 Jun 2016 11:16:15 -0700 Subject: CFV: New JDK 9 Committer: Felix Yang In-Reply-To: <75ca884a-fa55-2cce-fdee-3ce8d8527dab@Oracle.com> References: <2b16fc92-ae12-3bf7-fbac-3b13d96a6757@oracle.com> <75ca884a-fa55-2cce-fdee-3ce8d8527dab@Oracle.com> Message-ID: <5e1fe8f9-6b69-065c-4408-ec1ab8688e0a@oracle.com> Vote: yes On 6/6/16 6:55 AM, Roger Riggs wrote: > I hereby nominate Felix Yang (xiaofeya) to JDK 9 Committer. > > Felix Yang is a leading engineer in Corelibs SQE team, he has been testing Java > for more than 5 years. > He spent the first 3 years developing tests for Java install (JDS), then moved > to Corelibs SQE team in 2014 > to develop tests for Oracle Java features. > In the past year, he has been fixing test bugs and developing new tests for > Jigsaw and other JDK 9 features. > > He has 18 contributions to OpenJDK[3], most significantly [4] > > Votes are due by June 20th, 2016.|| > || > Only current JDK 9 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].|| > || > > Roger Riggs > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] http://hg.openjdk.java.net/jdk9/jdk9/jdk/log?revcount=2000&rev=felix.yang > [4] > 8078812: Test RMI with client and servers as modules > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/3785e222a8d0 > 8157931: jdk/internal/jrtfs/Basic.java fails with exploded builds > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/d8d6c5e0def5 > 8154543: NetworkInterfaceStreamTest.java fails intermittently after JDK-8146758 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/dd6af52fc8aa > 8141609: Need test for jrtfs that runs on JDK 8 to target a JDK 9 image > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/81b03502e5e7 > 8151352: jdk/test/sample fails with "effective library path is outside the test > suite" > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/dbb0fd7f2a2b > 8133704: > java/net/DatagramSocket/SetDatagramSocketImplFactory/ADatagramSocket.java may > fail with address already in use > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/f746a5e4a0f6 > 8140472: java/net/ipv6tests/TcpTest.java failed intermittently with > java.net.BindException: Address already in use: NET_Bind > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/af7720682024 > 8130394: DatagramChannel tests need to be hardended to ignore stray datagrams > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/426582cc6ad0 > 8061442: Update jdk/tools tests to remove check for the "jre" directory > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/ab9c56c997e3 > 8048052: Permission tests for setFactory > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/d877cbb8e2a2 > 8043836: Need new tests for AES cipher > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/f63d1bbae1b9 > From artem.smotrakov at oracle.com Mon Jun 6 18:35:52 2016 From: artem.smotrakov at oracle.com (Artem Smotrakov) Date: Mon, 6 Jun 2016 11:35:52 -0700 Subject: CFV: New JDK 9 Committer: Felix Yang In-Reply-To: <75ca884a-fa55-2cce-fdee-3ce8d8527dab@Oracle.com> References: <2b16fc92-ae12-3bf7-fbac-3b13d96a6757@oracle.com> <75ca884a-fa55-2cce-fdee-3ce8d8527dab@Oracle.com> Message-ID: <5755C288.1020206@oracle.com> Vote: yes Artem On 06/06/2016 06:55 AM, Roger Riggs wrote: > I hereby nominate Felix Yang (xiaofeya) to JDK 9 Committer. > > Felix Yang is a leading engineer in Corelibs SQE team, he has been > testing Java for more than 5 years. > He spent the first 3 years developing tests for Java install (JDS), > then moved to Corelibs SQE team in 2014 > to develop tests for Oracle Java features. > In the past year, he has been fixing test bugs and developing new > tests for Jigsaw and other JDK 9 features. > > He has 18 contributions to OpenJDK[3], most significantly [4] > > Votes are due by June 20th, 2016.|| > || > Only current JDK 9 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].|| > || > > Roger Riggs > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] > http://hg.openjdk.java.net/jdk9/jdk9/jdk/log?revcount=2000&rev=felix.yang > [4] > 8078812: Test RMI with client and servers as modules > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/3785e222a8d0 > 8157931: jdk/internal/jrtfs/Basic.java fails with exploded builds > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/d8d6c5e0def5 > 8154543: NetworkInterfaceStreamTest.java fails intermittently after > JDK-8146758 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/dd6af52fc8aa > 8141609: Need test for jrtfs that runs on JDK 8 to target a JDK 9 image > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/81b03502e5e7 > 8151352: jdk/test/sample fails with "effective library path is outside > the test suite" > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/dbb0fd7f2a2b > 8133704: > java/net/DatagramSocket/SetDatagramSocketImplFactory/ADatagramSocket.java > may fail with address already in use > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/f746a5e4a0f6 > 8140472: java/net/ipv6tests/TcpTest.java failed intermittently with > java.net.BindException: Address already in use: NET_Bind > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/af7720682024 > 8130394: DatagramChannel tests need to be hardended to ignore stray > datagrams > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/426582cc6ad0 > 8061442: Update jdk/tools tests to remove check for the "jre" directory > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/ab9c56c997e3 > 8048052: Permission tests for setFactory > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/d877cbb8e2a2 > 8043836: Need new tests for AES cipher > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/f63d1bbae1b9 > From huizhe.wang at oracle.com Mon Jun 6 19:45:08 2016 From: huizhe.wang at oracle.com (huizhe wang) Date: Mon, 06 Jun 2016 12:45:08 -0700 Subject: CFV: New JDK 9 Committer: Felix Yang In-Reply-To: <75ca884a-fa55-2cce-fdee-3ce8d8527dab@Oracle.com> References: <2b16fc92-ae12-3bf7-fbac-3b13d96a6757@oracle.com> <75ca884a-fa55-2cce-fdee-3ce8d8527dab@Oracle.com> Message-ID: <5755D2C4.3070706@oracle.com> Vote: yes Joe (joehw) On 6/6/2016 6:55 AM, Roger Riggs wrote: > I hereby nominate Felix Yang (xiaofeya) to JDK 9 Committer. From serguei.spitsyn at oracle.com Mon Jun 6 19:52:35 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 6 Jun 2016 12:52:35 -0700 Subject: CFV: New JDK 9 Committer: Felix Yang In-Reply-To: <75ca884a-fa55-2cce-fdee-3ce8d8527dab@Oracle.com> References: <2b16fc92-ae12-3bf7-fbac-3b13d96a6757@oracle.com> <75ca884a-fa55-2cce-fdee-3ce8d8527dab@Oracle.com> Message-ID: <5755D483.4090607@oracle.com> Vote: yes From alejandro.murillo at oracle.com Mon Jun 6 21:11:33 2016 From: alejandro.murillo at oracle.com (Alejandro Murillo) Date: Mon, 6 Jun 2016 15:11:33 -0600 Subject: jdk9-dev: HotSpot Message-ID: <17ed5ea1-5e4d-e40f-d6a6-67544ef904c0@oracle.com> jdk9-hs-2016-06-03 has been integrated into jdk9-dev. http://hg.openjdk.java.net/jdk9/dev/rev/346be2df0f5b http://hg.openjdk.java.net/jdk9/dev/corba/rev/a39131aafc51 http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/af6b4ad908e7 http://hg.openjdk.java.net/jdk9/dev/jaxp/rev/f8899b1884e2 http://hg.openjdk.java.net/jdk9/dev/jaxws/rev/342705d785ff http://hg.openjdk.java.net/jdk9/dev/jdk/rev/981ae344923f http://hg.openjdk.java.net/jdk9/dev/langtools/rev/203a9e1b82b6 http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/b1de131a3fed Component : VM Status : Go for integration Date : 06/06/2016 at 17:00 MSK Tested By : VM SQE &dmitry.fazunenko at oracle.com Bundles : 2016-06-03-163101.amurillo.jdk9-hs-2016-06-03-snapshot Testing: 0 new failures, 981 known failures, 520789 passed. Issues and Notes: No stoppers have been detected so far. Go for integration CRs for testing: 8137296: [JVMCI] Enable sharing of debug info by default in all configurations 8139703: [TESTBUG] compiler/jvmci/compilerToVM/MaterializeVirtualObjectTest fails using -Xcomp 8140594: Various minor code improvements (compiler) 8141149: [jittester] create Visitor for generating bytecode 8141635: Implement VarHandles/Unsafe intrinsics on POWER 8144826: [JVMCI] Remove jdk.vm.ci.hotspot.Stable and use jdk.internal.vm.annotation.Stable 8144856: fix assert in CompiledStaticCall::set_to_interpreted 8145148: InterfaceMethod CP entry pointing to a class should cause ICCE 8145247: incorrect comment in SystemDictionary::load_shared_class 8149463: [jittester] rarely generates tests with compile error 8150016: small typo in ciReplay code 8152207: Perform array bound checks while getting a length of bytecode instructions 8152311: [JVMCI] allow JVMCI compiler to change the compilation policy for a method 8152341: JVMCI test task: Unit tests for MemoryAccessProvider 8152342: JVMCI test task: Unit tests for MethodHandleAccessProvider 8152343: JVMCI test tasks: Unit tests for MetaAccessProvider 8152856: Xcode 7.3 -Wshift-negative-value compile failure on Mac OS X 8152950: BasicLauncherTest.java fails due to type error 8153352: Crash with assert(pd != 0L) failed: PcDesc must not be NULL 8153782: [JVMCI] update JVMCI sources to Eclipse 4.5.2 format style 8153792: EA: assert(ptn->as_LocalVar()->edge_count() > 0) failed: sanity when compiling compareAndExchange 8154096: Extend WhiteBox API with methods which retrieve from VM information about available GC 8154473: Update for CompilerDirectives to control stub generation and intrinsics 8154589: assert(k != NULL) failed: preloaded klass not initialized 8154831: CastII/ConvI2L for a range check is prematurely eliminated 8155023: jdk.vm.ci needs to securely export services 8155047: [JVMCI] findLeafConcreteSubtype should handle arrays of leaf concrete subtype 8155108: CompilerControl: tests incorrectly set states for excluded methods 8155241: Crash with assert in Xcomp mode and with disabled ReduceBulkZeroing 8155608: String intrinsic range checks are not strict enough 8155643: Java crash with assert in Xcomp mode and disabled ReduceInitialCardMarks 8155719: remove TrustedInterface from JVMCI 8155957: java.lang.IllegalAccessError: class (in unnamed module XXX) cannot access class jdk.internal.misc.Unsafe 8156025: [JVMCI] make HotSpotResolvedObjectTypeImpl.createField non-public 8156028: G1YoungGenSizer _adaptive_size not correct when setting NewSize and MaxNewSize to the same value 8156034: [JVMCI] Notify the jvmci compiler on completion of a bootstrap 8156156: Add module specific NMT MemoryType 8156159: replace CompilerToVM.readUncompressedOop with Unsafe.getUncompressedObject 8156211: [JVMCI] ResolvedJava* interfaces should extend AnnotatedElement 8156470: [JITtester] EOL on Windows 8156548: gc/gctests/StringInternSyncWithGC2 fails with Test level exit status: 151 8156552: [JVMCI] remove final and stable field handling from ConstantReflectionProvider 8156585: Cosmetic: AARCH64 defines in c1_LIRAssembler_aarch64.hpp 8156741: [JVMCI] remove LocationIdentity interface 8156768: [JVMCI] remove support for patching Symbol pointers 8156775: IGV: StringUtils is absent 8156835: [JVMCI] clean up and minimize JVMCI 8156922: [ppc] Implement template interpreter stack overflow checks as on x86/sparc. 8156942: [JVMCI] replace LIRKind with abstract base class 8157153: TestStressRSetCoarsening fails with OOM 8157175: GetNanoTimeAdjustment.java fails with excessive adjustment error 8157438: JVMCI: MaterializeVirtualObjectTest fails w/ "CASE: invalidate=true: has no virtual object before" 8157452: [TESTBUG] PLAB tests don't handle unexpected GC 8157555: com/sun/jdi/RedefineClearBreakpoint.sh times out due to Indify String Concat being slow in debug mode 8157560: Reserve space for allocation prefetch only in builds that support allocation prefetching 8157683: Thread.onSpinWait intrinsification doesn't have sufficient test coverage 8157716: jdk.internal.loader.ClassLoaders.addURLToUCP() should return converted real path URL. 8157717: MultiCommand breaks directives amount limit 8157834: aarch64: Hello World crashes with fastdebug build 8157841: aarch64: prefetch ignores cache line size 8158060: BasicLayerTest causes fatal error: Thread holding lock at safepoint that vm can block on: Module_lock 8158106: native/GTestWrapper.java gets SIGABR 8158150: LogConfiguration::describe output can get truncated -- Alejandro From claes.redestad at oracle.com Mon Jun 6 23:20:43 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Tue, 7 Jun 2016 01:20:43 +0200 Subject: CFV: New JDK 9 Reviewer: Michael Haupt In-Reply-To: References: Message-ID: <5756054B.4010405@oracle.com> Vote: yes /Claes On 2016-05-31 17:52, Jim Laskey (Oracle) wrote: > I hereby nominate Michael Haupt to JDK 9 Reviewer. From huaming.li at oracle.com Tue Jun 7 00:35:31 2016 From: huaming.li at oracle.com (Hamlin Li) Date: Tue, 7 Jun 2016 08:35:31 +0800 Subject: CFV: New JDK 9 Committer: Felix Yang In-Reply-To: <75ca884a-fa55-2cce-fdee-3ce8d8527dab@Oracle.com> References: <2b16fc92-ae12-3bf7-fbac-3b13d96a6757@oracle.com> <75ca884a-fa55-2cce-fdee-3ce8d8527dab@Oracle.com> Message-ID: <4ad6e4f0-4f68-cfa8-1e5c-3ce301ecb9d0@oracle.com> Vote: yes. -Halmin On 2016/6/6 21:55, Roger Riggs wrote: > I hereby nominate Felix Yang (xiaofeya) to JDK 9 Committer. > > Felix Yang is a leading engineer in Corelibs SQE team, he has been > testing Java for more than 5 years. > He spent the first 3 years developing tests for Java install (JDS), > then moved to Corelibs SQE team in 2014 > to develop tests for Oracle Java features. > In the past year, he has been fixing test bugs and developing new > tests for Jigsaw and other JDK 9 features. > > He has 18 contributions to OpenJDK[3], most significantly [4] > > Votes are due by June 20th, 2016.|| > || > Only current JDK 9 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].|| > || > > Roger Riggs > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] > http://hg.openjdk.java.net/jdk9/jdk9/jdk/log?revcount=2000&rev=felix.yang > [4] > 8078812: Test RMI with client and servers as modules > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/3785e222a8d0 > 8157931: jdk/internal/jrtfs/Basic.java fails with exploded builds > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/d8d6c5e0def5 > 8154543: NetworkInterfaceStreamTest.java fails intermittently after > JDK-8146758 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/dd6af52fc8aa > 8141609: Need test for jrtfs that runs on JDK 8 to target a JDK 9 image > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/81b03502e5e7 > 8151352: jdk/test/sample fails with "effective library path is outside > the test suite" > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/dbb0fd7f2a2b > 8133704: > java/net/DatagramSocket/SetDatagramSocketImplFactory/ADatagramSocket.java > may fail with address already in use > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/f746a5e4a0f6 > 8140472: java/net/ipv6tests/TcpTest.java failed intermittently with > java.net.BindException: Address already in use: NET_Bind > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/af7720682024 > 8130394: DatagramChannel tests need to be hardended to ignore stray > datagrams > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/426582cc6ad0 > 8061442: Update jdk/tools tests to remove check for the "jre" directory > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/ab9c56c997e3 > 8048052: Permission tests for setFactory > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/d877cbb8e2a2 > 8043836: Need new tests for AES cipher > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/f63d1bbae1b9 > From joe.darcy at oracle.com Tue Jun 7 00:47:18 2016 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Mon, 06 Jun 2016 17:47:18 -0700 Subject: RFR 8158039 VarHandle float/double field/array access should support CAS/set/add atomics In-Reply-To: References: <23FAF71F-F8B9-4AD6-9BF3-896795540788@oracle.com> <6ed640e8-f581-e81d-3e77-ef47405f9618@oracle.com> Message-ID: <57561996.4000501@oracle.com> Hello, Catching up on email, there are several different notions on floating-point equality one might want to use. [1] One notion is the built-in "==" operator on float and double. This has the wrinkle of not defining an equivalence relation because of NaN values (not reflexive) and signed zeros (distinguishable values compare as equal). When I write floating-point tests, I'll use a notion of equality close to Float.compare(x, y) == 0 which means all NaN values are treated as the same and Float.compare(NaN, NaN) == 0 is true. This also distinguishes the signed zeros from each other. So comparing based on the non-raw bitwise conversion can give resonable semantics, at the cost of not preserving any payload stored in the NaN significand. HTH, -Joe [1] "Notions of Floating-Point Equality ," https://blogs.oracle.com/darcy/entry/notions_of_floating_point_equality On 6/2/2016 1:34 AM, Paul Sandoz wrote: >> On 2 Jun 2016, at 09:13, David Holmes wrote: >> >> On 2/06/2016 1:24 AM, Paul Sandoz wrote: >>> (Please note this work is or will be covered with FC exception) >>> >>> Hi, >>> >>> Please review the VarHandles/Unsafe support for atomic ops on double/float fields/arrays. >> I think this is misguided. If the user wants CAS for float/double they can do the conversion to int/long in a context where they know that conversion makes sense and where they can deal with NaNs appropriately. >> > I would still like to support some clearly defined default behaviour if at all possible, since this is not easy to get right so we can add some value here. The user can use int/long if that behaviour is not suitable. > > >> At a minimum the fact this deals with raw bit patterns not semantic values needs to be exposed somehow. ie the handling of NaN needs to be explicit. >> > Yes, it?s multiple NaN values that collapse to a single NaN value. > > It would be good if our resident floating point expert Mr. Joe Darcy could chime in this respect. > > On Float.intBitsToFloat: > > *

Note that this method may not be able to return a > * {@code float} NaN with exactly same bit pattern as the > * {@code int} argument. IEEE 754 distinguishes between two > * kinds of NaNs, quiet NaNs and signaling NaNs. The > * differences between the two kinds of NaN are generally not > * visible in Java. Arithmetic operations on signaling NaNs turn > * them into quiet NaNs with a different, but often similar, bit > * pattern. However, on some processors merely copying a > * signaling NaN also performs that conversion. In particular, > * copying a signaling NaN to return it to the calling method may > * perform this conversion. So {@code intBitsToFloat} may > * not be able to return a {@code float} with a signaling NaN > * bit pattern. Consequently, for some {@code int} values, > * {@code floatToRawIntBits(intBitsToFloat(start))} may > * not equal {@code start}. Moreover, which > * particular bit patterns represent signaling NaNs is platform > * dependent; although all NaN bit patterns, quiet or signaling, > * must be in the NaN range identified above. > > > > I am concerned that the CAS loops could in some cases loop without termination: > > @ForceInline > public final float getAndAddFloat(Object o, long offset, float delta) { > float v; > do { > v = getFloatVolatile(o, offset); > } while (!weakCompareAndSwapFloatVolatile(o, offset, v, v + delta)); > return v; > } > > > I think this should be: > > @ForceInline > public final float getAndAddFloat(Object o, long offset, float delta) { > int expectedBits; > float v; > do { > expectedBits = getIntVolatile(o, offset); > v = Float.intBitsToFloat(bits); // May not preserve a NaN value with the same bit pattern as expectedBits > } while (!weakCompareAndSwapIntVolatile(o, offset, expectedBits, Float.floatToRawIntBits(v + delta))); > return v; > } > > and likewise for the atomic get-and-set methods. > > Paul. > >> David >> ----- >> >>> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8158039-float-double-field-array-cas.jdk/webrev/ >>> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8158039-float-double-field-array-cas.hotspot/webrev/ >>> >>> These patches are based on those of for sub-word CAS >>> >>> https://bugs.openjdk.java.net/browse/JDK-8157726 >>> http://cr.openjdk.java.net/~shade/8157726/webrev.hs.03/ >>> http://cr.openjdk.java.net/~shade/8157726/webrev.jdk.03/ >>> >>> And the two patches combined expand the support of fields/arrays. >>> >>> >>> New float/double CAS methods are added to Unsafe that defer to int/long equivalents. Then the other atomic methods are built from weak CAS loops. >>> >>> No changes are required to HotSpot, but changes are required to the Unsafe tests in the hotspot repository. >>> >>> In general the changes to VHs and tests are minimal since it is triggered from changes to the generating scripts that now include float/double into the CAS category. >>> >>> There are some minor specification changes and a CCC has been initiated. >>> >>> JPRT tests results show no relevant failures for hotspot and core test sets. >>> >>> Thanks, >>> Paul. >>> From weijun.wang at oracle.com Tue Jun 7 01:17:50 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Tue, 7 Jun 2016 09:17:50 +0800 Subject: CFV: New JDK 9 Committer: Felix Yang In-Reply-To: <75ca884a-fa55-2cce-fdee-3ce8d8527dab@Oracle.com> References: <2b16fc92-ae12-3bf7-fbac-3b13d96a6757@oracle.com> <75ca884a-fa55-2cce-fdee-3ce8d8527dab@Oracle.com> Message-ID: <2E1E09D9-B446-4572-A35C-9434049978AD@oracle.com> Vote: yes. --Weijun > On Jun 6, 2016, at 9:55 PM, Roger Riggs wrote: > > I hereby nominate Felix Yang (xiaofeya) to JDK 9 Committer. From szegedia at gmail.com Tue Jun 7 05:30:06 2016 From: szegedia at gmail.com (Attila Szegedi) Date: Mon, 6 Jun 2016 22:30:06 -0700 Subject: CFV: New JDK 9 Reviewer: Michael Haupt In-Reply-To: References: Message-ID: <5292D3AB-E6F5-4E46-88FB-E5BF93F1DFB4@gmail.com> Vote: yes > On 31 May 2016, at 08:52, Jim Laskey (Oracle) wrote: > > I hereby nominate Michael Haupt to JDK 9 Reviewer. From mandy.chung at oracle.com Wed Jun 8 05:31:27 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 7 Jun 2016 22:31:27 -0700 Subject: CFV: New JDK 9 Committer: Felix Yang In-Reply-To: <75ca884a-fa55-2cce-fdee-3ce8d8527dab@Oracle.com> References: <2b16fc92-ae12-3bf7-fbac-3b13d96a6757@oracle.com> <75ca884a-fa55-2cce-fdee-3ce8d8527dab@Oracle.com> Message-ID: <60E20A37-F4AF-4CED-8931-5C28C9C0F6F4@oracle.com> Vote: yes Mandy From sean.mullan at oracle.com Wed Jun 8 16:58:09 2016 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 8 Jun 2016 12:58:09 -0400 Subject: Result: New JDK 9 Committer: Rajan Halade Message-ID: <57584EA1.5030203@oracle.com> Voting for Rajan Halade [1] is now closed. Yes: 18 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. Sean Mullan [1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-May/004346.html From brent.christian at oracle.com Wed Jun 8 19:04:48 2016 From: brent.christian at oracle.com (Brent Christian) Date: Wed, 8 Jun 2016 12:04:48 -0700 Subject: CFV: New JDK 9 Committer: Felix Yang In-Reply-To: <75ca884a-fa55-2cce-fdee-3ce8d8527dab@Oracle.com> References: <2b16fc92-ae12-3bf7-fbac-3b13d96a6757@oracle.com> <75ca884a-fa55-2cce-fdee-3ce8d8527dab@Oracle.com> Message-ID: Vote: yes -Brent On 6/6/16 6:55 AM, Roger Riggs wrote: > I hereby nominate Felix Yang (xiaofeya) to JDK 9 Committer. > From pavel.rappo at oracle.com Wed Jun 8 19:31:04 2016 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Wed, 8 Jun 2016 20:31:04 +0100 Subject: CFV: New JDK 9 Committer: Felix Yang In-Reply-To: References: <2b16fc92-ae12-3bf7-fbac-3b13d96a6757@oracle.com> <75ca884a-fa55-2cce-fdee-3ce8d8527dab@Oracle.com> Message-ID: <5965FA5E-7329-44B6-8746-87A464206ECC@oracle.com> Vote: yes From daniil.x.titov at oracle.com Wed Jun 8 19:33:27 2016 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Wed, 8 Jun 2016 12:33:27 -0700 (PDT) Subject: Review Request: 8156960 Deprecate JSObject.getWindow(Applet) method Message-ID: <1f05a2b9-a68b-4684-a58a-163189c710af@default> Hello, Please review the fix for JDK 9. The fix adds @Deprecated annotation to netscape.javascript.JSObject.getWindow(Applet) method and ensures that netscape.javascript package is included in the generated docs. Bug: https://bugs.openjdk.java.net/browse/JDK-8156960 Webrev: http://cr.openjdk.java.net/~dtitov/8156960/jdk/webrev.00/ http://cr.openjdk.java.net/~dtitov/8156960/webrev.00/ Best regards, Daniil From lana.steuck at oracle.com Wed Jun 8 20:46:58 2016 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 8 Jun 2016 20:46:58 GMT Subject: jdk9-b122: dev Message-ID: <201606082046.u58KkwY0004153@scaaa563.us.oracle.com> http://hg.openjdk.java.net/jdk9/jdk9/rev/346be2df0f5b http://hg.openjdk.java.net/jdk9/jdk9/nashorn/rev/b1de131a3fed http://hg.openjdk.java.net/jdk9/jdk9/langtools/rev/203a9e1b82b6 http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/981ae344923f http://hg.openjdk.java.net/jdk9/jdk9/jaxws/rev/342705d785ff http://hg.openjdk.java.net/jdk9/jdk9/jaxp/rev/f8899b1884e2 http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/af6b4ad908e7 http://hg.openjdk.java.net/jdk9/jdk9/corba/rev/a39131aafc51 --- All the fixes will be tested during promotion (no PIT testing at this point): List of all fixes: =================== JDK-8158281 client-libs java_sql_Timestamp.java fails with AssertionError JDK-8158651 client-libs ConcurrentModification exceptions in httpclient JDK-5040830 core-libs (ann) please improve toString() for annotations containing exception p JDK-8059361 core-libs (spec) Properties.stringPropertyNames() returns a set inconsistent wit JDK-8061777 core-libs (zipfs) IllegalArgumentException in ZipCoder.toString when using Shitf JDK-8066258 core-libs Re-examine com.sun.nio.file to see if it should be a supported API JDK-8072099 core-libs Format "ha" is unable to parse hours 10-12 JDK-8074819 core-libs Resolve disabled warnings for libzip JDK-8085785 core-libs sun/net/www/protocol/http/ZoneId.java times out intermittently JDK-8145136 core-libs Upgrade CLDR locale data JDK-8146156 core-libs Inconsistent default locale in string formatter methods JDK-8148457 core-libs Remove jdk.nashorn.tools.FXShell class JDK-8151876 core-libs (tz) Support tzdata2016d JDK-8154189 core-libs Deprivilege java.sql and java.sql.rowset module JDK-8154980 core-libs Remove intermittent key from test BandIntegrity.java JDK-8156868 core-libs MethodHandles.zero(Class) doc issues JDK-8157716 core-libs jdk.internal.loader.ClassLoaders.addURLToUCP() should return converted JDK-8157777 core-libs TEST_BUG: DeadCachedConnection doesn't wait for registry to die JDK-8157816 core-libs Mark 4 httpclient tests as intermittently failing JDK-8157850 core-libs Jar tests should pass through VM options JDK-8157892 core-libs StackFrame::getFileName returns null when a source file exists for nat JDK-8158025 core-libs Typo in java.util.Locale JDK-8158044 core-libs Add test that checks uri of upgradeable modules JDK-8158131 core-libs Nashorn should not use jdk.internal.module.Modules API JDK-8158171 core-libs MethodHandles.dropArgumentsToMatch(...) non-documented IAE JDK-8158250 core-libs nashorn ant javadoc targets are broken JDK-8158254 core-libs Put java/time/test/java/time/TestClock_System on the problem list for JDK-8158312 core-libs Update String.join example code to use List convenience factory method JDK-8158338 core-libs Nashorn's ScriptLoader split delegation has to be adjusted JDK-8158430 core-libs Push tests for JDK-5040830 JDK-8158467 core-libs AccessControlException is thrown on public Java class access if "scrip JDK-8158482 core-libs regex UNICODE_CHARACTER_CLASS flag cannot be disabled with an embedded JDK-8158525 core-libs Update a few java/net tests to use the loopback address instead of the JDK-8158551 core-libs BigDecimal.sqrt javadoc typo JDK-8158560 core-libs Mark java/rmi/transport/dgcDeadLock/DGCDeadLock.java as intermittently JDK-8158604 core-libs test/java/util/ResourceBundle/modules/appbasic missing @test JDK-8158736 core-libs Adapter class loaders can avoid creating named dynamic modules JDK-8157555 core-svc com/sun/jdi/RedefineClearBreakpoint.sh times out due to Indify String JDK-8135322 hotspot ConstantPool::release_C_heap_structures not run in some circumstances JDK-8137296 hotspot [JVMCI] Enable sharing of debug info by default in all configurations JDK-8139703 hotspot [TESTBUG] compiler/jvmci/compilerToVM/MaterializeVirtualObjectTest fai JDK-8140594 hotspot Various minor code improvements (compiler) JDK-8141149 hotspot [jittester] create Visitor for generating bytecode JDK-8141635 hotspot Implement VarHandles/Unsafe intrinsics on POWER JDK-8144826 hotspot [JVMCI] Remove jdk.vm.ci.hotspot.Stable and use jdk.internal.vm.annota JDK-8144856 hotspot fix assert in CompiledStaticCall::set_to_interpreted JDK-8145148 hotspot InterfaceMethod CP entry pointing to a class should cause ICCE JDK-8145247 hotspot incorrect comment in SystemDictionary::load_shared_class JDK-8149463 hotspot [jittester] rarely generates tests with compile error JDK-8149901 hotspot [Solaris] Use of -XX:+UseThreadPriorities crashes fastdebug JDK-8150016 hotspot small typo in ciReplay code JDK-8151805 hotspot fatal error: heap walk aborted with error 1 JDK-8152207 hotspot Perform array bound checks while getting a length of bytecode instruct JDK-8152311 hotspot [JVMCI] allow JVMCI compiler to change the compilation policy for a me JDK-8152341 hotspot JVMCI test task: Unit tests for MemoryAccessProvider JDK-8152342 hotspot JVMCI test task: Unit tests for MethodHandleAccessProvider JDK-8152343 hotspot JVMCI test tasks: Unit tests for MetaAccessProvider JDK-8152856 hotspot Xcode 7.3 -Wshift-negative-value compile failure on Mac OS X JDK-8152950 hotspot BasicLauncherTest.java fails due to type error JDK-8153352 hotspot Crash with assert(pd != 0L) failed: PcDesc must not be NULL JDK-8153582 hotspot Logging of ConcGCThreads is done too early JDK-8153723 hotspot Change the default logging output for errors and warnings from stderr JDK-8153782 hotspot [JVMCI] update JVMCI sources to Eclipse 4.5.2 format style JDK-8153792 hotspot EA: assert(ptn->as_LocalVar()->edge_count() > 0) failed: sanity when c JDK-8154096 hotspot Extend WhiteBox API with methods which retrieve from VM information ab JDK-8154473 hotspot Update for CompilerDirectives to control stub generation and intrinsic JDK-8154589 hotspot assert(k != NULL) failed: preloaded klass not initialized JDK-8154787 hotspot gc/g1/Test2GbHeap.java fails with java.lang.RuntimeException JDK-8154831 hotspot CastII/ConvI2L for a range check is prematurely eliminated JDK-8155023 hotspot [JVMCI] jdk.vm.ci needs to securely export services JDK-8155047 hotspot [JVMCI] findLeafConcreteSubtype should handle arrays of leaf concrete JDK-8155108 hotspot CompilerControl: Enable option set incorrectly JDK-8155241 hotspot Crash with assert in Xcomp mode and with disabled ReduceBulkZeroing JDK-8155608 hotspot String intrinsic range checks are not strict enough JDK-8155643 hotspot Java crash with assert in Xcomp mode and disabled ReduceInitialCardMar JDK-8155719 hotspot remove TrustedInterface from JVMCI JDK-8155945 hotspot JavaStatisticsThrowables is called JavaStaticsThrowables in JFC files JDK-8155957 hotspot java.lang.IllegalAccessError: class (in unnamed module XXX) cann JDK-8156025 hotspot [JVMCI] make HotSpotResolvedObjectTypeImpl.createField non-public JDK-8156028 hotspot G1YoungGenSizer _adaptive_size not correct when setting NewSize and Ma JDK-8156034 hotspot [JVMCI] Notify the jvmci compiler on completion of a bootstrap JDK-8156156 hotspot Add module specific NMT MemoryType JDK-8156159 hotspot replace CompilerToVM.readUncompressedOop with Unsafe.getUncompressedOb JDK-8156211 hotspot [JVMCI] ResolvedJava* interfaces should extend AnnotatedElement JDK-8156470 hotspot [JITtester] EOL on Windows JDK-8156548 hotspot gc/gctests/StringInternSyncWithGC2 fails with Test level exit status: JDK-8156552 hotspot [JVMCI] remove final and stable field handling from ConstantReflection JDK-8156585 hotspot Cosmetic: AARCH64 defines in c1_LIRAssembler_aarch64.hpp JDK-8156741 hotspot [JVMCI] remove LocationIdentity interface JDK-8156768 hotspot [JVMCI] remove support for patching Symbol pointers JDK-8156775 hotspot IGV: StringUtils is absent JDK-8156777 hotspot [TESTBUG] test/testlibrary_tests/SimpleClassFileLoadHookTest.java requ JDK-8156835 hotspot [JVMCI] clean up and minimize JVMCI JDK-8156922 hotspot [ppc] Implement template interpreter stack overflow checks as on x86/s JDK-8156942 hotspot [JVMCI] replace LIRKind with abstract base class JDK-8157090 hotspot SharedArchiveFile/SpaceUtilizationCheck.java fails as space utilizatio JDK-8157153 hotspot TestStressRSetCoarsening fails with OOM JDK-8157188 hotspot 2 test failures in demo/jvmti due to unexpected class file version 53 JDK-8157284 hotspot nsk/jvmti/PopFrame/popframe005 generates hundreds of unexpected events JDK-8157325 hotspot gtest tests are not excluded for minimal builds JDK-8157438 hotspot JVMCI: MaterializeVirtualObjectTest fails w/ "CASE: invalidate=true: h JDK-8157452 hotspot [TESTBUG] PLAB tests don't handle unexpected GC JDK-8157560 hotspot Reserve space for allocation prefetch only in builds that support allo JDK-8157683 hotspot Thread.onSpinWait intrinsification doesn't have sufficient test covera JDK-8157717 hotspot MultiCommand breaks directives amount limit JDK-8157834 hotspot aarch64: Hello World crashes with fastdebug build JDK-8157841 hotspot aarch64: prefetch ignores cache line size JDK-8158060 hotspot BasicLayerTest causes fatal error: Thread holding lock at safepoint th JDK-8158106 hotspot native/GTestWrapper.java gets SIGABRT JDK-8158150 hotspot LogConfiguration::describe output can get truncated JDK-8154469 infrastructure Update FSF address JDK-8158540 infrastructure Open only linux-x86 builds using Jib fails when building "minimal" jvm JDK-8158553 javafx Remove testrpath.sh from the problem list JDK-8152108 security-libs Correct jarsigner warning message about missing timestamp JDK-8156059 security-libs Test Task: Update/Develop new tests for JEP 287: SHA-3 Hash Algorithms JDK-8158111 security-libs Make handling of 3rd party providers more stable JDK-8037947 tools functional interface causes ClassCastException when extending raw supe JDK-8080843 tools JShell tool: invalid key error occurs when external editor is used. JDK-8131024 tools JShell: multi-line comment not detected as incomplete JDK-8131029 tools JShell: recover from VMConnection launch failure JDK-8145489 tools NPE while compiling annotations with qualified names in package-info.j JDK-8146167 tools Anonymous type declarations drop supertype type parameter annotations JDK-8152062 tools obscure error message for bad 'provides' JDK-8152721 tools Java Web Start splash mechanism is not working in JDK9 JDK-8157975 tools Remove duplicate files in sample API JDK-8158149 tools test bug for SystemModuleFinder when fast path is supported JDK-8158190 tools Add test that checks -Xpatch with both Jar and exploded patches JDK-8158194 tools Rename the directory ???InstalledModuleDescriptors??? and any referenc JDK-8158355 tools Inference graph dot support broken JDK-8158451 tools Problem list IncludeLocalesPluginTest.java JDK-8158559 tools Fix for 8132216 breaks langtools build JDK-8150187 xml NPE expected if the system identifier is null for CatalogResolver JDK-8153944 xml wsimport and wsgen usage messages not printed JDK-8158246 xml Several api/org_xml/sax/helpers/XMLReader tests failed due to no SAXEx From mandy.chung at oracle.com Wed Jun 8 19:41:59 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 8 Jun 2016 12:41:59 -0700 Subject: Review Request: 8156960 Deprecate JSObject.getWindow(Applet) method In-Reply-To: <1f05a2b9-a68b-4684-a58a-163189c710af@default> References: <1f05a2b9-a68b-4684-a58a-163189c710af@default> Message-ID: The client team owns jdk.jsobject module and so I add awt-dev to this thread. And bcc jdk9-dev. It is not Java SE API and it should not add to CORE-PKGS.gmk. As for @Deprecated, I believe the plan is to remove the getWindows method in a future release. Kevin and Dave can confirm. Mandy > On Jun 8, 2016, at 12:33 PM, Daniil Titov wrote: > > Hello, > > > > Please review the fix for JDK 9. > > > > The fix adds @Deprecated annotation to netscape.javascript.JSObject.getWindow(Applet) method and ensures that netscape.javascript package is included in the generated docs. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8156960 > > > > Webrev: http://cr.openjdk.java.net/~dtitov/8156960/jdk/webrev.00/ > > http://cr.openjdk.java.net/~dtitov/8156960/webrev.00/ > > > > > > Best regards, > > Daniil From kumar.x.srinivasan at oracle.com Thu Jun 9 14:12:20 2016 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Thu, 09 Jun 2016 07:12:20 -0700 Subject: CFV: New JDK 9 Reviewer: Michael Haupt In-Reply-To: References: Message-ID: <57597944.6080808@oracle.com> Vote: yes On 5/31/2016 8:52 AM, Jim Laskey (Oracle) wrote: > I hereby nominate Michael Haupt to JDK 9 Reviewer. > > Michael is a member to the Nashorn team; his focus is on dynamic language implementations. He also collaborates with the Valhalla project for value types. Prior to joining Nashorn, Michael worked briefly in the HotSpot compiler team. He has been an Oracle employee since 2011, which is when he joined the Virtual Machine Research Group at Oracle Labs, where he has worked on the Maxine meta-circular JVM and on dynamic language implementations. He used to be the tech lead of the FastR project, a high-performance Java-based implementation of the R programming language. Michael has also contributed to the Invokedynamic infrastructure in the past. > > Votes are due by June 15, 2016 > > Only current JDK9 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]. > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > > Michael?s contributions: > > === JDK 9 > > *** JSR 292 > > changeset: 14592:80f1fb052dee > user: mhaupt > date: Tue May 24 09:13:47 2016 +0200 > summary: 8157590: MethodHandles.arrayLength() lacks @since tag, implementation throws wrong exception > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/80f1fb052dee > > changeset: 14495:fd39cefc5c8f > user: mhaupt > date: Wed May 18 10:42:29 2016 +0200 > summary: 8156915: introduce MethodHandle factory for array length > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/fd39cefc5c8f > > changeset: 14301:c0e1a94f27f5 > user: mhaupt > date: Wed Apr 27 20:18:49 2016 +0200 > summary: 8155106: MHs.Lookup.findConstructor returns handles for array classes > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/c0e1a94f27f5 > > changeset: 14298:5a48729a7eb6 > user: mhaupt > date: Wed Apr 27 15:01:21 2016 +0200 > summary: 8155214: java/lang/invoke/PermuteArgsTest.java fails due to exhausted code cache > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/5a48729a7eb6 > > changeset: 14276:e8217d94b72e > user: mhaupt > date: Fri Apr 22 15:05:54 2016 +0200 > summary: 8154754: MethodHandles.countedLoop errors in deriving loop arguments, result type, and local state > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/e8217d94b72e > > changeset: 14275:14065c26ea1a > user: mhaupt > date: Fri Apr 22 15:05:26 2016 +0200 > summary: 8154751: MethodHandles.countedLoop does not accept empty bodies > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/14065c26ea1a > > changeset: 14274:beac9a439d0f > user: mhaupt > date: Fri Apr 22 13:36:22 2016 +0200 > summary: 8152667: MHs.iteratedLoop(...) throws unexpected WMTE, disallows Iterator subclasses, generates inconsistent loop result type > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/beac9a439d0f > > changeset: 14210:214c1ee32e00 > user: mhaupt > date: Tue Apr 19 14:39:35 2016 +0200 > summary: 8150956: j.l.i.MethodHandles.whileLoop(...) and .iteratedLoop(...) throw unexpected exceptions in the case of 'init' return type is void > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/214c1ee32e00 > > changeset: 14169:210cce63ef9c > user: mhaupt > date: Thu Apr 14 15:18:42 2016 +0200 > summary: 8150824: Exceptions when omitting trailing arguments in cleanup > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/210cce63ef9c > > changeset: 14152:fe806038ae74 > user: mhaupt > date: Wed Apr 13 09:20:22 2016 +0200 > summary: 8153637: MethodHandles.countedLoop/3 initialises loop counter to 1 instead of 0 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/fe806038ae74 > > changeset: 13903:d14f551f4d52 > user: mhaupt > date: Mon Mar 14 08:10:44 2016 +0100 > summary: 8151778: TestLookup.java fails after push of JDK-8150782 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/d14f551f4d52 > > changeset: 13902:25e8c082d7ef > user: mhaupt > date: Sun Mar 13 20:26:29 2016 +0100 > summary: 8150782: findClass / accessClass throw unexpected exceptions > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/25e8c082d7ef > > changeset: 13805:e941d983c8e4 > user: mhaupt > date: Thu Mar 03 14:29:00 2016 +0100 > summary: 8150957: j.l.i.MethodHandles.whileLoop(...) fails with IOOBE in the case init is null, step and pred have parameters > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/e941d983c8e4 > > changeset: 13799:c48cb760984f > user: mhaupt > date: Wed Mar 02 20:36:00 2016 +0100 > summary: 8150832: split T8139885 into several tests by functionality > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/c48cb760984f > > changeset: 13798:a24ddbbc4beb > user: mhaupt > date: Wed Mar 02 20:16:11 2016 +0100 > summary: 8150635: j.l.i.MethodHandles.loop(...) throws IndexOutOfBoundsException > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/a24ddbbc4beb > > changeset: 13796:8c2194ad4ca3 > user: mhaupt > date: Wed Mar 02 14:15:15 2016 +0100 > summary: 8150953: j.l.i.MethodHandles: example section in whileLoop(...) provides example for doWhileLoop > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/8c2194ad4ca3 > > changeset: 13790:42794e648cfe > user: mhaupt > date: Mon Feb 29 14:16:20 2016 +0100 > summary: 8150825: MethodHandles.tryFinally throws IndexOutOfBoundsException for non-conforming parameter lists > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/42794e648cfe > > changeset: 13767:9d536355b828 > user: mhaupt > date: Tue Feb 23 09:49:04 2016 +0100 > summary: 8143410: augment pseudo-code descriptions in MethodHandles API > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/9d536355b828 > > changeset: 13765:4d1292a702b8 > user: mhaupt > date: Tue Feb 23 07:17:54 2016 +0100 > summary: 8150360: augment/correct MethodHandle API documentation > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/4d1292a702b8 > > changeset: 13474:1de1a321ea87 > user: mhaupt > date: Wed Dec 09 11:02:54 2015 +0000 > summary: 8081512: Remove sun.invoke.anon classes, or move / co-locate them with tests > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/1de1a321ea87 > > changeset: 13458:f5d02fbd8095 > user: mhaupt > date: Thu Jan 14 13:53:13 2016 +0100 > summary: 8147078: MethodHandles.catchException does not enforce Throwable subtype > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/f5d02fbd8095 > > changeset: 13443:5be075daee3a > user: mhaupt > date: Mon Jan 11 17:19:16 2016 +0100 > summary: 8146786: [TESTBUG] straighten out testability for several issues > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/5be075daee3a > > changeset: 13255:4d010a9bd0d9 > user: mhaupt > date: Thu Dec 03 15:36:20 2015 +0100 > summary: 8143343: add JEP 274 Javadoc tests to JavaDocExamplesTest > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/4d010a9bd0d9 > > changeset: 13254:d41609429f2e > user: mhaupt > date: Thu Dec 03 15:34:39 2015 +0100 > summary: 8072844: Use more efficient LambdaForm type representation > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/d41609429f2e > > changeset: 13176:33c6cca30255 > user: mhaupt > date: Wed Dec 02 10:59:03 2015 +0100 > summary: 8076596: BytecodeDescriptor.parseMethod doesn't work during bootstrapping > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/33c6cca30255 > > changeset: 13124:ff8ce38663d9 > user: mhaupt > date: Wed Nov 25 09:23:07 2015 +0100 > summary: 8143798: jck failures: api/java_lang/invoke/MethodHandle/index_MethodsTests[asSpreaderWMTE]: java.lang.VerifyError: Bad type on operand stack > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/ff8ce38663d9 > > changeset: 13109:957e4e29ff28 > user: mhaupt > date: Fri Nov 20 15:34:12 2015 +0100 > summary: 8139885: implement JEP 274: enhanced method handles > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/957e4e29ff28 > > changeset: 12962:0f6c981f1cbf > user: mhaupt > date: Tue Oct 27 09:09:37 2015 +0100 > summary: 8136967: revert all changes applied to obtain information about 8131129 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/0f6c981f1cbf > > changeset: 12789:69f78bcd65f8 > user: mhaupt > date: Wed Sep 23 08:43:51 2015 +0200 > summary: 8136931: more fine-grained condition checking for BMH species creation > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/69f78bcd65f8 > > changeset: 12415:2919a03653a8 > user: mhaupt > date: Fri Jul 17 08:10:41 2015 +0200 > summary: 8062543: Replace uses of MethodHandleImpl.castReference with Class.cast > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/2919a03653a8 > > changeset: 8369:465e5b2bb615 > user: acorn > date: Fri May 08 14:00:24 2015 -0400 > summary: 8030680: 292 cleanup from default method code assessment > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/465e5b2bb615 > > changeset: 11850:e0ac3e9decb0 > user: mhaupt > date: Tue Apr 14 18:26:01 2015 +0300 > summary: 8033465: JSR292: InvokerBytecodeGenerator: convert a check for REF_invokeVirtual on an interface into an assert > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/e0ac3e9decb0 > > changeset: 5688:050116960e99 > user: twisti > date: Tue Jul 24 10:47:44 2012 -0700 > summary: 7023639: JSR 292 method handle invocation needs a fast path for compiled code > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/050116960e99 > > *** nashorn > > changeset: 1699:141d0cf2c12e > user: mhaupt > date: Fri May 20 16:02:36 2016 +0200 > summary: 8157444: exclude jjs shebang handling test from runs > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/141d0cf2c12e > > changeset: 1692:7099f590cdec > user: mhaupt > date: Wed May 18 17:37:34 2016 +0200 > summary: 8157250: BeanLinker assumes fixed array type linkage > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/7099f590cdec > > changeset: 1690:c187d75b77aa > user: mhaupt > date: Wed May 18 12:07:54 2016 +0200 > summary: 8157225: adopt method handle for array length getter in BeanLinker > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/c187d75b77aa > > changeset: 1663:ba21793a0e48 > user: mhaupt > date: Mon Apr 11 18:10:30 2016 +0200 > summary: 8137149: add tests for issues closed during Nashorn issue cleanup > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/ba21793a0e48 > > changeset: 1637:11811302fe75 > user: mhaupt > date: Wed Mar 09 15:15:29 2016 +0100 > summary: 8151518: relax test requirements to reduce dependency on directory contents > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/11811302fe75 > > changeset: 1636:f27bb66ac9d3 > user: mhaupt > date: Wed Mar 09 13:24:01 2016 +0100 > summary: 8151291: $EXEC yields "unknown command" on Cygwin > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/f27bb66ac9d3 > > changeset: 1633:58409eff7e3e > user: mhaupt > date: Mon Feb 29 09:49:46 2016 +0100 > summary: 8150814: correct package declaration in Nashorn test > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/58409eff7e3e > > changeset: 1626:221378857767 > user: mhaupt > date: Tue Feb 16 15:34:27 2016 +0100 > summary: 8148140: arguments are handled differently in apply for JS functions and AbstractJSObjects > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/221378857767 > > changeset: 1624:cfb316745693 > user: mhaupt > date: Fri Feb 12 17:00:54 2016 +0100 > summary: 8149744: fix testng.jar delivery in Nashorn build.xml > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/cfb316745693 > > changeset: 1619:7ac82655d829 > user: mhaupt > date: Tue Feb 09 14:14:06 2016 +0100 > summary: 8149462: revert changes for 8149186 > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/7ac82655d829 > > changeset: 1618:4e9749cc32f1 > user: mhaupt > date: Mon Feb 08 17:43:02 2016 +0100 > summary: 8149334: JSON.parse(JSON.stringify([])).push(10) creates an array containing two elements > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/4e9749cc32f1 > > changeset: 1611:0da44ab8c417 > user: mhaupt > date: Thu Jan 28 11:20:44 2016 +0100 > summary: 8147591: Revisit Collection.toArray(new T[size]) calls in nashorn and dynalink code > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/0da44ab8c417 > > changeset: 1607:b3c945675e8c > user: mhaupt > date: Fri Jan 22 11:12:26 2016 +0100 > summary: 8134933: re-enable LambdaFormEditor assertions in Nashorn testing > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/b3c945675e8c > > changeset: 1602:086c19a36be6 > user: mhaupt > date: Wed Jan 20 09:56:29 2016 +0100 > summary: 8144113: enable jjs testing > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/086c19a36be6 > > changeset: 1601:981b353f2f75 > user: mhaupt > date: Mon Jan 18 11:31:43 2016 +0100 > summary: 8145305: fix Nashorn shebang handling on Cygwin > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/981b353f2f75 > > changeset: 1594:0f21903deef8 > user: mhaupt > date: Thu Jan 14 10:55:26 2016 +0100 > summary: 8036977: Make process singleton options to be context wide > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/0f21903deef8 > > changeset: 1568:5fed6b47d01a > user: mhaupt > date: Mon Dec 14 14:02:59 2015 +0100 > summary: 8144221: fix Nashorn shebang argument handling on Mac/Linux > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/5fed6b47d01a > > changeset: 1525:d98fe27f6ba9 > user: mhaupt > date: Thu Nov 26 12:01:41 2015 +0100 > summary: 8143642: Nashorn shebang argument handling is broken > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/d98fe27f6ba9 > > changeset: 1520:d2eb81e4ddc8 > user: mhaupt > date: Thu Nov 19 11:28:34 2015 +0100 > summary: 8143297: Nashorn compilation time reported in nanoseconds > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/d2eb81e4ddc8 > > changeset: 1488:1ceda730b9a3 > user: mhaupt > date: Thu Oct 29 11:37:48 2015 +0100 > summary: 8140759: add ES6 template literal test > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/1ceda730b9a3 > > changeset: 1487:6d9a3ef84ebf > user: mhaupt > date: Wed Oct 28 10:54:05 2015 +0100 > summary: 8134941: Implement ES6 template literal support > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/6d9a3ef84ebf > > changeset: 1462:6c6df82265f0 > user: mhaupt > date: Mon Oct 12 13:36:41 2015 +0200 > summary: 8139266: add JSAdapter example with fallthrough > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/6c6df82265f0 > > changeset: 1456:446625d6e8cc > user: mhaupt > date: Wed Oct 07 15:02:15 2015 +0200 > summary: 8139047: add test for JSAdapter __getIds__ > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/446625d6e8cc > > changeset: 1455:11b48db399bf > user: mhaupt > date: Wed Oct 07 14:00:45 2015 +0200 > summary: 8139038: cleanup and documentation around JSAdapter > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/11b48db399bf > > changeset: 1392:d61744c0d1d2 > user: mhaupt > date: Wed Aug 26 13:11:35 2015 +0200 > summary: 8134484: disallow backquotes as heredoc end marker delimiters > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/d61744c0d1d2 > > changeset: 1391:5efd65e18b71 > user: mhaupt > date: Wed Aug 26 09:59:29 2015 +0200 > summary: 8073613: Here documents: how to avoid string interpolation? > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/5efd65e18b71 > > changeset: 1379:6060f7652a28 > user: mhaupt > date: Tue Aug 18 09:13:46 2015 -0700 > summary: 8077168: CodeStoreAndPathTest.java fails in jtreg mode on Mac > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/6060f7652a28 > > changeset: 1363:9fddd7695ded > user: mhaupt > date: Mon Jul 27 09:42:09 2015 +0200 > summary: 8132305: fix incorrect title assignment in Nashorn JavaFX samples > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/9fddd7695ded > > changeset: 1360:b27730a502c3 > user: mhaupt > date: Wed Jul 22 09:28:28 2015 +0200 > summary: 8131142: late-bind check for testng.jar presence in Nashorn test execution > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/b27730a502c3 > > changeset: 1352:3fe85fdf1651 > user: mhaupt > date: Fri Jul 10 08:42:35 2015 +0200 > summary: 8130862: let hg ignore TestNG ZIP file in Nashorn test library directory > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/3fe85fdf1651 > > changeset: 1342:becb3bb6a422 > user: mhaupt > date: Thu Jul 02 11:20:47 2015 +0200 > summary: 8130307: improve Nashorn Javadoc target > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/becb3bb6a422 > > changeset: 1341:6eca661ddf79 > user: mhaupt > date: Thu Jul 02 11:09:20 2015 +0200 > summary: 8130306: enable running Nashorn test on Windows > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/6eca661ddf79 > > changeset: 1339:d95394322204 > user: mhaupt > date: Wed Jul 01 16:26:25 2015 +0200 > summary: 8130127: streamline input parameter of Nashorn scripting $EXEC function > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/d95394322204 > > changeset: 1313:a24cb0bf79bc > user: mhaupt > date: Tue Jun 09 09:27:02 2015 +0200 > summary: 8080490: add $EXECV command to Nashorn scripting mode > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/a24cb0bf79bc > > changeset: 1311:d1689c1df3aa > user: mhaupt > date: Mon Jun 08 10:28:04 2015 +0200 > summary: 8085885: address Javadoc warnings in Nashorn source code > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/d1689c1df3aa > > changeset: 1307:0eeaadd17fff > user: mhaupt > date: Fri Jun 05 12:38:53 2015 +0200 > summary: 8080087: Nashorn $ENV.PWD is originally undefined > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/0eeaadd17fff > > changeset: 1301:10553f87f3e7 > user: mhaupt > date: Tue Jun 02 17:08:13 2015 +0200 > summary: 8081696: reduce dependency of Nashorn tests on external components > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/10553f87f3e7 > > changeset: 1300:14ec7d7af490 > user: mhaupt > date: Tue Jun 02 14:35:03 2015 +0200 > summary: 8080275: transparently download testng.jar for Nashorn testing > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/14ec7d7af490 > > changeset: 1299:078107e0651f > user: mhaupt > date: Tue Jun 02 14:34:37 2015 +0200 > summary: 8081668: fix Nashorn ant externals command > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/078107e0651f > > changeset: 1298:0d4841f2c800 > user: mhaupt > date: Tue Jun 02 10:40:19 2015 +0200 > summary: 8081604: rename ScriptingFunctions.tokenizeCommandLine > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/0d4841f2c800 > > changeset: 1297:776551a5b3a2 > user: mhaupt > date: Tue Jun 02 10:40:10 2015 +0200 > summary: 8081603: erroneous dot file generated from Nashorn --print-code > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/776551a5b3a2 > > changeset: 1279:71d7a37e6dfb > user: mhaupt > date: Fri May 15 16:36:25 2015 +0200 > summary: 8049300: jjs scripting: need way to quote $EXEC command arguments to protect spaces > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/71d7a37e6dfb > > changeset: 1277:4dc7eb763139 > user: mhaupt > date: Fri May 15 10:21:48 2015 +0200 > summary: 8080471: fix usage of replace and file separator in Nashorn tests > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/4dc7eb763139 > > changeset: 1271:063ed2f959e4 > user: mhaupt > date: Wed May 13 15:41:46 2015 +0200 > summary: 8080286: use path separator setting consistently in Nashorn project properties > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/063ed2f959e4 > > *** hotspot > > changeset: 8796:6ad64d95053d > user: mhaupt > date: Wed Mar 18 16:16:30 2015 +0100 > summary: 8004073: Implement C2 Ideal node specific dump() method > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/6ad64d95053d > > changeset: 8690:0fb7705845de > user: mhaupt > date: Tue Mar 31 21:46:44 2015 +0200 > summary: 6900757: minor bug fixes to LogCompilation tool > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/0fb7705845de > > changeset: 8345:d3413c4fee16 > parent: 8343:67729f5f33c4 > user: mhaupt > date: Tue May 05 13:06:10 2015 +0200 > summary: 8075492: adopt recent IGV > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/d3413c4fee16 > > changeset: 8208:6c4ca18a0666 > user: mhaupt > date: Tue Apr 14 18:16:10 2015 +0300 > summary: 8076461: JSR292: remove unused native and constants > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/6c4ca18a0666 > > > From dalibor.topic at oracle.com Fri Jun 10 10:32:16 2016 From: dalibor.topic at oracle.com (dalibor topic) Date: Fri, 10 Jun 2016 12:32:16 +0200 Subject: CFV: New JDK 9 Committer: Felix Yang In-Reply-To: <75ca884a-fa55-2cce-fdee-3ce8d8527dab@Oracle.com> References: <2b16fc92-ae12-3bf7-fbac-3b13d96a6757@oracle.com> <75ca884a-fa55-2cce-fdee-3ce8d8527dab@Oracle.com> Message-ID: <328fb37d-3ed3-c599-8abf-93edbbf01157@oracle.com> Vote: Yes. -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From mark.reinhold at oracle.com Fri Jun 10 14:24:37 2016 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Fri, 10 Jun 2016 07:24:37 -0700 Subject: JDK 9 is not (yet) Feature Complete -- how will we get there? Message-ID: <20160610072437.975638333eggemoggin.niobe.net> The JDK 9 schedule [1] lists a date for the Feature Complete milestone of 2016/5/26, about two weeks ago. There's been some concern that this means that the JDK 9 (and hence Java SE 9) feature set is somehow frozen, but that's not the case. The milestones listed in the JDK 9 schedule are condition-driven rather than date-driven, as noted along with the milestone definitions [2]. We try our best to reach the goal of each milestone by its scheduled date. If we miss a date then we don't just blindly constrain further work so as to fit the date, we instead manage the remaining changes relevant to the milestone so as to reach its goal in a reasonable time frame without putting the final GA date at undue risk. When we finally do reach the goal then we declare the milestone on that date. The goal of the Feature Complete milestone is to get all of the planned features, i.e., JEPs, and smaller enhancements integrated into the JDK 9 master forest, together with their unit tests. As of today most JEPs targeted to JDK 9 have been completed [3]. Fifteen JEPs remain, and a number of small enhancements are listed as intended for JDK 9 but are still either open or in progress. To manage the remaining JEPs and small enhancements so that we can reach the Feature Complete state in a timely fashion I hereby propose the following process: - If you own a JEP or a small enhancement that is not yet complete then you can request an FC extension as follows: Update the JBS issue to add a comment whose first line is "FC Extension Request". In that comment describe the remaining work to be done, the risk level, a brief justification, and your best estimate of the date by which the feature will be complete. Add the label "jdk9-fc-request" to the issue. - The Area Leads, relevant Group Leads, and I will review such requests on a regular basis, at least weekly if not more often. One of us will take one of the following actions: - Approve the request by adding the label "jdk9-fc-yes". - Reject the request by adding the label "jdk9-fc-no", along with a comment describing the reason for this action. - Request more information by adding the label "jdk9-fc-nmi" ("nmi" = "needs more information"), along with a comment describing what information is requested. - If you're asked to provide more information for an FC extension request then please do so in a new comment in the issue, and then remove the "jdk9-fc-nmi" label so that we see that it's ready for re-review. - If your request is approved then update the issue's due date to the expected completion date. - If you own a JEP that's targeted to JDK 9, but won't make it, then please propose to drop it [4]; this will move the JEP back to the Candidate state unless there are strong objections. If you own a small enhancement whose fix version is 9, but won't make it, then please clear the fix-version field. If a JEP has been granted an FC extension then enhancement issues that block the JEP's issue are automatically considered to have FC extensions. If a JEP has not yet been targeted to JDK 9 then you can still propose to target it to the release, but going forward the bar for accepting new features will be increasingly high. For the record, the Area Leads are Mikael Vidstedt (VM) and Brian Goetz (Language and Libraries). The relevant Group Leads are as follows, per the Census [5]: Artem Ananiev - AWT Alan Bateman - Core Libraries Tim Bell - Build Daniel D. Daugherty - Serviceability Jonathan Gibbons - Compiler Vladimir Kozlov - HotSpot Michael McMahon - Networking Sean Mullan - Security Masayoshi Okutsu - Internationalization Pavel Porvatov - Swing Phil Race - 2D Graphics & Sound Dalibor Topic - Porters JDK 9 Committers are invited to comment on this process proposal. If no serious objections are raised in one week's time, by 15:00 UTC on 17 June 2016, then this is the process that we'll use. In anticipation that we will use this process, more or less, I encourage owners of not-yet-complete JEPs and small enhancements to go ahead and request extensions as described above, if desired, so that we can move quickly once the process is in place. - Mark [1] http://openjdk.java.net/projects/jdk9/ [2] http://openjdk.java.net/projects/jdk8/milestones#definitions [3] http://j.mp/jdk9-features-jbs [4] http://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html#Proposed-to-Drop [5] http://openjdk.java.net/census From paul.sandoz at oracle.com Fri Jun 10 22:39:54 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 10 Jun 2016 15:39:54 -0700 Subject: RFR 8158039 VarHandle float/double field/array access should support CAS/set/add atomics In-Reply-To: <57561996.4000501@oracle.com> References: <23FAF71F-F8B9-4AD6-9BF3-896795540788@oracle.com> <6ed640e8-f581-e81d-3e77-ef47405f9618@oracle.com> <57561996.4000501@oracle.com> Message-ID: <951844EF-D517-4BF5-861A-81769EA1C306@oracle.com> Hi Joe, It?s my turn to catch up on email? > On 6 Jun 2016, at 17:47, Joseph D. Darcy wrote: > > Hello, > > Catching up on email, there are several different notions on floating-point equality one might want to use. [1] > > One notion is the built-in "==" operator on float and double. This has the wrinkle of not defining an equivalence relation because of NaN values (not reflexive) and signed zeros (distinguishable values compare as equal). > > When I write floating-point tests, I'll use a notion of equality close to > > Float.compare(x, y) == 0 > > which means all NaN values are treated as the same and Float.compare(NaN, NaN) == 0 is true. This also distinguishes the signed zeros from each other. > > So comparing based on the non-raw bitwise conversion can give resonable semantics, at the cost of not preserving any payload stored in the NaN significand. > And potentially a performance hit too [*]. Pedantically since (NaN == NaN) is false, one could argue that it should not possible to CAS with an expected NaN value and/or a witness NaN value. Such behaviour might be considered BaNaNas :-) (sorry). I don?t think we can or should enforce that, but we should strongly advise against it and mention the pitfalls, and i will need to specify that the atomic ops perform bit-wise equality with suitable ?as if? text. Paul. [*] For example, the double[] accepting Arrays.equals method used to compare each element as: 2762 for (int i=0; i HTH, > > -Joe > > [1] "Notions of Floating-Point Equality ," https://blogs.oracle.com/darcy/entry/notions_of_floating_point_equality > > On 6/2/2016 1:34 AM, Paul Sandoz wrote: >>> On 2 Jun 2016, at 09:13, David Holmes wrote: >>> >>> On 2/06/2016 1:24 AM, Paul Sandoz wrote: >>>> (Please note this work is or will be covered with FC exception) >>>> >>>> Hi, >>>> >>>> Please review the VarHandles/Unsafe support for atomic ops on double/float fields/arrays. >>> I think this is misguided. If the user wants CAS for float/double they can do the conversion to int/long in a context where they know that conversion makes sense and where they can deal with NaNs appropriately. >>> >> I would still like to support some clearly defined default behaviour if at all possible, since this is not easy to get right so we can add some value here. The user can use int/long if that behaviour is not suitable. >> >> >>> At a minimum the fact this deals with raw bit patterns not semantic values needs to be exposed somehow. ie the handling of NaN needs to be explicit. >>> >> Yes, it?s multiple NaN values that collapse to a single NaN value. >> >> It would be good if our resident floating point expert Mr. Joe Darcy could chime in this respect. >> >> On Float.intBitsToFloat: >> >> *

Note that this method may not be able to return a >> * {@code float} NaN with exactly same bit pattern as the >> * {@code int} argument. IEEE 754 distinguishes between two >> * kinds of NaNs, quiet NaNs and signaling NaNs. The >> * differences between the two kinds of NaN are generally not >> * visible in Java. Arithmetic operations on signaling NaNs turn >> * them into quiet NaNs with a different, but often similar, bit >> * pattern. However, on some processors merely copying a >> * signaling NaN also performs that conversion. In particular, >> * copying a signaling NaN to return it to the calling method may >> * perform this conversion. So {@code intBitsToFloat} may >> * not be able to return a {@code float} with a signaling NaN >> * bit pattern. Consequently, for some {@code int} values, >> * {@code floatToRawIntBits(intBitsToFloat(start))} may >> * not equal {@code start}. Moreover, which >> * particular bit patterns represent signaling NaNs is platform >> * dependent; although all NaN bit patterns, quiet or signaling, >> * must be in the NaN range identified above. >> >> >> >> I am concerned that the CAS loops could in some cases loop without termination: >> >> @ForceInline >> public final float getAndAddFloat(Object o, long offset, float delta) { >> float v; >> do { >> v = getFloatVolatile(o, offset); >> } while (!weakCompareAndSwapFloatVolatile(o, offset, v, v + delta)); >> return v; >> } >> >> >> I think this should be: >> >> @ForceInline >> public final float getAndAddFloat(Object o, long offset, float delta) { >> int expectedBits; >> float v; >> do { >> expectedBits = getIntVolatile(o, offset); >> v = Float.intBitsToFloat(bits); // May not preserve a NaN value with the same bit pattern as expectedBits >> } while (!weakCompareAndSwapIntVolatile(o, offset, expectedBits, Float.floatToRawIntBits(v + delta))); >> return v; >> } >> >> and likewise for the atomic get-and-set methods. >> >> Paul. >> >>> David >>> ----- >>> >>>> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8158039-float-double-field-array-cas.jdk/webrev/ >>>> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8158039-float-double-field-array-cas.hotspot/webrev/ >>>> >>>> These patches are based on those of for sub-word CAS >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8157726 >>>> http://cr.openjdk.java.net/~shade/8157726/webrev.hs.03/ >>>> http://cr.openjdk.java.net/~shade/8157726/webrev.jdk.03/ >>>> >>>> And the two patches combined expand the support of fields/arrays. >>>> >>>> >>>> New float/double CAS methods are added to Unsafe that defer to int/long equivalents. Then the other atomic methods are built from weak CAS loops. >>>> >>>> No changes are required to HotSpot, but changes are required to the Unsafe tests in the hotspot repository. >>>> >>>> In general the changes to VHs and tests are minimal since it is triggered from changes to the generating scripts that now include float/double into the CAS category. >>>> >>>> There are some minor specification changes and a CCC has been initiated. >>>> >>>> JPRT tests results show no relevant failures for hotspot and core test sets. >>>> >>>> Thanks, >>>> Paul. >>>> > From li.jiang at oracle.com Sun Jun 12 15:58:57 2016 From: li.jiang at oracle.com (Leo Jiang) Date: Sun, 12 Jun 2016 23:58:57 +0800 Subject: RFR 8159324 JDK9 msg drop 10 resource update Message-ID: <575D86C1.1080308@oracle.com> Hi, Please review the resource update for JDK9 message drop 10. After preparation message drop, we have minor update for jaxp, jdk and langtools. CR: http://cr.openjdk.java.net/~fyuan/leo/ Bug: https://bugs.openjdk.java.net/browse/JDK-8159324 Thanks, Leo From weijun.wang at oracle.com Mon Jun 13 01:37:25 2016 From: weijun.wang at oracle.com (Weijun Wang) Date: Sun, 12 Jun 2016 18:37:25 -0700 (PDT) Subject: RFR 8159324 JDK9 msg drop 10 resource update Message-ID: <3447950b-eec9-4d69-9d99-42afd846766f@default> jarsigner/Resources_zh_CN.java looks good to me. Thanks Max ----- li.jiang at oracle.com wrote: > Hi, > > Please review the resource update for JDK9 message drop 10. After > preparation message drop, we have minor update for > jaxp, jdk and langtools. > > CR: http://cr.openjdk.java.net/~fyuan/leo/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8159324 > > Thanks, > Leo From huizhe.wang at oracle.com Mon Jun 13 17:56:36 2016 From: huizhe.wang at oracle.com (huizhe wang) Date: Mon, 13 Jun 2016 10:56:36 -0700 Subject: RFR 8159324 JDK9 msg drop 10 resource update In-Reply-To: <575D86C1.1080308@oracle.com> References: <575D86C1.1080308@oracle.com> Message-ID: <575EF3D4.8030408@oracle.com> Hi Leo, That jaxp portion of the change looks fine. For XMLSchemaMessages_de.properties, feel free to remove the $Id line, e.g. # @version $Id: ... Thanks, Joe On 6/12/2016 8:58 AM, Leo Jiang wrote: > Hi, > > Please review the resource update for JDK9 message drop 10. After > preparation message drop, we have minor update for jaxp, jdk and > langtools. > > CR: http://cr.openjdk.java.net/~fyuan/leo/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8159324 > > Thanks, > Leo From paul.sandoz at oracle.com Tue Jun 14 00:12:14 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 13 Jun 2016 17:12:14 -0700 Subject: RFR 8158039 VarHandle float/double field/array access should support CAS/set/add atomics In-Reply-To: <951844EF-D517-4BF5-861A-81769EA1C306@oracle.com> References: <23FAF71F-F8B9-4AD6-9BF3-896795540788@oracle.com> <6ed640e8-f581-e81d-3e77-ef47405f9618@oracle.com> <57561996.4000501@oracle.com> <951844EF-D517-4BF5-861A-81769EA1C306@oracle.com> Message-ID: Hi, Here is an updated webrev. http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8158039-float-double-field-array-cas.jdk/webrev/ http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8158039-float-double-field-array-cas.hotspot/webrev/ Changes - the Unsafe.getAndAdd for float/double operate in the bit-domain. - documentation added to the factory methods: 1221 *

1222 * If the field type is {@code float} or {@code double} then numeric 1223 * and atomic update access modes compare values using their bitwise 1224 * representation (see {@link Float#floatToRawIntBits} and 1225 * {@link Double#doubleToRawLongBits}, respectively). 1226 *

1227 * @apiNote 1228 * Bitwise comparison of {@code float} values or {@code double} values, 1229 * as performed by the numeric and atomic update access modes, differ 1230 * from the primitive {@code ==} operator and the {@link Float#equals} 1231 * and {@link Double#equals} methods, notably with respect to 1232 * {@code NaN}. There are many possible NaN values that are considered 1233 * to be {@code NaN} in Java, although no IEEE 754 floating-point 1234 * operation provided by Java can distinguish between them. As such 1235 * care should be taken when performing a compare and set or a compare 1236 * and exchange operation with NaN values since the operation may 1237 * unexpectedly fail. Failure can occur if the expected or witness 1238 * value is a NaN value and it is transformed (perhaps in a platform 1239 * specific manner) into another NaN value, and thus has a different 1240 * bitwise representation (see {@link Float#intBitsToFloat} or 1241 * Double#longBitsToDouble for more details). (I also updated the documentation on array/ByteBuffer view methods but did not bother with the api note) Paul. > On 10 Jun 2016, at 15:39, Paul Sandoz wrote: > > Hi Joe, > > It?s my turn to catch up on email? > > >> On 6 Jun 2016, at 17:47, Joseph D. Darcy wrote: >> >> Hello, >> >> Catching up on email, there are several different notions on floating-point equality one might want to use. [1] >> >> One notion is the built-in "==" operator on float and double. This has the wrinkle of not defining an equivalence relation because of NaN values (not reflexive) and signed zeros (distinguishable values compare as equal). >> >> When I write floating-point tests, I'll use a notion of equality close to >> >> Float.compare(x, y) == 0 >> >> which means all NaN values are treated as the same and Float.compare(NaN, NaN) == 0 is true. This also distinguishes the signed zeros from each other. >> >> So comparing based on the non-raw bitwise conversion can give resonable semantics, at the cost of not preserving any payload stored in the NaN significand. >> > > And potentially a performance hit too [*]. > > Pedantically since (NaN == NaN) is false, one could argue that it should not possible to CAS with an expected NaN value and/or a witness NaN value. Such behaviour might be considered BaNaNas :-) (sorry). I don?t think we can or should enforce that, but we should strongly advise against it and mention the pitfalls, and i will need to specify that the atomic ops perform bit-wise equality with suitable ?as if? text. > > Paul. > > [*] For example, the double[] accepting Arrays.equals method used to compare each element as: > > 2762 for (int i=0; i 2763 if (Double.doubleToLongBits(a[i])!=Double.doubleToLongBits(a2[i])) > 2764 return false; > > In the interim of my adding vectorized mismatch support i changed that to: > > 3057 for (int i=0; i 3058 double v1 = a[i], v2 = a2[i]; > 3059 if (Double.doubleToRawLongBits(v1) != Double.doubleToRawLongBits(v2)) > 3060 if (!Double.isNaN(v1) || !Double.isNaN(v2)) > 3061 return false; > 3062 } > > Which boosted the performance similar to that of comparing long[] (when no NaNs are present). > > >> HTH, >> >> -Joe >> >> [1] "Notions of Floating-Point Equality ," https://blogs.oracle.com/darcy/entry/notions_of_floating_point_equality >> >> On 6/2/2016 1:34 AM, Paul Sandoz wrote: >>>> On 2 Jun 2016, at 09:13, David Holmes wrote: >>>> >>>> On 2/06/2016 1:24 AM, Paul Sandoz wrote: >>>>> (Please note this work is or will be covered with FC exception) >>>>> >>>>> Hi, >>>>> >>>>> Please review the VarHandles/Unsafe support for atomic ops on double/float fields/arrays. >>>> I think this is misguided. If the user wants CAS for float/double they can do the conversion to int/long in a context where they know that conversion makes sense and where they can deal with NaNs appropriately. >>>> >>> I would still like to support some clearly defined default behaviour if at all possible, since this is not easy to get right so we can add some value here. The user can use int/long if that behaviour is not suitable. >>> >>> >>>> At a minimum the fact this deals with raw bit patterns not semantic values needs to be exposed somehow. ie the handling of NaN needs to be explicit. >>>> >>> Yes, it?s multiple NaN values that collapse to a single NaN value. >>> >>> It would be good if our resident floating point expert Mr. Joe Darcy could chime in this respect. >>> >>> On Float.intBitsToFloat: >>> >>> *

Note that this method may not be able to return a >>> * {@code float} NaN with exactly same bit pattern as the >>> * {@code int} argument. IEEE 754 distinguishes between two >>> * kinds of NaNs, quiet NaNs and signaling NaNs. The >>> * differences between the two kinds of NaN are generally not >>> * visible in Java. Arithmetic operations on signaling NaNs turn >>> * them into quiet NaNs with a different, but often similar, bit >>> * pattern. However, on some processors merely copying a >>> * signaling NaN also performs that conversion. In particular, >>> * copying a signaling NaN to return it to the calling method may >>> * perform this conversion. So {@code intBitsToFloat} may >>> * not be able to return a {@code float} with a signaling NaN >>> * bit pattern. Consequently, for some {@code int} values, >>> * {@code floatToRawIntBits(intBitsToFloat(start))} may >>> * not equal {@code start}. Moreover, which >>> * particular bit patterns represent signaling NaNs is platform >>> * dependent; although all NaN bit patterns, quiet or signaling, >>> * must be in the NaN range identified above. >>> >>> >>> >>> I am concerned that the CAS loops could in some cases loop without termination: >>> >>> @ForceInline >>> public final float getAndAddFloat(Object o, long offset, float delta) { >>> float v; >>> do { >>> v = getFloatVolatile(o, offset); >>> } while (!weakCompareAndSwapFloatVolatile(o, offset, v, v + delta)); >>> return v; >>> } >>> >>> >>> I think this should be: >>> >>> @ForceInline >>> public final float getAndAddFloat(Object o, long offset, float delta) { >>> int expectedBits; >>> float v; >>> do { >>> expectedBits = getIntVolatile(o, offset); >>> v = Float.intBitsToFloat(bits); // May not preserve a NaN value with the same bit pattern as expectedBits >>> } while (!weakCompareAndSwapIntVolatile(o, offset, expectedBits, Float.floatToRawIntBits(v + delta))); >>> return v; >>> } >>> >>> and likewise for the atomic get-and-set methods. >>> >>> Paul. >>> >>>> David >>>> ----- >>>> >>>>> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8158039-float-double-field-array-cas.jdk/webrev/ >>>>> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8158039-float-double-field-array-cas.hotspot/webrev/ >>>>> >>>>> These patches are based on those of for sub-word CAS >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8157726 >>>>> http://cr.openjdk.java.net/~shade/8157726/webrev.hs.03/ >>>>> http://cr.openjdk.java.net/~shade/8157726/webrev.jdk.03/ >>>>> >>>>> And the two patches combined expand the support of fields/arrays. >>>>> >>>>> >>>>> New float/double CAS methods are added to Unsafe that defer to int/long equivalents. Then the other atomic methods are built from weak CAS loops. >>>>> >>>>> No changes are required to HotSpot, but changes are required to the Unsafe tests in the hotspot repository. >>>>> >>>>> In general the changes to VHs and tests are minimal since it is triggered from changes to the generating scripts that now include float/double into the CAS category. >>>>> >>>>> There are some minor specification changes and a CCC has been initiated. >>>>> >>>>> JPRT tests results show no relevant failures for hotspot and core test sets. >>>>> >>>>> Thanks, >>>>> Paul. >>>>> >> > From joe.darcy at oracle.com Tue Jun 14 04:09:01 2016 From: joe.darcy at oracle.com (joe darcy) Date: Mon, 13 Jun 2016 21:09:01 -0700 Subject: RFR 8158039 VarHandle float/double field/array access should support CAS/set/add atomics In-Reply-To: References: <23FAF71F-F8B9-4AD6-9BF3-896795540788@oracle.com> <6ed640e8-f581-e81d-3e77-ef47405f9618@oracle.com> <57561996.4000501@oracle.com> <951844EF-D517-4BF5-861A-81769EA1C306@oracle.com> Message-ID: <8d668cf7-1f40-8310-117e-267cefe2ab5c@oracle.com> Hi Paul, I suggest also pointing out that a bitwise comparison distinguishes -0.0 from +0.0; they compare as == under the built-in operation. HTH, -Joe On 6/13/2016 5:12 PM, Paul Sandoz wrote: > Hi, > > Here is an updated webrev. > > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8158039-float-double-field-array-cas.jdk/webrev/ > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8158039-float-double-field-array-cas.hotspot/webrev/ > > Changes > > - the Unsafe.getAndAdd for float/double operate in the bit-domain. > > - documentation added to the factory methods: > > 1221 *

> 1222 * If the field type is {@code float} or {@code double} then numeric > 1223 * and atomic update access modes compare values using their bitwise > 1224 * representation (see {@link Float#floatToRawIntBits} and > 1225 * {@link Double#doubleToRawLongBits}, respectively). > 1226 *

> 1227 * @apiNote > 1228 * Bitwise comparison of {@code float} values or {@code double} values, > 1229 * as performed by the numeric and atomic update access modes, differ > 1230 * from the primitive {@code ==} operator and the {@link Float#equals} > 1231 * and {@link Double#equals} methods, notably with respect to > 1232 * {@code NaN}. There are many possible NaN values that are considered > 1233 * to be {@code NaN} in Java, although no IEEE 754 floating-point > 1234 * operation provided by Java can distinguish between them. As such > 1235 * care should be taken when performing a compare and set or a compare > 1236 * and exchange operation with NaN values since the operation may > 1237 * unexpectedly fail. Failure can occur if the expected or witness > 1238 * value is a NaN value and it is transformed (perhaps in a platform > 1239 * specific manner) into another NaN value, and thus has a different > 1240 * bitwise representation (see {@link Float#intBitsToFloat} or > 1241 * Double#longBitsToDouble for more details). > > (I also updated the documentation on array/ByteBuffer view methods but did not bother with the api note) > > Paul. > >> On 10 Jun 2016, at 15:39, Paul Sandoz wrote: >> >> Hi Joe, >> >> It?s my turn to catch up on email? >> >> >>> On 6 Jun 2016, at 17:47, Joseph D. Darcy wrote: >>> >>> Hello, >>> >>> Catching up on email, there are several different notions on floating-point equality one might want to use. [1] >>> >>> One notion is the built-in "==" operator on float and double. This has the wrinkle of not defining an equivalence relation because of NaN values (not reflexive) and signed zeros (distinguishable values compare as equal). >>> >>> When I write floating-point tests, I'll use a notion of equality close to >>> >>> Float.compare(x, y) == 0 >>> >>> which means all NaN values are treated as the same and Float.compare(NaN, NaN) == 0 is true. This also distinguishes the signed zeros from each other. >>> >>> So comparing based on the non-raw bitwise conversion can give resonable semantics, at the cost of not preserving any payload stored in the NaN significand. >>> >> And potentially a performance hit too [*]. >> >> Pedantically since (NaN == NaN) is false, one could argue that it should not possible to CAS with an expected NaN value and/or a witness NaN value. Such behaviour might be considered BaNaNas :-) (sorry). I don?t think we can or should enforce that, but we should strongly advise against it and mention the pitfalls, and i will need to specify that the atomic ops perform bit-wise equality with suitable ?as if? text. >> >> Paul. >> >> [*] For example, the double[] accepting Arrays.equals method used to compare each element as: >> >> 2762 for (int i=0; i> 2763 if (Double.doubleToLongBits(a[i])!=Double.doubleToLongBits(a2[i])) >> 2764 return false; >> >> In the interim of my adding vectorized mismatch support i changed that to: >> >> 3057 for (int i=0; i> 3058 double v1 = a[i], v2 = a2[i]; >> 3059 if (Double.doubleToRawLongBits(v1) != Double.doubleToRawLongBits(v2)) >> 3060 if (!Double.isNaN(v1) || !Double.isNaN(v2)) >> 3061 return false; >> 3062 } >> >> Which boosted the performance similar to that of comparing long[] (when no NaNs are present). >> >> >>> HTH, >>> >>> -Joe >>> >>> [1] "Notions of Floating-Point Equality ," https://blogs.oracle.com/darcy/entry/notions_of_floating_point_equality >>> >>> On 6/2/2016 1:34 AM, Paul Sandoz wrote: >>>>> On 2 Jun 2016, at 09:13, David Holmes wrote: >>>>> >>>>> On 2/06/2016 1:24 AM, Paul Sandoz wrote: >>>>>> (Please note this work is or will be covered with FC exception) >>>>>> >>>>>> Hi, >>>>>> >>>>>> Please review the VarHandles/Unsafe support for atomic ops on double/float fields/arrays. >>>>> I think this is misguided. If the user wants CAS for float/double they can do the conversion to int/long in a context where they know that conversion makes sense and where they can deal with NaNs appropriately. >>>>> >>>> I would still like to support some clearly defined default behaviour if at all possible, since this is not easy to get right so we can add some value here. The user can use int/long if that behaviour is not suitable. >>>> >>>> >>>>> At a minimum the fact this deals with raw bit patterns not semantic values needs to be exposed somehow. ie the handling of NaN needs to be explicit. >>>>> >>>> Yes, it?s multiple NaN values that collapse to a single NaN value. >>>> >>>> It would be good if our resident floating point expert Mr. Joe Darcy could chime in this respect. >>>> >>>> On Float.intBitsToFloat: >>>> >>>> *

Note that this method may not be able to return a >>>> * {@code float} NaN with exactly same bit pattern as the >>>> * {@code int} argument. IEEE 754 distinguishes between two >>>> * kinds of NaNs, quiet NaNs and signaling NaNs. The >>>> * differences between the two kinds of NaN are generally not >>>> * visible in Java. Arithmetic operations on signaling NaNs turn >>>> * them into quiet NaNs with a different, but often similar, bit >>>> * pattern. However, on some processors merely copying a >>>> * signaling NaN also performs that conversion. In particular, >>>> * copying a signaling NaN to return it to the calling method may >>>> * perform this conversion. So {@code intBitsToFloat} may >>>> * not be able to return a {@code float} with a signaling NaN >>>> * bit pattern. Consequently, for some {@code int} values, >>>> * {@code floatToRawIntBits(intBitsToFloat(start))} may >>>> * not equal {@code start}. Moreover, which >>>> * particular bit patterns represent signaling NaNs is platform >>>> * dependent; although all NaN bit patterns, quiet or signaling, >>>> * must be in the NaN range identified above. >>>> >>>> >>>> >>>> I am concerned that the CAS loops could in some cases loop without termination: >>>> >>>> @ForceInline >>>> public final float getAndAddFloat(Object o, long offset, float delta) { >>>> float v; >>>> do { >>>> v = getFloatVolatile(o, offset); >>>> } while (!weakCompareAndSwapFloatVolatile(o, offset, v, v + delta)); >>>> return v; >>>> } >>>> >>>> >>>> I think this should be: >>>> >>>> @ForceInline >>>> public final float getAndAddFloat(Object o, long offset, float delta) { >>>> int expectedBits; >>>> float v; >>>> do { >>>> expectedBits = getIntVolatile(o, offset); >>>> v = Float.intBitsToFloat(bits); // May not preserve a NaN value with the same bit pattern as expectedBits >>>> } while (!weakCompareAndSwapIntVolatile(o, offset, expectedBits, Float.floatToRawIntBits(v + delta))); >>>> return v; >>>> } >>>> >>>> and likewise for the atomic get-and-set methods. >>>> >>>> Paul. >>>> >>>>> David >>>>> ----- >>>>> >>>>>> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8158039-float-double-field-array-cas.jdk/webrev/ >>>>>> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8158039-float-double-field-array-cas.hotspot/webrev/ >>>>>> >>>>>> These patches are based on those of for sub-word CAS >>>>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8157726 >>>>>> http://cr.openjdk.java.net/~shade/8157726/webrev.hs.03/ >>>>>> http://cr.openjdk.java.net/~shade/8157726/webrev.jdk.03/ >>>>>> >>>>>> And the two patches combined expand the support of fields/arrays. >>>>>> >>>>>> >>>>>> New float/double CAS methods are added to Unsafe that defer to int/long equivalents. Then the other atomic methods are built from weak CAS loops. >>>>>> >>>>>> No changes are required to HotSpot, but changes are required to the Unsafe tests in the hotspot repository. >>>>>> >>>>>> In general the changes to VHs and tests are minimal since it is triggered from changes to the generating scripts that now include float/double into the CAS category. >>>>>> >>>>>> There are some minor specification changes and a CCC has been initiated. >>>>>> >>>>>> JPRT tests results show no relevant failures for hotspot and core test sets. >>>>>> >>>>>> Thanks, >>>>>> Paul. >>>>>> From li.jiang at oracle.com Tue Jun 14 04:38:37 2016 From: li.jiang at oracle.com (Leo Jiang) Date: Tue, 14 Jun 2016 12:38:37 +0800 Subject: RFR 8159324 JDK9 msg drop 10 resource update In-Reply-To: <575EF3D4.8030408@oracle.com> References: <575D86C1.1080308@oracle.com> <575EF3D4.8030408@oracle.com> Message-ID: <575F8A4D.5060807@oracle.com> Thank you Joe! I have filed a separated bug to remove the $Id line for JDK9. Thanks, Leo On 06/14/2016 01:56 AM, huizhe wang wrote: > Hi Leo, > > That jaxp portion of the change looks fine. For XMLSchemaMessages_de.properties, feel free to remove the $Id line, e.g. > > # @version $Id: ... > > Thanks, > Joe > > On 6/12/2016 8:58 AM, Leo Jiang wrote: >> Hi, >> >> Please review the resource update for JDK9 message drop 10. After preparation message drop, we have minor update for >> jaxp, jdk and langtools. >> >> CR: http://cr.openjdk.java.net/~fyuan/leo/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8159324 >> >> Thanks, >> Leo > From volker.simonis at gmail.com Tue Jun 14 16:36:06 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 14 Jun 2016 18:36:06 +0200 Subject: CFV: New jdk9 Committer: Christoph Langer Message-ID: I hereby nominate Christoph Langer to jdk9 Committer. Christoph is a long-term member of the SAP JVM support team at SAP. He has a broad knowledge of the entire JDK as can be seen from the variety of his changes which are in the class library [1], jaxp [2] as well as in the hotspot repository [3]. Recently he has contributed 13 non-trivial changes to jdk9 (see below for details). Votes are due by 20:00 CET, June 28, 2016. Only current JDK9 Committers [4] 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 [5]. Thanks, Volker JDK: 8158519: Incorrect network mask and broadcast address on Linux when there are multiple IPv4 addresses on an interface http://hg.openjdk.java.net/jdk9/dev/jdk/rev/ac3e32924dfb 8134505: Cleanup of "TimeZone_md.c" http://hg.openjdk.java.net/jdk9/dev/jdk/rev/4b948e5a3e77 8133830: [solaris] Fix for potential memory leak in TimeZone_md.c, function findJavaTZ_md() http://hg.openjdk.java.net/jdk9/dev/jdk/rev/e40abeb715f0 8156521: Minor fixes and cleanups in NetworkInterface.c http://hg.openjdk.java.net/jdk9/dev/jdk/rev/fe3e1508653e 8149169: SSLSocketInputRecord.decodeInputRecord buffer overflow http://hg.openjdk.java.net/jdk9/dev/jdk/rev/d6a0479363ed 8139436: sun.security.mscapi.KeyStore might load incomplete data http://hg.openjdk.java.net/jdk9/dev/jdk/rev/05899a336fcd JAXP: 8153781: Issue in XMLScanner: EXPECTED_SQUARE_BRACKET_TO_CLOSE_INTERNAL_SUBSET when skipping large DOCTYPE section with CRLF at wrong place http://hg.openjdk.java.net/jdk9/dev/jaxp/rev/8be2998d17d6 8150704: XALAN: ERROR: 'No more DTM IDs are available' when transforming with lots of temporary result trees http://hg.openjdk.java.net/jdk9/dev/jaxp/rev/0fe7231b64a6 8149915: enabling validate-annotations feature for xsd schema with annotation causes NPE http://hg.openjdk.java.net/jdk9/dev/jaxp/rev/95c223e6eaf0 8150470: JCK: api/xsl/conf/copy/copy19 test failure http://hg.openjdk.java.net/jdk9/dev/jaxp/rev/264df5d957cd HOTSPOT: 8130910: hsperfdata file is created in wrong directory and not cleaned up if /tmp/hsperfdata_ has wrong permissions http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/efc17f03e5d4 8150232: AIX cleanup: Integrate changes of 7178026 and others http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/ad7a71500f4a 8140244: Port fix of JDK-8075773 to AIX and possibly MacOSX http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/9ff773cd4ba2 [1] http://hg.openjdk.java.net/jdk9/dev/jdk/log?rev=%28author%28%22clanger%22%29+or+desc%28%22Contributed-by%3A+christoph.langer at sap.com%22%29%29+and+not+merge%28%29 [2] http://hg.openjdk.java.net/jdk9/dev/jaxp/log?rev=%28author%28%22clanger%22%29+or+desc%28%22Contributed-by%3A+christoph.langer at sap.com%22%29%29+and+not+merge%28%29 [3] http://hg.openjdk.java.net/jdk9/dev/hotspot/log?rev=%28author%28%22clanger%22%29+or+desc%28%22Contributed-by%3A+christoph.langer at sap.com%22%29%29+and+not+merge%28%29 [4] http://openjdk.java.net/census#jdk9 [5] http://openjdk.java.net/projects#committer-vote From vladimir.kozlov at oracle.com Tue Jun 14 16:39:39 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 14 Jun 2016 09:39:39 -0700 Subject: CFV: New jdk9 Committer: Christoph Langer In-Reply-To: References: Message-ID: <6ac76d9b-8a16-8e1e-3b87-b9e5870bfa7f@oracle.com> Vote: yes On 6/14/16 9:36 AM, Volker Simonis wrote: > I hereby nominate Christoph Langer to jdk9 Committer. > > Christoph is a long-term member of the SAP JVM support team at SAP. > He has a broad knowledge of the entire JDK as can be seen from the > variety of his changes which are in the class library [1], jaxp [2] as > well as in the hotspot repository [3]. > > Recently he has contributed 13 non-trivial changes to jdk9 (see below > for details). > > Votes are due by 20:00 CET, June 28, 2016. > > Only current JDK9 Committers [4] 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 [5]. > > Thanks, > Volker > > JDK: > > 8158519: Incorrect network mask and broadcast address on Linux when > there are multiple IPv4 addresses on an interface > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/ac3e32924dfb > > 8134505: Cleanup of "TimeZone_md.c" > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/4b948e5a3e77 > > 8133830: [solaris] Fix for potential memory leak in TimeZone_md.c, > function findJavaTZ_md() > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/e40abeb715f0 > > 8156521: Minor fixes and cleanups in NetworkInterface.c > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/fe3e1508653e > > 8149169: SSLSocketInputRecord.decodeInputRecord buffer overflow > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/d6a0479363ed > > 8139436: sun.security.mscapi.KeyStore might load incomplete data > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/05899a336fcd > > JAXP: > > 8153781: Issue in XMLScanner: > EXPECTED_SQUARE_BRACKET_TO_CLOSE_INTERNAL_SUBSET when skipping large > DOCTYPE section with CRLF at wrong place > http://hg.openjdk.java.net/jdk9/dev/jaxp/rev/8be2998d17d6 > > 8150704: XALAN: ERROR: 'No more DTM IDs are available' when > transforming with lots of temporary result trees > http://hg.openjdk.java.net/jdk9/dev/jaxp/rev/0fe7231b64a6 > > 8149915: enabling validate-annotations feature for xsd schema with > annotation causes NPE > http://hg.openjdk.java.net/jdk9/dev/jaxp/rev/95c223e6eaf0 > > 8150470: JCK: api/xsl/conf/copy/copy19 test failure > http://hg.openjdk.java.net/jdk9/dev/jaxp/rev/264df5d957cd > > HOTSPOT: > > 8130910: hsperfdata file is created in wrong directory and not cleaned > up if /tmp/hsperfdata_ has wrong permissions > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/efc17f03e5d4 > > 8150232: AIX cleanup: Integrate changes of 7178026 and others > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/ad7a71500f4a > > 8140244: Port fix of JDK-8075773 to AIX and possibly MacOSX > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/9ff773cd4ba2 > > > > [1] http://hg.openjdk.java.net/jdk9/dev/jdk/log?rev=%28author%28%22clanger%22%29+or+desc%28%22Contributed-by%3A+christoph.langer at sap.com%22%29%29+and+not+merge%28%29 > > [2] http://hg.openjdk.java.net/jdk9/dev/jaxp/log?rev=%28author%28%22clanger%22%29+or+desc%28%22Contributed-by%3A+christoph.langer at sap.com%22%29%29+and+not+merge%28%29 > > [3] http://hg.openjdk.java.net/jdk9/dev/hotspot/log?rev=%28author%28%22clanger%22%29+or+desc%28%22Contributed-by%3A+christoph.langer at sap.com%22%29%29+and+not+merge%28%29 > > [4] http://openjdk.java.net/census#jdk9 > [5] http://openjdk.java.net/projects#committer-vote > From vladimir.x.ivanov at oracle.com Tue Jun 14 16:44:28 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Tue, 14 Jun 2016 19:44:28 +0300 Subject: CFV: New jdk9 Committer: Christoph Langer In-Reply-To: References: Message-ID: Vote: yes Best regards, Vladimir Ivanov On 6/14/16 7:36 PM, Volker Simonis wrote: > I hereby nominate Christoph Langer to jdk9 Committer. From aleksej.efimov at oracle.com Tue Jun 14 17:08:38 2016 From: aleksej.efimov at oracle.com (Aleks Efimov) Date: Tue, 14 Jun 2016 20:08:38 +0300 Subject: CFV: New jdk9 Committer: Christoph Langer In-Reply-To: References: Message-ID: <57603A16.8070709@oracle.com> Vote: yes On 14/06/16 19:36, Volker Simonis wrote: > I hereby nominate Christoph Langer to jdk9 Committer. > > Christoph is a long-term member of the SAP JVM support team at SAP. > He has a broad knowledge of the entire JDK as can be seen from the > variety of his changes which are in the class library [1], jaxp [2] as > well as in the hotspot repository [3]. > > Recently he has contributed 13 non-trivial changes to jdk9 (see below > for details). > > Votes are due by 20:00 CET, June 28, 2016. > > Only current JDK9 Committers [4] 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 [5]. > > Thanks, > Volker > > JDK: > > 8158519: Incorrect network mask and broadcast address on Linux when > there are multiple IPv4 addresses on an interface > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/ac3e32924dfb > > 8134505: Cleanup of "TimeZone_md.c" > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/4b948e5a3e77 > > 8133830: [solaris] Fix for potential memory leak in TimeZone_md.c, > function findJavaTZ_md() > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/e40abeb715f0 > > 8156521: Minor fixes and cleanups in NetworkInterface.c > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/fe3e1508653e > > 8149169: SSLSocketInputRecord.decodeInputRecord buffer overflow > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/d6a0479363ed > > 8139436: sun.security.mscapi.KeyStore might load incomplete data > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/05899a336fcd > > JAXP: > > 8153781: Issue in XMLScanner: > EXPECTED_SQUARE_BRACKET_TO_CLOSE_INTERNAL_SUBSET when skipping large > DOCTYPE section with CRLF at wrong place > http://hg.openjdk.java.net/jdk9/dev/jaxp/rev/8be2998d17d6 > > 8150704: XALAN: ERROR: 'No more DTM IDs are available' when > transforming with lots of temporary result trees > http://hg.openjdk.java.net/jdk9/dev/jaxp/rev/0fe7231b64a6 > > 8149915: enabling validate-annotations feature for xsd schema with > annotation causes NPE > http://hg.openjdk.java.net/jdk9/dev/jaxp/rev/95c223e6eaf0 > > 8150470: JCK: api/xsl/conf/copy/copy19 test failure > http://hg.openjdk.java.net/jdk9/dev/jaxp/rev/264df5d957cd > > HOTSPOT: > > 8130910: hsperfdata file is created in wrong directory and not cleaned > up if /tmp/hsperfdata_ has wrong permissions > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/efc17f03e5d4 > > 8150232: AIX cleanup: Integrate changes of 7178026 and others > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/ad7a71500f4a > > 8140244: Port fix of JDK-8075773 to AIX and possibly MacOSX > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/9ff773cd4ba2 > > > > [1] http://hg.openjdk.java.net/jdk9/dev/jdk/log?rev=%28author%28%22clanger%22%29+or+desc%28%22Contributed-by%3A+christoph.langer at sap.com%22%29%29+and+not+merge%28%29 > > [2] http://hg.openjdk.java.net/jdk9/dev/jaxp/log?rev=%28author%28%22clanger%22%29+or+desc%28%22Contributed-by%3A+christoph.langer at sap.com%22%29%29+and+not+merge%28%29 > > [3] http://hg.openjdk.java.net/jdk9/dev/hotspot/log?rev=%28author%28%22clanger%22%29+or+desc%28%22Contributed-by%3A+christoph.langer at sap.com%22%29%29+and+not+merge%28%29 > > [4] http://openjdk.java.net/census#jdk9 > [5] http://openjdk.java.net/projects#committer-vote From sean.coffey at oracle.com Tue Jun 14 17:46:13 2016 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Tue, 14 Jun 2016 18:46:13 +0100 Subject: CFV: New jdk9 Committer: Christoph Langer In-Reply-To: References: Message-ID: Vote: Yes Regards, Sean. On 14/06/2016 17:36, Volker Simonis wrote: > I hereby nominate Christoph Langer to jdk9 Committer. > > Christoph is a long-term member of the SAP JVM support team at SAP. > He has a broad knowledge of the entire JDK as can be seen from the > variety of his changes which are in the class library [1], jaxp [2] as > well as in the hotspot repository [3]. > > Recently he has contributed 13 non-trivial changes to jdk9 (see below > for details). > > Votes are due by 20:00 CET, June 28, 2016. > > Only current JDK9 Committers [4] 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 [5]. > > Thanks, > Volker > > JDK: > > 8158519: Incorrect network mask and broadcast address on Linux when > there are multiple IPv4 addresses on an interface > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/ac3e32924dfb > > 8134505: Cleanup of "TimeZone_md.c" > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/4b948e5a3e77 > > 8133830: [solaris] Fix for potential memory leak in TimeZone_md.c, > function findJavaTZ_md() > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/e40abeb715f0 > > 8156521: Minor fixes and cleanups in NetworkInterface.c > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/fe3e1508653e > > 8149169: SSLSocketInputRecord.decodeInputRecord buffer overflow > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/d6a0479363ed > > 8139436: sun.security.mscapi.KeyStore might load incomplete data > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/05899a336fcd > > JAXP: > > 8153781: Issue in XMLScanner: > EXPECTED_SQUARE_BRACKET_TO_CLOSE_INTERNAL_SUBSET when skipping large > DOCTYPE section with CRLF at wrong place > http://hg.openjdk.java.net/jdk9/dev/jaxp/rev/8be2998d17d6 > > 8150704: XALAN: ERROR: 'No more DTM IDs are available' when > transforming with lots of temporary result trees > http://hg.openjdk.java.net/jdk9/dev/jaxp/rev/0fe7231b64a6 > > 8149915: enabling validate-annotations feature for xsd schema with > annotation causes NPE > http://hg.openjdk.java.net/jdk9/dev/jaxp/rev/95c223e6eaf0 > > 8150470: JCK: api/xsl/conf/copy/copy19 test failure > http://hg.openjdk.java.net/jdk9/dev/jaxp/rev/264df5d957cd > > HOTSPOT: > > 8130910: hsperfdata file is created in wrong directory and not cleaned > up if /tmp/hsperfdata_ has wrong permissions > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/efc17f03e5d4 > > 8150232: AIX cleanup: Integrate changes of 7178026 and others > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/ad7a71500f4a > > 8140244: Port fix of JDK-8075773 to AIX and possibly MacOSX > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/9ff773cd4ba2 > > > > [1] http://hg.openjdk.java.net/jdk9/dev/jdk/log?rev=%28author%28%22clanger%22%29+or+desc%28%22Contributed-by%3A+christoph.langer at sap.com%22%29%29+and+not+merge%28%29 > > [2] http://hg.openjdk.java.net/jdk9/dev/jaxp/log?rev=%28author%28%22clanger%22%29+or+desc%28%22Contributed-by%3A+christoph.langer at sap.com%22%29%29+and+not+merge%28%29 > > [3] http://hg.openjdk.java.net/jdk9/dev/hotspot/log?rev=%28author%28%22clanger%22%29+or+desc%28%22Contributed-by%3A+christoph.langer at sap.com%22%29%29+and+not+merge%28%29 > > [4] http://openjdk.java.net/census#jdk9 > [5] http://openjdk.java.net/projects#committer-vote From goetz.lindenmaier at sap.com Tue Jun 14 18:56:58 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 14 Jun 2016 18:56:58 +0000 Subject: New jdk9 Committer: Christoph Langer In-Reply-To: References: Message-ID: <0c4209dd33714b5a96188361eeda8e53@DEWDFE13DE09.global.corp.sap> vote: yes Cheers, Goetz. > -----Original Message----- > From: jdk9-dev [mailto:jdk9-dev-bounces at openjdk.java.net] On Behalf Of > Volker Simonis > Sent: Tuesday, June 14, 2016 6:36 PM > To: jdk9-dev at openjdk.java.net > Subject: CFV: New jdk9 Committer: Christoph Langer > > I hereby nominate Christoph Langer to jdk9 Committer. > > Christoph is a long-term member of the SAP JVM support team at SAP. > He has a broad knowledge of the entire JDK as can be seen from the > variety of his changes which are in the class library [1], jaxp [2] as > well as in the hotspot repository [3]. > > Recently he has contributed 13 non-trivial changes to jdk9 (see below > for details). > > Votes are due by 20:00 CET, June 28, 2016. > > Only current JDK9 Committers [4] 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 [5]. > > Thanks, > Volker > > JDK: > > 8158519: Incorrect network mask and broadcast address on Linux when > there are multiple IPv4 addresses on an interface > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/ac3e32924dfb > > 8134505: Cleanup of "TimeZone_md.c" > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/4b948e5a3e77 > > 8133830: [solaris] Fix for potential memory leak in TimeZone_md.c, > function findJavaTZ_md() > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/e40abeb715f0 > > 8156521: Minor fixes and cleanups in NetworkInterface.c > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/fe3e1508653e > > 8149169: SSLSocketInputRecord.decodeInputRecord buffer overflow > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/d6a0479363ed > > 8139436: sun.security.mscapi.KeyStore might load incomplete data > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/05899a336fcd > > JAXP: > > 8153781: Issue in XMLScanner: > EXPECTED_SQUARE_BRACKET_TO_CLOSE_INTERNAL_SUBSET when skipping > large > DOCTYPE section with CRLF at wrong place > http://hg.openjdk.java.net/jdk9/dev/jaxp/rev/8be2998d17d6 > > 8150704: XALAN: ERROR: 'No more DTM IDs are available' when > transforming with lots of temporary result trees > http://hg.openjdk.java.net/jdk9/dev/jaxp/rev/0fe7231b64a6 > > 8149915: enabling validate-annotations feature for xsd schema with > annotation causes NPE > http://hg.openjdk.java.net/jdk9/dev/jaxp/rev/95c223e6eaf0 > > 8150470: JCK: api/xsl/conf/copy/copy19 test failure > http://hg.openjdk.java.net/jdk9/dev/jaxp/rev/264df5d957cd > > HOTSPOT: > > 8130910: hsperfdata file is created in wrong directory and not cleaned > up if /tmp/hsperfdata_ has wrong permissions > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/efc17f03e5d4 > > 8150232: AIX cleanup: Integrate changes of 7178026 and others > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/ad7a71500f4a > > 8140244: Port fix of JDK-8075773 to AIX and possibly MacOSX > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/9ff773cd4ba2 > > > > [1] > http://hg.openjdk.java.net/jdk9/dev/jdk/log?rev=%28author%28%22clange > r%22%29+or+desc%28%22Contributed- > by%3A+christoph.langer at sap.com%22%29%29+and+not+merge%28%29 > > [2] > http://hg.openjdk.java.net/jdk9/dev/jaxp/log?rev=%28author%28%22clang > er%22%29+or+desc%28%22Contributed- > by%3A+christoph.langer at sap.com%22%29%29+and+not+merge%28%29 > > [3] > http://hg.openjdk.java.net/jdk9/dev/hotspot/log?rev=%28author%28%22cl > anger%22%29+or+desc%28%22Contributed- > by%3A+christoph.langer at sap.com%22%29%29+and+not+merge%28%29 > > [4] http://openjdk.java.net/census#jdk9 > [5] http://openjdk.java.net/projects#committer-vote From david.holmes at oracle.com Tue Jun 14 21:26:24 2016 From: david.holmes at oracle.com (David Holmes) Date: Wed, 15 Jun 2016 07:26:24 +1000 Subject: CFV: New jdk9 Committer: Christoph Langer In-Reply-To: References: Message-ID: Vote: yes David On 15/06/2016 2:36 AM, Volker Simonis wrote: > I hereby nominate Christoph Langer to jdk9 Committer. > > Christoph is a long-term member of the SAP JVM support team at SAP. > He has a broad knowledge of the entire JDK as can be seen from the > variety of his changes which are in the class library [1], jaxp [2] as > well as in the hotspot repository [3]. > > Recently he has contributed 13 non-trivial changes to jdk9 (see below > for details). > > Votes are due by 20:00 CET, June 28, 2016. > > Only current JDK9 Committers [4] 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 [5]. > > Thanks, > Volker > > JDK: > > 8158519: Incorrect network mask and broadcast address on Linux when > there are multiple IPv4 addresses on an interface > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/ac3e32924dfb > > 8134505: Cleanup of "TimeZone_md.c" > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/4b948e5a3e77 > > 8133830: [solaris] Fix for potential memory leak in TimeZone_md.c, > function findJavaTZ_md() > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/e40abeb715f0 > > 8156521: Minor fixes and cleanups in NetworkInterface.c > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/fe3e1508653e > > 8149169: SSLSocketInputRecord.decodeInputRecord buffer overflow > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/d6a0479363ed > > 8139436: sun.security.mscapi.KeyStore might load incomplete data > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/05899a336fcd > > JAXP: > > 8153781: Issue in XMLScanner: > EXPECTED_SQUARE_BRACKET_TO_CLOSE_INTERNAL_SUBSET when skipping large > DOCTYPE section with CRLF at wrong place > http://hg.openjdk.java.net/jdk9/dev/jaxp/rev/8be2998d17d6 > > 8150704: XALAN: ERROR: 'No more DTM IDs are available' when > transforming with lots of temporary result trees > http://hg.openjdk.java.net/jdk9/dev/jaxp/rev/0fe7231b64a6 > > 8149915: enabling validate-annotations feature for xsd schema with > annotation causes NPE > http://hg.openjdk.java.net/jdk9/dev/jaxp/rev/95c223e6eaf0 > > 8150470: JCK: api/xsl/conf/copy/copy19 test failure > http://hg.openjdk.java.net/jdk9/dev/jaxp/rev/264df5d957cd > > HOTSPOT: > > 8130910: hsperfdata file is created in wrong directory and not cleaned > up if /tmp/hsperfdata_ has wrong permissions > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/efc17f03e5d4 > > 8150232: AIX cleanup: Integrate changes of 7178026 and others > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/ad7a71500f4a > > 8140244: Port fix of JDK-8075773 to AIX and possibly MacOSX > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/9ff773cd4ba2 > > > > [1] http://hg.openjdk.java.net/jdk9/dev/jdk/log?rev=%28author%28%22clanger%22%29+or+desc%28%22Contributed-by%3A+christoph.langer at sap.com%22%29%29+and+not+merge%28%29 > > [2] http://hg.openjdk.java.net/jdk9/dev/jaxp/log?rev=%28author%28%22clanger%22%29+or+desc%28%22Contributed-by%3A+christoph.langer at sap.com%22%29%29+and+not+merge%28%29 > > [3] http://hg.openjdk.java.net/jdk9/dev/hotspot/log?rev=%28author%28%22clanger%22%29+or+desc%28%22Contributed-by%3A+christoph.langer at sap.com%22%29%29+and+not+merge%28%29 > > [4] http://openjdk.java.net/census#jdk9 > [5] http://openjdk.java.net/projects#committer-vote > From huizhe.wang at oracle.com Tue Jun 14 21:54:05 2016 From: huizhe.wang at oracle.com (huizhe wang) Date: Tue, 14 Jun 2016 14:54:05 -0700 Subject: CFV: New jdk9 Committer: Christoph Langer In-Reply-To: References: Message-ID: <57607CFD.9080601@oracle.com> Vote: yes Joe (id: joehw) On 6/14/2016 9:36 AM, Volker Simonis wrote: > I hereby nominate Christoph Langer to jdk9 Committer. From dalibor.topic at oracle.com Tue Jun 14 22:04:44 2016 From: dalibor.topic at oracle.com (dalibor topic) Date: Wed, 15 Jun 2016 00:04:44 +0200 Subject: CFV: New jdk9 Committer: Christoph Langer In-Reply-To: <6ac76d9b-8a16-8e1e-3b87-b9e5870bfa7f@oracle.com> References: <6ac76d9b-8a16-8e1e-3b87-b9e5870bfa7f@oracle.com> Message-ID: <718f6afd-beef-69d8-e615-1372b78bd725@oracle.com> Vote: Yes. -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From alejandro.murillo at oracle.com Wed Jun 15 03:25:26 2016 From: alejandro.murillo at oracle.com (Alejandro Murillo) Date: Tue, 14 Jun 2016 21:25:26 -0600 Subject: jdk9-dev: HotSpot Message-ID: <7d1d7857-b7cc-489b-401a-8b54924dbc48@oracle.com> jdk9-hs-2016-06-10 has been integrated into jdk9-dev. http://hg.openjdk.java.net/jdk9/dev/rev/405d811c0d7b http://hg.openjdk.java.net/jdk9/dev/corba/rev/e33a34cc5519 http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/196f9c7b4c60 http://hg.openjdk.java.net/jdk9/dev/jaxp/rev/dfaa0e5e981c http://hg.openjdk.java.net/jdk9/dev/jaxws/rev/c42decd28bbf http://hg.openjdk.java.net/jdk9/dev/jdk/rev/591fb6f93c40 http://hg.openjdk.java.net/jdk9/dev/langtools/rev/5771c5f60aa4 http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/9ed859b4faaf Component : VM Status : Go for integration Date : 06/14/2016 at 16:30 MSK Tested By : VM SQE &dmitry.fazunenko at oracle.com Bundles : 2016-06-10-221413.amurillo.jdk9-hs-2016-06-10-snapshot Testing: 0 new failures, 1044 known failures, 513354 passed. Issues and Notes: No detailed analysis. No stoppers have been detected so far. Go for integration CRs for testing: 8138705: Kitchen sink stress test fails 8152239: hotspot/test/gc/TestSmallHeap.java failed in jdk9 8152404: Stabilize PackageEntry::package_exports_do 8154750: Add missing OrderAccess operations to ClassLoaderData lock-free data structures 8155009: [TESTBUG] jstack subtest of BasicLauncherTest should not be executed under OS X 8155936: Boolean value should be set 1/0 or true/false via VM.set_flag jcmd 8156537: Tools using MonitoredVmUtil do not parse module in cmdline correctly 8156923: [ppc] Implement "JEP 270: Reserved Stack Areas for Critical Sections". 8157189: 'iload_w' in shared class is not interpreted correctly. 8157954: [TESTBUG] G1 tests fail with defined MaxGCPauseMillis 8158397: Crash: assert(save_resolved_method == resolved_method()) failed: does this change? -- Alejandro From serguei.spitsyn at oracle.com Wed Jun 15 04:21:54 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 14 Jun 2016 21:21:54 -0700 Subject: CFV: New jdk9 Committer: Christoph Langer In-Reply-To: References: Message-ID: <5760D7E2.7090504@oracle.com> Vote: yes From volker.simonis at gmail.com Wed Jun 15 07:16:01 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 15 Jun 2016 09:16:01 +0200 Subject: CFV: New jdk9 Committer: Christoph Langer In-Reply-To: References: Message-ID: Vote: yes On Tue, Jun 14, 2016 at 6:36 PM, Volker Simonis wrote: > I hereby nominate Christoph Langer to jdk9 Committer. > > Christoph is a long-term member of the SAP JVM support team at SAP. > He has a broad knowledge of the entire JDK as can be seen from the > variety of his changes which are in the class library [1], jaxp [2] as > well as in the hotspot repository [3]. > > Recently he has contributed 13 non-trivial changes to jdk9 (see below > for details). > > Votes are due by 20:00 CET, June 28, 2016. > > Only current JDK9 Committers [4] 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 [5]. > > Thanks, > Volker > > JDK: > > 8158519: Incorrect network mask and broadcast address on Linux when > there are multiple IPv4 addresses on an interface > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/ac3e32924dfb > > 8134505: Cleanup of "TimeZone_md.c" > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/4b948e5a3e77 > > 8133830: [solaris] Fix for potential memory leak in TimeZone_md.c, > function findJavaTZ_md() > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/e40abeb715f0 > > 8156521: Minor fixes and cleanups in NetworkInterface.c > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/fe3e1508653e > > 8149169: SSLSocketInputRecord.decodeInputRecord buffer overflow > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/d6a0479363ed > > 8139436: sun.security.mscapi.KeyStore might load incomplete data > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/05899a336fcd > > JAXP: > > 8153781: Issue in XMLScanner: > EXPECTED_SQUARE_BRACKET_TO_CLOSE_INTERNAL_SUBSET when skipping large > DOCTYPE section with CRLF at wrong place > http://hg.openjdk.java.net/jdk9/dev/jaxp/rev/8be2998d17d6 > > 8150704: XALAN: ERROR: 'No more DTM IDs are available' when > transforming with lots of temporary result trees > http://hg.openjdk.java.net/jdk9/dev/jaxp/rev/0fe7231b64a6 > > 8149915: enabling validate-annotations feature for xsd schema with > annotation causes NPE > http://hg.openjdk.java.net/jdk9/dev/jaxp/rev/95c223e6eaf0 > > 8150470: JCK: api/xsl/conf/copy/copy19 test failure > http://hg.openjdk.java.net/jdk9/dev/jaxp/rev/264df5d957cd > > HOTSPOT: > > 8130910: hsperfdata file is created in wrong directory and not cleaned > up if /tmp/hsperfdata_ has wrong permissions > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/efc17f03e5d4 > > 8150232: AIX cleanup: Integrate changes of 7178026 and others > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/ad7a71500f4a > > 8140244: Port fix of JDK-8075773 to AIX and possibly MacOSX > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/9ff773cd4ba2 > > > > [1] http://hg.openjdk.java.net/jdk9/dev/jdk/log?rev=%28author%28%22clanger%22%29+or+desc%28%22Contributed-by%3A+christoph.langer at sap.com%22%29%29+and+not+merge%28%29 > > [2] http://hg.openjdk.java.net/jdk9/dev/jaxp/log?rev=%28author%28%22clanger%22%29+or+desc%28%22Contributed-by%3A+christoph.langer at sap.com%22%29%29+and+not+merge%28%29 > > [3] http://hg.openjdk.java.net/jdk9/dev/hotspot/log?rev=%28author%28%22clanger%22%29+or+desc%28%22Contributed-by%3A+christoph.langer at sap.com%22%29%29+and+not+merge%28%29 > > [4] http://openjdk.java.net/census#jdk9 > [5] http://openjdk.java.net/projects#committer-vote From chris.hegarty at oracle.com Wed Jun 15 07:29:22 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 15 Jun 2016 08:29:22 +0100 Subject: CFV: New jdk9 Committer: Christoph Langer In-Reply-To: References: Message-ID: Vote: Yes -Chris. > On 14 Jun 2016, at 17:36, Volker Simonis wrote: > > I hereby nominate Christoph Langer to jdk9 Committer. > > Christoph is a long-term member of the SAP JVM support team at SAP. > He has a broad knowledge of the entire JDK as can be seen from the > variety of his changes which are in the class library [1], jaxp [2] as > well as in the hotspot repository [3]. > > Recently he has contributed 13 non-trivial changes to jdk9 (see below > for details). > > Votes are due by 20:00 CET, June 28, 2016. > > Only current JDK9 Committers [4] 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 [5]. > > Thanks, > Volker > > JDK: > > 8158519: Incorrect network mask and broadcast address on Linux when > there are multiple IPv4 addresses on an interface > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/ac3e32924dfb > > 8134505: Cleanup of "TimeZone_md.c" > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/4b948e5a3e77 > > 8133830: [solaris] Fix for potential memory leak in TimeZone_md.c, > function findJavaTZ_md() > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/e40abeb715f0 > > 8156521: Minor fixes and cleanups in NetworkInterface.c > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/fe3e1508653e > > 8149169: SSLSocketInputRecord.decodeInputRecord buffer overflow > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/d6a0479363ed > > 8139436: sun.security.mscapi.KeyStore might load incomplete data > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/05899a336fcd > > JAXP: > > 8153781: Issue in XMLScanner: > EXPECTED_SQUARE_BRACKET_TO_CLOSE_INTERNAL_SUBSET when skipping large > DOCTYPE section with CRLF at wrong place > http://hg.openjdk.java.net/jdk9/dev/jaxp/rev/8be2998d17d6 > > 8150704: XALAN: ERROR: 'No more DTM IDs are available' when > transforming with lots of temporary result trees > http://hg.openjdk.java.net/jdk9/dev/jaxp/rev/0fe7231b64a6 > > 8149915: enabling validate-annotations feature for xsd schema with > annotation causes NPE > http://hg.openjdk.java.net/jdk9/dev/jaxp/rev/95c223e6eaf0 > > 8150470: JCK: api/xsl/conf/copy/copy19 test failure > http://hg.openjdk.java.net/jdk9/dev/jaxp/rev/264df5d957cd > > HOTSPOT: > > 8130910: hsperfdata file is created in wrong directory and not cleaned > up if /tmp/hsperfdata_ has wrong permissions > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/efc17f03e5d4 > > 8150232: AIX cleanup: Integrate changes of 7178026 and others > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/ad7a71500f4a > > 8140244: Port fix of JDK-8075773 to AIX and possibly MacOSX > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/9ff773cd4ba2 > > > > [1] http://hg.openjdk.java.net/jdk9/dev/jdk/log?rev=%28author%28%22clanger%22%29+or+desc%28%22Contributed-by%3A+christoph.langer at sap.com%22%29%29+and+not+merge%28%29 > > [2] http://hg.openjdk.java.net/jdk9/dev/jaxp/log?rev=%28author%28%22clanger%22%29+or+desc%28%22Contributed-by%3A+christoph.langer at sap.com%22%29%29+and+not+merge%28%29 > > [3] http://hg.openjdk.java.net/jdk9/dev/hotspot/log?rev=%28author%28%22clanger%22%29+or+desc%28%22Contributed-by%3A+christoph.langer at sap.com%22%29%29+and+not+merge%28%29 > > [4] http://openjdk.java.net/census#jdk9 > [5] http://openjdk.java.net/projects#committer-vote From daniel.fuchs at oracle.com Wed Jun 15 16:41:57 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 15 Jun 2016 17:41:57 +0100 Subject: CFV: New JDK 9 Reviewer: Michael Haupt In-Reply-To: References: Message-ID: <2029d10a-f7c0-29f7-6ae3-f48f05ae73e7@oracle.com> Vote: yes -- daniel On 31/05/16 16:52, Jim Laskey (Oracle) wrote: > I hereby nominate Michael Haupt to JDK 9 Reviewer. From daniel.fuchs at oracle.com Wed Jun 15 16:43:00 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 15 Jun 2016 17:43:00 +0100 Subject: CFV: New JDK 9 Committer: Felix Yang In-Reply-To: <75ca884a-fa55-2cce-fdee-3ce8d8527dab@Oracle.com> References: <2b16fc92-ae12-3bf7-fbac-3b13d96a6757@oracle.com> <75ca884a-fa55-2cce-fdee-3ce8d8527dab@Oracle.com> Message-ID: <71d39d4b-fcaa-c631-6997-075953033288@oracle.com> Vote: yes On 06/06/16 14:55, Roger Riggs wrote: > I hereby nominate Felix Yang (xiaofeya) to JDK 9 Committer. From Roger.Riggs at Oracle.com Wed Jun 15 16:56:39 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Wed, 15 Jun 2016 12:56:39 -0400 Subject: CFV: New JDK 9 Committer: Felix Yang In-Reply-To: <75ca884a-fa55-2cce-fdee-3ce8d8527dab@Oracle.com> References: <2b16fc92-ae12-3bf7-fbac-3b13d96a6757@oracle.com> <75ca884a-fa55-2cce-fdee-3ce8d8527dab@Oracle.com> Message-ID: Vote: yes On 6/6/2016 9:55 AM, Roger Riggs wrote: > I hereby nominate Felix Yang (xiaofeya) to JDK 9 Committer. From Roger.Riggs at Oracle.com Wed Jun 15 17:29:16 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Wed, 15 Jun 2016 13:29:16 -0400 Subject: CFV: New jdk9 Committer: Christoph Langer In-Reply-To: References: Message-ID: <71c0dfe9-0309-281b-7552-045b187fc386@Oracle.com> Vote: yes On 6/14/2016 12:36 PM, Volker Simonis wrote: > I hereby nominate Christoph Langer to jdk9 Committer. From vladimir.kozlov at oracle.com Wed Jun 15 19:23:29 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 15 Jun 2016 12:23:29 -0700 Subject: JDK 9 is not (yet) Feature Complete -- how will we get there? In-Reply-To: <20160610072437.975638333eggemoggin.niobe.net> References: <20160610072437.975638333eggemoggin.niobe.net> Message-ID: <376b542b-69cb-a4f3-a539-70f30ded42c9@oracle.com> I would suggest to have a link to the latest webrev in JBS, when it is ready, to see the scope of changes. And to have ability to change jdk9-fc-yes (approved) to jdk9-fc-no (rejected) if scope of final changes is larger than initially described in FC Extension Request. thanks, Vladimir On 6/10/16 7:24 AM, mark.reinhold at oracle.com wrote: > The JDK 9 schedule [1] lists a date for the Feature Complete milestone > of 2016/5/26, about two weeks ago. There's been some concern that this > means that the JDK 9 (and hence Java SE 9) feature set is somehow frozen, > but that's not the case. > > The milestones listed in the JDK 9 schedule are condition-driven rather > than date-driven, as noted along with the milestone definitions [2]. We > try our best to reach the goal of each milestone by its scheduled date. > If we miss a date then we don't just blindly constrain further work so as > to fit the date, we instead manage the remaining changes relevant to the > milestone so as to reach its goal in a reasonable time frame without > putting the final GA date at undue risk. When we finally do reach the > goal then we declare the milestone on that date. > > The goal of the Feature Complete milestone is to get all of the planned > features, i.e., JEPs, and smaller enhancements integrated into the JDK 9 > master forest, together with their unit tests. As of today most JEPs > targeted to JDK 9 have been completed [3]. Fifteen JEPs remain, and a > number of small enhancements are listed as intended for JDK 9 but are > still either open or in progress. > > To manage the remaining JEPs and small enhancements so that we can reach > the Feature Complete state in a timely fashion I hereby propose the > following process: > > - If you own a JEP or a small enhancement that is not yet complete then > you can request an FC extension as follows: Update the JBS issue to > add a comment whose first line is "FC Extension Request". In that > comment describe the remaining work to be done, the risk level, a > brief justification, and your best estimate of the date by which the > feature will be complete. Add the label "jdk9-fc-request" to the > issue. > > - The Area Leads, relevant Group Leads, and I will review such requests > on a regular basis, at least weekly if not more often. One of us > will take one of the following actions: > > - Approve the request by adding the label "jdk9-fc-yes". > > - Reject the request by adding the label "jdk9-fc-no", along > with a comment describing the reason for this action. > > - Request more information by adding the label "jdk9-fc-nmi" > ("nmi" = "needs more information"), along with a comment > describing what information is requested. > > - If you're asked to provide more information for an FC extension > request then please do so in a new comment in the issue, and then > remove the "jdk9-fc-nmi" label so that we see that it's ready for > re-review. > > - If your request is approved then update the issue's due date to the > expected completion date. > > - If you own a JEP that's targeted to JDK 9, but won't make it, then > please propose to drop it [4]; this will move the JEP back to the > Candidate state unless there are strong objections. If you own a > small enhancement whose fix version is 9, but won't make it, then > please clear the fix-version field. > > If a JEP has been granted an FC extension then enhancement issues that > block the JEP's issue are automatically considered to have FC extensions. > > If a JEP has not yet been targeted to JDK 9 then you can still propose to > target it to the release, but going forward the bar for accepting new > features will be increasingly high. > > For the record, the Area Leads are Mikael Vidstedt (VM) and Brian Goetz > (Language and Libraries). The relevant Group Leads are as follows, per > the Census [5]: > > Artem Ananiev - AWT > Alan Bateman - Core Libraries > Tim Bell - Build > Daniel D. Daugherty - Serviceability > Jonathan Gibbons - Compiler > Vladimir Kozlov - HotSpot > Michael McMahon - Networking > Sean Mullan - Security > Masayoshi Okutsu - Internationalization > Pavel Porvatov - Swing > Phil Race - 2D Graphics & Sound > Dalibor Topic - Porters > > JDK 9 Committers are invited to comment on this process proposal. If no > serious objections are raised in one week's time, by 15:00 UTC on 17 June > 2016, then this is the process that we'll use. > > In anticipation that we will use this process, more or less, I encourage > owners of not-yet-complete JEPs and small enhancements to go ahead and > request extensions as described above, if desired, so that we can move > quickly once the process is in place. > > - Mark > > > [1] http://openjdk.java.net/projects/jdk9/ > [2] http://openjdk.java.net/projects/jdk8/milestones#definitions > [3] http://j.mp/jdk9-features-jbs > [4] http://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html#Proposed-to-Drop > [5] http://openjdk.java.net/census > From lana.steuck at oracle.com Wed Jun 15 21:42:56 2016 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 15 Jun 2016 21:42:56 GMT Subject: jdk9-b123: dev Message-ID: <201606152142.u5FLguWi028548@scaaa563.us.oracle.com> http://hg.openjdk.java.net/jdk9/jdk9/rev/405d811c0d7b http://hg.openjdk.java.net/jdk9/jdk9/nashorn/rev/9ed859b4faaf http://hg.openjdk.java.net/jdk9/jdk9/langtools/rev/d0c742ddfb01 http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/c40c8739bcdc http://hg.openjdk.java.net/jdk9/jdk9/jaxws/rev/c42decd28bbf http://hg.openjdk.java.net/jdk9/jdk9/jaxp/rev/3c19ab8742c1 http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/75f81e1fecfb http://hg.openjdk.java.net/jdk9/jdk9/corba/rev/e33a34cc5519 --- All the fixes will be tested during promotion (no PIT testing at this point): List of all fixes: =================== JDK-5041778 core-libs (ann) AnnotationFormatError if "default" Class type not found JDK-8040211 core-libs Update LSR datafile for BCP 47 JDK-8041924 core-libs [TESTBUG] sun/net/www/http/ChunkedOutputStream/checkError.java fails o JDK-8047780 core-libs [Doc] Locale.LanguageRange() throws an undocumented IAE when range is JDK-8073611 core-libs javax.script.ScriptEngineFactory: formatting error in javadoc of getPa JDK-8139507 core-libs WARNING: Could not open/create prefs root node Software\JavaSoft\Prefs JDK-8147585 core-libs Annotations with lambda expressions has parameter result in wrong beha JDK-8151913 core-libs Fix module dependencies in java/net tests JDK-8153666 core-libs Optimize Formatter.formatMessage JDK-8156650 core-libs Simplify Text message support in WebSocket API JDK-8156693 core-libs Improve usability of CompletableFuture use in WebSocket API JDK-8158519 core-libs Incorrect network mask and broadcast address on Linux when there are m JDK-8158851 core-libs MH.publicLookup() init circularity, triggered by custom SecurityManage JDK-8158870 core-libs Temporarily problem list DGCDeadLock.java on Mac JDK-8158881 core-libs Doc typo in src/../java/net/URI.java JDK-8158922 core-libs jjs tab completion of Java classes shows package-private, "hidden" cla JDK-8158933 core-libs String concat stringifiers setup should avoid unnecessary lookups JDK-8159012 core-libs Problem list sun/net/www/http/ChunkedOutputStream/checkError.java JDK-8159031 core-libs jjs throws NoSuchFileException if ~/.jjs.history does not exist JDK-8159034 core-libs 4 nashorn ant tests fail with latest jdk9-dev build with IncompatibleC JDK-8159039 core-libs sun/net/httpclient/hpack/HeaderTableTest.java fails on some locales JDK-8159220 core-libs Preserve position info in module import and export entries JDK-8159334 core-libs ModuleDescriptor retains overlapping sets for all and concealed packag JDK-8159378 core-libs Correct wording of RoundEnvironment.getElementsAnnotatedWithAny JDK-8055735 infrastructure JDK_FILTER is broken JDK-8144911 infrastructure Consider having modifications to jdk.jlink trigger recreation of all j JDK-8158535 infrastructure Configure script uses basic tools directly in many places JDK-8159047 infrastructure Disable redundant build steps when creating buildjdk JDK-8159186 infrastructure jdk/test/Makefile: allow users to set verbosity JDK-8158458 other-libs Update references from "1.9" to "9" JDK-8062758 security-libs Update java/security/Security/ClassLoaderDeadlock/Deadlock2.sh with th JDK-8151836 security-libs keytool -importkeystore -help does not list option -destprotected JDK-8153632 security-libs Update security tests to eliminate dependency on JAXB JDK-8157308 security-libs Make AbstractDrbg non-Serializable JDK-8157495 security-libs SHA-3 Hash algorithm performance improvements (~12x speedup) JDK-8157603 security-libs TestCipher.java doesn't check one of the decrypted message as expected JDK-8157627 security-libs Ucrypto prov need to workaround the renaming of CK_AES_GCM_PARAMS star JDK-8157665 security-libs ProblemList.txt needs to be updated as 7041639 closed JDK-8157896 security-libs TestDSAGenParameterSpec.java test fails with timeout JDK-8157898 security-libs SupportedDSAParamGen.java failed with timeout JDK-8157925 security-libs Typo in the API documentation of X509KeyManager JDK-8158442 security-libs SecureRandomParameters missing "@since 9" JDK-8158534 security-libs DrbgParameters strength parameter is underspecified if < -1 JDK-8158620 security-libs Enable debug option for sun/security/ec/TestEC.java JDK-8158978 security-libs ALPN not working when values are set directly on a SSLServerSocket JDK-8037804 tools Implement specified test for related functional interface types JDK-8139829 tools JShell API: No use of fields to return information from public types JDK-8144767 tools Fix handling of capture variables in most-specific test JDK-8155581 tools jshell tool: replace use of Option.get() JDK-8155880 tools Fix langtools usage of the deprecated Class.newInstance method JDK-8156077 tools Support javadoc tags in module documentation JDK-8156994 tools jimage --help is not helpful JDK-8156995 tools jimage: extract specified contents JDK-8158123 tools NPE when the annotations is used in export-to of module-info JDK-8158174 tools jshell tool: leaks threads waiting on StopDetectingInputStream JDK-8158402 tools jlink and related tools should use PathPatterns for all pattern operat JDK-8158630 tools Langtools Intellij project is missing some source roots JDK-8159228 tools Exclude jlink tests until jrt-fs patterns are rectified JDK-8159263 tools Problem list tools/jmod/JmodTest.java From paul.sandoz at oracle.com Thu Jun 16 03:54:40 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 15 Jun 2016 20:54:40 -0700 Subject: RFR 8158039 VarHandle float/double field/array access should support CAS/set/add atomics In-Reply-To: <575FC8D5.8050900@redhat.com> References: <23FAF71F-F8B9-4AD6-9BF3-896795540788@oracle.com> <6ed640e8-f581-e81d-3e77-ef47405f9618@oracle.com> <57561996.4000501@oracle.com> <951844EF-D517-4BF5-861A-81769EA1C306@oracle.com> <8d668cf7-1f40-8310-117e-267cefe2ab5c@oracle.com> <575FC8D5.8050900@redhat.com> Message-ID: Hi Joe, Andrew, > On 14 Jun 2016, at 02:05, Andrew Haley wrote: > > On 14/06/16 05:09, joe darcy wrote: >> I suggest also pointing out that a bitwise comparison distinguishes -0.0 >> from +0.0; they compare as == under the built-in operation. > > Indeed so, yes. This is particularly likely to bite people who have > a zero created by, say, an algorithm which converges on zero with > successive terms which alternate sign. Eww. > In a previously unpublished incarnation i did talk about -0.0/+0.0, then i dropped it... Here is an updated revision of the note: 1226 * @apiNote 1227 * Bitwise comparison of {@code float} values or {@code double} values, 1228 * as performed by the numeric and atomic update access modes, differ 1229 * from the primitive {@code ==} operator and the {@link Float#equals} 1230 * and {@link Double#equals} methods, specifically with respect to 1231 * comparing NaN values or comparing {@code -0.0} with {@code +0.0}. 1232 * Care should be taken when performing a compare and set or a compare 1233 * and exchange operation with such values since the operation may 1234 * unexpectedly fail. 1235 * There are many possible NaN values that are considered to be 1236 * {@code NaN} in Java, although no IEEE 754 floating-point operation 1237 * provided by Java can distinguish between them. Operation failure can 1238 * occur if the expected or witness value is a NaN value and it is 1239 * transformed (perhaps in a platform specific manner) into another NaN 1240 * value, and thus has a different bitwise representation (see 1241 * {@link Float#intBitsToFloat} or {@link Double#longBitsToDouble} for more 1242 * details). 1243 * The values {@code -0.0} and {@code +0.0} have different bitwise 1244 * representations but are considered equal when using the primitive 1245 * {@code ==} operator. Operation failure can occur if, for example, a 1246 * numeric algorithm computes an expected value to be say {@code -0.0} 1247 * and previously computed the witness value to be say {@code +0.0}. Paul. From thomas.stuefe at gmail.com Thu Jun 16 08:22:25 2016 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 16 Jun 2016 10:22:25 +0200 Subject: New jdk9 Committer: Christoph Langer In-Reply-To: <0c4209dd33714b5a96188361eeda8e53@DEWDFE13DE09.global.corp.sap> References: <0c4209dd33714b5a96188361eeda8e53@DEWDFE13DE09.global.corp.sap> Message-ID: vote: yes! ..Thomas On Tue, Jun 14, 2016 at 8:56 PM, Lindenmaier, Goetz < goetz.lindenmaier at sap.com> wrote: > vote: yes > > Cheers, > Goetz. > > > -----Original Message----- > > From: jdk9-dev [mailto:jdk9-dev-bounces at openjdk.java.net] On Behalf Of > > Volker Simonis > > Sent: Tuesday, June 14, 2016 6:36 PM > > To: jdk9-dev at openjdk.java.net > > Subject: CFV: New jdk9 Committer: Christoph Langer > > > > I hereby nominate Christoph Langer to jdk9 Committer. > > > > Christoph is a long-term member of the SAP JVM support team at SAP. > > He has a broad knowledge of the entire JDK as can be seen from the > > variety of his changes which are in the class library [1], jaxp [2] as > > well as in the hotspot repository [3]. > > > > Recently he has contributed 13 non-trivial changes to jdk9 (see below > > for details). > > > > Votes are due by 20:00 CET, June 28, 2016. > > > > Only current JDK9 Committers [4] 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 [5]. > > > > Thanks, > > Volker > > > > JDK: > > > > 8158519: Incorrect network mask and broadcast address on Linux when > > there are multiple IPv4 addresses on an interface > > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/ac3e32924dfb > > > > 8134505: Cleanup of "TimeZone_md.c" > > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/4b948e5a3e77 > > > > 8133830: [solaris] Fix for potential memory leak in TimeZone_md.c, > > function findJavaTZ_md() > > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/e40abeb715f0 > > > > 8156521: Minor fixes and cleanups in NetworkInterface.c > > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/fe3e1508653e > > > > 8149169: SSLSocketInputRecord.decodeInputRecord buffer overflow > > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/d6a0479363ed > > > > 8139436: sun.security.mscapi.KeyStore might load incomplete data > > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/05899a336fcd > > > > JAXP: > > > > 8153781: Issue in XMLScanner: > > EXPECTED_SQUARE_BRACKET_TO_CLOSE_INTERNAL_SUBSET when skipping > > large > > DOCTYPE section with CRLF at wrong place > > http://hg.openjdk.java.net/jdk9/dev/jaxp/rev/8be2998d17d6 > > > > 8150704: XALAN: ERROR: 'No more DTM IDs are available' when > > transforming with lots of temporary result trees > > http://hg.openjdk.java.net/jdk9/dev/jaxp/rev/0fe7231b64a6 > > > > 8149915: enabling validate-annotations feature for xsd schema with > > annotation causes NPE > > http://hg.openjdk.java.net/jdk9/dev/jaxp/rev/95c223e6eaf0 > > > > 8150470: JCK: api/xsl/conf/copy/copy19 test failure > > http://hg.openjdk.java.net/jdk9/dev/jaxp/rev/264df5d957cd > > > > HOTSPOT: > > > > 8130910: hsperfdata file is created in wrong directory and not cleaned > > up if /tmp/hsperfdata_ has wrong permissions > > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/efc17f03e5d4 > > > > 8150232: AIX cleanup: Integrate changes of 7178026 and others > > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/ad7a71500f4a > > > > 8140244: Port fix of JDK-8075773 to AIX and possibly MacOSX > > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/9ff773cd4ba2 > > > > > > > > [1] > > http://hg.openjdk.java.net/jdk9/dev/jdk/log?rev=%28author%28%22clange > > r%22%29+or+desc%28%22Contributed- > > by%3A+christoph.langer at sap.com%22%29%29+and+not+merge%28%29 > > > > [2] > > http://hg.openjdk.java.net/jdk9/dev/jaxp/log?rev=%28author%28%22clang > > er%22%29+or+desc%28%22Contributed- > > by%3A+christoph.langer at sap.com%22%29%29+and+not+merge%28%29 > > > > [3] > > http://hg.openjdk.java.net/jdk9/dev/hotspot/log?rev=%28author%28%22cl > > anger%22%29+or+desc%28%22Contributed- > > by%3A+christoph.langer at sap.com%22%29%29+and+not+merge%28%29 > > > > [4] http://openjdk.java.net/census#jdk9 > > [5] http://openjdk.java.net/projects#committer-vote > From james.laskey at oracle.com Thu Jun 16 11:00:50 2016 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Thu, 16 Jun 2016 08:00:50 -0300 Subject: Result: New JDK 9 Reviewer: Michael Haupt Message-ID: Voting for Michael Haupt [1] is now closed. Yes: 21 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. Jim Laskey [1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-May/004383.html From michael.haupt at oracle.com Thu Jun 16 13:51:19 2016 From: michael.haupt at oracle.com (Michael Haupt) Date: Thu, 16 Jun 2016 15:51:19 +0200 Subject: Result: New JDK 9 Reviewer: Michael Haupt In-Reply-To: References: Message-ID: ... thanks, everyone! :-) Best, Michael > Am 16.06.2016 um 13:00 schrieb Jim Laskey (Oracle) : > > Voting for Michael Haupt [1] is now closed. > > Yes: 21 > Veto: 0 > Abstain: 0 > > According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. > > Jim Laskey > > [1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-May/004383.html -- Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331 200 7561 Oracle Java Platform Group | LangTools Team | Nashorn Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstra?e 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From michael.haupt at oracle.com Thu Jun 16 13:52:28 2016 From: michael.haupt at oracle.com (Michael Haupt) Date: Thu, 16 Jun 2016 15:52:28 +0200 Subject: CFV: New jdk9 Committer: Christoph Langer In-Reply-To: References: Message-ID: <9E05656B-4214-491B-927B-AB26C7257A78@oracle.com> Vote: yes. Best, Michael > Am 14.06.2016 um 18:36 schrieb Volker Simonis : > I hereby nominate Christoph Langer to jdk9 Committer. -- Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331 200 7561 Oracle Java Platform Group | LangTools Team | Nashorn Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstra?e 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From maurizio.cimadamore at oracle.com Thu Jun 16 15:11:33 2016 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 16 Jun 2016 16:11:33 +0100 Subject: CFV: New jdk9 Committer: Christoph Langer In-Reply-To: References: Message-ID: <5762C1A5.5090207@oracle.com> Vote: yes Maurizio On 14/06/16 17:36, Volker Simonis wrote: > I hereby nominate Christoph Langer to jdk9 Committer. > > Christoph is a long-term member of the SAP JVM support team at SAP. > He has a broad knowledge of the entire JDK as can be seen from the > variety of his changes which are in the class library [1], jaxp [2] as > well as in the hotspot repository [3]. > > Recently he has contributed 13 non-trivial changes to jdk9 (see below > for details). > > Votes are due by 20:00 CET, June 28, 2016. > > Only current JDK9 Committers [4] 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 [5]. > > Thanks, > Volker > > JDK: > > 8158519: Incorrect network mask and broadcast address on Linux when > there are multiple IPv4 addresses on an interface > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/ac3e32924dfb > > 8134505: Cleanup of "TimeZone_md.c" > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/4b948e5a3e77 > > 8133830: [solaris] Fix for potential memory leak in TimeZone_md.c, > function findJavaTZ_md() > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/e40abeb715f0 > > 8156521: Minor fixes and cleanups in NetworkInterface.c > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/fe3e1508653e > > 8149169: SSLSocketInputRecord.decodeInputRecord buffer overflow > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/d6a0479363ed > > 8139436: sun.security.mscapi.KeyStore might load incomplete data > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/05899a336fcd > > JAXP: > > 8153781: Issue in XMLScanner: > EXPECTED_SQUARE_BRACKET_TO_CLOSE_INTERNAL_SUBSET when skipping large > DOCTYPE section with CRLF at wrong place > http://hg.openjdk.java.net/jdk9/dev/jaxp/rev/8be2998d17d6 > > 8150704: XALAN: ERROR: 'No more DTM IDs are available' when > transforming with lots of temporary result trees > http://hg.openjdk.java.net/jdk9/dev/jaxp/rev/0fe7231b64a6 > > 8149915: enabling validate-annotations feature for xsd schema with > annotation causes NPE > http://hg.openjdk.java.net/jdk9/dev/jaxp/rev/95c223e6eaf0 > > 8150470: JCK: api/xsl/conf/copy/copy19 test failure > http://hg.openjdk.java.net/jdk9/dev/jaxp/rev/264df5d957cd > > HOTSPOT: > > 8130910: hsperfdata file is created in wrong directory and not cleaned > up if /tmp/hsperfdata_ has wrong permissions > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/efc17f03e5d4 > > 8150232: AIX cleanup: Integrate changes of 7178026 and others > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/ad7a71500f4a > > 8140244: Port fix of JDK-8075773 to AIX and possibly MacOSX > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/9ff773cd4ba2 > > > > [1] http://hg.openjdk.java.net/jdk9/dev/jdk/log?rev=%28author%28%22clanger%22%29+or+desc%28%22Contributed-by%3A+christoph.langer at sap.com%22%29%29+and+not+merge%28%29 > > [2] http://hg.openjdk.java.net/jdk9/dev/jaxp/log?rev=%28author%28%22clanger%22%29+or+desc%28%22Contributed-by%3A+christoph.langer at sap.com%22%29%29+and+not+merge%28%29 > > [3] http://hg.openjdk.java.net/jdk9/dev/hotspot/log?rev=%28author%28%22clanger%22%29+or+desc%28%22Contributed-by%3A+christoph.langer at sap.com%22%29%29+and+not+merge%28%29 > > [4] http://openjdk.java.net/census#jdk9 > [5] http://openjdk.java.net/projects#committer-vote From vladimir.x.ivanov at oracle.com Fri Jun 17 11:13:20 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 17 Jun 2016 14:13:20 +0300 Subject: RFR 8158039 VarHandle float/double field/array access should support CAS/set/add atomics In-Reply-To: References: <23FAF71F-F8B9-4AD6-9BF3-896795540788@oracle.com> <6ed640e8-f581-e81d-3e77-ef47405f9618@oracle.com> <57561996.4000501@oracle.com> <951844EF-D517-4BF5-861A-81769EA1C306@oracle.com> Message-ID: Looks good. Best regards, Vladimir Ivanov On 6/14/16 3:12 AM, Paul Sandoz wrote: > Hi, > > Here is an updated webrev. > > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8158039-float-double-field-array-cas.jdk/webrev/ > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8158039-float-double-field-array-cas.hotspot/webrev/ > > Changes > > - the Unsafe.getAndAdd for float/double operate in the bit-domain. > > - documentation added to the factory methods: > > 1221 *

> 1222 * If the field type is {@code float} or {@code double} then numeric > 1223 * and atomic update access modes compare values using their bitwise > 1224 * representation (see {@link Float#floatToRawIntBits} and > 1225 * {@link Double#doubleToRawLongBits}, respectively). > 1226 *

> 1227 * @apiNote > 1228 * Bitwise comparison of {@code float} values or {@code double} values, > 1229 * as performed by the numeric and atomic update access modes, differ > 1230 * from the primitive {@code ==} operator and the {@link Float#equals} > 1231 * and {@link Double#equals} methods, notably with respect to > 1232 * {@code NaN}. There are many possible NaN values that are considered > 1233 * to be {@code NaN} in Java, although no IEEE 754 floating-point > 1234 * operation provided by Java can distinguish between them. As such > 1235 * care should be taken when performing a compare and set or a compare > 1236 * and exchange operation with NaN values since the operation may > 1237 * unexpectedly fail. Failure can occur if the expected or witness > 1238 * value is a NaN value and it is transformed (perhaps in a platform > 1239 * specific manner) into another NaN value, and thus has a different > 1240 * bitwise representation (see {@link Float#intBitsToFloat} or > 1241 * Double#longBitsToDouble for more details). > > (I also updated the documentation on array/ByteBuffer view methods but did not bother with the api note) > > Paul. > >> On 10 Jun 2016, at 15:39, Paul Sandoz wrote: >> >> Hi Joe, >> >> It?s my turn to catch up on email? >> >> >>> On 6 Jun 2016, at 17:47, Joseph D. Darcy wrote: >>> >>> Hello, >>> >>> Catching up on email, there are several different notions on floating-point equality one might want to use. [1] >>> >>> One notion is the built-in "==" operator on float and double. This has the wrinkle of not defining an equivalence relation because of NaN values (not reflexive) and signed zeros (distinguishable values compare as equal). >>> >>> When I write floating-point tests, I'll use a notion of equality close to >>> >>> Float.compare(x, y) == 0 >>> >>> which means all NaN values are treated as the same and Float.compare(NaN, NaN) == 0 is true. This also distinguishes the signed zeros from each other. >>> >>> So comparing based on the non-raw bitwise conversion can give resonable semantics, at the cost of not preserving any payload stored in the NaN significand. >>> >> >> And potentially a performance hit too [*]. >> >> Pedantically since (NaN == NaN) is false, one could argue that it should not possible to CAS with an expected NaN value and/or a witness NaN value. Such behaviour might be considered BaNaNas :-) (sorry). I don?t think we can or should enforce that, but we should strongly advise against it and mention the pitfalls, and i will need to specify that the atomic ops perform bit-wise equality with suitable ?as if? text. >> >> Paul. >> >> [*] For example, the double[] accepting Arrays.equals method used to compare each element as: >> >> 2762 for (int i=0; i> 2763 if (Double.doubleToLongBits(a[i])!=Double.doubleToLongBits(a2[i])) >> 2764 return false; >> >> In the interim of my adding vectorized mismatch support i changed that to: >> >> 3057 for (int i=0; i> 3058 double v1 = a[i], v2 = a2[i]; >> 3059 if (Double.doubleToRawLongBits(v1) != Double.doubleToRawLongBits(v2)) >> 3060 if (!Double.isNaN(v1) || !Double.isNaN(v2)) >> 3061 return false; >> 3062 } >> >> Which boosted the performance similar to that of comparing long[] (when no NaNs are present). >> >> >>> HTH, >>> >>> -Joe >>> >>> [1] "Notions of Floating-Point Equality ," https://blogs.oracle.com/darcy/entry/notions_of_floating_point_equality >>> >>> On 6/2/2016 1:34 AM, Paul Sandoz wrote: >>>>> On 2 Jun 2016, at 09:13, David Holmes wrote: >>>>> >>>>> On 2/06/2016 1:24 AM, Paul Sandoz wrote: >>>>>> (Please note this work is or will be covered with FC exception) >>>>>> >>>>>> Hi, >>>>>> >>>>>> Please review the VarHandles/Unsafe support for atomic ops on double/float fields/arrays. >>>>> I think this is misguided. If the user wants CAS for float/double they can do the conversion to int/long in a context where they know that conversion makes sense and where they can deal with NaNs appropriately. >>>>> >>>> I would still like to support some clearly defined default behaviour if at all possible, since this is not easy to get right so we can add some value here. The user can use int/long if that behaviour is not suitable. >>>> >>>> >>>>> At a minimum the fact this deals with raw bit patterns not semantic values needs to be exposed somehow. ie the handling of NaN needs to be explicit. >>>>> >>>> Yes, it?s multiple NaN values that collapse to a single NaN value. >>>> >>>> It would be good if our resident floating point expert Mr. Joe Darcy could chime in this respect. >>>> >>>> On Float.intBitsToFloat: >>>> >>>> *

Note that this method may not be able to return a >>>> * {@code float} NaN with exactly same bit pattern as the >>>> * {@code int} argument. IEEE 754 distinguishes between two >>>> * kinds of NaNs, quiet NaNs and signaling NaNs. The >>>> * differences between the two kinds of NaN are generally not >>>> * visible in Java. Arithmetic operations on signaling NaNs turn >>>> * them into quiet NaNs with a different, but often similar, bit >>>> * pattern. However, on some processors merely copying a >>>> * signaling NaN also performs that conversion. In particular, >>>> * copying a signaling NaN to return it to the calling method may >>>> * perform this conversion. So {@code intBitsToFloat} may >>>> * not be able to return a {@code float} with a signaling NaN >>>> * bit pattern. Consequently, for some {@code int} values, >>>> * {@code floatToRawIntBits(intBitsToFloat(start))} may >>>> * not equal {@code start}. Moreover, which >>>> * particular bit patterns represent signaling NaNs is platform >>>> * dependent; although all NaN bit patterns, quiet or signaling, >>>> * must be in the NaN range identified above. >>>> >>>> >>>> >>>> I am concerned that the CAS loops could in some cases loop without termination: >>>> >>>> @ForceInline >>>> public final float getAndAddFloat(Object o, long offset, float delta) { >>>> float v; >>>> do { >>>> v = getFloatVolatile(o, offset); >>>> } while (!weakCompareAndSwapFloatVolatile(o, offset, v, v + delta)); >>>> return v; >>>> } >>>> >>>> >>>> I think this should be: >>>> >>>> @ForceInline >>>> public final float getAndAddFloat(Object o, long offset, float delta) { >>>> int expectedBits; >>>> float v; >>>> do { >>>> expectedBits = getIntVolatile(o, offset); >>>> v = Float.intBitsToFloat(bits); // May not preserve a NaN value with the same bit pattern as expectedBits >>>> } while (!weakCompareAndSwapIntVolatile(o, offset, expectedBits, Float.floatToRawIntBits(v + delta))); >>>> return v; >>>> } >>>> >>>> and likewise for the atomic get-and-set methods. >>>> >>>> Paul. >>>> >>>>> David >>>>> ----- >>>>> >>>>>> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8158039-float-double-field-array-cas.jdk/webrev/ >>>>>> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8158039-float-double-field-array-cas.hotspot/webrev/ >>>>>> >>>>>> These patches are based on those of for sub-word CAS >>>>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8157726 >>>>>> http://cr.openjdk.java.net/~shade/8157726/webrev.hs.03/ >>>>>> http://cr.openjdk.java.net/~shade/8157726/webrev.jdk.03/ >>>>>> >>>>>> And the two patches combined expand the support of fields/arrays. >>>>>> >>>>>> >>>>>> New float/double CAS methods are added to Unsafe that defer to int/long equivalents. Then the other atomic methods are built from weak CAS loops. >>>>>> >>>>>> No changes are required to HotSpot, but changes are required to the Unsafe tests in the hotspot repository. >>>>>> >>>>>> In general the changes to VHs and tests are minimal since it is triggered from changes to the generating scripts that now include float/double into the CAS category. >>>>>> >>>>>> There are some minor specification changes and a CCC has been initiated. >>>>>> >>>>>> JPRT tests results show no relevant failures for hotspot and core test sets. >>>>>> >>>>>> Thanks, >>>>>> Paul. >>>>>> >>> >> > From Alan.Bateman at oracle.com Fri Jun 17 13:34:32 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 17 Jun 2016 14:34:32 +0100 Subject: RFR 8159324 JDK9 msg drop 10 resource update In-Reply-To: <575D86C1.1080308@oracle.com> References: <575D86C1.1080308@oracle.com> Message-ID: <3bdacfa3-1a31-4988-27df-9afc04829dec@oracle.com> On 12/06/2016 16:58, Leo Jiang wrote: > Hi, > > Please review the resource update for JDK9 message drop 10. After > preparation message drop, we have minor update for jaxp, jdk and > langtools. > > CR: http://cr.openjdk.java.net/~fyuan/leo/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8159324 I skimmed through this and don't see any issues. I was pleased to see that `requires` and other module clauses in the jar tool resources have not been translated. Also copyright headers have been added to the jmod and other new files as these were missing originally. -Alan From robert.field at oracle.com Fri Jun 17 17:24:31 2016 From: robert.field at oracle.com (Robert Field) Date: Fri, 17 Jun 2016 10:24:31 -0700 Subject: RFR 8159324 JDK9 msg drop 10 resource update In-Reply-To: <575D86C1.1080308@oracle.com> References: <575D86C1.1080308@oracle.com> Message-ID: <5764324F.7020702@oracle.com> jshell/tool/resources/l10n_ja.properties -- Looks pretty good. This line in startup.feedback didn't get translated: /set format normal display '{pre}{action} variable {name}, reset to null{post}' replaced-vardecl,varinit-ok-update jshell/tool/resources/l10n_zh_CN.properties -- Unlike the above, this doesn't look like it is based on anything near current jshell/resources/l10n_zh_CN.properties -- Just has a space added (fine) -Robert On 06/12/16 08:58, Leo Jiang wrote: > Hi, > > Please review the resource update for JDK9 message drop 10. After > preparation message drop, we have minor update for jaxp, jdk and > langtools. > > CR: http://cr.openjdk.java.net/~fyuan/leo/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8159324 > > Thanks, > Leo From li.jiang at oracle.com Fri Jun 17 18:51:02 2016 From: li.jiang at oracle.com (Leo Jiang) Date: Sat, 18 Jun 2016 02:51:02 +0800 Subject: RFR 8159324 JDK9 msg drop 10 resource update In-Reply-To: <5764324F.7020702@oracle.com> References: <575D86C1.1080308@oracle.com> <5764324F.7020702@oracle.com> Message-ID: <57644696.2000007@oracle.com> jshell/tool/resources/l10n_ja.properties I will confirm with translation team then file a bug to them if confirmed. jshell/tool/resources/l10n_zh_CN.properties Sorry I didn't catch your mean. Did you mean the translation of strings missing in zh_CN. If that, would you tell the string id? So I can check if the string catch this message drop schedule. jshell/resources/l10n_zh_CN.properties The old translation is the fix I made before got the translation bug fix. Sounds translation team feel it better if a space between the Chinese and English word. Thanks, Leo On 06/18/2016 01:24 AM, Robert Field wrote: > jshell/tool/resources/l10n_ja.properties -- > Looks pretty good. > This line in startup.feedback didn't get translated: > /set format normal display '{pre}{action} variable {name}, reset to null{post}' > replaced-vardecl,varinit-ok-update > > jshell/tool/resources/l10n_zh_CN.properties -- > Unlike the above, this doesn't look like it is based on anything near current > > jshell/resources/l10n_zh_CN.properties -- > Just has a space added (fine) > > -Robert > > On 06/12/16 08:58, Leo Jiang wrote: >> Hi, >> >> Please review the resource update for JDK9 message drop 10. After preparation message drop, we have minor update for >> jaxp, jdk and langtools. >> >> CR: http://cr.openjdk.java.net/~fyuan/leo/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8159324 >> >> Thanks, >> Leo > From robert.field at oracle.com Fri Jun 17 19:37:15 2016 From: robert.field at oracle.com (Robert Field) Date: Fri, 17 Jun 2016 12:37:15 -0700 Subject: RFR 8159324 JDK9 msg drop 10 resource update In-Reply-To: <57644696.2000007@oracle.com> References: <575D86C1.1080308@oracle.com> <5764324F.7020702@oracle.com> <57644696.2000007@oracle.com> Message-ID: <5764516B.6050900@oracle.com> All three JShell files look fine except the one untranslated line I mentioned. Thanks, Robert On 06/17/16 11:51, Leo Jiang wrote: > jshell/tool/resources/l10n_ja.properties > I will confirm with translation team then file a bug to them if > confirmed. > > jshell/tool/resources/l10n_zh_CN.properties > Sorry I didn't catch your mean. Did you mean the translation of > strings missing in zh_CN. If that, would you tell the string id? So I > can check if the string catch this message drop schedule. > > jshell/resources/l10n_zh_CN.properties > The old translation is the fix I made before got the translation bug > fix. Sounds translation team feel it better if a space between the > Chinese and English word. > > Thanks, > Leo > > On 06/18/2016 01:24 AM, Robert Field wrote: >> jshell/tool/resources/l10n_ja.properties -- >> Looks pretty good. >> This line in startup.feedback didn't get translated: >> /set format normal display '{pre}{action} variable {name}, reset to >> null{post}' >> replaced-vardecl,varinit-ok-update >> >> jshell/tool/resources/l10n_zh_CN.properties -- >> Unlike the above, this doesn't look like it is based on anything near >> current >> >> jshell/resources/l10n_zh_CN.properties -- >> Just has a space added (fine) >> >> -Robert >> >> On 06/12/16 08:58, Leo Jiang wrote: >>> Hi, >>> >>> Please review the resource update for JDK9 message drop 10. After >>> preparation message drop, we have minor update for >>> jaxp, jdk and langtools. >>> >>> CR: http://cr.openjdk.java.net/~fyuan/leo/ >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8159324 >>> >>> Thanks, >>> Leo >> From joe.darcy at oracle.com Mon Jun 20 14:58:39 2016 From: joe.darcy at oracle.com (joe darcy) Date: Mon, 20 Jun 2016 07:58:39 -0700 Subject: RFR 8158039 VarHandle float/double field/array access should support CAS/set/add atomics In-Reply-To: References: <23FAF71F-F8B9-4AD6-9BF3-896795540788@oracle.com> <6ed640e8-f581-e81d-3e77-ef47405f9618@oracle.com> <57561996.4000501@oracle.com> <951844EF-D517-4BF5-861A-81769EA1C306@oracle.com> <8d668cf7-1f40-8310-117e-267cefe2ab5c@oracle.com> <575FC8D5.8050900@redhat.com> Message-ID: New spec sounds fine; thanks Paul, -Joe On 6/15/2016 8:54 PM, Paul Sandoz wrote: > Hi Joe, Andrew, > >> On 14 Jun 2016, at 02:05, Andrew Haley wrote: >> >> On 14/06/16 05:09, joe darcy wrote: >>> I suggest also pointing out that a bitwise comparison distinguishes -0.0 >>> from +0.0; they compare as == under the built-in operation. >> Indeed so, yes. This is particularly likely to bite people who have >> a zero created by, say, an algorithm which converges on zero with >> successive terms which alternate sign. Eww. >> > In a previously unpublished incarnation i did talk about -0.0/+0.0, then i dropped it... > > Here is an updated revision of the note: > > 1226 * @apiNote > 1227 * Bitwise comparison of {@code float} values or {@code double} values, > 1228 * as performed by the numeric and atomic update access modes, differ > 1229 * from the primitive {@code ==} operator and the {@link Float#equals} > 1230 * and {@link Double#equals} methods, specifically with respect to > 1231 * comparing NaN values or comparing {@code -0.0} with {@code +0.0}. > 1232 * Care should be taken when performing a compare and set or a compare > 1233 * and exchange operation with such values since the operation may > 1234 * unexpectedly fail. > 1235 * There are many possible NaN values that are considered to be > 1236 * {@code NaN} in Java, although no IEEE 754 floating-point operation > 1237 * provided by Java can distinguish between them. Operation failure can > 1238 * occur if the expected or witness value is a NaN value and it is > 1239 * transformed (perhaps in a platform specific manner) into another NaN > 1240 * value, and thus has a different bitwise representation (see > 1241 * {@link Float#intBitsToFloat} or {@link Double#longBitsToDouble} for more > 1242 * details). > 1243 * The values {@code -0.0} and {@code +0.0} have different bitwise > 1244 * representations but are considered equal when using the primitive > 1245 * {@code ==} operator. Operation failure can occur if, for example, a > 1246 * numeric algorithm computes an expected value to be say {@code -0.0} > 1247 * and previously computed the witness value to be say {@code +0.0}. > > Paul. From jonathan.gibbons at oracle.com Mon Jun 20 16:06:58 2016 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 20 Jun 2016 09:06:58 -0700 Subject: RFR 8159324 JDK9 msg drop 10 resource update In-Reply-To: <575D86C1.1080308@oracle.com> References: <575D86C1.1080308@oracle.com> Message-ID: <576814A2.5040409@oracle.com> On 06/12/2016 08:58 AM, Leo Jiang wrote: > Hi, > > Please review the resource update for JDK9 message drop 10. After > preparation message drop, we have minor update for jaxp, jdk and > langtools. > > CR: http://cr.openjdk.java.net/~fyuan/leo/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8159324 > > Thanks, > Leo Although the changes in the modified lines look reasonable, at least for the langtools repo, the webrev as a comparison between "old" and "new" looks suspect, since the changes seem to add resources, rather than just change the content of resources. The new lines look OK, it's the old set that look suspect. -- Jon From david.holmes at oracle.com Mon Jun 20 23:48:50 2016 From: david.holmes at oracle.com (David Holmes) Date: Tue, 21 Jun 2016 09:48:50 +1000 Subject: JDK 9 is not (yet) Feature Complete -- how will we get there? In-Reply-To: <20160610072437.975638333eggemoggin.niobe.net> References: <20160610072437.975638333eggemoggin.niobe.net> Message-ID: <170db8a9-827c-7253-6acc-2d55eb1f07b9@oracle.com> The June 17 deadline has passed. Can we take it that the process is now approved and in-place and so we can start pushing once issues have been labelled with jdk9-fc-yes? Thanks, David On 11/06/2016 12:24 AM, mark.reinhold at oracle.com wrote: > The JDK 9 schedule [1] lists a date for the Feature Complete milestone > of 2016/5/26, about two weeks ago. There's been some concern that this > means that the JDK 9 (and hence Java SE 9) feature set is somehow frozen, > but that's not the case. > > The milestones listed in the JDK 9 schedule are condition-driven rather > than date-driven, as noted along with the milestone definitions [2]. We > try our best to reach the goal of each milestone by its scheduled date. > If we miss a date then we don't just blindly constrain further work so as > to fit the date, we instead manage the remaining changes relevant to the > milestone so as to reach its goal in a reasonable time frame without > putting the final GA date at undue risk. When we finally do reach the > goal then we declare the milestone on that date. > > The goal of the Feature Complete milestone is to get all of the planned > features, i.e., JEPs, and smaller enhancements integrated into the JDK 9 > master forest, together with their unit tests. As of today most JEPs > targeted to JDK 9 have been completed [3]. Fifteen JEPs remain, and a > number of small enhancements are listed as intended for JDK 9 but are > still either open or in progress. > > To manage the remaining JEPs and small enhancements so that we can reach > the Feature Complete state in a timely fashion I hereby propose the > following process: > > - If you own a JEP or a small enhancement that is not yet complete then > you can request an FC extension as follows: Update the JBS issue to > add a comment whose first line is "FC Extension Request". In that > comment describe the remaining work to be done, the risk level, a > brief justification, and your best estimate of the date by which the > feature will be complete. Add the label "jdk9-fc-request" to the > issue. > > - The Area Leads, relevant Group Leads, and I will review such requests > on a regular basis, at least weekly if not more often. One of us > will take one of the following actions: > > - Approve the request by adding the label "jdk9-fc-yes". > > - Reject the request by adding the label "jdk9-fc-no", along > with a comment describing the reason for this action. > > - Request more information by adding the label "jdk9-fc-nmi" > ("nmi" = "needs more information"), along with a comment > describing what information is requested. > > - If you're asked to provide more information for an FC extension > request then please do so in a new comment in the issue, and then > remove the "jdk9-fc-nmi" label so that we see that it's ready for > re-review. > > - If your request is approved then update the issue's due date to the > expected completion date. > > - If you own a JEP that's targeted to JDK 9, but won't make it, then > please propose to drop it [4]; this will move the JEP back to the > Candidate state unless there are strong objections. If you own a > small enhancement whose fix version is 9, but won't make it, then > please clear the fix-version field. > > If a JEP has been granted an FC extension then enhancement issues that > block the JEP's issue are automatically considered to have FC extensions. > > If a JEP has not yet been targeted to JDK 9 then you can still propose to > target it to the release, but going forward the bar for accepting new > features will be increasingly high. > > For the record, the Area Leads are Mikael Vidstedt (VM) and Brian Goetz > (Language and Libraries). The relevant Group Leads are as follows, per > the Census [5]: > > Artem Ananiev - AWT > Alan Bateman - Core Libraries > Tim Bell - Build > Daniel D. Daugherty - Serviceability > Jonathan Gibbons - Compiler > Vladimir Kozlov - HotSpot > Michael McMahon - Networking > Sean Mullan - Security > Masayoshi Okutsu - Internationalization > Pavel Porvatov - Swing > Phil Race - 2D Graphics & Sound > Dalibor Topic - Porters > > JDK 9 Committers are invited to comment on this process proposal. If no > serious objections are raised in one week's time, by 15:00 UTC on 17 June > 2016, then this is the process that we'll use. > > In anticipation that we will use this process, more or less, I encourage > owners of not-yet-complete JEPs and small enhancements to go ahead and > request extensions as described above, if desired, so that we can move > quickly once the process is in place. > > - Mark > > > [1] http://openjdk.java.net/projects/jdk9/ > [2] http://openjdk.java.net/projects/jdk8/milestones#definitions > [3] http://j.mp/jdk9-features-jbs > [4] http://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html#Proposed-to-Drop > [5] http://openjdk.java.net/census > From vladimir.kozlov at oracle.com Tue Jun 21 16:06:38 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 21 Jun 2016 09:06:38 -0700 Subject: JDK 9 is not (yet) Feature Complete -- how will we get there? In-Reply-To: <170db8a9-827c-7253-6acc-2d55eb1f07b9@oracle.com> References: <20160610072437.975638333eggemoggin.niobe.net> <170db8a9-827c-7253-6acc-2d55eb1f07b9@oracle.com> Message-ID: <89c2f5bf-0296-1d3f-2b18-7b191bb60c70@oracle.com> On 6/20/16 4:48 PM, David Holmes wrote: > The June 17 deadline has passed. Can we take it that the process is now approved and in-place and so we can start > pushing once issues have been labelled with jdk9-fc-yes? I thought Mark will comment about this but I think we can start with approvals since there were no objections. I am starting approval of Hotspot FC extension requests. Regards, Vladimir > > Thanks, > David > > On 11/06/2016 12:24 AM, mark.reinhold at oracle.com wrote: >> The JDK 9 schedule [1] lists a date for the Feature Complete milestone >> of 2016/5/26, about two weeks ago. There's been some concern that this >> means that the JDK 9 (and hence Java SE 9) feature set is somehow frozen, >> but that's not the case. >> >> The milestones listed in the JDK 9 schedule are condition-driven rather >> than date-driven, as noted along with the milestone definitions [2]. We >> try our best to reach the goal of each milestone by its scheduled date. >> If we miss a date then we don't just blindly constrain further work so as >> to fit the date, we instead manage the remaining changes relevant to the >> milestone so as to reach its goal in a reasonable time frame without >> putting the final GA date at undue risk. When we finally do reach the >> goal then we declare the milestone on that date. >> >> The goal of the Feature Complete milestone is to get all of the planned >> features, i.e., JEPs, and smaller enhancements integrated into the JDK 9 >> master forest, together with their unit tests. As of today most JEPs >> targeted to JDK 9 have been completed [3]. Fifteen JEPs remain, and a >> number of small enhancements are listed as intended for JDK 9 but are >> still either open or in progress. >> >> To manage the remaining JEPs and small enhancements so that we can reach >> the Feature Complete state in a timely fashion I hereby propose the >> following process: >> >> - If you own a JEP or a small enhancement that is not yet complete then >> you can request an FC extension as follows: Update the JBS issue to >> add a comment whose first line is "FC Extension Request". In that >> comment describe the remaining work to be done, the risk level, a >> brief justification, and your best estimate of the date by which the >> feature will be complete. Add the label "jdk9-fc-request" to the >> issue. >> >> - The Area Leads, relevant Group Leads, and I will review such requests >> on a regular basis, at least weekly if not more often. One of us >> will take one of the following actions: >> >> - Approve the request by adding the label "jdk9-fc-yes". >> >> - Reject the request by adding the label "jdk9-fc-no", along >> with a comment describing the reason for this action. >> >> - Request more information by adding the label "jdk9-fc-nmi" >> ("nmi" = "needs more information"), along with a comment >> describing what information is requested. >> >> - If you're asked to provide more information for an FC extension >> request then please do so in a new comment in the issue, and then >> remove the "jdk9-fc-nmi" label so that we see that it's ready for >> re-review. >> >> - If your request is approved then update the issue's due date to the >> expected completion date. >> >> - If you own a JEP that's targeted to JDK 9, but won't make it, then >> please propose to drop it [4]; this will move the JEP back to the >> Candidate state unless there are strong objections. If you own a >> small enhancement whose fix version is 9, but won't make it, then >> please clear the fix-version field. >> >> If a JEP has been granted an FC extension then enhancement issues that >> block the JEP's issue are automatically considered to have FC extensions. >> >> If a JEP has not yet been targeted to JDK 9 then you can still propose to >> target it to the release, but going forward the bar for accepting new >> features will be increasingly high. >> >> For the record, the Area Leads are Mikael Vidstedt (VM) and Brian Goetz >> (Language and Libraries). The relevant Group Leads are as follows, per >> the Census [5]: >> >> Artem Ananiev - AWT >> Alan Bateman - Core Libraries >> Tim Bell - Build >> Daniel D. Daugherty - Serviceability >> Jonathan Gibbons - Compiler >> Vladimir Kozlov - HotSpot >> Michael McMahon - Networking >> Sean Mullan - Security >> Masayoshi Okutsu - Internationalization >> Pavel Porvatov - Swing >> Phil Race - 2D Graphics & Sound >> Dalibor Topic - Porters >> >> JDK 9 Committers are invited to comment on this process proposal. If no >> serious objections are raised in one week's time, by 15:00 UTC on 17 June >> 2016, then this is the process that we'll use. >> >> In anticipation that we will use this process, more or less, I encourage >> owners of not-yet-complete JEPs and small enhancements to go ahead and >> request extensions as described above, if desired, so that we can move >> quickly once the process is in place. >> >> - Mark >> >> >> [1] http://openjdk.java.net/projects/jdk9/ >> [2] http://openjdk.java.net/projects/jdk8/milestones#definitions >> [3] http://j.mp/jdk9-features-jbs >> [4] http://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html#Proposed-to-Drop >> [5] http://openjdk.java.net/census >> From mark.reinhold at oracle.com Tue Jun 21 21:56:07 2016 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Tue, 21 Jun 2016 14:56:07 -0700 Subject: JDK 9 is not (yet) Feature Complete -- how will we get there? In-Reply-To: <20160610072437.975638333eggemoggin.niobe.net> References: <20160610072437.975638333eggemoggin.niobe.net> Message-ID: <20160621145607.146493062eggemoggin.niobe.net> 2016/6/10 7:24:37 -0700, mark.reinhold at oracle.com: > ... > > To manage the remaining JEPs and small enhancements so that we can reach > the Feature Complete state in a timely fashion I hereby propose the > following process: > > ... > > JDK 9 Committers are invited to comment on this process proposal. If no > serious objections are raised in one week's time, by 15:00 UTC on 17 June > 2016, then this is the process that we'll use. Hearing no objections, this process is now adopted. I've summarized it here: http://openjdk.java.net/projects/jdk9/fc-extension-process Link to JBS query for pending requests: http://j.mp/jdk9-fc-pending - Mark From mark.reinhold at oracle.com Tue Jun 21 22:09:42 2016 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Tue, 21 Jun 2016 15:09:42 -0700 Subject: JDK 9 is not (yet) Feature Complete -- how will we get there? In-Reply-To: <376b542b-69cb-a4f3-a539-70f30ded42c9@oracle.com> References: <20160610072437.975638333eggemoggin.niobe.net> <376b542b-69cb-a4f3-a539-70f30ded42c9@oracle.com> Message-ID: <20160621150942.488116667eggemoggin.niobe.net> 2016/6/15 12:23:29 -0700, vladimir.kozlov at oracle.com: > I would suggest to have a link to the latest webrev in JBS, when it is > ready, to see the scope of changes. This might be appropriate for a small change prior to requesting an FC extension, but someone responsible for a larger change will likely want to request (and receive) an extension before finishing up all the work, so I don't think we can mandate this for all requests. > And to have ability to change jdk9-fc-yes (approved) to jdk9-fc-no > (rejected) if scope of final changes is larger than initially > described in FC Extension Request. I don't think this sort of case needs to be baked into the process. If a Lead who has previously approved a request later sees that it's grown dramatically in scope then they should contact the responsible developer directly. This may result in the issue being closed or targeted to a later release. Replacing the jdk9-fc-yes label with jdk9-fc-no isn't really needed, but it wouldn't hurt. - Mark From Roger.Riggs at Oracle.com Wed Jun 22 17:29:27 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Wed, 22 Jun 2016 13:29:27 -0400 Subject: Result: New JDK 9 Committer: Felix Yang In-Reply-To: <75ca884a-fa55-2cce-fdee-3ce8d8527dab@Oracle.com> References: <2b16fc92-ae12-3bf7-fbac-3b13d96a6757@oracle.com> <75ca884a-fa55-2cce-fdee-3ce8d8527dab@Oracle.com> Message-ID: Voting for Felix Yang [1] is now closed. Yes: 16 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. Roger Riggs [1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-June/004419.html From mark.reinhold at oracle.com Wed Jun 22 18:54:43 2016 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Wed, 22 Jun 2016 11:54:43 -0700 Subject: JDK 9 is not (yet) Feature Complete -- how will we get there? In-Reply-To: <20160621145607.146493062eggemoggin.niobe.net> References: <20160610072437.975638333eggemoggin.niobe.net> <20160621145607.146493062eggemoggin.niobe.net> Message-ID: <20160622115443.540949322eggemoggin.niobe.net> 2016/6/21 14:56:07 -0700, mark.reinhold at oracle.com: > Hearing no objections, this process is now adopted. > > I've summarized it here: > > http://openjdk.java.net/projects/jdk9/fc-extension-process To highlight an important clarification I added to that page, relative to the original proposal: Once the jdk9-fc-request label is added to an issue, it should never be removed. This simplifies the process, so that people don't have to think about when to remove it. The prepackaged JBS query (http://j.mp/jdk9-fc-pending) already takes this into account. - Mark From lana.steuck at oracle.com Wed Jun 22 20:16:51 2016 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 22 Jun 2016 20:16:51 GMT Subject: jdk9-b124: dev Message-ID: <201606222016.u5MKGpvI018752@scaaa563.us.oracle.com> http://hg.openjdk.java.net/jdk9/jdk9/rev/f80c841ae254 http://hg.openjdk.java.net/jdk9/jdk9/nashorn/rev/5d68f5155dde http://hg.openjdk.java.net/jdk9/jdk9/langtools/rev/26aa3caa778e http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/7ff61c55b5c6 http://hg.openjdk.java.net/jdk9/jdk9/jaxws/rev/1600da1665cd http://hg.openjdk.java.net/jdk9/jdk9/jaxp/rev/e04a15153cc2 http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/479631362b49 http://hg.openjdk.java.net/jdk9/jdk9/corba/rev/45121d5afb9d --- All the fixes will be tested during promotion (no PIT testing at this point): List of all fixes: =================== JDK-4957035 client-libs Code given in api is not compilable: docs/api/javax/print/package-summ JDK-6212751 client-libs DOC: ServiceUI.printDialog() need to enhance the description for X,Y c JDK-6477756 client-libs GraphicsDevice.getConfigurations() is slow taking 3 or more seconds JDK-6509729 client-libs javax.print.ServiceUI.printDialog Border/Margin Evaluation is bugged JDK-6529030 client-libs Java Printing: Print range > Selection gets enabled JDK-6587251 client-libs "noreg-cleanup" Import declaration not used in sun.java2d.* JDK-6827800 client-libs Default button is activated even when it is invisible JDK-6842011 client-libs StackOverflowError printing landscape with scale and transform. JDK-6882559 client-libs new JEditorPane("text/plain","") fails for null context class loader JDK-7070795 client-libs High contrast colour scheme fails to be applied to JFormattedTextField JDK-7172749 client-libs Xrender: Class cast exception in 2D code running an AWT regression tes JDK-7172750 client-libs Nimbus ScrollBar:ScrollBarThumb[Pressed].backgroundPainter is never in JDK-8028486 client-libs java/awt/Window/WindowsLeak/WindowsLeak.java fails JDK-8041694 client-libs JFileChooser removes trailing spaces in the selected directory name JDK-8046031 client-libs UI of Java Web Start app isn't updated when changing Windows theme JDK-8057574 client-libs inconsistent behavior for setBackground (Windows/Linux) JDK-8074829 client-libs Resolve disabled warnings for libawt_headless JDK-8078268 client-libs javax.swing.text.html.parser.Parser parseScript incorrectly optimized JDK-8078382 client-libs Wrong glyph is displayed for a derived font JDK-8132771 client-libs [TEST_BUG][macosx] Test javax/swing/JTree/DnD/LastNodeLowerHalfDrop.ja JDK-8132973 client-libs @BeanProperty: what is the correct output in case of repeating annotat JDK-8133731 client-libs [TEST_BUG] Unmappable in ASCII character such as Thai should be escape JDK-8136366 client-libs Add a public API to create a L&F without installation JDK-8136998 client-libs JComboBox prevents wheel mouse scrolling of JScrollPane JDK-8139192 client-libs Custom ImageFilters return blank images in Java 8(.45) while working i JDK-8139218 client-libs Dialog that opens and closes quickly changes focus in original focusow JDK-8144161 client-libs [TESTBUG] [macosx] Test javax/swing/plaf/basic/BasicComboPopup/7072653 JDK-8145284 client-libs [Documentation] [TextField] Missing new line character handling JDK-8146313 client-libs The java.beans.Statement.invoke() method handles 3-arg Class.forName i JDK-8146319 client-libs JEditorPane function setPage leaves a file lock JDK-8147521 client-libs [macosx] Internal API Usage: setPopupType used to force creation of he JDK-8147842 client-libs IME Composition Window is displayed at incorrect location JDK-8148915 client-libs Intermittent failures of bug6400879.java JDK-8151015 client-libs JTextArea.insert() does not behave as expected with invalid position JDK-8152981 client-libs Double icons with JMenuItem setHorizontalTextPosition on Win 10 JDK-8153184 client-libs BorderLayout javadoc says current version of JDK is 1.2 JDK-8153282 client-libs [TEST_BUG] some new JInternalFrame tests fail JDK-8154431 client-libs Allow source and target based validation for the focus transfer betwee JDK-8154860 client-libs ImageIO.getImageReadersByFormatName() fails when jai_imageio is in the JDK-8155103 client-libs [TEST_BUG] @BeanProperty: unwanted "declaringClass" descriptor when an JDK-8156043 client-libs Unstable behavior of PropertyDescriptor's getWriteMethod() in case of JDK-8156116 client-libs [macosx] two JNI locals to delete in AWTWindow.m, CGraphicsEnv.m JDK-8156121 client-libs "Fail forward" fails for GTK3 if no GTK2 available JDK-8156169 client-libs Some sound tests rarely hangs because of incorrect synchronization JDK-8156579 client-libs Two JavaBeans tests failed JDK-8156580 client-libs Make TIFFTagSet subclasses final JDK-8156583 client-libs Typo in the spec of javax.sound.sampled.AudioFormat.Encoding.toString( JDK-8156894 client-libs Cleanup of sun.java2d.pipe.Region JDK-8157163 client-libs AWT FileDialog does not inherit icon image from parent Frame JDK-8157320 client-libs The CheckboxMenuItem can not be selected JDK-8157322 client-libs Several typos in javadoc JDK-8157339 client-libs Further stabilization for the SwingSet client sanity tests. JDK-8158072 client-libs Need a test for JDK-7172749 JDK-8158178 client-libs java.awt.SplashScreen.getSize() returns incorrect size for high dpi sp JDK-8158230 client-libs [macosx] ActionEvent is not fired for menu item with option apple.laf. JDK-8158358 client-libs [TEST_BUG] test/javax/swing/JPopupMenu/8147521/PopupMenuTest.java: com JDK-8158408 client-libs Font2DTest demo needs to use FontPanel resolution matching the screen JDK-8158495 client-libs CCE: sun.java2d.NullSurfaceData cannot be cast to sun.java2d.opengl.OG JDK-8158520 client-libs [TEST_BUG] java/awt/PrintJob/PrinterException.java fails on timeout JDK-8159690 client-libs [TESTBUG] Mark headful tests with @key headful. JDK-8039955 core-libs [TESTBUG] jdk/lambda/LambdaTranslationTest1 - java.lang.AssertionError JDK-8043387 core-libs java/time/test/java/util/TestFormatter.java failed. JDK-8066070 core-libs PriorityQueue corrupted when adding non-Comparable JDK-8068764 core-libs java/lang/ClassLoader/ExtDirs.java failed with java.lang.IllegalThread JDK-8071859 core-libs AnnotationInvocationHandler.equals(Object) return true when apply to a JDK-8072582 core-libs Scanner delimits incorrectly when delimiter spans a buffer boundary JDK-8135061 core-libs java.util.Locale#lookup throws java.lang.StringIndexOutOfBoundsExcepti JDK-8139414 core-libs java.util.Scanner hasNext() returns true, next() throws NoSuchElementE JDK-8140449 core-libs (fs) Paths.get("x").relativize("") return ..\ on Windows JDK-8150219 core-libs ReferenceError in 1.8.0_72 JDK-8155808 core-libs Process.getInputStream().skip() method is faulty JDK-8156614 core-libs Lazy parsing of ES6 shorthand method syntax is broken JDK-8157045 core-libs NPE during websocket communication with wss JDK-8158253 core-libs Collections: Implement a noop clear() for EmptyList, EmptyMap and Empt JDK-8158456 core-libs ModuleDescriptor.read does not verify dependence on java.base in modul JDK-8158855 core-libs Fix remaining module dependences in java/lang JDK-8159248 core-libs ModuleFinder.of not clear that FindException thrown if module descript JDK-8159330 core-libs Improve deprecation text for Class.newInstance JDK-8159351 core-libs non-atomic "bulk" ops note in class javadoc for ConcurrentLinkedQueue, JDK-8159420 core-libs The LanguageRange.parse() method is throwing IllegalArgumentException JDK-8159530 core-libs recent compiler change results in compile error in JapaneseDate.java JDK-8159630 core-libs Add new test for jdk.internal.misc.VM::getRuntimeArguments JDK-8159745 core-libs Remove java.net.Parts JDK-8159762 core-libs Some minor test bugs in java/lang/module/ModuleDescriptorTest.java JDK-8159785 core-libs Add test that tests ClassLoader.getResource/getResources in Multi-Rele JDK-8159821 core-libs "PrimitiveStream.iterateFinite" methods contain incorrect code sample JDK-8156537 core-svc Tools using MonitoredVmUtil do not parse module in cmdline correctly JDK-6510995 deploy Resources with download="lazy" are eagerly updated JDK-8144348 deploy Desktop shortcut is not updated after JNLP is changed in deployment ca JDK-8153077 deploy Allow -XaddExports be specified via the java-vm-args attribute JDK-8153800 deploy Revamped JCP: General Tab JDK-8155076 deploy Webstart loads JARs from MANIFEST.MF after loading the jars from resou JDK-8155785 deploy Add @Deprecated annotations to the Applet API classes JDK-8156672 deploy "javaws.exe -viewer" does not open Java Cache Viewer for new JCP JDK-8156673 deploy Fix "Advanced -> Configurations" for new JCP JDK-8156822 deploy Application started using javaws now starts in {java.home} rather than JDK-8157238 deploy Nothing could be saved in tab Update in new FX JCP. JDK-8157337 deploy Allow always checkbox in security dialog when jnlp location is unknown JDK-8157340 deploy new JCP: cannot import certificate file into user trusted cacerts file JDK-8157342 deploy new JCP: cannot remove certificates from user trust store JDK-8157692 deploy Need Test : JDK-8041798 JDK-8157694 deploy Need test JDK-8068707 JDK-8157785 deploy Signed JWS application unexpectedly asks for permission to open a sock JDK-8158187 deploy At step4.It always shows a blank page after loading the applet for a w JDK-8158201 deploy It always shows a 404 error page after loading the applet. JDK-8158202 deploy [TEST_BUG]at step2,the title of security dialog is not "Security Infor JDK-8158208 deploy Update CLSIDScenarios/TestAppletLaunchUsingOlderCLSID.html with more JDK-8158216 deploy At step 3:There's no 'Update Now' after going to JCP/Update tab JDK-8158627 deploy [TEST_BUG]At step 3,there is no the dllinject.dll file in the given di JDK-8158817 docs add documentation for NativeMath JDK-8155918 globalization JDK 9 Prep Message Drop L10n resource file translation update - JDK JDK-8157775 globalization JDK 9 Prep Message Drop L10n resource file translation update - JAXP JDK-8157776 globalization JDK 9 Prep Message Drop L10n resource file translation update - Corba JDK-8157778 globalization JDK 9 Prep Message Drop L10n resource file translation update - Langto JDK-8138705 hotspot Kitchen sink stress test fails JDK-8152239 hotspot hotspot/test/gc/TestSmallHeap.java failed in jdk9 JDK-8152404 hotspot Stabilize PackageEntry::package_exports_do JDK-8154750 hotspot Add missing OrderAccess operations to ClassLoaderData lock-free data s JDK-8155009 hotspot [TESTBUG] jstack subtest of BasicLauncherTest should not be executed u JDK-8155936 hotspot Boolean value should be set 1/0 or true/false via VM.set_flag jcmd JDK-8156923 hotspot [ppc] Implement "JEP 270: Reserved Stack Areas for Critical Sections". JDK-8157189 hotspot 'iload_w' in shared class is not interpreted correctly JDK-8157954 hotspot [TESTBUG] G1 tests fail with defined MaxGCPauseMillis JDK-8157317 infrastructure Remove bundle target logic from install makefiles JDK-8158992 infrastructure langtools/test/Makefile: improve support for control via variables JDK-8156895 install ent msi does not have double-click support JDK-6968542 security-libs keytool -importcert cannot deal with duplicate certs JDK-8027781 security-libs New jarsigner timestamp warning is grammatically incorrect JDK-8146619 security-libs Re-examine supportness of public classes in com.sun.security.auth.** JDK-8150966 security-libs Typo in javax.net.ssl.SSLEngineResult.HandshakeStatus.NEED_UNWRAP_AGAI JDK-8154191 security-libs Deprivilege java.smartcardio module JDK-8156471 security-libs test/sun/security/krb5/auto/TestHosts should not be modified in-place JDK-8157387 security-libs StrongSecureRandom.java timeout after push for JDK-8141039 JDK-8157489 security-libs AppleProvider in java.base/macosx/classes/module-info.java.extra JDK-8157848 security-libs Mark deprecated javax.security.auth.Policy API with forRemoval=true JDK-8157881 security-libs security.provider property description needs to be updated for modules JDK-8158633 security-libs BASE64 encoded cert not correctly parsed with UTF-16 JDK-8159038 security-libs javax/net/ssl/SSLSession/SessionCacheSizeTests.java failed with java.n JDK-8159501 security-libs ShortRSAKey512.java intermittently times out JDK-8159502 security-libs Mark ShortRSAKey512.java as intermittently failing JDK-8159805 security-libs sun/security/tools/jarsigner/warnings/NoTimestampTest.java fails after JDK-8058244 tools missing error in qualified default super call JDK-8059631 tools Use of '#' to represent MethodHandle kind is confusing JDK-8065831 tools Ensure the pack200/unpack200 help is consistent with man page JDK-8068460 tools Pretty printing for loops JDK-8158272 tools IncludeLocalesPluginTest.java fails with timeout JDK-8158468 tools tools/jlink/plugins/IncludeLocalesPluginTest.java doesn't detect test JDK-8158836 tools langtools build.xml needs some adjustments JDK-8159206 tools All jlink tests failing JDK-8159396 tools javadoc getSupportedVersion returns 8 instead of 9 JDK-8159524 tools jdeps -jdkinternals throws NPE when no replacement is known JDK-8159680 tools Inference failure with unchecked subtyping and arrays JDK-8159749 tools Update toolbox ModuleBuilder for doc comments JDK-8159756 tools javadoc tests needs a tool invoker From james.laskey at oracle.com Thu Jun 23 18:40:33 2016 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Thu, 23 Jun 2016 15:40:33 -0300 Subject: RFR: JDK-8159172 - Update usage of jlink/jimage/jmod to show option patterns Message-ID: <44DC3692-7542-4502-84BC-6916A1E11FB7@oracle.com> http://cr.openjdk.java.net/~jlaskey/8159172/webrev/index.html https://bugs.openjdk.java.net/browse/JDK-8159172 This is an initial clean up of help for jlink/jimage/jmod. More work is required (like unifying the options tooling), but comments welcome. ? Jim /Projects/jdk9-dev% jmod --help Usage: jmod (create|list|describe|hash) Main operation modes: create - Creates a new jmod archive list - Prints the names of all the entries describe - Prints the module details hash - Records hashes of tied modules. Option Description ------ ----------- --class-path Application jar files|dir containing classes --cmds Location of native commands --config Location of user-editable config files --dry-run Dry run of hash mode --exclude Exclude files matching the supplied comma separated pattern list, each element using one the following forms: , glob: or regex: --hash-modules Compute and record hashes to tie a packaged module with modules matching the given and depending upon it directly or indirectly. The hashes are recorded in the JMOD file being created, or a JMOD file or modular JAR on the module path specified the jmod hash command. --help Print this usage message --libs Location of native libraries --main-class Main class --module-version Module version --modulepath, --mp Module path --os-arch Operating system architecture --os-name Operating system name --os-version Operating system version --version Version information @ Read options from the specified file /Projects/jdk9-dev% jimage --help Usage: jimage jimage... extract - Extract all jimage entries and place in a directory specified by the --dir= (default=.) option. info - Prints detailed information contained in the jimage header. list - Prints the names of all the entries in the jimage. When used with --verbose, list will also print entry size and offset attributes. verify - Reports on any .class entries that dont verify as classes. Possible options include: --dir Target directory for extract directive --include Pattern list for filtering list or extract entries.w --fullversion Print full version information --help Print usage message --verbose Listing prints entry size and offset attributes --version Print version information For options requiring a , the value will be a comma separated list of elements each using one the following forms: glob: regex: @ where filename is the name of a file containing patterns to be used, one pattern per line /Projects/jdk9-dev% jlink --list-plugins List of available plugins: Plugin Name: class-optim Option: --class-optim=[:log=] Description: Class optimization. Warning: This plugin is experimental. An optional can be specified to log applied optimizations. Plugin Name: compress Option: --compress=<0|1|2>[:filter=] Description: Compress all resources in the output image. Level 0: constant string sharing Level 1: ZIP Level 2: both. An optional filter can be specified to list the pattern of files to be included. Plugin Name: copy-files Option: --copy-files== to copy to the image>. Description: If files to copy are not absolute path, JDK home dir is used. e.g.: jrt-fs.jar,LICENSE,/home/me/myfile.txt=somewehere/conf.txt Plugin Name: exclude-files Option: --exclude-files= of files to exclude Description: Specify files to exclude. e.g.: **.java,glob:/java.base/native/client/** Plugin Name: exclude-resources Option: --exclude-resources= resources to exclude Description: Specify resources to exclude. e.g.: **.jcov,glob:**/META-INF/** Plugin Name: generate-jli-classes Option: --generate-jli-classes= Description: Concrete java.lang.invoke classes to generate Plugin Name: include-locales Option: --include-locales=[,]* Description: BCP 47 language tags separated by a comma, allowing locale matching defined in RFC 4647. e.g.: en,ja,*-IN Plugin Name: installed-modules Option: --installed-modules Description: Fast loading of module descriptors (always enabled) Plugin Name: order-resources Option: --order-resources= of paths in priority order. If a @file is specified, then each line should be an exact match for the path to be ordered Description: Order resources. e.g.: **/module-info.class, at classlist,/java.base/java/lang/** Plugin Name: release-info Option: --release-info=|add:=:=:...|del: Description: option is to load release properties from the supplied file. add: is to add properties to the release file. Any number of = pairs can be passed. del: is to delete the list of keys in release file. Plugin Name: strip-debug Option: --strip-debug Description: Strip debug information from the output image Plugin Name: strip-native-commands Option: --strip-native-commands Description: Exclude native commands (such as java/java.exe) from the image Plugin Name: vm Option: --vm= Description: Select the HotSpot VM in the output image. Default is all For options requiring a , the value will be a comma separated list of elements each using one the following forms: glob: regex: @ where filename is the name of a file containing patterns to be used, one pattern per line From james.laskey at oracle.com Thu Jun 23 18:48:42 2016 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Thu, 23 Jun 2016 15:48:42 -0300 Subject: RFR: JDK-8159172 - Update usage of jlink/jimage/jmod to show option patterns In-Reply-To: <6CD6B7C6-0719-491C-BC88-8F6938CB2CBD@oracle.com> References: <44DC3692-7542-4502-84BC-6916A1E11FB7@oracle.com> <6CD6B7C6-0719-491C-BC88-8F6938CB2CBD@oracle.com> Message-ID: <6BB9CA07-4FEB-4071-82DD-120A19FE448B@oracle.com> Bug number? > On Jun 23, 2016, at 3:46 PM, Chris Bensen wrote: > > --mp should be -p, at least according to Mark?s email about options unification: > >>> Existing spellings New spellings >>> -------------------------------- ------------------------------- > >>> -modulepath | -mp | --modulepath --module-path | -p > > Chris > > >> On Jun 23, 2016, at 11:40 AM, Jim Laskey (Oracle) wrote: >> >> >> http://cr.openjdk.java.net/~jlaskey/8159172/webrev/index.html >> https://bugs.openjdk.java.net/browse/JDK-8159172 >> >> This is an initial clean up of help for jlink/jimage/jmod. More work is required (like unifying the options tooling), but comments welcome. ? Jim >> >> /Projects/jdk9-dev% jmod --help >> Usage: jmod (create|list|describe|hash) >> >> Main operation modes: >> create - Creates a new jmod archive >> list - Prints the names of all the entries >> describe - Prints the module details >> hash - Records hashes of tied modules. >> >> Option Description >> ------ ----------- >> --class-path Application jar files|dir containing >> classes >> --cmds Location of native commands >> --config Location of user-editable config files >> --dry-run Dry run of hash mode >> --exclude Exclude files matching the supplied >> comma separated pattern list, each >> element using one the following >> forms: , glob:> pattern> or regex: >> --hash-modules Compute and record hashes to tie a >> packaged module with modules >> matching the given >> and depending upon it directly or >> indirectly. The hashes are recorded >> in the JMOD file being created, or a >> JMOD file or modular JAR on the >> module path specified the jmod hash >> command. >> --help Print this usage message >> --libs Location of native libraries >> --main-class Main class >> --module-version Module version >> --modulepath, --mp Module path >> --os-arch Operating system architecture >> --os-name Operating system name >> --os-version Operating system version >> --version Version information >> @ Read options from the specified file >> >> /Projects/jdk9-dev% jimage --help >> Usage: jimage jimage... >> >> extract - Extract all jimage entries and place in a directory specified >> by the --dir= (default=.) option. >> >> info - Prints detailed information contained in the jimage header. >> >> list - Prints the names of all the entries in the jimage. When used with >> --verbose, list will also print entry size and offset attributes. >> >> verify - Reports on any .class entries that dont verify as classes. >> >> Possible options include: >> --dir Target directory for extract directive >> --include Pattern list for filtering list or extract entries.w >> --fullversion Print full version information >> --help Print usage message >> --verbose Listing prints entry size and offset attributes >> --version Print version information >> >> For options requiring a , the value will be a comma separated list of elements each using one the following forms: >> >> glob: >> regex: >> >> @ where filename is the name of a file containing patterns to be used, one pattern per line >> >> /Projects/jdk9-dev% jlink --list-plugins >> >> List of available plugins: >> >> Plugin Name: class-optim >> Option: --class-optim=[:log=] >> Description: Class optimization. Warning: This plugin is experimental. >> An optional can be specified to log applied optimizations. >> >> Plugin Name: compress >> Option: --compress=<0|1|2>[:filter=] >> Description: Compress all resources in the output image. >> Level 0: constant string sharing >> Level 1: ZIP >> Level 2: both. >> An optional filter can be specified to list the pattern of >> files to be included. >> >> Plugin Name: copy-files >> Option: --copy-files== to copy to the image>. >> Description: If files to copy are not absolute path, JDK home dir is used. >> e.g.: jrt-fs.jar,LICENSE,/home/me/myfile.txt=somewehere/conf.txt >> >> Plugin Name: exclude-files >> Option: --exclude-files= of files to exclude >> Description: Specify files to exclude. e.g.: **.java,glob:/java.base/native/client/** >> >> Plugin Name: exclude-resources >> Option: --exclude-resources= resources to exclude >> Description: Specify resources to exclude. e.g.: **.jcov,glob:**/META-INF/** >> >> Plugin Name: generate-jli-classes >> Option: --generate-jli-classes= >> Description: Concrete java.lang.invoke classes to generate >> >> Plugin Name: include-locales >> Option: --include-locales=[,]* >> Description: BCP 47 language tags separated by a comma, allowing locale matching >> defined in RFC 4647. e.g.: en,ja,*-IN >> >> Plugin Name: installed-modules >> Option: --installed-modules >> Description: Fast loading of module descriptors (always enabled) >> >> Plugin Name: order-resources >> Option: --order-resources= of paths in priority order. If a @file >> is specified, then each line should be an exact match for the path to be ordered >> Description: Order resources. e.g.: **/module-info.class, at classlist,/java.base/java/lang/** >> >> Plugin Name: release-info >> Option: --release-info=|add:=:=:...|del: >> Description: option is to load release properties from the supplied file. >> add: is to add properties to the release file. >> Any number of = pairs can be passed. >> del: is to delete the list of keys in release file. >> >> Plugin Name: strip-debug >> Option: --strip-debug >> Description: Strip debug information from the output image >> >> Plugin Name: strip-native-commands >> Option: --strip-native-commands >> Description: Exclude native commands (such as java/java.exe) from the image >> >> Plugin Name: vm >> Option: --vm= >> Description: Select the HotSpot VM in the output image. Default is all >> >> For options requiring a , the value will be a comma separated list of elements each using one the following forms: >> >> glob: >> regex: >> @ where filename is the name of a file containing patterns to be used, one pattern per line >> > From mark.reinhold at oracle.com Thu Jun 23 18:50:47 2016 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 23 Jun 2016 11:50:47 -0700 Subject: JEP proposed to target JDK 9 (2016/6/23) Message-ID: <20160623115047.972905983eggemoggin.niobe.net> The following JEP has been placed into the "Proposed to Target" state by its owner after discussion and review: 288: Disable SHA-1 Certificates http://openjdk.java.net/jeps/288 Feedback on this proposal is more than welcome, as are reasoned objections. If no such objections are raised by 19:00 UTC next Thursday, 30 June, or if they're raised and then satisfactorily answered, then per the JEP 2.0 process proposal [1] I'll target this JEP to JDK 9. (This information is also available on the JDK 9 Project Page [2]). - Mark [1] http://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html [2] http://openjdk.java.net/projects/jdk9/ From chris.bensen at oracle.com Thu Jun 23 18:46:28 2016 From: chris.bensen at oracle.com (Chris Bensen) Date: Thu, 23 Jun 2016 11:46:28 -0700 Subject: RFR: JDK-8159172 - Update usage of jlink/jimage/jmod to show option patterns In-Reply-To: <44DC3692-7542-4502-84BC-6916A1E11FB7@oracle.com> References: <44DC3692-7542-4502-84BC-6916A1E11FB7@oracle.com> Message-ID: <6CD6B7C6-0719-491C-BC88-8F6938CB2CBD@oracle.com> --mp should be -p, at least according to Mark?s email about options unification: >> Existing spellings New spellings >> -------------------------------- ------------------------------- >> -modulepath | -mp | --modulepath --module-path | -p Chris > On Jun 23, 2016, at 11:40 AM, Jim Laskey (Oracle) wrote: > > > http://cr.openjdk.java.net/~jlaskey/8159172/webrev/index.html > https://bugs.openjdk.java.net/browse/JDK-8159172 > > This is an initial clean up of help for jlink/jimage/jmod. More work is required (like unifying the options tooling), but comments welcome. ? Jim > > /Projects/jdk9-dev% jmod --help > Usage: jmod (create|list|describe|hash) > > Main operation modes: > create - Creates a new jmod archive > list - Prints the names of all the entries > describe - Prints the module details > hash - Records hashes of tied modules. > > Option Description > ------ ----------- > --class-path Application jar files|dir containing > classes > --cmds Location of native commands > --config Location of user-editable config files > --dry-run Dry run of hash mode > --exclude Exclude files matching the supplied > comma separated pattern list, each > element using one the following > forms: , glob: pattern> or regex: > --hash-modules Compute and record hashes to tie a > packaged module with modules > matching the given > and depending upon it directly or > indirectly. The hashes are recorded > in the JMOD file being created, or a > JMOD file or modular JAR on the > module path specified the jmod hash > command. > --help Print this usage message > --libs Location of native libraries > --main-class Main class > --module-version Module version > --modulepath, --mp Module path > --os-arch Operating system architecture > --os-name Operating system name > --os-version Operating system version > --version Version information > @ Read options from the specified file > > /Projects/jdk9-dev% jimage --help > Usage: jimage jimage... > > extract - Extract all jimage entries and place in a directory specified > by the --dir= (default=.) option. > > info - Prints detailed information contained in the jimage header. > > list - Prints the names of all the entries in the jimage. When used with > --verbose, list will also print entry size and offset attributes. > > verify - Reports on any .class entries that dont verify as classes. > > Possible options include: > --dir Target directory for extract directive > --include Pattern list for filtering list or extract entries.w > --fullversion Print full version information > --help Print usage message > --verbose Listing prints entry size and offset attributes > --version Print version information > > For options requiring a , the value will be a comma separated list of elements each using one the following forms: > > glob: > regex: > > @ where filename is the name of a file containing patterns to be used, one pattern per line > > /Projects/jdk9-dev% jlink --list-plugins > > List of available plugins: > > Plugin Name: class-optim > Option: --class-optim=[:log=] > Description: Class optimization. Warning: This plugin is experimental. > An optional can be specified to log applied optimizations. > > Plugin Name: compress > Option: --compress=<0|1|2>[:filter=] > Description: Compress all resources in the output image. > Level 0: constant string sharing > Level 1: ZIP > Level 2: both. > An optional filter can be specified to list the pattern of > files to be included. > > Plugin Name: copy-files > Option: --copy-files== to copy to the image>. > Description: If files to copy are not absolute path, JDK home dir is used. > e.g.: jrt-fs.jar,LICENSE,/home/me/myfile.txt=somewehere/conf.txt > > Plugin Name: exclude-files > Option: --exclude-files= of files to exclude > Description: Specify files to exclude. e.g.: **.java,glob:/java.base/native/client/** > > Plugin Name: exclude-resources > Option: --exclude-resources= resources to exclude > Description: Specify resources to exclude. e.g.: **.jcov,glob:**/META-INF/** > > Plugin Name: generate-jli-classes > Option: --generate-jli-classes= > Description: Concrete java.lang.invoke classes to generate > > Plugin Name: include-locales > Option: --include-locales=[,]* > Description: BCP 47 language tags separated by a comma, allowing locale matching > defined in RFC 4647. e.g.: en,ja,*-IN > > Plugin Name: installed-modules > Option: --installed-modules > Description: Fast loading of module descriptors (always enabled) > > Plugin Name: order-resources > Option: --order-resources= of paths in priority order. If a @file > is specified, then each line should be an exact match for the path to be ordered > Description: Order resources. e.g.: **/module-info.class, at classlist,/java.base/java/lang/** > > Plugin Name: release-info > Option: --release-info=|add:=:=:...|del: > Description: option is to load release properties from the supplied file. > add: is to add properties to the release file. > Any number of = pairs can be passed. > del: is to delete the list of keys in release file. > > Plugin Name: strip-debug > Option: --strip-debug > Description: Strip debug information from the output image > > Plugin Name: strip-native-commands > Option: --strip-native-commands > Description: Exclude native commands (such as java/java.exe) from the image > > Plugin Name: vm > Option: --vm= > Description: Select the HotSpot VM in the output image. Default is all > > For options requiring a , the value will be a comma separated list of elements each using one the following forms: > > glob: > regex: > @ where filename is the name of a file containing patterns to be used, one pattern per line > From yasuenag at gmail.com Fri Jun 24 15:14:03 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Sat, 25 Jun 2016 00:14:03 +0900 Subject: JDK 9 build with GCC 6.1.1 Message-ID: <0106e92a-8429-8173-52d3-bb8989a7343b@gmail.com> Hi all, I've tried to OpenJDK 9 build at Fedora 24 x64. Fedora 24 has GCC 6.1.1, and OpenJDK 9 build was failed. I fixed build error and several issues (VM crash and internal error) as below: hotspot: http://cr.openjdk.java.net/~ysuenaga/jdk9-for-gcc6/hotspot/ jdk: http://cr.openjdk.java.net/~ysuenaga/jdk9-for-gcc6/jdk/ Does someone work for it? If no one works for it, I will file it to JBS and will send review request. Thanks, Yasumasa From martinrb at google.com Fri Jun 24 16:35:34 2016 From: martinrb at google.com (Martin Buchholz) Date: Fri, 24 Jun 2016 09:35:34 -0700 Subject: JDK 9 build with GCC 6.1.1 In-Reply-To: <0106e92a-8429-8173-52d3-bb8989a7343b@gmail.com> References: <0106e92a-8429-8173-52d3-bb8989a7343b@gmail.com> Message-ID: For code maintained by openjdk, it seems best to fix misleading indentation warnings, as you are doing. For code maintained elsewhere (LCMS), it seems best to suppress warnings as you are doing, or fix them in LCMS upstream. In the code below you are changing the behavior of the code, which is very likely a mistake. fdlibm is an imported ancient library we should probably not be reformatting. --- old/src/java.base/share/native/libfdlibm/k_rem_pio2.c 2016-06-25 00:08:16.467503269 +0900 +++ new/src/java.base/share/native/libfdlibm/k_rem_pio2.c 2016-06-25 00:08:16.122504578 +0900 @@ -198,7 +198,9 @@ /* compute q[0],q[1],...q[jk] */ for (i=0;i<=jk;i++) { - for(j=0,fw=0.0;j<=jx;j++) fw += x[j]*f[jx+i-j]; q[i] = fw; + for (j=0,fw=0.0;j<=jx;j++) { + fw += x[j]*f[jx+i-j]; q[i] = fw; + } } On Fri, Jun 24, 2016 at 8:14 AM, Yasumasa Suenaga wrote: > Hi all, > > I've tried to OpenJDK 9 build at Fedora 24 x64. > Fedora 24 has GCC 6.1.1, and OpenJDK 9 build was failed. > > I fixed build error and several issues (VM crash and internal error) as > below: > > hotspot: http://cr.openjdk.java.net/~ysuenaga/jdk9-for-gcc6/hotspot/ > jdk: http://cr.openjdk.java.net/~ysuenaga/jdk9-for-gcc6/jdk/ > > Does someone work for it? > If no one works for it, I will file it to JBS and will send review request. > > > Thanks, > > Yasumasa > From joe.darcy at oracle.com Fri Jun 24 16:39:52 2016 From: joe.darcy at oracle.com (joe darcy) Date: Fri, 24 Jun 2016 09:39:52 -0700 Subject: JDK 9 build with GCC 6.1.1 In-Reply-To: References: <0106e92a-8429-8173-52d3-bb8989a7343b@gmail.com> Message-ID: <857ca6be-4e8d-79f8-fe07-0571bce6872a@oracle.com> Hello, Yes, please leave fdlibm alone. There is a chance I'll finish porting fdlibm to more idiomatic Java code later in JDK 9 (JDK-8134780). Thanks, -Joe On 6/24/2016 9:35 AM, Martin Buchholz wrote: > For code maintained by openjdk, it seems best to fix misleading > indentation warnings, as you are doing. > For code maintained elsewhere (LCMS), it seems best to suppress > warnings as you are doing, or fix them in LCMS upstream. > > In the code below you are changing the behavior of the code, which is > very likely a mistake. fdlibm is an imported ancient library we > should probably not be reformatting. > > --- old/src/java.base/share/native/libfdlibm/k_rem_pio2.c2016-06-25 > 00:08:16.467503269 +0900 > +++ new/src/java.base/share/native/libfdlibm/k_rem_pio2.c2016-06-25 > 00:08:16.122504578 +0900 > @@ -198,7 +198,9 @@ > /* compute q[0],q[1],...q[jk] */ > for (i=0;i<=jk;i++) { > - for(j=0,fw=0.0;j<=jx;j++) fw += x[j]*f[jx+i-j]; q[i] = fw; > + for (j=0,fw=0.0;j<=jx;j++) { > + fw += x[j]*f[jx+i-j]; q[i] = fw; > + } > } > > > On Fri, Jun 24, 2016 at 8:14 AM, Yasumasa Suenaga > wrote: > > Hi all, > > I've tried to OpenJDK 9 build at Fedora 24 x64. > Fedora 24 has GCC 6.1.1, and OpenJDK 9 build was failed. > > I fixed build error and several issues (VM crash and internal > error) as below: > > hotspot: > http://cr.openjdk.java.net/~ysuenaga/jdk9-for-gcc6/hotspot/ > > jdk: http://cr.openjdk.java.net/~ysuenaga/jdk9-for-gcc6/jdk/ > > > Does someone work for it? > If no one works for it, I will file it to JBS and will send review > request. > > > Thanks, > > Yasumasa > > From philip.race at oracle.com Fri Jun 24 16:53:29 2016 From: philip.race at oracle.com (Phil Race) Date: Fri, 24 Jun 2016 09:53:29 -0700 Subject: JDK 9 build with GCC 6.1.1 In-Reply-To: <857ca6be-4e8d-79f8-fe07-0571bce6872a@oracle.com> References: <0106e92a-8429-8173-52d3-bb8989a7343b@gmail.com> <857ca6be-4e8d-79f8-fe07-0571bce6872a@oracle.com> Message-ID: <576D6589.6040305@oracle.com> After taking out fdlibm *everything* else is in the client-libs You should propose any changes on the relevant mailing lists (jdk9-dev is not usually a code review list). I suggest 2d-dev at openjdk.java.net since all but one file is definitely 2D .. Also the changes should be prepared against jdk9/client And as Martin notes changes to upstream external libraries are not recommended. So the two in the IJG JPEG library maybe should just be suppressed .. but we can discuss that on 2d-dev. -phil. On 06/24/2016 09:39 AM, joe darcy wrote: > Hello, > > Yes, please leave fdlibm alone. There is a chance I'll finish porting > fdlibm to more idiomatic Java code later in JDK 9 (JDK-8134780). > > Thanks, > > -Joe > > > On 6/24/2016 9:35 AM, Martin Buchholz wrote: >> For code maintained by openjdk, it seems best to fix misleading >> indentation warnings, as you are doing. >> For code maintained elsewhere (LCMS), it seems best to suppress >> warnings as you are doing, or fix them in LCMS upstream. >> >> In the code below you are changing the behavior of the code, which is >> very likely a mistake. fdlibm is an imported ancient library we >> should probably not be reformatting. >> >> --- old/src/java.base/share/native/libfdlibm/k_rem_pio2.c2016-06-25 >> 00:08:16.467503269 +0900 >> +++ new/src/java.base/share/native/libfdlibm/k_rem_pio2.c2016-06-25 >> 00:08:16.122504578 +0900 >> @@ -198,7 +198,9 @@ >> /* compute q[0],q[1],...q[jk] */ >> for (i=0;i<=jk;i++) { >> - for(j=0,fw=0.0;j<=jx;j++) fw += x[j]*f[jx+i-j]; q[i] = fw; >> + for (j=0,fw=0.0;j<=jx;j++) { >> + fw += x[j]*f[jx+i-j]; q[i] = fw; >> + } >> } >> >> >> On Fri, Jun 24, 2016 at 8:14 AM, Yasumasa Suenaga > > wrote: >> >> Hi all, >> >> I've tried to OpenJDK 9 build at Fedora 24 x64. >> Fedora 24 has GCC 6.1.1, and OpenJDK 9 build was failed. >> >> I fixed build error and several issues (VM crash and internal >> error) as below: >> >> hotspot: >> http://cr.openjdk.java.net/~ysuenaga/jdk9-for-gcc6/hotspot/ >> >> jdk: http://cr.openjdk.java.net/~ysuenaga/jdk9-for-gcc6/jdk/ >> >> >> Does someone work for it? >> If no one works for it, I will file it to JBS and will send review >> request. >> >> >> Thanks, >> >> Yasumasa >> >> > From yasuenag at gmail.com Sat Jun 25 13:48:26 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Sat, 25 Jun 2016 22:48:26 +0900 Subject: JDK 9 build with GCC 6.1.1 In-Reply-To: <576D6589.6040305@oracle.com> References: <0106e92a-8429-8173-52d3-bb8989a7343b@gmail.com> <857ca6be-4e8d-79f8-fe07-0571bce6872a@oracle.com> <576D6589.6040305@oracle.com> Message-ID: <5cb71492-747e-433e-cec5-7913454452bf@gmail.com> Thanks all! I've sent review request for it to 2d-dev [1]. This change does not include fix for fdlibm, and JPEG library is just suppressed warning. I want to continue to discuss for this issue in 2d-dev :-) Thanks, Yasumasa [1] http://mail.openjdk.java.net/pipermail/2d-dev/2016-June/007081.html On 2016/06/25 1:53, Phil Race wrote: > After taking out fdlibm *everything* else is in the client-libs > You should propose any changes on the relevant mailing lists (jdk9-dev is not usually a code review list). > I suggest 2d-dev at openjdk.java.net since all but one file is definitely 2D .. > Also the changes should be prepared against jdk9/client > > And as Martin notes changes to upstream external libraries are not recommended. > So the two in the IJG JPEG library maybe should just be suppressed .. but > we can discuss that on 2d-dev. > > -phil. > > On 06/24/2016 09:39 AM, joe darcy wrote: >> Hello, >> >> Yes, please leave fdlibm alone. There is a chance I'll finish porting fdlibm to more idiomatic Java code later in JDK 9 (JDK-8134780). >> >> Thanks, >> >> -Joe >> >> >> On 6/24/2016 9:35 AM, Martin Buchholz wrote: >>> For code maintained by openjdk, it seems best to fix misleading indentation warnings, as you are doing. >>> For code maintained elsewhere (LCMS), it seems best to suppress warnings as you are doing, or fix them in LCMS upstream. >>> >>> In the code below you are changing the behavior of the code, which is very likely a mistake. fdlibm is an imported ancient library we should probably not be reformatting. >>> >>> --- old/src/java.base/share/native/libfdlibm/k_rem_pio2.c2016-06-25 00:08:16.467503269 +0900 >>> +++ new/src/java.base/share/native/libfdlibm/k_rem_pio2.c2016-06-25 00:08:16.122504578 +0900 >>> @@ -198,7 +198,9 @@ >>> /* compute q[0],q[1],...q[jk] */ >>> for (i=0;i<=jk;i++) { >>> - for(j=0,fw=0.0;j<=jx;j++) fw += x[j]*f[jx+i-j]; q[i] = fw; >>> + for (j=0,fw=0.0;j<=jx;j++) { >>> + fw += x[j]*f[jx+i-j]; q[i] = fw; >>> + } >>> } >>> >>> >>> On Fri, Jun 24, 2016 at 8:14 AM, Yasumasa Suenaga > wrote: >>> >>> Hi all, >>> >>> I've tried to OpenJDK 9 build at Fedora 24 x64. >>> Fedora 24 has GCC 6.1.1, and OpenJDK 9 build was failed. >>> >>> I fixed build error and several issues (VM crash and internal >>> error) as below: >>> >>> hotspot: >>> http://cr.openjdk.java.net/~ysuenaga/jdk9-for-gcc6/hotspot/ >>> >>> jdk: http://cr.openjdk.java.net/~ysuenaga/jdk9-for-gcc6/jdk/ >>> >>> >>> Does someone work for it? >>> If no one works for it, I will file it to JBS and will send review >>> request. >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >> > From erik.joelsson at oracle.com Mon Jun 27 13:15:54 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 27 Jun 2016 15:15:54 +0200 Subject: JDK 9 build with GCC 6.1.1 In-Reply-To: <0106e92a-8429-8173-52d3-bb8989a7343b@gmail.com> References: <0106e92a-8429-8173-52d3-bb8989a7343b@gmail.com> Message-ID: <5771270A.2010300@oracle.com> For the change to Awt2dLibraries.gmk, please add the disabled warning to "DISABLED_WARNINGS_gcc parameter further down instead of explicitly adding CFLAGS. Not all versions of GCC can handle unknown warning tags. We handle that automatically with the DISABLED_WARNINGS variables. /Erik On 2016-06-24 17:14, Yasumasa Suenaga wrote: > Hi all, > > I've tried to OpenJDK 9 build at Fedora 24 x64. > Fedora 24 has GCC 6.1.1, and OpenJDK 9 build was failed. > > I fixed build error and several issues (VM crash and internal error) > as below: > > hotspot: http://cr.openjdk.java.net/~ysuenaga/jdk9-for-gcc6/hotspot/ > jdk: http://cr.openjdk.java.net/~ysuenaga/jdk9-for-gcc6/jdk/ > > Does someone work for it? > If no one works for it, I will file it to JBS and will send review > request. > > > Thanks, > > Yasumasa From yasuenag at gmail.com Mon Jun 27 13:56:43 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Mon, 27 Jun 2016 22:56:43 +0900 Subject: JDK 9 build with GCC 6.1.1 In-Reply-To: <5771270A.2010300@oracle.com> References: <0106e92a-8429-8173-52d3-bb8989a7343b@gmail.com> <5771270A.2010300@oracle.com> Message-ID: Hi Erik, Thank you for your comment. I've fixed it and send review request [1]. Could you check [1] ? Thanks, Yasumasa [1] http://mail.openjdk.java.net/pipermail/2d-dev/2016-June/007090.html On 2016/06/27 22:15, Erik Joelsson wrote: > For the change to Awt2dLibraries.gmk, please add the disabled warning to "DISABLED_WARNINGS_gcc parameter further down instead of explicitly adding CFLAGS. Not all versions of GCC can handle unknown warning tags. We handle that automatically with the DISABLED_WARNINGS variables. > > /Erik > > On 2016-06-24 17:14, Yasumasa Suenaga wrote: >> Hi all, >> >> I've tried to OpenJDK 9 build at Fedora 24 x64. >> Fedora 24 has GCC 6.1.1, and OpenJDK 9 build was failed. >> >> I fixed build error and several issues (VM crash and internal error) as below: >> >> hotspot: http://cr.openjdk.java.net/~ysuenaga/jdk9-for-gcc6/hotspot/ >> jdk: http://cr.openjdk.java.net/~ysuenaga/jdk9-for-gcc6/jdk/ >> >> Does someone work for it? >> If no one works for it, I will file it to JBS and will send review request. >> >> >> Thanks, >> >> Yasumasa > From daniel.fuchs at oracle.com Tue Jun 28 09:15:57 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 28 Jun 2016 10:15:57 +0100 Subject: CFV: New JDK9 Committer: Vyom Tewari Message-ID: Hi, I hereby nominate Vyom Tewari (vtewari) to JDK 9 Committer. Vyom is a member of the java core libraries team at Oracle. In total Vyom has contributed 18 changes to jdk9/jdk since September 2015 [1]. Votes are due by 12th July. Only current JDK9 Committers [2] 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 [3]. Thanks, -- daniel [1] hg log -f -k vyom.tewari -k vtewari --template "{date|isodate}\n{desc|firstline}\nhttp://hg.openjdk.java.net/jdk9/dev/jdk/rev/{rev}\n\n" 2016-06-22 09:01 +0100 8071660: URLPermission not handling empty method lists correctly http://hg.openjdk.java.net/jdk9/dev/jdk/rev/14876 2016-06-21 16:52 +0100 8114860: Behavior of java.net.URLPermission.getActions() contradicts spec http://hg.openjdk.java.net/jdk9/dev/jdk/rev/14871 2016-06-21 16:42 +0100 8154234: Remove netdoc URL protocol Handler http://hg.openjdk.java.net/jdk9/dev/jdk/rev/14870 2016-06-21 14:00 +0100 8144008: Setting NO_PROXY on HTTP URL connections does not stop proxying http://hg.openjdk.java.net/jdk9/dev/jdk/rev/14867 2016-05-24 20:15 +0100 8016521: InetAddress should not always re-order addresses returned from name service http://hg.openjdk.java.net/jdk9/dev/jdk/rev/14600 2016-05-24 12:31 +0100 8143923: java.net socket supportedOptions set depends on call order http://hg.openjdk.java.net/jdk9/dev/jdk/rev/14597 2016-04-06 21:31 +0100 8151586: Wrong exception catch for FTPClient in JDK-8055032 http://hg.openjdk.java.net/jdk9/dev/jdk/rev/14087 2016-04-05 17:07 +0100 7167293: FtpURLConnection connection leak on FileNotFoundException http://hg.openjdk.java.net/jdk9/dev/jdk/rev/13998 2016-03-03 17:27 +0000 8150521: SharedSecrets.getJavaNetInetAddressAccess should ensure that InetAddress is initialised http://hg.openjdk.java.net/jdk9/dev/jdk/rev/13807 2016-03-03 17:21 +0000 8148609: socket impl supportedOptions() should return an immutable set http://hg.openjdk.java.net/jdk9/dev/jdk/rev/13806 2015-12-18 16:06 +0530 4823133: RandomAccessFile.length() is not thread-safe http://hg.openjdk.java.net/jdk9/dev/jdk/rev/13425 2015-12-02 21:32 +0100 6856817: Poor performance of Writer#append with CharBuffer http://hg.openjdk.java.net/jdk9/dev/jdk/rev/13215 2015-10-27 10:14 +0530 8068887: java.lang.Throwable could use Collections.emptyList for suppressedException http://hg.openjdk.java.net/jdk9/dev/jdk/rev/12963 2015-09-29 19:50 +0200 8038075: JNI warnings in jdk/src/share/native/sun/misc/VMSupport.c http://hg.openjdk.java.net/jdk9/dev/jdk/rev/12812 2015-09-17 17:33 +0200 8073542: File Leak in jdk/src/java/base/unix/native/libnet/PlainDatagramSocketImpl.c http://hg.openjdk.java.net/jdk9/dev/jdk/rev/12747 2015-09-10 17:14 +0200 8080402: File Leak in jdk/src/java.base/share/classes/sun/net/sdp/SdpSupport.java http://hg.openjdk.java.net/jdk9/dev/jdk/rev/12720 2015-09-07 10:37 +0200 8080486: JNI exception pending in jdk/src/java.base/windows/native/libnet/DualStackPlainSocketImpl.c http://hg.openjdk.java.net/jdk9/dev/jdk/rev/12685 2015-09-01 15:34 +0200 8064470: JNI exception pending in jdk/src/java/base/unix/native/libjava/FileDescriptor_md.c http://hg.openjdk.java.net/jdk9/dev/jdk/rev/12670 [2] http://openjdk.java.net/census#jdk9 [3] http://openjdk.java.net/projects#committer-vote From nadeesh.tv at oracle.com Tue Jun 28 10:12:44 2016 From: nadeesh.tv at oracle.com (nadeesh tv) Date: Tue, 28 Jun 2016 15:42:44 +0530 Subject: CFV: New JDK9 Committer: Vyom Tewari In-Reply-To: References: Message-ID: <57724D9C.80107@oracle.com> Vote: Yes Thanks and Regards, Nadeesh On 6/28/2016 2:45 PM, Daniel Fuchs wrote: > Hi, > > I hereby nominate Vyom Tewari (vtewari) to JDK 9 Committer. > > Vyom is a member of the java core libraries team at Oracle. > In total Vyom has contributed 18 changes to jdk9/jdk since > September 2015 [1]. > > Votes are due by 12th July. > > Only current JDK9 Committers [2] 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 [3]. > > Thanks, > > -- daniel > > [1] > hg log -f -k vyom.tewari -k vtewari --template > "{date|isodate}\n{desc|firstline}\nhttp://hg.openjdk.java.net/jdk9/dev/jdk/rev/{rev}\n\n" > > 2016-06-22 09:01 +0100 > 8071660: URLPermission not handling empty method lists correctly > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/14876 > > 2016-06-21 16:52 +0100 > 8114860: Behavior of java.net.URLPermission.getActions() contradicts spec > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/14871 > > 2016-06-21 16:42 +0100 > 8154234: Remove netdoc URL protocol Handler > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/14870 > > 2016-06-21 14:00 +0100 > 8144008: Setting NO_PROXY on HTTP URL connections does not stop proxying > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/14867 > > 2016-05-24 20:15 +0100 > 8016521: InetAddress should not always re-order addresses returned > from name service > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/14600 > > 2016-05-24 12:31 +0100 > 8143923: java.net socket supportedOptions set depends on call order > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/14597 > > 2016-04-06 21:31 +0100 > 8151586: Wrong exception catch for FTPClient in JDK-8055032 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/14087 > > 2016-04-05 17:07 +0100 > 7167293: FtpURLConnection connection leak on FileNotFoundException > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/13998 > > 2016-03-03 17:27 +0000 > 8150521: SharedSecrets.getJavaNetInetAddressAccess should ensure that > InetAddress is initialised > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/13807 > > 2016-03-03 17:21 +0000 > 8148609: socket impl supportedOptions() should return an immutable set > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/13806 > > 2015-12-18 16:06 +0530 > 4823133: RandomAccessFile.length() is not thread-safe > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/13425 > > 2015-12-02 21:32 +0100 > 6856817: Poor performance of Writer#append with CharBuffer > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/13215 > > 2015-10-27 10:14 +0530 > 8068887: java.lang.Throwable could use Collections.emptyList for > suppressedException > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/12963 > > 2015-09-29 19:50 +0200 > 8038075: JNI warnings in jdk/src/share/native/sun/misc/VMSupport.c > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/12812 > > 2015-09-17 17:33 +0200 > 8073542: File Leak in > jdk/src/java/base/unix/native/libnet/PlainDatagramSocketImpl.c > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/12747 > > 2015-09-10 17:14 +0200 > 8080402: File Leak in > jdk/src/java.base/share/classes/sun/net/sdp/SdpSupport.java > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/12720 > > 2015-09-07 10:37 +0200 > 8080486: JNI exception pending in > jdk/src/java.base/windows/native/libnet/DualStackPlainSocketImpl.c > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/12685 > > 2015-09-01 15:34 +0200 > 8064470: JNI exception pending in > jdk/src/java/base/unix/native/libjava/FileDescriptor_md.c > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/12670 > > > [2] http://openjdk.java.net/census#jdk9 > [3] http://openjdk.java.net/projects#committer-vote -- Thanks and Regards, Nadeesh TV From claes.redestad at oracle.com Tue Jun 28 11:35:44 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Tue, 28 Jun 2016 13:35:44 +0200 Subject: CFV: New JDK9 Committer: Vyom Tewari In-Reply-To: References: Message-ID: <57726110.20606@oracle.com> Vote: yes /Claes On 2016-06-28 11:15, Daniel Fuchs wrote: > Hi, > > I hereby nominate Vyom Tewari (vtewari) to JDK 9 Committer. From pavel.rappo at oracle.com Tue Jun 28 11:45:49 2016 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Tue, 28 Jun 2016 12:45:49 +0100 Subject: CFV: New JDK9 Committer: Vyom Tewari In-Reply-To: References: Message-ID: <37D01DE0-E8B2-4F84-9987-2E3FBD6A013A@oracle.com> Vote: yes > On 28 Jun 2016, at 10:15, Daniel Fuchs wrote: > > Hi, > > I hereby nominate Vyom Tewari (vtewari) to JDK 9 Committer. > > Vyom is a member of the java core libraries team at Oracle. > In total Vyom has contributed 18 changes to jdk9/jdk since > September 2015 [1]. > > Votes are due by 12th July. > > Only current JDK9 Committers [2] 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 [3]. > > Thanks, > > -- daniel > > [1] > hg log -f -k vyom.tewari -k vtewari --template "{date|isodate}\n{desc|firstline}\nhttp://hg.openjdk.java.net/jdk9/dev/jdk/rev/{rev}\n\n" > > 2016-06-22 09:01 +0100 > 8071660: URLPermission not handling empty method lists correctly > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/14876 > > 2016-06-21 16:52 +0100 > 8114860: Behavior of java.net.URLPermission.getActions() contradicts spec > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/14871 > > 2016-06-21 16:42 +0100 > 8154234: Remove netdoc URL protocol Handler > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/14870 > > 2016-06-21 14:00 +0100 > 8144008: Setting NO_PROXY on HTTP URL connections does not stop proxying > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/14867 > > 2016-05-24 20:15 +0100 > 8016521: InetAddress should not always re-order addresses returned from name service > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/14600 > > 2016-05-24 12:31 +0100 > 8143923: java.net socket supportedOptions set depends on call order > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/14597 > > 2016-04-06 21:31 +0100 > 8151586: Wrong exception catch for FTPClient in JDK-8055032 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/14087 > > 2016-04-05 17:07 +0100 > 7167293: FtpURLConnection connection leak on FileNotFoundException > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/13998 > > 2016-03-03 17:27 +0000 > 8150521: SharedSecrets.getJavaNetInetAddressAccess should ensure that InetAddress is initialised > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/13807 > > 2016-03-03 17:21 +0000 > 8148609: socket impl supportedOptions() should return an immutable set > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/13806 > > 2015-12-18 16:06 +0530 > 4823133: RandomAccessFile.length() is not thread-safe > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/13425 > > 2015-12-02 21:32 +0100 > 6856817: Poor performance of Writer#append with CharBuffer > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/13215 > > 2015-10-27 10:14 +0530 > 8068887: java.lang.Throwable could use Collections.emptyList for suppressedException > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/12963 > > 2015-09-29 19:50 +0200 > 8038075: JNI warnings in jdk/src/share/native/sun/misc/VMSupport.c > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/12812 > > 2015-09-17 17:33 +0200 > 8073542: File Leak in jdk/src/java/base/unix/native/libnet/PlainDatagramSocketImpl.c > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/12747 > > 2015-09-10 17:14 +0200 > 8080402: File Leak in jdk/src/java.base/share/classes/sun/net/sdp/SdpSupport.java > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/12720 > > 2015-09-07 10:37 +0200 > 8080486: JNI exception pending in jdk/src/java.base/windows/native/libnet/DualStackPlainSocketImpl.c > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/12685 > > 2015-09-01 15:34 +0200 > 8064470: JNI exception pending in jdk/src/java/base/unix/native/libjava/FileDescriptor_md.c > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/12670 > > > [2] http://openjdk.java.net/census#jdk9 > [3] http://openjdk.java.net/projects#committer-vote From dalibor.topic at oracle.com Tue Jun 28 11:55:29 2016 From: dalibor.topic at oracle.com (dalibor topic) Date: Tue, 28 Jun 2016 13:55:29 +0200 Subject: CFV: New JDK9 Committer: Vyom Tewari In-Reply-To: <37D01DE0-E8B2-4F84-9987-2E3FBD6A013A@oracle.com> References: <37D01DE0-E8B2-4F84-9987-2E3FBD6A013A@oracle.com> Message-ID: Vote: Yes. -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From aleksej.efimov at oracle.com Tue Jun 28 12:03:10 2016 From: aleksej.efimov at oracle.com (Aleks Efimov) Date: Tue, 28 Jun 2016 15:03:10 +0300 Subject: CFV: New JDK9 Committer: Vyom Tewari In-Reply-To: References: Message-ID: <5772677E.7000507@oracle.com> Vote: Yes On 28/06/16 12:15, Daniel Fuchs wrote: > Hi, > > I hereby nominate Vyom Tewari (vtewari) to JDK 9 Committer. > > Vyom is a member of the java core libraries team at Oracle. > In total Vyom has contributed 18 changes to jdk9/jdk since > September 2015 [1]. > > Votes are due by 12th July. > > Only current JDK9 Committers [2] 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 [3]. > > Thanks, > > -- daniel > > [1] > hg log -f -k vyom.tewari -k vtewari --template > "{date|isodate}\n{desc|firstline}\nhttp://hg.openjdk.java.net/jdk9/dev/jdk/rev/{rev}\n\n" > > 2016-06-22 09:01 +0100 > 8071660: URLPermission not handling empty method lists correctly > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/14876 > > 2016-06-21 16:52 +0100 > 8114860: Behavior of java.net.URLPermission.getActions() contradicts spec > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/14871 > > 2016-06-21 16:42 +0100 > 8154234: Remove netdoc URL protocol Handler > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/14870 > > 2016-06-21 14:00 +0100 > 8144008: Setting NO_PROXY on HTTP URL connections does not stop proxying > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/14867 > > 2016-05-24 20:15 +0100 > 8016521: InetAddress should not always re-order addresses returned > from name service > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/14600 > > 2016-05-24 12:31 +0100 > 8143923: java.net socket supportedOptions set depends on call order > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/14597 > > 2016-04-06 21:31 +0100 > 8151586: Wrong exception catch for FTPClient in JDK-8055032 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/14087 > > 2016-04-05 17:07 +0100 > 7167293: FtpURLConnection connection leak on FileNotFoundException > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/13998 > > 2016-03-03 17:27 +0000 > 8150521: SharedSecrets.getJavaNetInetAddressAccess should ensure that > InetAddress is initialised > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/13807 > > 2016-03-03 17:21 +0000 > 8148609: socket impl supportedOptions() should return an immutable set > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/13806 > > 2015-12-18 16:06 +0530 > 4823133: RandomAccessFile.length() is not thread-safe > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/13425 > > 2015-12-02 21:32 +0100 > 6856817: Poor performance of Writer#append with CharBuffer > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/13215 > > 2015-10-27 10:14 +0530 > 8068887: java.lang.Throwable could use Collections.emptyList for > suppressedException > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/12963 > > 2015-09-29 19:50 +0200 > 8038075: JNI warnings in jdk/src/share/native/sun/misc/VMSupport.c > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/12812 > > 2015-09-17 17:33 +0200 > 8073542: File Leak in > jdk/src/java/base/unix/native/libnet/PlainDatagramSocketImpl.c > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/12747 > > 2015-09-10 17:14 +0200 > 8080402: File Leak in > jdk/src/java.base/share/classes/sun/net/sdp/SdpSupport.java > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/12720 > > 2015-09-07 10:37 +0200 > 8080486: JNI exception pending in > jdk/src/java.base/windows/native/libnet/DualStackPlainSocketImpl.c > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/12685 > > 2015-09-01 15:34 +0200 > 8064470: JNI exception pending in > jdk/src/java/base/unix/native/libjava/FileDescriptor_md.c > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/12670 > > > [2] http://openjdk.java.net/census#jdk9 > [3] http://openjdk.java.net/projects#committer-vote From michael.haupt at oracle.com Tue Jun 28 14:02:35 2016 From: michael.haupt at oracle.com (Michael Haupt) Date: Tue, 28 Jun 2016 16:02:35 +0200 Subject: CFV: New JDK9 Committer: Vyom Tewari In-Reply-To: References: Message-ID: <71CAE805-CEB1-47DF-92FF-667F27D736CD@oracle.com> Vote: yes Best, Michael > Am 28.06.2016 um 11:15 schrieb Daniel Fuchs : > I hereby nominate Vyom Tewari (vtewari) to JDK 9 Committer. -- Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331 200 7561 Oracle Java Platform Group | LangTools Team | Nashorn Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstra?e 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From Roger.Riggs at Oracle.com Tue Jun 28 14:18:52 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Tue, 28 Jun 2016 10:18:52 -0400 Subject: CFV: New JDK9 Committer: Vyom Tewari In-Reply-To: References: Message-ID: <84d794b9-8822-acf1-59fa-1c62e9f978db@Oracle.com> Vote: Yes On 6/28/2016 5:15 AM, Daniel Fuchs wrote: > Hi, > > I hereby nominate Vyom Tewari (vtewari) to JDK 9 Committer. From mandy.chung at oracle.com Tue Jun 28 15:08:56 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 28 Jun 2016 08:08:56 -0700 Subject: CFV: New JDK9 Committer: Vyom Tewari In-Reply-To: References: Message-ID: <3EB89B29-B668-49A1-B1DC-29E968417A54@oracle.com> Vote: yes Mandy From naoto.sato at oracle.com Tue Jun 28 15:57:18 2016 From: naoto.sato at oracle.com (Naoto Sato) Date: Tue, 28 Jun 2016 08:57:18 -0700 Subject: CFV: New JDK9 Committer: Vyom Tewari In-Reply-To: References: Message-ID: <5bb93cea-dbc5-ceb8-0274-cd88719fc022@oracle.com> Vote: yes Naoto On 6/28/16 2:15 AM, Daniel Fuchs wrote: > Hi, > > I hereby nominate Vyom Tewari (vtewari) to JDK 9 Committer. > > Vyom is a member of the java core libraries team at Oracle. > In total Vyom has contributed 18 changes to jdk9/jdk since > September 2015 [1]. > > Votes are due by 12th July. > > Only current JDK9 Committers [2] 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 [3]. > > Thanks, > > -- daniel > > [1] > hg log -f -k vyom.tewari -k vtewari --template > "{date|isodate}\n{desc|firstline}\nhttp://hg.openjdk.java.net/jdk9/dev/jdk/rev/{rev}\n\n" > > > 2016-06-22 09:01 +0100 > 8071660: URLPermission not handling empty method lists correctly > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/14876 > > 2016-06-21 16:52 +0100 > 8114860: Behavior of java.net.URLPermission.getActions() contradicts spec > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/14871 > > 2016-06-21 16:42 +0100 > 8154234: Remove netdoc URL protocol Handler > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/14870 > > 2016-06-21 14:00 +0100 > 8144008: Setting NO_PROXY on HTTP URL connections does not stop proxying > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/14867 > > 2016-05-24 20:15 +0100 > 8016521: InetAddress should not always re-order addresses returned from > name service > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/14600 > > 2016-05-24 12:31 +0100 > 8143923: java.net socket supportedOptions set depends on call order > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/14597 > > 2016-04-06 21:31 +0100 > 8151586: Wrong exception catch for FTPClient in JDK-8055032 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/14087 > > 2016-04-05 17:07 +0100 > 7167293: FtpURLConnection connection leak on FileNotFoundException > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/13998 > > 2016-03-03 17:27 +0000 > 8150521: SharedSecrets.getJavaNetInetAddressAccess should ensure that > InetAddress is initialised > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/13807 > > 2016-03-03 17:21 +0000 > 8148609: socket impl supportedOptions() should return an immutable set > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/13806 > > 2015-12-18 16:06 +0530 > 4823133: RandomAccessFile.length() is not thread-safe > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/13425 > > 2015-12-02 21:32 +0100 > 6856817: Poor performance of Writer#append with CharBuffer > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/13215 > > 2015-10-27 10:14 +0530 > 8068887: java.lang.Throwable could use Collections.emptyList for > suppressedException > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/12963 > > 2015-09-29 19:50 +0200 > 8038075: JNI warnings in jdk/src/share/native/sun/misc/VMSupport.c > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/12812 > > 2015-09-17 17:33 +0200 > 8073542: File Leak in > jdk/src/java/base/unix/native/libnet/PlainDatagramSocketImpl.c > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/12747 > > 2015-09-10 17:14 +0200 > 8080402: File Leak in > jdk/src/java.base/share/classes/sun/net/sdp/SdpSupport.java > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/12720 > > 2015-09-07 10:37 +0200 > 8080486: JNI exception pending in > jdk/src/java.base/windows/native/libnet/DualStackPlainSocketImpl.c > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/12685 > > 2015-09-01 15:34 +0200 > 8064470: JNI exception pending in > jdk/src/java/base/unix/native/libjava/FileDescriptor_md.c > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/12670 > > > [2] http://openjdk.java.net/census#jdk9 > [3] http://openjdk.java.net/projects#committer-vote From brent.christian at oracle.com Tue Jun 28 16:00:51 2016 From: brent.christian at oracle.com (Brent Christian) Date: Tue, 28 Jun 2016 09:00:51 -0700 Subject: CFV: New JDK9 Committer: Vyom Tewari In-Reply-To: References: Message-ID: <57729F33.7020307@oracle.com> Vote: yes -Brent On 06/28/2016 02:15 AM, Daniel Fuchs wrote: > Hi, > > I hereby nominate Vyom Tewari (vtewari) to JDK 9 Committer. > > Vyom is a member of the java core libraries team at Oracle. > In total Vyom has contributed 18 changes to jdk9/jdk since > September 2015 [1]. > > Votes are due by 12th July. > > Only current JDK9 Committers [2] 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 [3]. > > Thanks, > > -- daniel From volker.simonis at gmail.com Wed Jun 29 08:49:07 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 29 Jun 2016 10:49:07 +0200 Subject: Result: New jdk9 Committer: Christoph Langer Message-ID: Voting for Christoph Langer [1] is now closed. Yes: 15 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. Volker Simonis [1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-June/thread.html#4451 From lana.steuck at oracle.com Wed Jun 29 21:34:40 2016 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 29 Jun 2016 21:34:40 GMT Subject: jdk9-b125: dev Message-ID: <201606292134.u5TLYeFs012439@scaaa563.us.oracle.com> http://hg.openjdk.java.net/jdk9/jdk9/rev/9aa7d40f3a45 http://hg.openjdk.java.net/jdk9/jdk9/nashorn/rev/a32d419d73fe http://hg.openjdk.java.net/jdk9/jdk9/langtools/rev/2d65e127e93d http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/073ab1d4edf5 http://hg.openjdk.java.net/jdk9/jdk9/jaxws/rev/5b0570e3db29 http://hg.openjdk.java.net/jdk9/jdk9/jaxp/rev/493eb91ec32a http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/bb640b49741a http://hg.openjdk.java.net/jdk9/jdk9/corba/rev/1d48e67d1b91 --- All the fixes will be tested during promotion (no PIT testing at this point): List of all fixes: =================== JDK-7131356 core-libs (props) "No Java runtime present, requesting install" when creating VM JDK-8071660 core-libs URLPermission not handling empty method lists correctly JDK-8073653 core-libs Secondary heredoc eating wrong lines. JDK-8114860 core-libs Behavior of java.net.URLPermission.getActions() contradicts spec JDK-8136738 core-libs InputStream documentation for IOException in skip() is unclear or inco JDK-8137240 core-libs Negative lookahead in RegEx breaks backreference JDK-8144008 core-libs Setting NO_PROXY on HTTP URL connections does not stop proxying JDK-8154017 core-libs Shutdown hooks are racing against shutdown sequence, if System.exit()- JDK-8154234 core-libs Remove netdoc URL protocol Handler JDK-8156742 core-libs Miscellaneous WebSocket API improvements JDK-8157166 core-libs Update spec to account for platforms that do not support multicast JDK-8158690 core-libs GET request via HTTP/2 has a huge delays due to Nagle???s Algorithm an JDK-8158802 core-libs com.sun.jndi.ldap.SimpleClientId produces wrong hash code JDK-8158980 core-libs Memory leak in HTTP2Connection.streams JDK-8159548 core-libs Formatter returns unexpected strings if locale is null. JDK-8159766 core-libs "Switching encoding from UTF-8 to ISO-8859-1" log message should be tr JDK-8159879 core-libs Some typo and minor test bugs in ava/lang/module/ModuleReferenceTest.j JDK-8159977 core-libs typeof operator does not see lexical bindings declared in other script JDK-8160141 core-libs removed deprecated method calls in nashorn code JDK-8160264 core-libs Reuse Latin1/UTF16 compare routines JDK-8160278 core-libs Remove java/time/test/java/time/TestClock_System from the problem list JDK-8150900 hotspot Implement diagnostic_pd JDK-8081676 infrastructure Verify that configure detects AS on Solaris and print help otherwise JDK-8157253 infrastructure Fix compare script for html files JDK-8159537 infrastructure create build file to generate diags reports for all locales JDK-8159628 infrastructure Bundles contain extra /./ path element for all files JDK-8146975 other-libs NullPointerException in IIOPInputStream.inputClassFields JDK-8049314 security-libs javax/net/ssl/templates/SSLSocketSSLEngineTemplate.java fails intermit JDK-8074580 security-libs sun/security/pkcs11/rsa/TestKeyPairGenerator.java fails due to PKCS11E JDK-8152745 security-libs javax/net/ssl/TLS/TestJSSE.java fails intermittently: Unsupported or u JDK-8157318 security-libs ThreadedSeedGenerator uses System.currentTimeMillis and stops generati JDK-8157530 security-libs Remove intermittent key from javax/net/ssl/DTLS/WeakCipherSuite.java JDK-8136453 tools Parameter name indices array size not updated correctly JDK-8147794 tools Jlink's ModuleEntry.stream can't be consumed more than once and Module JDK-8150860 tools Mach 5 tier1 test started failing - jdk/jshell/ComputeFQNsTest.java ( JDK-8153238 tools Improve test/tools/jlink/JLinkTest.java not to hard code the number of JDK-8154399 tools Need replacement for jdk.javadoc/com.sun.tools.doclets.standard.Standa JDK-8155955 tools packager needs to determine the root modules to create JRE image JDK-8157936 tools Files.size(Path p) returns 0 if path is from JrtFileSystem with explod JDK-8159096 tools Expose (new) Standard doclet class. JDK-8159172 tools Update usage of jlink/jimage/jmod to show option patterns JDK-8159593 tools Plugin Set getType() should return a Category JDK-8159781 tools jlink --include-locales fails with java.util.regex.PatternSyntaxExcept JDK-8159834 tools Add some support for jtreg test headers in IntelliJ langtools project JDK-8160135 tools The Html doclet handles options incorrectly JDK-8160348 tools jlink should use System.out for usage messages JDK-8150173 xml JAXBContext.newInstance causes PrivilegedActionException when createCo From alejandro.murillo at oracle.com Thu Jun 30 17:50:34 2016 From: alejandro.murillo at oracle.com (Alejandro Murillo) Date: Thu, 30 Jun 2016 11:50:34 -0600 Subject: jdk9-dev: HotSpot Message-ID: jdk9-hs-2016-06-23 has been integrated into jdk9-dev. http://hg.openjdk.java.net/jdk9/dev/rev/b1b6e7556b30 http://hg.openjdk.java.net/jdk9/dev/corba/rev/1d48e67d1b91 http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/6012254acbad http://hg.openjdk.java.net/jdk9/dev/jaxp/rev/493eb91ec32a http://hg.openjdk.java.net/jdk9/dev/jaxws/rev/5b0570e3db29 http://hg.openjdk.java.net/jdk9/dev/jdk/rev/fafe16fe16e6 http://hg.openjdk.java.net/jdk9/dev/langtools/rev/2cdcc9283e47 http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/a0d37d08c989 Component : VM Status : Go for integration Date : 06/28/2016 at 19:06 MSK Tested By : VM SQE &leonid.mesnik at oracle.com Bundles : 2016-06-24-000807.amurillo.jdk9-hs-2016-06-23-snapsho Testing: 0 new failures, 1249 known failures, 504402 passed. Issues and Notes: No detailed analysis. No stoppers have been detected so far. Go for integration CRs for testing: 8026752: Cancel MetaspaceGC request for a CMS concurrent collection after GC 8072440: serviceability/dcmd/ tests timeout 8073159: improve Test6857159.java 8075030: JvmtiEnv::GetObjectSize reports incorrect java.lang.Class instance size 8132713: Add tests which check that Humongous objects behave as expected after finishing ConcMark Cycle 8146416: java.lang.OutOfMemoryError triggers: assert(current_bci == 0) failed: bci isn't zero for do_not_unlock_if_synchronized 8146530: [testbug] some tests fail because the compiler is using Java heap memory 8149085: IntegrationTest1.java fails intermittently due to use of semi-initialized TLAB 8149418: AArch64: replace tst+br with tbz instruction when tst's constant operand is 2 power 8149778: serviceability/tmtools/jstat/GcCapacityTest.java causes JVM to hang during GC 8149803: Adjust lock rankings for some Event-based tracing locks 8152271: MemberNameTable doesn't purge stale entries 8152376: [TESTBUG] compiler/floatingpoint/Test15FloatJNIArgs should use run main/othervm/native 8153278: sun/tools/jps/TestJpsJar.java fails in hs nightly 8153394: Add Unified Logging to make it easy to trace time taken in initPhase2 8153858: Clean up needed when obtaining the package name from a fully qualified class name 8153876: Replace 4K stack allocations with Resource allocations 8153994: Compiler tests should be correctly marked with @module 8154106: UL Xlog:help regd'g 'rt' tag 8154123: remove commented action from jdk/vm/ci/runtime/test/ConstantTest.java 8154156: PPC64: improve array copy stubs by using vector instructions 8154209: Remove client VM from default JIB profile on windows-x86 and linux-x86 8155046: Parse::Block construction using undefined behavior 8155638: Resource allocated BitMaps are often cleared twice 8156032: Clean up parallel GC specific code from vm/gc/shared/preservedMarks.cpp 8156226: DiagnosticCommandImpl::invoke throws not very comprehensive message in case if method exists but signature or parameters are wrong 8156469: [JITtester] Difference in generated golden output when run with Jigsaw build 8156587: [JVMCI] remove Unsafe.getJavaMirror and Unsafe.getKlassPointer 8156731: aarch64: java/util/Arrays/Correct.java fails due to _generic_arraycopy stub routine 8156760: VM crashes if -XX:-ReduceInitialCardMarks is set 8156871: Possible concurrency issue with JVM_AddModuleExports 8157243: JMap heap test fail when used with external heap 8157292: [JVMCI] add missing test files from 8156034 8157373: Active workers should not be reset in AbstractWorkGang initialize() 8157428: [JVMCI] remove MemoryAccessProvider.readUnsafeConstant from API 8157490: JCK test vm/jni/DefineClass/dfcl001/dfcl00101m1/dfcl00101m1 crashes when run with -Xlog:classload=info 8157620: Guarantee in run_task(task, num_workers) fails 8157821: [JITtester] OptionResolver and LiteralFactory use deprecated c-tors 8157831: JVMCI tests should not be executed on linux-arm32 8157842: indexOfChar intrinsic is not emitted on x86 8157906: aarch64: some more integer rotate instructions are never emitted 8158000: [JVMCI] remove unused ParseClosure class 8158033: Notify_tracing() misplaced for intended purpose 8158065: [Jittester]: tests generation has tests generators hardcoded, blocking alternative tests generation 8158182: remove shell script from compiler/c2/6894807/IsInstanceTest.java 8158184: remove shell from compiler/c2/7070134/Stemmer.java 8158185: jdk/test/lib/FileInstaller throws NPE if dst is in current directory 8158214: Crash with "assert(VM_Version::supports_sse4_1()) failed" if UseSSE < 4 is set 8158228: C1 incorrectly folds mismatched loads from stable arrays 8158237: JVMTI hides critical debug information for memory leak tracing 8158297: Lack of proper checking of non-well formed elements in CONSTANT_Utf8_info's structure 8158351: [JVMCI] NoClassDefFoundError: jdk/vm/ci/runtime/JVMCI 8158412: [TESTBUG] TestIHOPErgo and TestStressG1Humongous should not be executed when JFR is enabled 8158681: ClassLoader::classloader_type() is called from code not included under #if INCLUDE_CDS. 8158763: --disable-hotspot-gtest not working on Solaris 8158913: aarch64: SEGV running Spark terasort 8158929: [TESTBUG] CommitOverlappingRegions.java can not deal with pages > 32K 8158938: AIX: some more new hotspot build fixes 8158985: [JVMCI] access to HotSpotJVMCIRuntime.vmEventListeners must be thread safe 8159019: ResourceMark in ClassLoader::open_versioned_entry() is being used incorrectly 8159045: Remove const from methods returning size_t in threadLocalAllocBuffer.hpp 8159056: [aix] Compressed class space not allocated in lower regions 8159156: [TESTBUG] ReserveMemory test is not useful on Aix. 8159237: PreservedMarks verification code fails 8159255: [TESTBUG] XpatchJavaBase.java compilation failure 8159328: [TESTBUG] ProblematicFrameTest.java throws an exception (due to trying to access Unsafe) but still passes 8159350: G1 String deduplication logging malformed -- Alejandro