From alexander.kulyakhtin at oracle.com Tue Jun 2 11:18:42 2015 From: alexander.kulyakhtin at oracle.com (Alexander Kulyakhtin) Date: Tue, 2 Jun 2015 04:18:42 -0700 (PDT) Subject: RFR: JDK-8075327: Merge jdk and hotspot test libraries Message-ID: <1a17632e-265f-4adb-864f-79cb9a1587ec@default> Hi, Could you, please, review the following test-only changes to the 'jdk', 'hotspot' and the common 'test' repository http://cr.openjdk.java.net/~akulyakh/8075327/wr_hs/webrev.01/index.html http://cr.openjdk.java.net/~akulyakh/8075327/wr_jdk/webrev.01/index.html http://cr.openjdk.java.net/~akulyakh/8075327/wr_test/webrev.01/ The changes are to move test library files common to both jdk and hotspot to the upper-level test repository. The following has been done: 1) Common files (Asserts.java, OutputAnalyzer.java etc) from the jdk and hotspot repositories, have been merged and moved to the upper-level common test repository, to test/lib/share/classes. 2) Package jdk.testlibrary in the jdk repository have been renamed to jdk.test.lib to have the same name as in the hotspot repository 2) Upper level test/lib/share/classes library references have been added to the @library statements 3) Some packages previously located at upper level test repo at /test/lib have been moved to /test/lib/share/classes for consistency Best regards, Alexander From ivan.gerasimov at oracle.com Tue Jun 2 15:44:31 2015 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Tue, 02 Jun 2015 18:44:31 +0300 Subject: RFR: JDK-8075327: Merge jdk and hotspot test libraries In-Reply-To: <1a17632e-265f-4adb-864f-79cb9a1587ec@default> References: <1a17632e-265f-4adb-864f-79cb9a1587ec@default> Message-ID: <556DCF5F.7050601@oracle.com> Hi Alexander! Would you please include jdk/test/lib/testlibrary/jdk/testlibrary/OptimalCapacity.java in the webrev? This file was added recently with the fix for JDK-8081027 It's currently used from the following three tests, which will need to be updated too: jdk/test/java/lang/Character/UnicodeBlock/OptimalMapSize.java jdk/test/sun/invoke/anon/ConstantPoolPatch/OptimalMapSize.java jdk/test/sun/security/ssl/ExtensionType/OptimalListSize.java Sincerely yours, Ivan On 02.06.2015 14:18, Alexander Kulyakhtin wrote: > Hi, > > Could you, please, review the following test-only changes to the 'jdk', 'hotspot' and the common 'test' repository > > http://cr.openjdk.java.net/~akulyakh/8075327/wr_hs/webrev.01/index.html > http://cr.openjdk.java.net/~akulyakh/8075327/wr_jdk/webrev.01/index.html > http://cr.openjdk.java.net/~akulyakh/8075327/wr_test/webrev.01/ > > The changes are to move test library files common to both jdk and hotspot to the upper-level test repository. > > The following has been done: > 1) Common files (Asserts.java, OutputAnalyzer.java etc) from the jdk and hotspot repositories, have been merged and moved to the upper-level common test repository, to test/lib/share/classes. > 2) Package jdk.testlibrary in the jdk repository have been renamed to jdk.test.lib to have the same name as in the hotspot repository > 2) Upper level test/lib/share/classes library references have been added to the @library statements > 3) Some packages previously located at upper level test repo at /test/lib have been moved to /test/lib/share/classes for consistency > > Best regards, > Alexander > > From alexander.kulyakhtin at oracle.com Tue Jun 2 16:26:29 2015 From: alexander.kulyakhtin at oracle.com (Alexander Kulyakhtin) Date: Tue, 2 Jun 2015 09:26:29 -0700 (PDT) Subject: RFR: JDK-8075327: Merge jdk and hotspot test libraries Message-ID: Hi Ivan, I did my changes using hs-rt repository. The file you mention is not there yet. I'm going to do the changes to this and any other possible new jdk files as a follow up to this bulk change. The goal of the webrev is to receive approval of the way the test libraries are going to be merged. Best regards, Alexander ----- Original Message ----- From: ivan.gerasimov at oracle.com To: alexander.kulyakhtin at oracle.com, jdk9-dev at openjdk.java.net, hotspot-dev at openjdk.java.net Sent: Tuesday, June 2, 2015 6:44:33 PM GMT +03:00 Iraq Subject: Re: RFR: JDK-8075327: Merge jdk and hotspot test libraries Hi Alexander! Would you please include jdk/test/lib/testlibrary/jdk/testlibrary/OptimalCapacity.java in the webrev? This file was added recently with the fix for JDK-8081027 It's currently used from the following three tests, which will need to be updated too: jdk/test/java/lang/Character/UnicodeBlock/OptimalMapSize.java jdk/test/sun/invoke/anon/ConstantPoolPatch/OptimalMapSize.java jdk/test/sun/security/ssl/ExtensionType/OptimalListSize.java Sincerely yours, Ivan On 02.06.2015 14:18, Alexander Kulyakhtin wrote: > Hi, > > Could you, please, review the following test-only changes to the 'jdk', 'hotspot' and the common 'test' repository > > http://cr.openjdk.java.net/~akulyakh/8075327/wr_hs/webrev.01/index.html > http://cr.openjdk.java.net/~akulyakh/8075327/wr_jdk/webrev.01/index.html > http://cr.openjdk.java.net/~akulyakh/8075327/wr_test/webrev.01/ > > The changes are to move test library files common to both jdk and hotspot to the upper-level test repository. > > The following has been done: > 1) Common files (Asserts.java, OutputAnalyzer.java etc) from the jdk and hotspot repositories, have been merged and moved to the upper-level common test repository, to test/lib/share/classes. > 2) Package jdk.testlibrary in the jdk repository have been renamed to jdk.test.lib to have the same name as in the hotspot repository > 2) Upper level test/lib/share/classes library references have been added to the @library statements > 3) Some packages previously located at upper level test repo at /test/lib have been moved to /test/lib/share/classes for consistency > > Best regards, > Alexander > > From Roger.Riggs at Oracle.com Tue Jun 2 17:29:21 2015 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Tue, 02 Jun 2015 13:29:21 -0400 Subject: RFR: JDK-8075327: Merge jdk and hotspot test libraries In-Reply-To: <1a17632e-265f-4adb-864f-79cb9a1587ec@default> References: <1a17632e-265f-4adb-864f-79cb9a1587ec@default> Message-ID: <556DE7F1.10507@Oracle.com> Hi Alexander, It would useful to also update the top level common/bin/unshuffle_list.txt so backports can be handled more easily. Are all of the additions of /lib/share/classes necessary (in the JDK webrev)? I suppose it depends on whether each test depends on the moved files. (not a complete review) Roger On 6/2/2015 7:18 AM, Alexander Kulyakhtin wrote: > Hi, > > Could you, please, review the following test-only changes to the 'jdk', 'hotspot' and the common 'test' repository > > http://cr.openjdk.java.net/~akulyakh/8075327/wr_hs/webrev.01/index.html > http://cr.openjdk.java.net/~akulyakh/8075327/wr_jdk/webrev.01/index.html > http://cr.openjdk.java.net/~akulyakh/8075327/wr_test/webrev.01/ > > The changes are to move test library files common to both jdk and hotspot to the upper-level test repository. > > The following has been done: > 1) Common files (Asserts.java, OutputAnalyzer.java etc) from the jdk and hotspot repositories, have been merged and moved to the upper-level common test repository, to test/lib/share/classes. > 2) Package jdk.testlibrary in the jdk repository have been renamed to jdk.test.lib to have the same name as in the hotspot repository > 2) Upper level test/lib/share/classes library references have been added to the @library statements > 3) Some packages previously located at upper level test repo at /test/lib have been moved to /test/lib/share/classes for consistency > > Best regards, > Alexander From alejandro.murillo at oracle.com Tue Jun 2 20:36:57 2015 From: alejandro.murillo at oracle.com (Alejandro E Murillo) Date: Tue, 02 Jun 2015 14:36:57 -0600 Subject: jdk9-dev: HotSpot Message-ID: <556E13E9.2010906@oracle.com> jdk9-hs-2015-05-28 has been integrated into jdk9-dev. http://hg.openjdk.java.net/jdk9/dev/rev/b6201d741510 http://hg.openjdk.java.net/jdk9/dev/corba/rev/4418697e56f1 http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/5657d2f88180 http://hg.openjdk.java.net/jdk9/dev/jaxp/rev/e18204c4e064 http://hg.openjdk.java.net/jdk9/dev/jaxws/rev/769bb20850bd http://hg.openjdk.java.net/jdk9/dev/jdk/rev/f4fa3526b020 http://hg.openjdk.java.net/jdk9/dev/langtools/rev/51fc8d742def http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/10553f87f3e7 Component : VM Status : Go for integration Date : 06/01/2015 at 16:30 MSK Tested By : VM SQE &dmitry.fazunenko at oracle.com Bundles : 2015-05-28-184118.amurillo.jdk9-hs-2015-05-28-snapshot Testing: 91 new failures, 2146 known failures, 396444 passed. Issues and Notes: No stoppers have been detected so far. Go for integration CRs for testing: 8051712: regression Test7107135 crashes 8066757: Can't build 'images' with --disable-zip-debug-info on OS X after jigsaw m2 merge 8069068: VM warning: WaitForMultipleObjects timed out (0) ... 8080109: Use single-threaded code in Threads::possibly_parallel_oops_do when running with only one worker thread 8080110: Remove usage of CollectedHeap::n_par_threads() from root processing 8080111: Remove SubTaskDone::_n_threads 8080112: Replace and remove the last usages of CollectedHeap::n_par_threads() 8080113: Remove CollectedHeap::set_par_threads() 8080627: JavaThread::satb_mark_queue_offset() is too big for an ARM ldrsb instruction 8080663: Use sun.misc.SharedSecrets to allow access from java.management to @ConstructorProperties 8080746: Refactor oop iteration macros to be more general 8080828: Create sanity test for JDK-8080155 8080837: Move number of workers calculation out of CollectionSetChooser::prepare_for_par_region_addition 8080840: Clean up active_workers() asserts 8080855: Create sanity test for JDK-8080692 8080869: FlexibleWorkGang initializes _active_workers to more than _total_workers 8080876: Replace unnecessary MAX2(ParallelGCThreads, 1) calls with ParallelGCThreads 8080877: Don't use workers()->total_workers() when walking G1CollectedHeap::_task_queues 8080879: Remove FlexibleWorkGang::set_for_termination 8081007: Remove redundant active worker variables and calls in ParNewGeneration::collect 8081039: G1: Remove unused statistics code in G1NoteEndOfConcMarkClosure and G1ParNoteEndTask -- Alejandro From stefan.sarne at oracle.com Wed Jun 3 09:04:25 2015 From: stefan.sarne at oracle.com (=?UTF-8?B?U3RlZmFuIFPDpHJuZQ==?=) Date: Wed, 03 Jun 2015 11:04:25 +0200 Subject: RFR: JDK-8075327: Merge jdk and hotspot test libraries In-Reply-To: <1a17632e-265f-4adb-864f-79cb9a1587ec@default> References: <1a17632e-265f-4adb-864f-79cb9a1587ec@default> Message-ID: <556EC319.3020300@oracle.com> Hi Alexander, I think we want to group the utilities into packages directly. One reason for grouping is to support discovery, to clarify what belongs together. For example both the OutputAnalyzer and the StreamPumper belong together in a processtools package, while Asserts doesn't. Another reason is to simplify imports and reduce the impact of wild card includes, since for example an import of process tools should not have to bother with declaring usage of sun.misc.Unsafe in the modules world, just because Utils happen to be in the same package. Here are some examples - also available in the jira case: Package jdk.test.lib.processtools is the package for utilities for launching processes and analyzing the output. /test/lib/share/classes/jdk/test/lib/processtools/OutputAnalyzer.java /test/lib/share/classes/jdk/test/lib/processtools/OutputBuffer.java /test/lib/share/classes/jdk/test/lib/processtools/ProcessTools.java /test/lib/share/classes/jdk/test/lib/processtools/StreamPumper.java /test/lib/share/classes/jdk/test/lib/processtools/JDKToolFinder.java /test/lib/share/classes/jdk/test/lib/processtools/JDKToolLauncher.java /test/lib-test/jdk/test/lib/processtools/OutputAnalyzerTest.java Asserts can stay at top level. /test/lib/share/classes/jdk/test/lib/Asserts.java /test/lib-test/jdk/test/lib/AssertsTest.java For VM specific info, it would have vm package. Note that the whitebox API moves here. /test/lib/share/classes/jdk/test/lib/vm/InputArguments.java /test/lib/share/classes/jdk/test/lib/vm/Platform.java Ok, so then there are the stuff which just is a bucket of stuff and fluff. A later exercise could be to break this class into better named and placed classes, but this is a start: /test/lib/share/classes/jdk/test/lib/misc/Utils.java Thanks, Stefan Alexander Kulyakhtin skrev den 2015-06-02 13:18: > Hi, > > Could you, please, review the following test-only changes to the 'jdk', 'hotspot' and the common 'test' repository > > http://cr.openjdk.java.net/~akulyakh/8075327/wr_hs/webrev.01/index.html > http://cr.openjdk.java.net/~akulyakh/8075327/wr_jdk/webrev.01/index.html > http://cr.openjdk.java.net/~akulyakh/8075327/wr_test/webrev.01/ > > The changes are to move test library files common to both jdk and hotspot to the upper-level test repository. > > The following has been done: > 1) Common files (Asserts.java, OutputAnalyzer.java etc) from the jdk and hotspot repositories, have been merged and moved to the upper-level common test repository, to test/lib/share/classes. > 2) Package jdk.testlibrary in the jdk repository have been renamed to jdk.test.lib to have the same name as in the hotspot repository > 2) Upper level test/lib/share/classes library references have been added to the @library statements > 3) Some packages previously located at upper level test repo at /test/lib have been moved to /test/lib/share/classes for consistency > > Best regards, > Alexander From alexander.kulyakhtin at oracle.com Wed Jun 3 12:33:22 2015 From: alexander.kulyakhtin at oracle.com (Alexander Kulyakhtin) Date: Wed, 3 Jun 2015 05:33:22 -0700 (PDT) Subject: RFR: JDK-8075327: Merge jdk and hotspot test libraries Message-ID: Hi Stefan, Thank you very much for the review. I'll update the patch accordingly, shortly. Best regards, Alexander ----- Original Message ----- From: stefan.sarne at oracle.com To: alexander.kulyakhtin at oracle.com, jdk9-dev at openjdk.java.net, hotspot-dev at openjdk.java.net Cc: yekaterina.kantserova at oracle.com Sent: Wednesday, June 3, 2015 12:08:33 PM GMT +03:00 Iraq Subject: Re: RFR: JDK-8075327: Merge jdk and hotspot test libraries Hi Alexander, I think we want to group the utilities into packages directly. One reason for grouping is to support discovery, to clarify what belongs together. For example both the OutputAnalyzer and the StreamPumper belong together in a processtools package, while Asserts doesn't. Another reason is to simplify imports and reduce the impact of wild card includes, since for example an import of process tools should not have to bother with declaring usage of sun.misc.Unsafe in the modules world, just because Utils happen to be in the same package. Here are some examples - also available in the jira case: Package jdk.test.lib.processtools is the package for utilities for launching processes and analyzing the output. /test/lib/share/classes/jdk/test/lib/processtools/OutputAnalyzer.java /test/lib/share/classes/jdk/test/lib/processtools/OutputBuffer.java /test/lib/share/classes/jdk/test/lib/processtools/ProcessTools.java /test/lib/share/classes/jdk/test/lib/processtools/StreamPumper.java /test/lib/share/classes/jdk/test/lib/processtools/JDKToolFinder.java /test/lib/share/classes/jdk/test/lib/processtools/JDKToolLauncher.java /test/lib-test/jdk/test/lib/processtools/OutputAnalyzerTest.java Asserts can stay at top level. /test/lib/share/classes/jdk/test/lib/Asserts.java /test/lib-test/jdk/test/lib/AssertsTest.java For VM specific info, it would have vm package. Note that the whitebox API moves here. /test/lib/share/classes/jdk/test/lib/vm/InputArguments.java /test/lib/share/classes/jdk/test/lib/vm/Platform.java Ok, so then there are the stuff which just is a bucket of stuff and fluff. A later exercise could be to break this class into better named and placed classes, but this is a start: /test/lib/share/classes/jdk/test/lib/misc/Utils.java Thanks, Stefan Alexander Kulyakhtin skrev den 2015-06-02 13:18: Hi, Could you, please, review the following test-only changes to the 'jdk', 'hotspot' and the common 'test' repository http://cr.openjdk.java.net/~akulyakh/8075327/wr_hs/webrev.01/index.html http://cr.openjdk.java.net/~akulyakh/8075327/wr_jdk/webrev.01/index.html http://cr.openjdk.java.net/~akulyakh/8075327/wr_test/webrev.01/ The changes are to move test library files common to both jdk and hotspot to the upper-level test repository. The following has been done: 1) Common files (Asserts.java, OutputAnalyzer.java etc) from the jdk and hotspot repositories, have been merged and moved to the upper-level common test repository, to test/lib/share/classes. 2) Package jdk.testlibrary in the jdk repository have been renamed to jdk.test.lib to have the same name as in the hotspot repository 2) Upper level test/lib/share/classes library references have been added to the @library statements 3) Some packages previously located at upper level test repo at /test/lib have been moved to /test/lib/share/classes for consistency Best regards, Alexander From lana.steuck at oracle.com Wed Jun 3 20:48:41 2015 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 3 Jun 2015 13:48:41 -0700 (PDT) Subject: jdk9-b67: dev Message-ID: <201506032048.t53Kmf4l004281@sc11152554.us.oracle.com> http://hg.openjdk.java.net/jdk9/jdk9/rev/f546760134eb http://hg.openjdk.java.net/jdk9/jdk9/nashorn/rev/f822b749821e http://hg.openjdk.java.net/jdk9/jdk9/langtools/rev/fd782cd69b04 http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/1abd45df5480 http://hg.openjdk.java.net/jdk9/jdk9/jaxws/rev/c9785bc8ade9 http://hg.openjdk.java.net/jdk9/jdk9/jaxp/rev/78c2685daaba http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/d47dfabd16d4 http://hg.openjdk.java.net/jdk9/jdk9/corba/rev/4418697e56f1 --- All the fixes will be tested during promotion (no PIT testing at this point): List of all fixes: =================== JDK-8078855 client-libs [TEST_BUG] javax/swing/JComboBox/8032878/bug8032878.java fails in Wind JDK-8079440 client-libs [TESTBUG] @run is missing in java/awt/TrayIcon/8072769/bug8072769.java JDK-8081332 client-libs AIX: fix charset dependenicies after 8035302:Eliminate dependency on j JDK-8034773 core-libs (zipfs) newOutputstream uses CREATE_NEW when no options specified JDK-8028480 core-libs (zipfs) NoSuchFileException on creating a file in ZipFileSystem with C JDK-8077866 core-libs [TESTBUG] Some of java.lang tests cannot be run on compact profiles 1, JDK-8081347 core-libs Add @modules to jdk_core tests JDK-8068978 core-libs All versions of javax.script.ScriptEngine.eval(...) method may clarify JDK-8081015 core-libs Allow conversion of native arrays to Queue and Collection JDK-8075678 core-libs java.time javadoc error in DateTimeFormatter::parsedLeapSecond JDK-8075676 core-libs java.time package javadoc typos JDK-8068276 core-libs java.time.chrono.HijrahChronology.eraOf() assertions may lead to misun JDK-8077377 core-libs java/net/MulticastSocket/SetOutgoingIf.java fails intermittently with JDK-8041677 core-libs java/net/MulticastSocket/TestInterfaces failed on Oracle VM Virtual Et JDK-8081022 core-libs java/time/test/java/time/format/TestZoneTextPrinterParser.java fails b JDK-8081156 core-libs jjs "nashorn.args" system property is not effective when script argume JDK-8081062 core-libs ListAdapter should take advantage of JSObject JDK-8081204 core-libs ListAdapter throws NPE when adding/removing elements outside of JS con JDK-8081245 core-libs MHIllegalAccess.java failing across platforms JDK-8040147 core-libs minor cleanup for docs JDK-8007456 core-libs Nashorn test framework @argument does not handle quoted strings JDK-8036743 core-libs need ArrayBuffer constructor with specified data JDK-8064736 core-libs Part of java.util.jar.JarFile spec looks confusing with references to JDK-8038310 core-libs Re-examine integration of extended Charsets JDK-8060161 core-libs re-examine sun/nio/cs/Test4200310.sh, test is invalid for modular imag JDK-8080901 core-libs Replace package.html files with package-info.java in the java.base mod JDK-8074818 core-libs Resolve disabled warnings for libjava JDK-8080007 core-libs Stop ignoring warnings for libjava JDK-8080803 core-libs sun/nio/cs/FindEncoderBugs.java failing intermittently JDK-8081359 core-libs Update bug reporting URL JDK-8075926 core-svc Add a sun.management.JMXConnectorServer perf counter to track its stat JDK-8029098 core-svc Exclude javax/management/remote/mandatory/notif/ListenerScaleTest.java JDK-8078143 core-svc java/lang/management/ThreadMXBean/AllThreadIds.java fails intermittent JDK-8080833 core-svc JDK-8076524 has failed to remove binary files JDK-8046869 core-svc Several java/lang/instrument/PremainClass/* tests fail due to timeout JDK-8078470 hotspot [Linux] Replace syscall use in os::fork_and_exec with glibc fork() and JDK-8033445 hotspot [TESTBUG] Add test case for calling default methods from JNI JDK-8077620 hotspot [TESTBUG] Some of the hotspot tests require at least compact profile 3 JDK-8025979 hotspot [TESTBUG] Write test to exercise uninitialized strings from JNI code JDK-8080281 hotspot 8068945 changes break building the zero JVM variant JDK-8080600 hotspot AARCH64: testlibrary does not support AArch64 JDK-8080581 hotspot Align SA with new GC directory structure JDK-8080585 hotspot concurrentGCThread.hpp should not include suspendibleThreadSet.hpp JDK-8079792 hotspot GC directory structure cleanup JDK-8051045 hotspot HotSpot fails to wrap Exceptions from invokedynamic in a BootstrapMeth JDK-8080483 hotspot Incorrect test execution string at SumRed_Long.java JDK-8080584 hotspot isGCActiveMark.hpp should not include parallelScavengeHeap.hpp JDK-8080692 hotspot lots of jstack tests failing in pit JDK-8075288 hotspot malloc without free in VM_PopulateDumpSharedSpace::doit() JDK-8058265 hotspot No callers of ReferenceProcessor::clear_discovered_references JDK-8080190 hotspot PPC64: Fix wrong rotate instructions in the .ad file JDK-8079216 hotspot Remove undefined method oopDesc::is_null(Klass *). JDK-8047330 hotspot Remove unrolled card loops in G1 SparsePRTEntry JDK-8080930 hotspot SA changes broke bootcycle-images builds JDK-8080308 hotspot TypeProfileLevel on SPARC platform should enable JSR292-only profiling JDK-6811960 hotspot x86 biasedlocking epoch expired rare bug JDK-8080983 infrastructure libdt_socket: Build failed with VS2013 SP4 JDK-8078823 security-libs javax/net/ssl/ciphersuites/DisabledAlgorithms.java fails intermittentl JDK-8050374 security-libs More Signature tests JDK-8065233 security-libs Remove Policy provider code that synchronizes on identityPolicyEntries JDK-8080911 security-libs sun/security/krb5/auto/UseCacheAndStoreKey.java timed out intermittent JDK-8081278 security-libs Typo in Exception Message JDK-8081334 tools com.sun.tools.javap and com.sun.tools.javah are not exported API JDK-8080991 tools Compilation error with recent clang in java.base/share/native/launcher JDK-8080608 tools Missing archive name from jdeps -v -e output if no dependency on other JDK-8074432 tools Move jdeps and javap to jdk.jdeps module JDK-8080726 tools Redundant error message on private abstract interface method with body JDK-8074431 tools Remove native2ascii tool JDK-8081417 tools test CheckEBCDICLocaleTest.java is failing intermittently From alexander.kulyakhtin at oracle.com Thu Jun 4 14:23:21 2015 From: alexander.kulyakhtin at oracle.com (Alexander Kulyakhtin) Date: Thu, 4 Jun 2015 07:23:21 -0700 (PDT) Subject: RFR: JDK-8075327: Merge jdk and hotspot test libraries Message-ID: <1365a232-5a2d-4365-ad99-3638fdfac841@default> Stefan, There are some issues which may make it difficult to implement the grouping of the common test library files into the new packages as JDK-8075327 proposes. The changes in the current patch are trivial and made by a script (although they spread over many files). They are trivial because the names of the packages are left intact (except fo renaming of jdk.testlibrary to jdk.test.lib in the jdk repo). However, if we introduce the new packages per the CR description we will end up with import jdk.test.lib.*; import jdk.test.lib.vm.*; import jdk.test.lib.processtools.*; import jdk.test.lib.misc.*; where previously was just a single line import jdk.test.lib.*; The same goes for @build and @run directives where we end up with @build jdk.test.lib.* jdk.test.lib.vm.* jdk.test.lib.processtools.* jdk.test.lib.misc.* instead of @build jdk.test.lib.* There are many tests having import jdk.test.lib.* and @build jdk.test.lib.* and similar constructions. If we then want to deduce the minimal required dependencies for each and every jdk and hotspot test, then it will not be as trivial task as what we have currently done. It will, probably, require a significant review effort from both jdk and hotspot teams. The benefits of that effort are not quite evident for me though I, probably, might be missing something here. The current patch does already provide for the merge of the common part of the jdk and hotspot libraries and do eliminate the duplicated files. Therefore, I would suggest reviewing the current patch as it is , since the changes are trivial and postpone refactoring to the new packages until some time later, since such refactoring is not trivial and the current patch does provide for the merge. Best regards, Alexander ----- Original Message ----- From: alexander.kulyakhtin at oracle.com To: stefan.sarne at oracle.com Cc: jdk9-dev at openjdk.java.net, yekaterina.kantserova at oracle.com, hotspot-dev at openjdk.java.net Sent: Wednesday, June 3, 2015 3:33:22 PM GMT +03:00 Iraq Subject: Re: RFR: JDK-8075327: Merge jdk and hotspot test libraries Hi Stefan, Thank you very much for the review. I'll update the patch accordingly, shortly. Best regards, Alexander ----- Original Message ----- From: stefan.sarne at oracle.com To: alexander.kulyakhtin at oracle.com, jdk9-dev at openjdk.java.net, hotspot-dev at openjdk.java.net Cc: yekaterina.kantserova at oracle.com Sent: Wednesday, June 3, 2015 12:08:33 PM GMT +03:00 Iraq Subject: Re: RFR: JDK-8075327: Merge jdk and hotspot test libraries Hi Alexander, I think we want to group the utilities into packages directly. One reason for grouping is to support discovery, to clarify what belongs together. For example both the OutputAnalyzer and the StreamPumper belong together in a processtools package, while Asserts doesn't. Another reason is to simplify imports and reduce the impact of wild card includes, since for example an import of process tools should not have to bother with declaring usage of sun.misc.Unsafe in the modules world, just because Utils happen to be in the same package. Here are some examples - also available in the jira case: Package jdk.test.lib.processtools is the package for utilities for launching processes and analyzing the output. /test/lib/share/classes/jdk/test/lib/processtools/OutputAnalyzer.java /test/lib/share/classes/jdk/test/lib/processtools/OutputBuffer.java /test/lib/share/classes/jdk/test/lib/processtools/ProcessTools.java /test/lib/share/classes/jdk/test/lib/processtools/StreamPumper.java /test/lib/share/classes/jdk/test/lib/processtools/JDKToolFinder.java /test/lib/share/classes/jdk/test/lib/processtools/JDKToolLauncher.java /test/lib-test/jdk/test/lib/processtools/OutputAnalyzerTest.java Asserts can stay at top level. /test/lib/share/classes/jdk/test/lib/Asserts.java /test/lib-test/jdk/test/lib/AssertsTest.java For VM specific info, it would have vm package. Note that the whitebox API moves here. /test/lib/share/classes/jdk/test/lib/vm/InputArguments.java /test/lib/share/classes/jdk/test/lib/vm/Platform.java Ok, so then there are the stuff which just is a bucket of stuff and fluff. A later exercise could be to break this class into better named and placed classes, but this is a start: /test/lib/share/classes/jdk/test/lib/misc/Utils.java Thanks, Stefan Alexander Kulyakhtin skrev den 2015-06-02 13:18: Hi, Could you, please, review the following test-only changes to the 'jdk', 'hotspot' and the common 'test' repository http://cr.openjdk.java.net/~akulyakh/8075327/wr_hs/webrev.01/index.html http://cr.openjdk.java.net/~akulyakh/8075327/wr_jdk/webrev.01/index.html http://cr.openjdk.java.net/~akulyakh/8075327/wr_test/webrev.01/ The changes are to move test library files common to both jdk and hotspot to the upper-level test repository. The following has been done: 1) Common files (Asserts.java, OutputAnalyzer.java etc) from the jdk and hotspot repositories, have been merged and moved to the upper-level common test repository, to test/lib/share/classes. 2) Package jdk.testlibrary in the jdk repository have been renamed to jdk.test.lib to have the same name as in the hotspot repository 2) Upper level test/lib/share/classes library references have been added to the @library statements 3) Some packages previously located at upper level test repo at /test/lib have been moved to /test/lib/share/classes for consistency Best regards, Alexander From mark.reinhold at oracle.com Thu Jun 4 20:50:16 2015 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 04 Jun 2015 13:50:16 -0700 Subject: JEPs proposed to target JDK 9 (2015/6/4) Message-ID: <20150604135016.960314@eggemoggin.niobe.net> The following JEPs have been placed into the "Proposed to Target" state by their owners after discussion and review: 256: BeanInfo Annotations http://openjdk.java.net/jeps/256 257: Update JavaFX/Media to Newer Version of GStreamer http://openjdk.java.net/jeps/257 258: HarfBuzz Font-Layout Engine http://openjdk.java.net/jeps/258 Feedback on these proposals is more than welcome, as are reasoned objections. If no such objections are raised by 21:00 UTC next Thursday, 11 June, or if they're raised and then satisfactorily answered, then per the JEP 2.0 process proposal [1] I'll target these JEPs to JDK 9. The discussion of JEP 248 (Make G1 the Default Garbage Collector) continues, mainly on the hotspot-dev list [3]. Hopefully we can wind that down soon. (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/ [3] http://mail.openjdk.java.net/mailman/listinfo/hotspot-dev From frederic.gendebien at gmail.com Sat Jun 6 19:30:19 2015 From: frederic.gendebien at gmail.com (Frederic Gendebien) Date: Sat, 6 Jun 2015 21:30:19 +0200 Subject: Map enhancement Message-ID: <1F1EEE49-D21F-41B8-9692-4C2F00A299B8@gmail.com> Dears, I think it would be great to modify the Map so it implements Function as it is done in Scala. In fact, Mathematically, a map is function who takes an input parameter of type F and gives back a value of type T. Kind regards, Frederic Gendebien. From pavel.rappo at oracle.com Sat Jun 6 20:55:37 2015 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Sat, 6 Jun 2015 21:55:37 +0100 Subject: Map enhancement In-Reply-To: <1F1EEE49-D21F-41B8-9692-4C2F00A299B8@gmail.com> References: <1F1EEE49-D21F-41B8-9692-4C2F00A299B8@gmail.com> Message-ID: May I ask what tangible value would be in that? As far as I understand with lambda syntax whenever you have Map m and you want to use it in some context as a Function f you can simply write f = m::get so syntactical overhead is minimal. P.S. Let me point out that a map could be also seen as a collection of its entries, a predicate for its keys and values Predicate p1 = m::containsKey Predicate p2 = m::containsValue a bi-consumer for (k, v) BiConsumer c1 = m::put; or a bi-function (though with side-effects) BiFunction f1 = m::put; ... When we go down to this level of fundamental abstractions, everything could be seen almost as everything else :) > On 6 Jun 2015, at 20:30, Frederic Gendebien wrote: > > Dears, > > I think it would be great to modify the Map so it implements Function as it is done in Scala. In fact, Mathematically, a map is function who takes an input parameter of type F and gives back a value of type T. > > Kind regards, > > Frederic Gendebien. From brian.goetz at oracle.com Sat Jun 6 21:45:24 2015 From: brian.goetz at oracle.com (Brian Goetz) Date: Sat, 6 Jun 2015 17:45:24 -0400 Subject: Map enhancement In-Reply-To: References: <1F1EEE49-D21F-41B8-9692-4C2F00A299B8@gmail.com> Message-ID: <2361B269-F9AB-4352-BD48-BC72DD22611C@oracle.com> This was considered and rejected by the JSR-335 EG. In part, it made many EG members uncomfortable because a (mutable) map is not a function, so using inheritance to reflect this is just wrong. The easy convertibility of the bound method reference map::get was the final nail in the coffin for this idea; it is so easy to convert it if you want, that it was not worth justifying any degree of mismatch for the sake of convenience. (Some) maps in Scala are immutable; you could make a stronger argument that a Map is-a Function in that case, but we?re not in that case. On Jun 6, 2015, at 4:55 PM, Pavel Rappo wrote: > May I ask what tangible value would be in that? As far as I understand with > lambda syntax whenever you have > > Map m > > and you want to use it in some context as a > > Function f > > you can simply write > > f = m::get > > so syntactical overhead is minimal. > > P.S. Let me point out that a map could be also seen as a collection of its > entries, a predicate for its keys and values > > Predicate p1 = m::containsKey > Predicate p2 = m::containsValue > > a bi-consumer for (k, v) > > BiConsumer c1 = m::put; > > or a bi-function (though with side-effects) > > BiFunction f1 = m::put; > ... > > When we go down to this level of fundamental abstractions, everything could be > seen almost as everything else :) > >> On 6 Jun 2015, at 20:30, Frederic Gendebien wrote: >> >> Dears, >> >> I think it would be great to modify the Map so it implements Function as it is done in Scala. In fact, Mathematically, a map is function who takes an input parameter of type F and gives back a value of type T. >> >> Kind regards, >> >> Frederic Gendebien. > From alejandro.murillo at oracle.com Tue Jun 9 00:30:44 2015 From: alejandro.murillo at oracle.com (Alejandro E Murillo) Date: Mon, 08 Jun 2015 18:30:44 -0600 Subject: jdk9-dev: HotSpot Message-ID: <557633B4.8080302@oracle.com> jdk9-hs-2015-06-04 has been integrated into jdk9-dev. http://hg.openjdk.java.net/jdk9/dev/rev/e8592d0ee9e3 http://hg.openjdk.java.net/jdk9/dev/corba/rev/e57aa88c63c1 http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/ac8f7a9a590d http://hg.openjdk.java.net/jdk9/dev/jaxp/rev/82aae947938e http://hg.openjdk.java.net/jdk9/dev/jaxws/rev/884d98e00032 http://hg.openjdk.java.net/jdk9/dev/jdk/rev/99548f9b60ef http://hg.openjdk.java.net/jdk9/dev/langtools/rev/8d7f82e6d1b5 http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/d1689c1df3aa Component : VM Status : Go for integration Date : 06/08/2015 at 19:00 MSK Tested By : VM SQE &dmitry.fazunenko at oracle.com Bundles : 2015-06-04-224117.amurillo.jdk9-hs-2015-06-04-snapshot Testing: 64 new failures, 2229 known failures, 393623 passed. Issues and Notes: There are a number of minor issues which will be analyzed during the week. No stoppers have been detected so far. Go for integration CRs for testing: 8001622: loadUB2L_immI8 & loadUS2L_immI16 rules don't match some 8-bit/16-bit masks 8029567: Clean up linkResolver code 8059340: ConstantPool::_resolved_references is missing in heap dump 8060036: C2: CmpU nodes can end up with wrong type information 8072588: JVM crashes in JNI if toString is declared as an interface method 8072913: [REDO] GCCause should distinguish jcmd GC.run from System.gc() 8076319: jstat verified class fix 8076613: gc/TestSmallHeap.java failed with OOME 8077504: Unsafe load can loose control dependency and cause crash 8079093: Remove FakeRttiSupport workaround for gcc -Wtype-limits 8079135: C2 disables some optimizations when a large number of unique nodes exist 8079205: CallSite dependency tracking is broken after sun.misc.Cleaner became automatically cleared 8080156: Integer.toString(int value) sometimes throws NPE 8080428: [TESTBUG] java/lang/invoke/8022701/MHIllegalAccess.java - FAIL: Unexpected wrapped exception java.lang.BootstrapMethodError 8080446: The change for 8074354 removed the server check when creating minidumps on Windows 8080699: Assert failed: Not a Java pointer in JCK test 8080718: Make -XX:CreateCoredumpOnCrash control core dumping in all cases 8080928: Uninitialised variable in hotspot/src/share/vm/prims/jvmtiEnvBase.cpp 8080976: Unexpected AIOOB thrown from 1.9.0-ea-b64 on (regression) 8081037: serviceability/sa/ tests time out on Windows 8081320: Backout JDK-8059340: ConstantPool::_resolved_references is missing in heap dump 8081475: SystemTap does not work when JDK is compiled with GCC 5 8081508: metaspace/shrink_grow/CompressedClassSpaceSize fails with OOM: Compressed class space 8081616: Remove hard-coded CFLAGS_WARNINGS_ARE_ERRORS to fully respect --disable-warnings-as-errors 8081682: AbstractWorkGang::_terminate is never used -- Alejandro From vtsingaras at it.auth.gr Tue Jun 9 06:21:24 2015 From: vtsingaras at it.auth.gr (Vyronas Tsingaras) Date: Tue, 09 Jun 2015 09:21:24 +0300 Subject: sun.security.x509.DNSName leading dot in name constraints Message-ID: <201506090621.t596LS3j025801@hermes15.it.auth.gr> Hi all, I work for the Hellenic Academic and Research Institutions Certification Authority (https://www.harica.gr), a Root Certification Authority included in the NSS, Microsoft and Apple certificate stores. Our RootCA certificate uses the name constraints extension with a small error, instead of just gr, org and edu in the permitted subtrees it has .gr, .edu and .org. As a result certificates issued under our CA fail to verify with Java. We had the same issue with OpenSSL and gnuTLS but fortunately they modified their implementation to accommodate for our situation. I kindly ask if this is something that could also be done with OpenJDK, and if so what would be the best way to implement that. Currently we have a patch against the 'constrains' method of 'DNSName' that just ignores the leading dot in name constraints. Kind Regards, Vyronas Tsingaras, Aristotle University of Thessaloniki, IT Center From stefan.karlsson at oracle.com Tue Jun 9 13:32:09 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Tue, 09 Jun 2015 15:32:09 +0200 Subject: Result: New JDK 9 Reviewer: Per =?UTF-8?B?TGlkw6lu?= Message-ID: <5576EAD9.2080606@oracle.com> |Voting for Per Lid?n [1] is now closed. Yes: 19 Veto: 0 Abstain: 0 According to the Bylaws definition of Three-Vote Consensus, this is sufficient to approve the nomination. Stefan Karlsson [1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2015-May/002222.html| From sean.mullan at oracle.com Tue Jun 9 11:21:48 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 09 Jun 2015 07:21:48 -0400 Subject: sun.security.x509.DNSName leading dot in name constraints In-Reply-To: <201506090621.t596LS3j025801@hermes15.it.auth.gr> References: <201506090621.t596LS3j025801@hermes15.it.auth.gr> Message-ID: <5576CC4C.4000406@oracle.com> -Bcc jdk9-dev This question is more appropriate for security-dev, so I am copying that list for further discussion. --Sean On 06/09/2015 02:21 AM, Vyronas Tsingaras wrote: > Hi all, > > I work for the Hellenic Academic and Research Institutions Certification Authority (https://www.harica.gr), a Root Certification Authority included in the NSS, Microsoft and Apple certificate stores. Our RootCA certificate uses the name constraints extension with a small error, instead of just gr, org and edu in the permitted subtrees it has .gr, .edu and .org. As a result certificates issued under our CA fail to verify with Java. We had the same issue with OpenSSL and gnuTLS but fortunately they modified their implementation to accommodate for our situation. I kindly ask if this is something that could also be done with OpenJDK, and if so what would be the best way to implement that. Currently we have a patch against the 'constrains' method of 'DNSName' that just ignores the leading dot in name constraints. > > Kind Regards, > Vyronas Tsingaras, > Aristotle University of Thessaloniki, IT Center > From volker.simonis at gmail.com Wed Jun 10 17:01:57 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 10 Jun 2015 19:01:57 +0200 Subject: CFV: New jdk9 Committer: Thomas Stuefe Message-ID: I hereby nominate Thomas Stuefe to jdk9 Committer. Thomas is a long-term member of the SAP JVM team at SAP. He has spent most of the time working on HotSpot runtime issues, but he is also the author of our internal AS400/System-i port and one of the main contributors to the AIX port. Recently he has contributed 19 changes to jdk9: 8059868: JVM crashes on attach on Windows when compiled with /RTC1 http://hg.openjdk.java.net/jdk9/dev/jdk/rev/f6420ff4bc52 8024854: PPC64: Basic changes and files to build the class library on AIX http://hg.openjdk.java.net/jdk9/dev/jdk/rev/541585921c82 8077276: allocating heap with UseLargePages and HugeTLBFS may trash existing memory mappings (linux) http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/98faabe210e9 8078628: linux-zero does not build without precompiled header http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/dee7fefc6935 8076475: Misuses of strncpy/strncat http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/4cf3113c8f42 8074354: Make CreateMinidumpOnCrash a new name and available on all platforms http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/eb02bcd73927 8077257: Use CanUseSafeFetch instead of probing SafeFetch stub directly http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/315c2a350a40 8075505: aix: improve handling of native memory http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/1c471be03faf 8074860: Structured Exception Catcher missing around CreateJavaVM on Windows http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/883ae015914d 8076185: Provide SafeFetchX implementation for zero http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/633053d4d137 8074552: SafeFetch32 and SafeFetchN do not work in error handling http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/3eb61269f421 8074543: Missing symbol "objArrayOopDesc::obj_at" when buiding with CPP Interpreter http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/656216252893 8072935: Fix missing newline at end of file after 8067447 http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/b00d819e1fcc 8072575: Add missing test for 8065895 http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/a09b7ff9426d 8065895: Synchronous signals during error reporting may terminate or hang VM process http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/6bfc40057b3f 8065788: os::reserve_memory() on Windows should not assert that allocation size is aligned to OS allocation granularity http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/84af818eed0a 8064779: Add additional comments for "8062370: Various minor code improvements" http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/524b9a4ec5d9 7102541: RFE: os::set_native_thread_name() cleanups http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/763abe04c848 8020775: PPC64 (part 12): posix signal printing http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/f42f2e2a1518 Votes are due by 20:00 CET, June 24, 2015. 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]. Thanks, Volker [1] http://openjdk.java.net/census#jdk9 [2] http://openjdk.java.net/projects#committer-vote From vladimir.x.ivanov at oracle.com Wed Jun 10 17:04:52 2015 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 10 Jun 2015 20:04:52 +0300 Subject: CFV: New jdk9 Committer: Thomas Stuefe In-Reply-To: References: Message-ID: <55786E34.8040003@oracle.com> Vote: yes Best regards, Vladimir Ivanov On 6/10/15 8:01 PM, Volker Simonis wrote: > I hereby nominate Thomas Stuefe to jdk9 Committer. > > Thomas is a long-term member of the SAP JVM team at SAP. > He has spent most of the time working on HotSpot runtime issues, but > he is also the author of our internal AS400/System-i port and one of > the main contributors to the AIX port. > > Recently he has contributed 19 changes to jdk9: > > 8059868: JVM crashes on attach on Windows when compiled with /RTC1 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/f6420ff4bc52 > 8024854: PPC64: Basic changes and files to build the class library on AIX > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/541585921c82 > > 8077276: allocating heap with UseLargePages and HugeTLBFS may trash > existing memory mappings (linux) > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/98faabe210e9 > 8078628: linux-zero does not build without precompiled header > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/dee7fefc6935 > 8076475: Misuses of strncpy/strncat > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/4cf3113c8f42 > 8074354: Make CreateMinidumpOnCrash a new name and available on all platforms > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/eb02bcd73927 > 8077257: Use CanUseSafeFetch instead of probing SafeFetch stub directly > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/315c2a350a40 > 8075505: aix: improve handling of native memory > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/1c471be03faf > 8074860: Structured Exception Catcher missing around CreateJavaVM on Windows > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/883ae015914d > 8076185: Provide SafeFetchX implementation for zero > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/633053d4d137 > 8074552: SafeFetch32 and SafeFetchN do not work in error handling > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/3eb61269f421 > 8074543: Missing symbol "objArrayOopDesc::obj_at" when buiding with > CPP Interpreter > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/656216252893 > 8072935: Fix missing newline at end of file after 8067447 > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/b00d819e1fcc > 8072575: Add missing test for 8065895 > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/a09b7ff9426d > 8065895: Synchronous signals during error reporting may terminate or > hang VM process > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/6bfc40057b3f > 8065788: os::reserve_memory() on Windows should not assert that > allocation size is aligned to OS allocation granularity > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/84af818eed0a > 8064779: Add additional comments for "8062370: Various minor code improvements" > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/524b9a4ec5d9 > 7102541: RFE: os::set_native_thread_name() cleanups > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/763abe04c848 > 8020775: PPC64 (part 12): posix signal printing > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/f42f2e2a1518 > > > Votes are due by 20:00 CET, June 24, 2015. > > 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]. > > Thanks, > Volker > > [1] http://openjdk.java.net/census#jdk9 > [2] http://openjdk.java.net/projects#committer-vote > From christian.thalinger at oracle.com Wed Jun 10 17:11:46 2015 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 10 Jun 2015 10:11:46 -0700 Subject: CFV: New jdk9 Committer: Thomas Stuefe In-Reply-To: References: Message-ID: Vote: yes > On Jun 10, 2015, at 10:01 AM, Volker Simonis wrote: > > I hereby nominate Thomas Stuefe to jdk9 Committer. > > Thomas is a long-term member of the SAP JVM team at SAP. > He has spent most of the time working on HotSpot runtime issues, but > he is also the author of our internal AS400/System-i port and one of > the main contributors to the AIX port. > > Recently he has contributed 19 changes to jdk9: > > 8059868: JVM crashes on attach on Windows when compiled with /RTC1 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/f6420ff4bc52 > 8024854: PPC64: Basic changes and files to build the class library on AIX > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/541585921c82 > > 8077276: allocating heap with UseLargePages and HugeTLBFS may trash > existing memory mappings (linux) > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/98faabe210e9 > 8078628: linux-zero does not build without precompiled header > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/dee7fefc6935 > 8076475: Misuses of strncpy/strncat > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/4cf3113c8f42 > 8074354: Make CreateMinidumpOnCrash a new name and available on all platforms > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/eb02bcd73927 > 8077257: Use CanUseSafeFetch instead of probing SafeFetch stub directly > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/315c2a350a40 > 8075505: aix: improve handling of native memory > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/1c471be03faf > 8074860: Structured Exception Catcher missing around CreateJavaVM on Windows > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/883ae015914d > 8076185: Provide SafeFetchX implementation for zero > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/633053d4d137 > 8074552: SafeFetch32 and SafeFetchN do not work in error handling > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/3eb61269f421 > 8074543: Missing symbol "objArrayOopDesc::obj_at" when buiding with > CPP Interpreter > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/656216252893 > 8072935: Fix missing newline at end of file after 8067447 > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/b00d819e1fcc > 8072575: Add missing test for 8065895 > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/a09b7ff9426d > 8065895: Synchronous signals during error reporting may terminate or > hang VM process > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/6bfc40057b3f > 8065788: os::reserve_memory() on Windows should not assert that > allocation size is aligned to OS allocation granularity > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/84af818eed0a > 8064779: Add additional comments for "8062370: Various minor code improvements" > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/524b9a4ec5d9 > 7102541: RFE: os::set_native_thread_name() cleanups > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/763abe04c848 > 8020775: PPC64 (part 12): posix signal printing > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/f42f2e2a1518 > > > Votes are due by 20:00 CET, June 24, 2015. > > 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]. > > Thanks, > Volker > > [1] http://openjdk.java.net/census#jdk9 > [2] http://openjdk.java.net/projects#committer-vote From coleen.phillimore at oracle.com Wed Jun 10 17:12:31 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 10 Jun 2015 13:12:31 -0400 Subject: CFV: New jdk9 Committer: Thomas Stuefe In-Reply-To: References: Message-ID: <55786FFF.50107@oracle.com> Vote: yes On 6/10/15 1:11 PM, Christian Thalinger wrote: > Vote: yes > >> On Jun 10, 2015, at 10:01 AM, Volker Simonis wrote: >> >> I hereby nominate Thomas Stuefe to jdk9 Committer. >> >> Thomas is a long-term member of the SAP JVM team at SAP. >> He has spent most of the time working on HotSpot runtime issues, but >> he is also the author of our internal AS400/System-i port and one of >> the main contributors to the AIX port. >> >> Recently he has contributed 19 changes to jdk9: >> >> 8059868: JVM crashes on attach on Windows when compiled with /RTC1 >> http://hg.openjdk.java.net/jdk9/dev/jdk/rev/f6420ff4bc52 >> 8024854: PPC64: Basic changes and files to build the class library on AIX >> http://hg.openjdk.java.net/jdk9/dev/jdk/rev/541585921c82 >> >> 8077276: allocating heap with UseLargePages and HugeTLBFS may trash >> existing memory mappings (linux) >> http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/98faabe210e9 >> 8078628: linux-zero does not build without precompiled header >> http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/dee7fefc6935 >> 8076475: Misuses of strncpy/strncat >> http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/4cf3113c8f42 >> 8074354: Make CreateMinidumpOnCrash a new name and available on all platforms >> http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/eb02bcd73927 >> 8077257: Use CanUseSafeFetch instead of probing SafeFetch stub directly >> http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/315c2a350a40 >> 8075505: aix: improve handling of native memory >> http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/1c471be03faf >> 8074860: Structured Exception Catcher missing around CreateJavaVM on Windows >> http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/883ae015914d >> 8076185: Provide SafeFetchX implementation for zero >> http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/633053d4d137 >> 8074552: SafeFetch32 and SafeFetchN do not work in error handling >> http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/3eb61269f421 >> 8074543: Missing symbol "objArrayOopDesc::obj_at" when buiding with >> CPP Interpreter >> http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/656216252893 >> 8072935: Fix missing newline at end of file after 8067447 >> http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/b00d819e1fcc >> 8072575: Add missing test for 8065895 >> http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/a09b7ff9426d >> 8065895: Synchronous signals during error reporting may terminate or >> hang VM process >> http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/6bfc40057b3f >> 8065788: os::reserve_memory() on Windows should not assert that >> allocation size is aligned to OS allocation granularity >> http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/84af818eed0a >> 8064779: Add additional comments for "8062370: Various minor code improvements" >> http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/524b9a4ec5d9 >> 7102541: RFE: os::set_native_thread_name() cleanups >> http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/763abe04c848 >> 8020775: PPC64 (part 12): posix signal printing >> http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/f42f2e2a1518 >> >> >> Votes are due by 20:00 CET, June 24, 2015. >> >> 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]. >> >> Thanks, >> Volker >> >> [1] http://openjdk.java.net/census#jdk9 >> [2] http://openjdk.java.net/projects#committer-vote From vicente.romero at oracle.com Wed Jun 10 17:13:54 2015 From: vicente.romero at oracle.com (Vicente-Arturo Romero-Zaldivar) Date: Wed, 10 Jun 2015 10:13:54 -0700 Subject: CFV: New jdk9 Committer: Thomas Stuefe In-Reply-To: References: Message-ID: <55787052.9090808@oracle.com> vote: yes Vicente On 06/10/2015 10:01 AM, Volker Simonis wrote: > I hereby nominate Thomas Stuefe to jdk9 Committer. > > Thomas is a long-term member of the SAP JVM team at SAP. > He has spent most of the time working on HotSpot runtime issues, but > he is also the author of our internal AS400/System-i port and one of > the main contributors to the AIX port. > > Recently he has contributed 19 changes to jdk9: > > 8059868: JVM crashes on attach on Windows when compiled with /RTC1 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/f6420ff4bc52 > 8024854: PPC64: Basic changes and files to build the class library on AIX > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/541585921c82 > > 8077276: allocating heap with UseLargePages and HugeTLBFS may trash > existing memory mappings (linux) > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/98faabe210e9 > 8078628: linux-zero does not build without precompiled header > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/dee7fefc6935 > 8076475: Misuses of strncpy/strncat > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/4cf3113c8f42 > 8074354: Make CreateMinidumpOnCrash a new name and available on all platforms > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/eb02bcd73927 > 8077257: Use CanUseSafeFetch instead of probing SafeFetch stub directly > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/315c2a350a40 > 8075505: aix: improve handling of native memory > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/1c471be03faf > 8074860: Structured Exception Catcher missing around CreateJavaVM on Windows > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/883ae015914d > 8076185: Provide SafeFetchX implementation for zero > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/633053d4d137 > 8074552: SafeFetch32 and SafeFetchN do not work in error handling > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/3eb61269f421 > 8074543: Missing symbol "objArrayOopDesc::obj_at" when buiding with > CPP Interpreter > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/656216252893 > 8072935: Fix missing newline at end of file after 8067447 > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/b00d819e1fcc > 8072575: Add missing test for 8065895 > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/a09b7ff9426d > 8065895: Synchronous signals during error reporting may terminate or > hang VM process > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/6bfc40057b3f > 8065788: os::reserve_memory() on Windows should not assert that > allocation size is aligned to OS allocation granularity > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/84af818eed0a > 8064779: Add additional comments for "8062370: Various minor code improvements" > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/524b9a4ec5d9 > 7102541: RFE: os::set_native_thread_name() cleanups > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/763abe04c848 > 8020775: PPC64 (part 12): posix signal printing > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/f42f2e2a1518 > > > Votes are due by 20:00 CET, June 24, 2015. > > 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]. > > Thanks, > Volker > > [1] http://openjdk.java.net/census#jdk9 > [2] http://openjdk.java.net/projects#committer-vote From vladimir.kozlov at oracle.com Wed Jun 10 17:22:12 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 10 Jun 2015 10:22:12 -0700 Subject: CFV: New jdk9 Committer: Thomas Stuefe In-Reply-To: References: Message-ID: <55787244.5060201@oracle.com> Vote: yes On 6/10/15 10:01 AM, Volker Simonis wrote: > I hereby nominate Thomas Stuefe to jdk9 Committer. > > Thomas is a long-term member of the SAP JVM team at SAP. > He has spent most of the time working on HotSpot runtime issues, but > he is also the author of our internal AS400/System-i port and one of > the main contributors to the AIX port. > > Recently he has contributed 19 changes to jdk9: > > 8059868: JVM crashes on attach on Windows when compiled with /RTC1 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/f6420ff4bc52 > 8024854: PPC64: Basic changes and files to build the class library on AIX > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/541585921c82 > > 8077276: allocating heap with UseLargePages and HugeTLBFS may trash > existing memory mappings (linux) > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/98faabe210e9 > 8078628: linux-zero does not build without precompiled header > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/dee7fefc6935 > 8076475: Misuses of strncpy/strncat > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/4cf3113c8f42 > 8074354: Make CreateMinidumpOnCrash a new name and available on all platforms > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/eb02bcd73927 > 8077257: Use CanUseSafeFetch instead of probing SafeFetch stub directly > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/315c2a350a40 > 8075505: aix: improve handling of native memory > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/1c471be03faf > 8074860: Structured Exception Catcher missing around CreateJavaVM on Windows > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/883ae015914d > 8076185: Provide SafeFetchX implementation for zero > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/633053d4d137 > 8074552: SafeFetch32 and SafeFetchN do not work in error handling > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/3eb61269f421 > 8074543: Missing symbol "objArrayOopDesc::obj_at" when buiding with > CPP Interpreter > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/656216252893 > 8072935: Fix missing newline at end of file after 8067447 > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/b00d819e1fcc > 8072575: Add missing test for 8065895 > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/a09b7ff9426d > 8065895: Synchronous signals during error reporting may terminate or > hang VM process > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/6bfc40057b3f > 8065788: os::reserve_memory() on Windows should not assert that > allocation size is aligned to OS allocation granularity > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/84af818eed0a > 8064779: Add additional comments for "8062370: Various minor code improvements" > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/524b9a4ec5d9 > 7102541: RFE: os::set_native_thread_name() cleanups > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/763abe04c848 > 8020775: PPC64 (part 12): posix signal printing > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/f42f2e2a1518 > > > Votes are due by 20:00 CET, June 24, 2015. > > 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]. > > Thanks, > Volker > > [1] http://openjdk.java.net/census#jdk9 > [2] http://openjdk.java.net/projects#committer-vote > From aleksej.efimov at oracle.com Wed Jun 10 17:26:13 2015 From: aleksej.efimov at oracle.com (Aleksej Efimov) Date: Wed, 10 Jun 2015 20:26:13 +0300 Subject: CFV: New jdk9 Committer: Thomas Stuefe In-Reply-To: References: Message-ID: <55787335.4010004@oracle.com> Vote: yes On 06/10/2015 08:01 PM, Volker Simonis wrote: > I hereby nominate Thomas Stuefe to jdk9 Committer. > > Thomas is a long-term member of the SAP JVM team at SAP. > He has spent most of the time working on HotSpot runtime issues, but > he is also the author of our internal AS400/System-i port and one of > the main contributors to the AIX port. > > Recently he has contributed 19 changes to jdk9: > > 8059868: JVM crashes on attach on Windows when compiled with /RTC1 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/f6420ff4bc52 > 8024854: PPC64: Basic changes and files to build the class library on AIX > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/541585921c82 > > 8077276: allocating heap with UseLargePages and HugeTLBFS may trash > existing memory mappings (linux) > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/98faabe210e9 > 8078628: linux-zero does not build without precompiled header > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/dee7fefc6935 > 8076475: Misuses of strncpy/strncat > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/4cf3113c8f42 > 8074354: Make CreateMinidumpOnCrash a new name and available on all platforms > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/eb02bcd73927 > 8077257: Use CanUseSafeFetch instead of probing SafeFetch stub directly > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/315c2a350a40 > 8075505: aix: improve handling of native memory > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/1c471be03faf > 8074860: Structured Exception Catcher missing around CreateJavaVM on Windows > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/883ae015914d > 8076185: Provide SafeFetchX implementation for zero > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/633053d4d137 > 8074552: SafeFetch32 and SafeFetchN do not work in error handling > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/3eb61269f421 > 8074543: Missing symbol "objArrayOopDesc::obj_at" when buiding with > CPP Interpreter > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/656216252893 > 8072935: Fix missing newline at end of file after 8067447 > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/b00d819e1fcc > 8072575: Add missing test for 8065895 > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/a09b7ff9426d > 8065895: Synchronous signals during error reporting may terminate or > hang VM process > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/6bfc40057b3f > 8065788: os::reserve_memory() on Windows should not assert that > allocation size is aligned to OS allocation granularity > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/84af818eed0a > 8064779: Add additional comments for "8062370: Various minor code improvements" > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/524b9a4ec5d9 > 7102541: RFE: os::set_native_thread_name() cleanups > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/763abe04c848 > 8020775: PPC64 (part 12): posix signal printing > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/f42f2e2a1518 > > > Votes are due by 20:00 CET, June 24, 2015. > > 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]. > > Thanks, > Volker > > [1] http://openjdk.java.net/census#jdk9 > [2] http://openjdk.java.net/projects#committer-vote From serguei.spitsyn at oracle.com Wed Jun 10 18:54:29 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 10 Jun 2015 11:54:29 -0700 Subject: CFV: New jdk9 Committer: Thomas Stuefe In-Reply-To: References: Message-ID: <557887E5.9070009@oracle.com> Vote: yes On 6/10/15 10:01 AM, Volker Simonis wrote: > I hereby nominate Thomas Stuefe to jdk9 Committer. > > Thomas is a long-term member of the SAP JVM team at SAP. > He has spent most of the time working on HotSpot runtime issues, but > he is also the author of our internal AS400/System-i port and one of > the main contributors to the AIX port. > > Recently he has contributed 19 changes to jdk9: > > 8059868: JVM crashes on attach on Windows when compiled with /RTC1 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/f6420ff4bc52 > 8024854: PPC64: Basic changes and files to build the class library on AIX > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/541585921c82 > > 8077276: allocating heap with UseLargePages and HugeTLBFS may trash > existing memory mappings (linux) > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/98faabe210e9 > 8078628: linux-zero does not build without precompiled header > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/dee7fefc6935 > 8076475: Misuses of strncpy/strncat > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/4cf3113c8f42 > 8074354: Make CreateMinidumpOnCrash a new name and available on all platforms > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/eb02bcd73927 > 8077257: Use CanUseSafeFetch instead of probing SafeFetch stub directly > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/315c2a350a40 > 8075505: aix: improve handling of native memory > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/1c471be03faf > 8074860: Structured Exception Catcher missing around CreateJavaVM on Windows > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/883ae015914d > 8076185: Provide SafeFetchX implementation for zero > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/633053d4d137 > 8074552: SafeFetch32 and SafeFetchN do not work in error handling > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/3eb61269f421 > 8074543: Missing symbol "objArrayOopDesc::obj_at" when buiding with > CPP Interpreter > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/656216252893 > 8072935: Fix missing newline at end of file after 8067447 > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/b00d819e1fcc > 8072575: Add missing test for 8065895 > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/a09b7ff9426d > 8065895: Synchronous signals during error reporting may terminate or > hang VM process > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/6bfc40057b3f > 8065788: os::reserve_memory() on Windows should not assert that > allocation size is aligned to OS allocation granularity > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/84af818eed0a > 8064779: Add additional comments for "8062370: Various minor code improvements" > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/524b9a4ec5d9 > 7102541: RFE: os::set_native_thread_name() cleanups > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/763abe04c848 > 8020775: PPC64 (part 12): posix signal printing > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/f42f2e2a1518 > > > Votes are due by 20:00 CET, June 24, 2015. > > 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]. > > Thanks, > Volker > > [1] http://openjdk.java.net/census#jdk9 > [2] http://openjdk.java.net/projects#committer-vote From stefan.karlsson at oracle.com Wed Jun 10 20:14:29 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Wed, 10 Jun 2015 22:14:29 +0200 Subject: CFV: New jdk9 Committer: Thomas Stuefe In-Reply-To: References: Message-ID: <55789AA5.3070406@oracle.com> Vote: yes StefanK On 2015-06-10 19:01, Volker Simonis wrote: > I hereby nominate Thomas Stuefe to jdk9 Committer. > > Thomas is a long-term member of the SAP JVM team at SAP. > He has spent most of the time working on HotSpot runtime issues, but > he is also the author of our internal AS400/System-i port and one of > the main contributors to the AIX port. > > Recently he has contributed 19 changes to jdk9: > > 8059868: JVM crashes on attach on Windows when compiled with /RTC1 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/f6420ff4bc52 > 8024854: PPC64: Basic changes and files to build the class library on AIX > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/541585921c82 > > 8077276: allocating heap with UseLargePages and HugeTLBFS may trash > existing memory mappings (linux) > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/98faabe210e9 > 8078628: linux-zero does not build without precompiled header > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/dee7fefc6935 > 8076475: Misuses of strncpy/strncat > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/4cf3113c8f42 > 8074354: Make CreateMinidumpOnCrash a new name and available on all platforms > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/eb02bcd73927 > 8077257: Use CanUseSafeFetch instead of probing SafeFetch stub directly > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/315c2a350a40 > 8075505: aix: improve handling of native memory > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/1c471be03faf > 8074860: Structured Exception Catcher missing around CreateJavaVM on Windows > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/883ae015914d > 8076185: Provide SafeFetchX implementation for zero > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/633053d4d137 > 8074552: SafeFetch32 and SafeFetchN do not work in error handling > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/3eb61269f421 > 8074543: Missing symbol "objArrayOopDesc::obj_at" when buiding with > CPP Interpreter > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/656216252893 > 8072935: Fix missing newline at end of file after 8067447 > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/b00d819e1fcc > 8072575: Add missing test for 8065895 > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/a09b7ff9426d > 8065895: Synchronous signals during error reporting may terminate or > hang VM process > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/6bfc40057b3f > 8065788: os::reserve_memory() on Windows should not assert that > allocation size is aligned to OS allocation granularity > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/84af818eed0a > 8064779: Add additional comments for "8062370: Various minor code improvements" > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/524b9a4ec5d9 > 7102541: RFE: os::set_native_thread_name() cleanups > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/763abe04c848 > 8020775: PPC64 (part 12): posix signal printing > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/f42f2e2a1518 > > > Votes are due by 20:00 CET, June 24, 2015. > > 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]. > > Thanks, > Volker > > [1] http://openjdk.java.net/census#jdk9 > [2] http://openjdk.java.net/projects#committer-vote From lana.steuck at oracle.com Wed Jun 10 21:39:10 2015 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 10 Jun 2015 14:39:10 -0700 (PDT) Subject: jdk9-b68: dev Message-ID: <201506102139.t5ALdAuc021508@sc11152554.us.oracle.com> http://hg.openjdk.java.net/jdk9/jdk9/rev/70e4272790b6 http://hg.openjdk.java.net/jdk9/jdk9/nashorn/rev/dd6dd848b854 http://hg.openjdk.java.net/jdk9/jdk9/langtools/rev/c71857c93f57 http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/046fd17bb9a0 http://hg.openjdk.java.net/jdk9/jdk9/jaxws/rev/b5878b03d1b2 http://hg.openjdk.java.net/jdk9/jdk9/jaxp/rev/82aae947938e http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/11af3990d56c http://hg.openjdk.java.net/jdk9/jdk9/corba/rev/8efad64f40eb --- All the fixes will be tested during promotion (no PIT testing at this point): List of all fixes: =================== JDK-8035568 client-libs [macosx] Cursor management unification JDK-8065739 client-libs [macosx] Frame warps to lower left of screen when displayed JDK-7124365 client-libs [macosx] setMaximizedBounds() should be implemented JDK-8078149 client-libs [macosx] The text of the TextArea is not wrapped at word boundaries JDK-8079255 client-libs [TEST_BUG] [macosx] Test closed/java/awt/Robot/RobotWheelTest/RobotWhe JDK-8015900 client-libs [TEST_BUG] ScrollbarMouseWheelTest failed on ubuntu 12 with unity and JDK-8078483 client-libs Apparent endless loop running JEditorPanePaintTest JDK-8072448 client-libs Can not input Japanese in JTextField on RedHat Linux JDK-7155957 client-libs closed/java/awt/MenuBar/MenuBarStress1/MenuBarStress1.java hangs on wi JDK-8080137 client-libs Dragged events for extra mouse buttons (4,5,6) are not generated on JS JDK-8079640 client-libs GroupLayout incorrect layout with large JTextArea JDK-6260348 client-libs GTK+ L&F JTextComponent not respecting desktop caret blink rate JDK-8071306 client-libs GUI perfomance are very slow compared java 1.6.0_45 JDK-6587235 client-libs Incorrect javadoc: "no parameter" in 2d source code JDK-8078408 client-libs Java version applet hangs with Voice over turned on JDK-8075609 client-libs java.lang.IllegalArgumentException: aContainer is not a focus cycle ro JDK-8013820 client-libs JavaDoc for JSpinner contains errors JDK-8015368 client-libs javax/print/attribute/URLPDFPrinting.java fails on solaris with java.n JDK-7072653 client-libs JComboBox popup mispositioned if its height exceeds the screen height JDK-8081231 client-libs JDK9 client build broken on Windows JDK-8003399 client-libs JFileChooser gives wrong path to selected file when saving to Librarie JDK-5036022 client-libs JSpinner does not reflect new font on subsequent calls to setFont JDK-8001470 client-libs JTextField's size is computed incorrectly when it contains Indic or Th JDK-6980209 client-libs Make tracking SecondaryLoop.enter/exit methods easier JDK-6368321 client-libs MetalRootPaneUI calls to deprecated code JDK-8033069 client-libs mouse wheel scroll closes combobox popup JDK-7190544 client-libs Nimbus LaF: regression UnitTest failure JDK-8080628 client-libs No mnemonics on Open and Save buttons in JFileChooser JDK-8041654 client-libs OutOfMemoryError: RepaintManager doesn't clean up cache of volatile im JDK-8072775 client-libs Tremendous memory usage by JTextArea JDK-8083664 client-libs Update AudioFileWriter to generate working @see reference JDK-8077584 client-libs Value of java.awt.font.OpenType.TAG_OPBD is incorrect JDK-7172652 client-libs With JDK 1.7 text field does not obtain focus when using mnemonic Alt/ JDK-5109918 client-libs Wrong documentation for JSpinner.DateEditor constructor JDK-7011441 core-libs ./jndi/ldap/Connection.java needs to avoid spurious wakeup JDK-8081536 core-libs (process) remove unreliable ScaleTest from ProcessHandle tests JDK-8081773 core-libs [TEST_BUG] sun/net/www/protocol/https/ChunkedOutputStream.java referen JDK-8081775 core-libs [TEST_BUG] two lib/testlibrary tests are failing with "Error. failed t JDK-8072726 core-libs add adapter to convert Enumeration to Iterator JDK-8080835 core-libs Add blocking bulk read operations to java.io.InputStream JDK-8079778 core-libs Add intermittent tag to java/rmi/activation/rmidViaInheritedChannel/Rm JDK-8075555 core-libs Add tiered testing definitions to the nashorn repo JDK-8071474 core-libs Better failure atomicity for default read object JDK-8085858 core-libs Better failure output for test/java/util/Arrays/ParallelPrefix.java JDK-8081522 core-libs build failed with jdk8081452 change. JDK-8081027 core-libs Create a common test to check adequacy of initial size of static HashM JDK-8081609 core-libs engine.eval call from a java method which was called from a previous e JDK-8081603 core-libs erroneous dot file generated from Nashorn --print-code JDK-8058779 core-libs Faster implementation of String.replace(CharSequence, CharSequence) JDK-8081668 core-libs fix Nashorn ant externals command JDK-8066218 core-libs Fuzzing bug: And jdk.nashorn.internal.runtime.Source#byteToCharArray: JDK-8066220 core-libs Fuzzing bug: MethodHandle bug (Object,Object) != (boolean)Object JDK-8067808 core-libs java/lang/ProcessBuilder/Basic.java failed on Assertion JDK-8081567 core-libs java/lang/ProcessHandle/InfoTest.java failed Cannot run program "whoa JDK-8081566 core-libs java/lang/ProcessHandle/InfoTest.java failed on case sensitive command JDK-8077350 core-libs JEP 102 Process API Updates Implementation JDK-8066773 core-libs JSON-friendly wrapper for objects JDK-8081813 core-libs JSONListAdapter should delegate its [[DefaultValue]] to wrapped object JDK-8081809 core-libs Missing final modifier in method parameters (nashorn code convention) JDK-8081452 core-libs Move sun.nio.cs.AbstractCharsetProvider into jdk.charset/sun.nio.cs.ex JDK-8081696 core-libs reduce dependency of Nashorn tests on external components JDK-8081604 core-libs rename ScriptingFunctions.tokenizeCommandLine JDK-8072384 core-libs Setting IP_TOS on java.net sockets not working on unix JDK-8080275 core-libs transparently download testng.jar for Nashorn testing JDK-8079063 core-libs ZoneOffsetTransitionRule.of should throw IAE for non-zero nanoseconds JDK-8081470 core-svc com/sun/jdi tests are failing with "Error. failed to clean up files af JDK-8080663 core-svc Use sun.misc.SharedSecrets to allow access from java.management to @Co JDK-8078893 deploy cert based run rule doesn't work when running offline JDK-8079677 deploy fix to JDK-8078534 removed part of fix to JDK-8076220 JDK-8057164 deploy Remove dead code JDK-8080785 deploy remove dead code to donwload JavaFX on demand. JDK-8080554 deploy replace sun.misc.BASE64Encoder with java.util.Base64 JDK-8081289 hotspot aarch64: add support for RewriteFrequentPairs in interpreter JDK-8081669 hotspot aarch64: JTreg TestStable tests failing JDK-8079565 hotspot Add vectorization support for aarch64 JDK-8080840 hotspot Clean up active_workers() asserts JDK-8080828 hotspot Create sanity test for JDK-8080155 JDK-8080855 hotspot Create sanity test for JDK-8080692 JDK-8080877 hotspot Don't use workers()->total_workers() when walking G1CollectedHeap::_ta JDK-8080869 hotspot FlexibleWorkGang initializes _active_workers to more than _total_worke JDK-8081039 hotspot G1: Remove unused statistics code in G1NoteEndOfConcMarkClosure and G1 JDK-8080837 hotspot Move number of workers calculation out of CollectionSetChooser::prepar JDK-8080746 hotspot Refactor oop iteration macros to be more general JDK-8080879 hotspot Remove AbstractGangTask::set_for_termination JDK-8080113 hotspot Remove CollectedHeap::set_par_threads() JDK-8081007 hotspot Remove redundant active worker variables and calls in ParNewGeneration JDK-8080111 hotspot Remove SubTaskDone::_n_threads JDK-8080110 hotspot Remove usage of CollectedHeap::n_par_threads() from root processing JDK-8080112 hotspot Replace and remove the last usages of CollectedHeap::n_par_threads() JDK-8080876 hotspot Replace unnecessary MAX2(ParallelGCThreads, 1) calls with ParallelGCTh JDK-8080109 hotspot Use single-threaded code in Threads::possibly_parallel_oops_do when ru JDK-8066757 infrastructure Can't build 'images' with --disable-zip-debug-info on OS X after jigsa JDK-8081692 infrastructure Configure should verify that -fstack-protector is valid JDK-7198599 install Incorrect UninstallString windows register key in JDK 1.6, 1.7 and 8 JDK-8081565 other-libs javac lint warnings in jdk testlibrary JDK-8081792 security-libs buffer size calculation issue in NativeGCMCipher JDK-8083436 security-libs Doclint regression introduced by JDK-8043758 JDK-8031111 security-libs fix krb5 caddr JDK-8043758 security-libs JEP 219: Datagram Transport Layer Security (DTLS) JDK-8079821 security-libs MSOID2.java test is not perfect JDK-8038089 security-libs TLS optional support for Kerberos cipher suites needs to be re-examine JDK-8077667 tools 'variable may not have been initialized' error for parameter in lambda JDK-8081541 tools @ignore CheckEBCDICLocaleTest JDK-8075546 tools Add tiered testing definitions to the langtools repo JDK-8039262 tools Java compiler performance degradation jdk1.7 vs. jdk1.6 should be amen JDK-8081271 tools NPE while compiling a program with erroneous use of constructor refere JDK-8073372 tools Redundant CONSTANT_Class entry not generated for inlined constant JDK-8081824 tools Remove dead code GetPublicJREHome in the launcher JDK-8081538 tools test CheckEBCDICLocaleTest is failing JDK-8080842 tools Using Lambda Expression with name clash results in ClassFormatError JDK-8075551 xml Add tiered testing definitions to the jaxp repo JDK-8081392 xml getNodeValue should return 'null' value for Element nodes JDK-8080502 xml Update JAXB and JAX-WS to work with resource encapsulation From volker.simonis at gmail.com Wed Jun 10 22:46:15 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 11 Jun 2015 00:46:15 +0200 Subject: CFV: New jdk9 Committer: Thomas Stuefe In-Reply-To: References: Message-ID: Vote: yes On Wednesday, June 10, 2015, Volker Simonis wrote: > I hereby nominate Thomas Stuefe to jdk9 Committer. > > Thomas is a long-term member of the SAP JVM team at SAP. > He has spent most of the time working on HotSpot runtime issues, but > he is also the author of our internal AS400/System-i port and one of > the main contributors to the AIX port. > > Recently he has contributed 19 changes to jdk9: > > 8059868: JVM crashes on attach on Windows when compiled with /RTC1 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/f6420ff4bc52 > 8024854: PPC64: Basic changes and files to build the class library on AIX > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/541585921c82 > > 8077276: allocating heap with UseLargePages and HugeTLBFS may trash > existing memory mappings (linux) > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/98faabe210e9 > 8078628: linux-zero does not build without precompiled header > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/dee7fefc6935 > 8076475: Misuses of strncpy/strncat > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/4cf3113c8f42 > 8074354: Make CreateMinidumpOnCrash a new name and available on all > platforms > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/eb02bcd73927 > 8077257: Use CanUseSafeFetch instead of probing SafeFetch stub directly > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/315c2a350a40 > 8075505: aix: improve handling of native memory > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/1c471be03faf > 8074860: Structured Exception Catcher missing around CreateJavaVM on > Windows > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/883ae015914d > 8076185: Provide SafeFetchX implementation for zero > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/633053d4d137 > 8074552: SafeFetch32 and SafeFetchN do not work in error handling > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/3eb61269f421 > 8074543: Missing symbol "objArrayOopDesc::obj_at" when buiding with > CPP Interpreter > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/656216252893 > 8072935: Fix missing newline at end of file after 8067447 > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/b00d819e1fcc > 8072575: Add missing test for 8065895 > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/a09b7ff9426d > 8065895: Synchronous signals during error reporting may terminate or > hang VM process > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/6bfc40057b3f > 8065788: os::reserve_memory() on Windows should not assert that > allocation size is aligned to OS allocation granularity > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/84af818eed0a > 8064779: Add additional comments for "8062370: Various minor code > improvements" > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/524b9a4ec5d9 > 7102541: RFE: os::set_native_thread_name() cleanups > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/763abe04c848 > 8020775: PPC64 (part 12): posix signal printing > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/f42f2e2a1518 > > > Votes are due by 20:00 CET, June 24, 2015. > > 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]. > > Thanks, > Volker > > [1] http://openjdk.java.net/census#jdk9 > [2] http://openjdk.java.net/projects#committer-vote > From maurizio.cimadamore at oracle.com Wed Jun 10 23:13:54 2015 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 11 Jun 2015 00:13:54 +0100 Subject: CFV: New jdk9 Committer: Thomas Stuefe In-Reply-To: References: Message-ID: <5578C4B2.4040000@oracle.com> Vote: yes Maurizio On 10/06/15 18:01, Volker Simonis wrote: > I hereby nominate Thomas Stuefe to jdk9 Committer. > > Thomas is a long-term member of the SAP JVM team at SAP. > He has spent most of the time working on HotSpot runtime issues, but > he is also the author of our internal AS400/System-i port and one of > the main contributors to the AIX port. > > Recently he has contributed 19 changes to jdk9: > > 8059868: JVM crashes on attach on Windows when compiled with /RTC1 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/f6420ff4bc52 > 8024854: PPC64: Basic changes and files to build the class library on AIX > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/541585921c82 > > 8077276: allocating heap with UseLargePages and HugeTLBFS may trash > existing memory mappings (linux) > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/98faabe210e9 > 8078628: linux-zero does not build without precompiled header > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/dee7fefc6935 > 8076475: Misuses of strncpy/strncat > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/4cf3113c8f42 > 8074354: Make CreateMinidumpOnCrash a new name and available on all platforms > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/eb02bcd73927 > 8077257: Use CanUseSafeFetch instead of probing SafeFetch stub directly > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/315c2a350a40 > 8075505: aix: improve handling of native memory > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/1c471be03faf > 8074860: Structured Exception Catcher missing around CreateJavaVM on Windows > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/883ae015914d > 8076185: Provide SafeFetchX implementation for zero > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/633053d4d137 > 8074552: SafeFetch32 and SafeFetchN do not work in error handling > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/3eb61269f421 > 8074543: Missing symbol "objArrayOopDesc::obj_at" when buiding with > CPP Interpreter > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/656216252893 > 8072935: Fix missing newline at end of file after 8067447 > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/b00d819e1fcc > 8072575: Add missing test for 8065895 > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/a09b7ff9426d > 8065895: Synchronous signals during error reporting may terminate or > hang VM process > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/6bfc40057b3f > 8065788: os::reserve_memory() on Windows should not assert that > allocation size is aligned to OS allocation granularity > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/84af818eed0a > 8064779: Add additional comments for "8062370: Various minor code improvements" > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/524b9a4ec5d9 > 7102541: RFE: os::set_native_thread_name() cleanups > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/763abe04c848 > 8020775: PPC64 (part 12): posix signal printing > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/f42f2e2a1518 > > > Votes are due by 20:00 CET, June 24, 2015. > > 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]. > > Thanks, > Volker > > [1] http://openjdk.java.net/census#jdk9 > [2] http://openjdk.java.net/projects#committer-vote From david.holmes at oracle.com Thu Jun 11 05:14:34 2015 From: david.holmes at oracle.com (David Holmes) Date: Thu, 11 Jun 2015 15:14:34 +1000 Subject: CFV: New jdk9 Committer: Thomas Stuefe In-Reply-To: References: Message-ID: <5579193A.2020208@oracle.com> Vote: yes David On 11/06/2015 3:01 AM, Volker Simonis wrote: > I hereby nominate Thomas Stuefe to jdk9 Committer. > > Thomas is a long-term member of the SAP JVM team at SAP. > He has spent most of the time working on HotSpot runtime issues, but > he is also the author of our internal AS400/System-i port and one of > the main contributors to the AIX port. > > Recently he has contributed 19 changes to jdk9: > > 8059868: JVM crashes on attach on Windows when compiled with /RTC1 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/f6420ff4bc52 > 8024854: PPC64: Basic changes and files to build the class library on AIX > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/541585921c82 > > 8077276: allocating heap with UseLargePages and HugeTLBFS may trash > existing memory mappings (linux) > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/98faabe210e9 > 8078628: linux-zero does not build without precompiled header > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/dee7fefc6935 > 8076475: Misuses of strncpy/strncat > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/4cf3113c8f42 > 8074354: Make CreateMinidumpOnCrash a new name and available on all platforms > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/eb02bcd73927 > 8077257: Use CanUseSafeFetch instead of probing SafeFetch stub directly > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/315c2a350a40 > 8075505: aix: improve handling of native memory > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/1c471be03faf > 8074860: Structured Exception Catcher missing around CreateJavaVM on Windows > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/883ae015914d > 8076185: Provide SafeFetchX implementation for zero > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/633053d4d137 > 8074552: SafeFetch32 and SafeFetchN do not work in error handling > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/3eb61269f421 > 8074543: Missing symbol "objArrayOopDesc::obj_at" when buiding with > CPP Interpreter > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/656216252893 > 8072935: Fix missing newline at end of file after 8067447 > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/b00d819e1fcc > 8072575: Add missing test for 8065895 > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/a09b7ff9426d > 8065895: Synchronous signals during error reporting may terminate or > hang VM process > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/6bfc40057b3f > 8065788: os::reserve_memory() on Windows should not assert that > allocation size is aligned to OS allocation granularity > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/84af818eed0a > 8064779: Add additional comments for "8062370: Various minor code improvements" > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/524b9a4ec5d9 > 7102541: RFE: os::set_native_thread_name() cleanups > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/763abe04c848 > 8020775: PPC64 (part 12): posix signal printing > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/f42f2e2a1518 > > > Votes are due by 20:00 CET, June 24, 2015. > > 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]. > > Thanks, > Volker > > [1] http://openjdk.java.net/census#jdk9 > [2] http://openjdk.java.net/projects#committer-vote > From per.liden at oracle.com Thu Jun 11 10:30:49 2015 From: per.liden at oracle.com (Per Liden) Date: Thu, 11 Jun 2015 12:30:49 +0200 Subject: CFV: New jdk9 Committer: Thomas Stuefe In-Reply-To: References: Message-ID: <55796359.2060900@oracle.com> Vote: yes Per On 2015-06-10 19:01, Volker Simonis wrote: > I hereby nominate Thomas Stuefe to jdk9 Committer. > > Thomas is a long-term member of the SAP JVM team at SAP. > He has spent most of the time working on HotSpot runtime issues, but > he is also the author of our internal AS400/System-i port and one of > the main contributors to the AIX port. > > Recently he has contributed 19 changes to jdk9: > > 8059868: JVM crashes on attach on Windows when compiled with /RTC1 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/f6420ff4bc52 > 8024854: PPC64: Basic changes and files to build the class library on AIX > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/541585921c82 > > 8077276: allocating heap with UseLargePages and HugeTLBFS may trash > existing memory mappings (linux) > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/98faabe210e9 > 8078628: linux-zero does not build without precompiled header > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/dee7fefc6935 > 8076475: Misuses of strncpy/strncat > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/4cf3113c8f42 > 8074354: Make CreateMinidumpOnCrash a new name and available on all platforms > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/eb02bcd73927 > 8077257: Use CanUseSafeFetch instead of probing SafeFetch stub directly > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/315c2a350a40 > 8075505: aix: improve handling of native memory > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/1c471be03faf > 8074860: Structured Exception Catcher missing around CreateJavaVM on Windows > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/883ae015914d > 8076185: Provide SafeFetchX implementation for zero > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/633053d4d137 > 8074552: SafeFetch32 and SafeFetchN do not work in error handling > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/3eb61269f421 > 8074543: Missing symbol "objArrayOopDesc::obj_at" when buiding with > CPP Interpreter > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/656216252893 > 8072935: Fix missing newline at end of file after 8067447 > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/b00d819e1fcc > 8072575: Add missing test for 8065895 > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/a09b7ff9426d > 8065895: Synchronous signals during error reporting may terminate or > hang VM process > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/6bfc40057b3f > 8065788: os::reserve_memory() on Windows should not assert that > allocation size is aligned to OS allocation granularity > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/84af818eed0a > 8064779: Add additional comments for "8062370: Various minor code improvements" > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/524b9a4ec5d9 > 7102541: RFE: os::set_native_thread_name() cleanups > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/763abe04c848 > 8020775: PPC64 (part 12): posix signal printing > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/f42f2e2a1518 > > > Votes are due by 20:00 CET, June 24, 2015. > > 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]. > > Thanks, > Volker > > [1] http://openjdk.java.net/census#jdk9 > [2] http://openjdk.java.net/projects#committer-vote > From mikael.gerdin at oracle.com Thu Jun 11 10:33:16 2015 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Thu, 11 Jun 2015 12:33:16 +0200 Subject: CFV: New jdk9 Committer: Thomas Stuefe In-Reply-To: References: Message-ID: <557963EC.2090706@oracle.com> Vote: yes /Mikael On 2015-06-10 19:01, Volker Simonis wrote: > I hereby nominate Thomas Stuefe to jdk9 Committer. > > Thomas is a long-term member of the SAP JVM team at SAP. > He has spent most of the time working on HotSpot runtime issues, but > he is also the author of our internal AS400/System-i port and one of > the main contributors to the AIX port. > > Recently he has contributed 19 changes to jdk9: > > 8059868: JVM crashes on attach on Windows when compiled with /RTC1 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/f6420ff4bc52 > 8024854: PPC64: Basic changes and files to build the class library on AIX > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/541585921c82 > > 8077276: allocating heap with UseLargePages and HugeTLBFS may trash > existing memory mappings (linux) > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/98faabe210e9 > 8078628: linux-zero does not build without precompiled header > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/dee7fefc6935 > 8076475: Misuses of strncpy/strncat > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/4cf3113c8f42 > 8074354: Make CreateMinidumpOnCrash a new name and available on all platforms > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/eb02bcd73927 > 8077257: Use CanUseSafeFetch instead of probing SafeFetch stub directly > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/315c2a350a40 > 8075505: aix: improve handling of native memory > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/1c471be03faf > 8074860: Structured Exception Catcher missing around CreateJavaVM on Windows > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/883ae015914d > 8076185: Provide SafeFetchX implementation for zero > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/633053d4d137 > 8074552: SafeFetch32 and SafeFetchN do not work in error handling > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/3eb61269f421 > 8074543: Missing symbol "objArrayOopDesc::obj_at" when buiding with > CPP Interpreter > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/656216252893 > 8072935: Fix missing newline at end of file after 8067447 > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/b00d819e1fcc > 8072575: Add missing test for 8065895 > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/a09b7ff9426d > 8065895: Synchronous signals during error reporting may terminate or > hang VM process > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/6bfc40057b3f > 8065788: os::reserve_memory() on Windows should not assert that > allocation size is aligned to OS allocation granularity > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/84af818eed0a > 8064779: Add additional comments for "8062370: Various minor code improvements" > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/524b9a4ec5d9 > 7102541: RFE: os::set_native_thread_name() cleanups > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/763abe04c848 > 8020775: PPC64 (part 12): posix signal printing > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/f42f2e2a1518 > > > Votes are due by 20:00 CET, June 24, 2015. > > 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]. > > Thanks, > Volker > > [1] http://openjdk.java.net/census#jdk9 > [2] http://openjdk.java.net/projects#committer-vote > From yumin.qi at oracle.com Thu Jun 11 15:28:02 2015 From: yumin.qi at oracle.com (Yumin Qi) Date: Thu, 11 Jun 2015 08:28:02 -0700 Subject: CFV: New jdk9 Committer: Thomas Stuefe In-Reply-To: References: Message-ID: <5579A902.50903@oracle.com> Vote: yes Yumin On 6/10/2015 10:01 AM, Volker Simonis wrote: > I hereby nominate Thomas Stuefe to jdk9 Committer. > > Thomas is a long-term member of the SAP JVM team at SAP. > He has spent most of the time working on HotSpot runtime issues, but > he is also the author of our internal AS400/System-i port and one of > the main contributors to the AIX port. > > Recently he has contributed 19 changes to jdk9: > > 8059868: JVM crashes on attach on Windows when compiled with /RTC1 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/f6420ff4bc52 > 8024854: PPC64: Basic changes and files to build the class library on AIX > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/541585921c82 > > 8077276: allocating heap with UseLargePages and HugeTLBFS may trash > existing memory mappings (linux) > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/98faabe210e9 > 8078628: linux-zero does not build without precompiled header > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/dee7fefc6935 > 8076475: Misuses of strncpy/strncat > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/4cf3113c8f42 > 8074354: Make CreateMinidumpOnCrash a new name and available on all platforms > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/eb02bcd73927 > 8077257: Use CanUseSafeFetch instead of probing SafeFetch stub directly > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/315c2a350a40 > 8075505: aix: improve handling of native memory > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/1c471be03faf > 8074860: Structured Exception Catcher missing around CreateJavaVM on Windows > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/883ae015914d > 8076185: Provide SafeFetchX implementation for zero > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/633053d4d137 > 8074552: SafeFetch32 and SafeFetchN do not work in error handling > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/3eb61269f421 > 8074543: Missing symbol "objArrayOopDesc::obj_at" when buiding with > CPP Interpreter > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/656216252893 > 8072935: Fix missing newline at end of file after 8067447 > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/b00d819e1fcc > 8072575: Add missing test for 8065895 > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/a09b7ff9426d > 8065895: Synchronous signals during error reporting may terminate or > hang VM process > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/6bfc40057b3f > 8065788: os::reserve_memory() on Windows should not assert that > allocation size is aligned to OS allocation granularity > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/84af818eed0a > 8064779: Add additional comments for "8062370: Various minor code improvements" > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/524b9a4ec5d9 > 7102541: RFE: os::set_native_thread_name() cleanups > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/763abe04c848 > 8020775: PPC64 (part 12): posix signal printing > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/f42f2e2a1518 > > > Votes are due by 20:00 CET, June 24, 2015. > > 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]. > > Thanks, > Volker > > [1] http://openjdk.java.net/census#jdk9 > [2] http://openjdk.java.net/projects#committer-vote From sundararajan.athijegannathan at oracle.com Fri Jun 12 12:14:08 2015 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Fri, 12 Jun 2015 17:44:08 +0530 Subject: [8u60] approval request for 8087211: Indirect evals should be strict with -strict option Message-ID: <557ACD10.9010203@oracle.com> Please approve. Bug: https://bugs.openjdk.java.net/browse/JDK-8087211 jdk9 review thread: http://mail.openjdk.java.net/pipermail/nashorn-dev/2015-June/004746.html jdk8u-dev webrev: http://cr.openjdk.java.net/~sundar/8087211/8u60/webrev.00/ Backported "as is" except for the modular source layout difference. Thanks, -Sundar From sundararajan.athijegannathan at oracle.com Fri Jun 12 12:40:43 2015 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Fri, 12 Jun 2015 18:10:43 +0530 Subject: [8u60] approval request for 8087211: Indirect evals should be strict with -strict option In-Reply-To: <557ACD10.9010203@oracle.com> References: <557ACD10.9010203@oracle.com> Message-ID: <557AD34B.8020104@oracle.com> Please ignore. Sent to wrong list. -Sundar On Friday 12 June 2015 05:44 PM, A. Sundararajan wrote: > Please approve. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8087211 > jdk9 review thread: > http://mail.openjdk.java.net/pipermail/nashorn-dev/2015-June/004746.html > jdk8u-dev webrev: > http://cr.openjdk.java.net/~sundar/8087211/8u60/webrev.00/ > > Backported "as is" except for the modular source layout difference. > > Thanks, > -Sundar From staffan.larsen at oracle.com Mon Jun 15 08:06:14 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 15 Jun 2015 10:06:14 +0200 Subject: CFV: New jdk9 Committer: Thomas Stuefe In-Reply-To: References: Message-ID: Vote: yes > On 10 jun 2015, at 19:01, Volker Simonis wrote: > > I hereby nominate Thomas Stuefe to jdk9 Committer. > > Thomas is a long-term member of the SAP JVM team at SAP. > He has spent most of the time working on HotSpot runtime issues, but > he is also the author of our internal AS400/System-i port and one of > the main contributors to the AIX port. > > Recently he has contributed 19 changes to jdk9: > > 8059868: JVM crashes on attach on Windows when compiled with /RTC1 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/f6420ff4bc52 > 8024854: PPC64: Basic changes and files to build the class library on AIX > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/541585921c82 > > 8077276: allocating heap with UseLargePages and HugeTLBFS may trash > existing memory mappings (linux) > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/98faabe210e9 > 8078628: linux-zero does not build without precompiled header > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/dee7fefc6935 > 8076475: Misuses of strncpy/strncat > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/4cf3113c8f42 > 8074354: Make CreateMinidumpOnCrash a new name and available on all platforms > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/eb02bcd73927 > 8077257: Use CanUseSafeFetch instead of probing SafeFetch stub directly > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/315c2a350a40 > 8075505: aix: improve handling of native memory > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/1c471be03faf > 8074860: Structured Exception Catcher missing around CreateJavaVM on Windows > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/883ae015914d > 8076185: Provide SafeFetchX implementation for zero > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/633053d4d137 > 8074552: SafeFetch32 and SafeFetchN do not work in error handling > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/3eb61269f421 > 8074543: Missing symbol "objArrayOopDesc::obj_at" when buiding with > CPP Interpreter > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/656216252893 > 8072935: Fix missing newline at end of file after 8067447 > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/b00d819e1fcc > 8072575: Add missing test for 8065895 > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/a09b7ff9426d > 8065895: Synchronous signals during error reporting may terminate or > hang VM process > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/6bfc40057b3f > 8065788: os::reserve_memory() on Windows should not assert that > allocation size is aligned to OS allocation granularity > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/84af818eed0a > 8064779: Add additional comments for "8062370: Various minor code improvements" > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/524b9a4ec5d9 > 7102541: RFE: os::set_native_thread_name() cleanups > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/763abe04c848 > 8020775: PPC64 (part 12): posix signal printing > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/f42f2e2a1518 > > > Votes are due by 20:00 CET, June 24, 2015. > > 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]. > > Thanks, > Volker > > [1] http://openjdk.java.net/census#jdk9 > [2] http://openjdk.java.net/projects#committer-vote From Roger.Riggs at Oracle.com Mon Jun 15 13:12:59 2015 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Mon, 15 Jun 2015 09:12:59 -0400 Subject: CFV: New jdk9 Committer: Thomas Stuefe In-Reply-To: References: Message-ID: <557ECF5B.3090601@Oracle.com> Vote: Yes On 6/10/2015 1:01 PM, Volker Simonis wrote: > I hereby nominate Thomas Stuefe to jdk9 Committer. > From igor.ignatyev at oracle.com Mon Jun 15 13:34:24 2015 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Mon, 15 Jun 2015 16:34:24 +0300 Subject: RFR: JDK-8075327: Merge jdk and hotspot test libraries In-Reply-To: <1365a232-5a2d-4365-ad99-3638fdfac841@default> References: <1365a232-5a2d-4365-ad99-3638fdfac841@default> Message-ID: <557ED460.4050900@oracle.com> Alexander, > Therefore, I would suggest reviewing the current patch as it is , since the changes are trivial and postpone refactoring to the new packages until some time later, since such refactoring is not trivial and the current patch does provide for the merge. I agree that we should separate merge of test-libraries and refactoring them. however I do have a comment regarding the current patch. besides classes in jdk.test.lib package, hotspot test-library contains other common libraries: * jdk.test.lib.cli -- a test framework for command line option tests * jdk.test.lib.dcmd -- aux classes to simplify work w/ jcmd * jdk.test.lib.dtrace -- a test framework for dtrace tests From my point of view, all these packages can be used in jdk tests as well. so I think these packages should be moved to top-level repository. Another reason why these packages should be neither moved nor renamed (to smth like hotspot.test.lib) is ambiguity. If one see classes from jdk.test.lib package (or its subpackages), he/she will expect to find their source in /test, but in your current version, they are placed in hotspot/test. Even if we ok, we such ambiguity there is a risk that at some point, one will introduce another 'jdk.test.lib.cli' in top-level test directory. It will be really really hard to understand which libraries should be used. That means that all other classes from both jdk/test/lib/testlibrary/jdk/testlibrary/ and /hotspot/test/testlibrary/jdk/test/lib should be moved to /test. PS I also noticed that RandomFactory[1] class kinda duplicates Utils::getRandomInstance[2], could you please merge them or file an RFE to do it? Stuart, could you please review jdk part of this patch? [1] http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/c1947d42537b/test/lib/testlibrary/jdk/testlibrary/RandomFactory.java [2] http://hg.openjdk.java.net/jdk9/jdk9/hotspot/file/c25bfaaed7f2/test/testlibrary/jdk/test/lib/Utils.java#l367 -- Thanks, Igor On 06/04/2015 05:23 PM, Alexander Kulyakhtin wrote: > Stefan, > > There are some issues which may make it difficult to implement the grouping of the common test library files into the new packages as JDK-8075327 proposes. > > The changes in the current patch are trivial and made by a script (although they spread over many files). > They are trivial because the names of the packages are left intact (except fo renaming of jdk.testlibrary to jdk.test.lib in the jdk repo). > > However, if we introduce the new packages per the CR description we will end up with > > import jdk.test.lib.*; > import jdk.test.lib.vm.*; > import jdk.test.lib.processtools.*; > import jdk.test.lib.misc.*; > > where previously was just a single line > > import jdk.test.lib.*; > > The same goes for @build and @run directives where we end up with > > @build jdk.test.lib.* jdk.test.lib.vm.* jdk.test.lib.processtools.* jdk.test.lib.misc.* > > instead of > > @build jdk.test.lib.* > > There are many tests having import jdk.test.lib.* and @build jdk.test.lib.* and similar constructions. > > If we then want to deduce the minimal required dependencies for each and every jdk and hotspot test, then it will not be as trivial task as what we have currently done. It will, probably, require a significant review effort from both jdk and hotspot teams. > The benefits of that effort are not quite evident for me though I, probably, might be missing something here. > > The current patch does already provide for the merge of the common part of the jdk and hotspot libraries and do eliminate the duplicated files. > > Therefore, I would suggest reviewing the current patch as it is , since the changes are trivial and postpone refactoring to the new packages until some time later, since such refactoring is not trivial and the current patch does provide for the merge. > > Best regards, > Alexander > > ----- Original Message ----- > From: alexander.kulyakhtin at oracle.com > To: stefan.sarne at oracle.com > Cc: jdk9-dev at openjdk.java.net, yekaterina.kantserova at oracle.com, hotspot-dev at openjdk.java.net > Sent: Wednesday, June 3, 2015 3:33:22 PM GMT +03:00 Iraq > Subject: Re: RFR: JDK-8075327: Merge jdk and hotspot test libraries > > > > Hi Stefan, > > Thank you very much for the review. I'll update the patch accordingly, shortly. > > Best regards, > Alexander > > ----- Original Message ----- > From: stefan.sarne at oracle.com > To: alexander.kulyakhtin at oracle.com, jdk9-dev at openjdk.java.net, hotspot-dev at openjdk.java.net > Cc: yekaterina.kantserova at oracle.com > Sent: Wednesday, June 3, 2015 12:08:33 PM GMT +03:00 Iraq > Subject: Re: RFR: JDK-8075327: Merge jdk and hotspot test libraries > > > > Hi Alexander, > > I think we want to group the utilities into packages directly. > > One reason for grouping is to support discovery, to clarify what belongs together. For example both the OutputAnalyzer and the StreamPumper belong together in a processtools package, while Asserts doesn't. > > Another reason is to simplify imports and reduce the impact of wild card includes, since for example an import of process tools should not have to bother with declaring usage of sun.misc.Unsafe in the modules world, just because Utils happen to be in the same package. > > Here are some examples - also available in the jira case: > > Package jdk.test.lib.processtools is the package for utilities for launching processes and analyzing the output. > /test/lib/share/classes/jdk/test/lib/processtools/OutputAnalyzer.java > /test/lib/share/classes/jdk/test/lib/processtools/OutputBuffer.java > /test/lib/share/classes/jdk/test/lib/processtools/ProcessTools.java > /test/lib/share/classes/jdk/test/lib/processtools/StreamPumper.java > /test/lib/share/classes/jdk/test/lib/processtools/JDKToolFinder.java > /test/lib/share/classes/jdk/test/lib/processtools/JDKToolLauncher.java > > /test/lib-test/jdk/test/lib/processtools/OutputAnalyzerTest.java > > > Asserts can stay at top level. > /test/lib/share/classes/jdk/test/lib/Asserts.java > /test/lib-test/jdk/test/lib/AssertsTest.java > > > For VM specific info, it would have vm package. Note that the whitebox API moves here. > /test/lib/share/classes/jdk/test/lib/vm/InputArguments.java > /test/lib/share/classes/jdk/test/lib/vm/Platform.java > > > Ok, so then there are the stuff which just is a bucket of stuff and fluff. > A later exercise could be to break this class into better named and placed classes, but this is a start: > /test/lib/share/classes/jdk/test/lib/misc/Utils.java > > Thanks, > Stefan > > > Alexander Kulyakhtin skrev den 2015-06-02 13:18: > > > Hi, > > Could you, please, review the following test-only changes to the 'jdk', 'hotspot' and the common 'test' repository http://cr.openjdk.java.net/~akulyakh/8075327/wr_hs/webrev.01/index.html http://cr.openjdk.java.net/~akulyakh/8075327/wr_jdk/webrev.01/index.html http://cr.openjdk.java.net/~akulyakh/8075327/wr_test/webrev.01/ The changes are to move test library files common to both jdk and hotspot to the upper-level test repository. > > The following has been done: > 1) Common files (Asserts.java, OutputAnalyzer.java etc) from the jdk and hotspot repositories, have been merged and moved to the upper-level common test repository, to test/lib/share/classes. > 2) Package jdk.testlibrary in the jdk repository have been renamed to jdk.test.lib to have the same name as in the hotspot repository > 2) Upper level test/lib/share/classes library references have been added to the @library statements > 3) Some packages previously located at upper level test repo at /test/lib have been moved to /test/lib/share/classes for consistency > > Best regards, > Alexander > From stefan.sarne at oracle.com Mon Jun 15 14:23:16 2015 From: stefan.sarne at oracle.com (=?UTF-8?B?U3RlZmFuIFPDpHJuZQ==?=) Date: Mon, 15 Jun 2015 16:23:16 +0200 Subject: RFR: JDK-8075327: Merge jdk and hotspot test libraries In-Reply-To: <1365a232-5a2d-4365-ad99-3638fdfac841@default> References: <1365a232-5a2d-4365-ad99-3638fdfac841@default> Message-ID: <557EDFD4.8090303@oracle.com> Hi Alexander, If you prefer to make this change in two steps, I am ok with this. I think further cleanup into packages is important. But as you highlight, it will not be good if we just "add imports to all new locations". There should not be unused imports. Thanks, Stefan Alexander Kulyakhtin skrev den 2015-06-04 16:23: > Stefan, > > There are some issues which may make it difficult to implement the > grouping of the common test library files into the new packages as > JDK-8075327 proposes. > > The changes in the current patch are trivial and made by a script > (although they spread over many files). > They are trivial because the names of the packages are left intact > (except fo renaming of jdk.testlibrary to jdk.test.lib in the jdk repo). > > However, if we introduce the new packages per the CR description we > will end up with > > import jdk.test.lib.*; > import jdk.test.lib.vm.*; > import jdk.test.lib.processtools.*; > import jdk.test.lib.misc.*; > > where previously was just a single line > > import jdk.test.lib.*; > > The same goes for @build and @run directives where we end up with > > @build jdk.test.lib.* jdk.test.lib.vm.* jdk.test.lib.processtools.* > jdk.test.lib.misc.* > > instead of > > @build jdk.test.lib.* > > There are many tests having import jdk.test.lib.* and @build > jdk.test.lib.* and similar constructions. > > If we then want to deduce the minimal required dependencies for each > and every jdk and hotspot test, then it will not be as trivial task > as what we have currently done. It will, probably, require a > significant review effort from both jdk and hotspot teams. > The benefits of that effort are not quite evident for me though I, > probably, might be missing something here. > > The current patch does already provide for the merge of the common > part of the jdk and hotspot libraries and do eliminate the duplicated > files. > > Therefore, I would suggest reviewing the current patch as it is , > since the changes are trivial and postpone refactoring to the new > packages until some time later, since such refactoring is not trivial > and the current patch does provide for the merge. > > Best regards, > Alexander > > ----- Original Message ----- > From: alexander.kulyakhtin at oracle.com > To: stefan.sarne at oracle.com > Cc: jdk9-dev at openjdk.java.net, yekaterina.kantserova at oracle.com, > hotspot-dev at openjdk.java.net > Sent: Wednesday, June 3, 2015 3:33:22 PM GMT +03:00 Iraq > Subject: Re: RFR: JDK-8075327: Merge jdk and hotspot test libraries > > Hi Stefan, > > Thank you very much for the review. I'll update the patch accordingly, > shortly. > > Best regards, > Alexander > > ----- Original Message ----- > From: stefan.sarne at oracle.com > To: alexander.kulyakhtin at oracle.com, jdk9-dev at openjdk.java.net, > hotspot-dev at openjdk.java.net > Cc: yekaterina.kantserova at oracle.com > Sent: Wednesday, June 3, 2015 12:08:33 PM GMT +03:00 Iraq > Subject: Re: RFR: JDK-8075327: Merge jdk and hotspot test libraries > > > Hi Alexander, > > I think we want to group the utilities into packages directly. > > One reason for grouping is to support discovery, to clarify what > belongs together. For example both the OutputAnalyzer and the > StreamPumper belong together in a processtools package, while Asserts > doesn't. > > Another reason is to simplify imports and reduce the impact of wild > card includes, since for example an import of process tools should not > have to bother with declaring usage of sun.misc.Unsafe in the modules > world, just because Utils happen to be in the same package. > > Here are some examples - also available in the jira case: > > Package jdk.test.lib.processtools is the package for utilities for > launching processes and analyzing the output. > root>/test/lib/share/classes/jdk/test/lib/processtools/OutputAnalyzer.java > root>/test/lib/share/classes/jdk/test/lib/processtools/OutputBuffer.java > root>/test/lib/share/classes/jdk/test/lib/processtools/ProcessTools.java > root>/test/lib/share/classes/jdk/test/lib/processtools/StreamPumper.java > root>/test/lib/share/classes/jdk/test/lib/processtools/JDKToolFinder.java > root>/test/lib/share/classes/jdk/test/lib/processtools/JDKToolLauncher.java > > root>/test/lib-test/jdk/test/lib/processtools/OutputAnalyzerTest.java > > > Asserts can stay at top level. > /test/lib/share/classes/jdk/test/lib/Asserts.java > /test/lib-test/jdk/test/lib/AssertsTest.java > > > For VM specific info, it would have vm package. Note that the whitebox > API moves here. > /test/lib/share/classes/jdk/test/lib/vm/InputArguments.java > /test/lib/share/classes/jdk/test/lib/vm/Platform.java > > > Ok, so then there are the stuff which just is a bucket of stuff and fluff. > A later exercise could be to break this class into better named and > placed classes, but this is a start: > /test/lib/share/classes/jdk/test/lib/misc/Utils.java > > Thanks, > Stefan > > Alexander Kulyakhtin skrev den 2015-06-02 13:18: > > Hi, > > Could you, please, review the following test-only changes to the 'jdk', 'hotspot' and the common 'test' repository > > http://cr.openjdk.java.net/~akulyakh/8075327/wr_hs/webrev.01/index.html > http://cr.openjdk.java.net/~akulyakh/8075327/wr_jdk/webrev.01/index.html > http://cr.openjdk.java.net/~akulyakh/8075327/wr_test/webrev.01/ > > The changes are to move test library files common to both jdk and hotspot to the upper-level test repository. > > The following has been done: > 1) Common files (Asserts.java, OutputAnalyzer.java etc) from the jdk and hotspot repositories, have been merged and moved to the upper-level common test repository, to test/lib/share/classes. > 2) Package jdk.testlibrary in the jdk repository have been renamed to jdk.test.lib to have the same name as in the hotspot repository > 2) Upper level test/lib/share/classes library references have been added to the @library statements > 3) Some packages previously located at upper level test repo at /test/lib have been moved to /test/lib/share/classes for consistency > > Best regards, > Alexander > > From alejandro.murillo at oracle.com Mon Jun 15 23:39:26 2015 From: alejandro.murillo at oracle.com (Alejandro E Murillo) Date: Mon, 15 Jun 2015 17:39:26 -0600 Subject: jdk9-dev: HotSpot Message-ID: <557F622E.5000207@oracle.com> jdk9-hs-2015-06-11 has been integrated into jdk9-dev. http://hg.openjdk.java.net/jdk9/dev/rev/1bcfd6b87265 http://hg.openjdk.java.net/jdk9/dev/corba/rev/c43da2a11652 http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/43e11a06fcf3 http://hg.openjdk.java.net/jdk9/dev/jaxp/rev/06e3ee9962f6 http://hg.openjdk.java.net/jdk9/dev/jaxws/rev/f5911c6155c2 http://hg.openjdk.java.net/jdk9/dev/jdk/rev/06b88be168b6 http://hg.openjdk.java.net/jdk9/dev/langtools/rev/931ec7dd6cd9 http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/0e28af5ee013 Component : VM Status : Go for integration Date : 06/15/2015 at 20:30 MSK Tested By : VM SQE &dmitry.fazunenko at oracle.com Bundles : 2015-06-04-224117.amurillo.jdk9-hs-2015-06-04-snapshot Testing: 92 new failures, 1529 known failures, 348772 passed. Issues and Notes: No detailed analysis. No stoppers have been detected so far. Go for integration CRs for testing: 8078866: compiler/eliminateAutobox/6934604/TestIntBoxing.java assert(p_f->Opcode() == Op_IfFalse) failed 8081778: Use Intel x64 CPU instructions for RSA acceleration 8081823: C2 performs unsigned comparison against -1 8085832: Optimize main and post loop out when pre loop is found empty -- Alejandro From alexander.kulyakhtin at oracle.com Tue Jun 16 13:12:39 2015 From: alexander.kulyakhtin at oracle.com (Alexander Kulyakhtin) Date: Tue, 16 Jun 2015 06:12:39 -0700 (PDT) Subject: RFR: JDK-8075327: Merge jdk and hotspot test libraries Message-ID: <1e9b38b0-e19d-49c2-861c-06024a25334a@default> Igor, Stuart As Igor has suggested, we have divided the changes into several subtasks. The changes under review are then for the subtask https://bugs.openjdk.java.net/browse/JDK-8098823 "Merge common classes from jdk and hotspot test libraries" These changes merge the common files from the jdk and hotspot test libraries and move them one level up to the top-level 'test' repository. This eliminates the duplicate files between the jdk and the hotspot test libraries. The changes are as follows: 1) Common files (Asserts.java, OutputAnalyzer.java etc) from the jdk and hotspot repositories, have been merged and moved to the upper-level common test repository, to test/lib/share/classes. 2) Package jdk.testlibrary in the jdk repository have been renamed to jdk.test.lib to have the same name as in the hotspot repository 3) Upper level test/lib/share/classes library references have been added to the @library statements 4) Some packages previously located at upper level test repo at /test/lib have been moved to /test/lib/share/classes for consistency http://cr.openjdk.java.net/~akulyakh/8075327/wr_hs/webrev.01/index.html http://cr.openjdk.java.net/~akulyakh/8075327/wr_jdk/webrev.01/index.html http://cr.openjdk.java.net/~akulyakh/8075327/wr_test/webrev.01/index.html The other proposed changes are addressed by different subtasks and will be reviewed later. Stuart, Could you, please, provide your comments on the proposed changes from the jdk repository perspective? Best regards, Alexander ----- Original Message ----- From: igor.ignatyev at oracle.com To: alexander.kulyakhtin at oracle.com, stuart.marks at oracle.com Cc: jdk9-dev at openjdk.java.net, stefan.sarne at oracle.com, yekaterina.kantserova at oracle.com, hotspot-dev at openjdk.java.net, alexandre.iline at oracle.com, aleksey.voytilov at oracle.com Sent: Monday, June 15, 2015 4:34:38 PM GMT +03:00 Iraq Subject: Re: RFR: JDK-8075327: Merge jdk and hotspot test libraries Alexander, > Therefore, I would suggest reviewing the current patch as it is , since the changes are trivial and postpone refactoring to the new packages until some time later, since such refactoring is not trivial and the current patch does provide for the merge. I agree that we should separate merge of test-libraries and refactoring them. however I do have a comment regarding the current patch. besides classes in jdk.test.lib package, hotspot test-library contains other common libraries: * jdk.test.lib.cli -- a test framework for command line option tests * jdk.test.lib.dcmd -- aux classes to simplify work w/ jcmd * jdk.test.lib.dtrace -- a test framework for dtrace tests From my point of view, all these packages can be used in jdk tests as well. so I think these packages should be moved to top-level repository. Another reason why these packages should be neither moved nor renamed (to smth like hotspot.test.lib) is ambiguity. If one see classes from jdk.test.lib package (or its subpackages), he/she will expect to find their source in /test, but in your current version, they are placed in hotspot/test. Even if we ok, we such ambiguity there is a risk that at some point, one will introduce another 'jdk.test.lib.cli' in top-level test directory. It will be really really hard to understand which libraries should be used. That means that all other classes from both jdk/test/lib/testlibrary/jdk/testlibrary/ and /hotspot/test/testlibrary/jdk/test/lib should be moved to /test. PS I also noticed that RandomFactory[1] class kinda duplicates Utils::getRandomInstance[2], could you please merge them or file an RFE to do it? Stuart, could you please review jdk part of this patch? [1] http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/c1947d42537b/test/lib/testlibrary/jdk/testlibrary/RandomFactory.java [2] http://hg.openjdk.java.net/jdk9/jdk9/hotspot/file/c25bfaaed7f2/test/testlibrary/jdk/test/lib/Utils.java#l367 -- Thanks, Igor On 06/04/2015 05:23 PM, Alexander Kulyakhtin wrote: > Stefan, > > There are some issues which may make it difficult to implement the grouping of the common test library files into the new packages as JDK-8075327 proposes. > > The changes in the current patch are trivial and made by a script (although they spread over many files). > They are trivial because the names of the packages are left intact (except fo renaming of jdk.testlibrary to jdk.test.lib in the jdk repo). > > However, if we introduce the new packages per the CR description we will end up with > > import jdk.test.lib.*; > import jdk.test.lib.vm.*; > import jdk.test.lib.processtools.*; > import jdk.test.lib.misc.*; > > where previously was just a single line > > import jdk.test.lib.*; > > The same goes for @build and @run directives where we end up with > > @build jdk.test.lib.* jdk.test.lib.vm.* jdk.test.lib.processtools.* jdk.test.lib.misc.* > > instead of > > @build jdk.test.lib.* > > There are many tests having import jdk.test.lib.* and @build jdk.test.lib.* and similar constructions. > > If we then want to deduce the minimal required dependencies for each and every jdk and hotspot test, then it will not be as trivial task as what we have currently done. It will, probably, require a significant review effort from both jdk and hotspot teams. > The benefits of that effort are not quite evident for me though I, probably, might be missing something here. > > The current patch does already provide for the merge of the common part of the jdk and hotspot libraries and do eliminate the duplicated files. > > Therefore, I would suggest reviewing the current patch as it is , since the changes are trivial and postpone refactoring to the new packages until some time later, since such refactoring is not trivial and the current patch does provide for the merge. > > Best regards, > Alexander > > ----- Original Message ----- > From: alexander.kulyakhtin at oracle.com > To: stefan.sarne at oracle.com > Cc: jdk9-dev at openjdk.java.net, yekaterina.kantserova at oracle.com, hotspot-dev at openjdk.java.net > Sent: Wednesday, June 3, 2015 3:33:22 PM GMT +03:00 Iraq > Subject: Re: RFR: JDK-8075327: Merge jdk and hotspot test libraries > > > > Hi Stefan, > > Thank you very much for the review. I'll update the patch accordingly, shortly. > > Best regards, > Alexander > > ----- Original Message ----- > From: stefan.sarne at oracle.com > To: alexander.kulyakhtin at oracle.com, jdk9-dev at openjdk.java.net, hotspot-dev at openjdk.java.net > Cc: yekaterina.kantserova at oracle.com > Sent: Wednesday, June 3, 2015 12:08:33 PM GMT +03:00 Iraq > Subject: Re: RFR: JDK-8075327: Merge jdk and hotspot test libraries > > > > Hi Alexander, > > I think we want to group the utilities into packages directly. > > One reason for grouping is to support discovery, to clarify what belongs together. For example both the OutputAnalyzer and the StreamPumper belong together in a processtools package, while Asserts doesn't. > > Another reason is to simplify imports and reduce the impact of wild card includes, since for example an import of process tools should not have to bother with declaring usage of sun.misc.Unsafe in the modules world, just because Utils happen to be in the same package. > > Here are some examples - also available in the jira case: > > Package jdk.test.lib.processtools is the package for utilities for launching processes and analyzing the output. > /test/lib/share/classes/jdk/test/lib/processtools/OutputAnalyzer.java > /test/lib/share/classes/jdk/test/lib/processtools/OutputBuffer.java > /test/lib/share/classes/jdk/test/lib/processtools/ProcessTools.java > /test/lib/share/classes/jdk/test/lib/processtools/StreamPumper.java > /test/lib/share/classes/jdk/test/lib/processtools/JDKToolFinder.java > /test/lib/share/classes/jdk/test/lib/processtools/JDKToolLauncher.java > > /test/lib-test/jdk/test/lib/processtools/OutputAnalyzerTest.java > > > Asserts can stay at top level. > /test/lib/share/classes/jdk/test/lib/Asserts.java > /test/lib-test/jdk/test/lib/AssertsTest.java > > > For VM specific info, it would have vm package. Note that the whitebox API moves here. > /test/lib/share/classes/jdk/test/lib/vm/InputArguments.java > /test/lib/share/classes/jdk/test/lib/vm/Platform.java > > > Ok, so then there are the stuff which just is a bucket of stuff and fluff. > A later exercise could be to break this class into better named and placed classes, but this is a start: > /test/lib/share/classes/jdk/test/lib/misc/Utils.java > > Thanks, > Stefan > > > Alexander Kulyakhtin skrev den 2015-06-02 13:18: > > > Hi, > > Could you, please, review the following test-only changes to the 'jdk', 'hotspot' and the common 'test' repository http://cr.openjdk.java.net/~akulyakh/8075327/wr_hs/webrev.01/index.html http://cr.openjdk.java.net/~akulyakh/8075327/wr_jdk/webrev.01/index.html http://cr.openjdk.java.net/~akulyakh/8075327/wr_test/webrev.01/ The changes are to move test library files common to both jdk and hotspot to the upper-level test repository. > > The following has been done: > 1) Common files (Asserts.java, OutputAnalyzer.java etc) from the jdk and hotspot repositories, have been merged and moved to the upper-level common test repository, to test/lib/share/classes. > 2) Package jdk.testlibrary in the jdk repository have been renamed to jdk.test.lib to have the same name as in the hotspot repository > 2) Upper level test/lib/share/classes library references have been added to the @library statements > 3) Some packages previously located at upper level test repo at /test/lib have been moved to /test/lib/share/classes for consistency > > Best regards, > Alexander > From timo.kinnunen at gmail.com Tue Jun 16 09:23:47 2015 From: timo.kinnunen at gmail.com (=?utf-8?Q?Timo_Kinnunen?=) Date: Tue, 16 Jun 2015 09:23:47 +0000 Subject: =?utf-8?Q?Self-type?= Message-ID: <55809773.2853b40a.249d.ffff92ba@mx.google.com> How come this simple and obvious thing doesn?t work? B init(B this, T value) { this.item = value; return this; } To me that says: ?whatever type you used as a receiver, you get the same back?, as simple as that. The equivalent static method version works as expected but isn?t as convenient to use for consumers: static , T> B init2_OK(B thiz, T value) { thiz.item = value; return thiz; } This similar construct works as well but requires extra discipline from the consumer: B init3_OK(B thiz, T value) { this.item = value; return thiz; } This is the closest I have gotten to a workaround, but it is obviously not completely type-safe: > B init4_OKISH(T value) { this.item = value; return thiz(); } private > B thiz() { @SuppressWarnings("unchecked") B thiz = (B) this; return thiz; } A little help from the language, please? -- Have a nice day, Timo. Sent from Windows Mail From alex.buckley at oracle.com Tue Jun 16 22:53:04 2015 From: alex.buckley at oracle.com (Alex Buckley) Date: Tue, 16 Jun 2015 15:53:04 -0700 Subject: Self-type In-Reply-To: <55809773.2853b40a.249d.ffff92ba@mx.google.com> References: <55809773.2853b40a.249d.ffff92ba@mx.google.com> Message-ID: <5580A8D0.3030206@oracle.com> Because the "B this" term in your method signature is a receiver parameter. Per JLS8 8.4.1, a receiver parameter "represents the object for which the method is invoked" and "exists solely to allow the type of the represented object to be denoted in source code, so that the type may be annotated." The only type permitted for a receiver parameter is the enclosing class, i.e., a self type but not with the generality you desire. Alex On 6/16/2015 2:23 AM, Timo Kinnunen wrote: > How come this simple and obvious thing doesn?t work? > > > B init(B this, T value) { > > this.item = value; > > return this; > > } > > > To me that says: ?whatever type you used as a receiver, you get the same back?, as simple as that. The equivalent static method version works as expected but isn?t as convenient to use for consumers: > > > static , T> B init2_OK(B thiz, T value) { > > thiz.item = value; > > return thiz; > > } > > > This similar construct works as well but requires extra discipline from the consumer: > > > B init3_OK(B thiz, T value) { > > this.item = value; > > return thiz; > > } > > > This is the closest I have gotten to a workaround, but it is obviously not completely type-safe: > > > > B init4_OKISH(T value) { > > this.item = value; > > return thiz(); > > } > > private > B thiz() { > > @SuppressWarnings("unchecked") > > B thiz = (B) this; > > return thiz; > > } > > > A little help from the language, please? > > > > > From lana.steuck at oracle.com Wed Jun 17 03:58:27 2015 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Tue, 16 Jun 2015 20:58:27 -0700 (PDT) Subject: jdk9-b69: dev Message-ID: <201506170358.t5H3wRbM021672@sc11152554.us.oracle.com> http://hg.openjdk.java.net/jdk9/jdk9/rev/1bcfd6b87265 http://hg.openjdk.java.net/jdk9/jdk9/nashorn/rev/194b74467afc http://hg.openjdk.java.net/jdk9/jdk9/langtools/rev/931ec7dd6cd9 http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/551323004d0c http://hg.openjdk.java.net/jdk9/jdk9/jaxws/rev/f5911c6155c2 http://hg.openjdk.java.net/jdk9/jdk9/jaxp/rev/f844a908d330 http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/ff0929a59ced http://hg.openjdk.java.net/jdk9/jdk9/corba/rev/de8acedcb5b5 --- All the fixes will be tested during promotion (no PIT testing at this point): List of all fixes: =================== JDK-8080490 core-libs add $EXECV command to Nashorn scripting mode JDK-8085937 core-libs add autoimports sample script to easily explore Java classes in intera JDK-8086032 core-libs Add compiler error tests when syntax extensions are used with --no-syn JDK-8085885 core-libs address Javadoc warnings in Nashorn source code JDK-8081674 core-libs EmptyStackException at startup if running with extended or unsupported JDK-8080945 core-libs Improve the performance of primitive Arrays.sort for certain patterns JDK-8080819 core-libs Inet4AddressImpl regression caused by JDK-7180557 JDK-8086117 core-libs java/lang/Runtime/exec/LotsOfOutput.java still fails intermittently wi JDK-8068416 core-libs LFGarbageCollectedTest.java fails with OOME: "GC overhead limit exceed JDK-8081517 core-libs Minor cleanup for docs JDK-8085802 core-libs Nashorn -nse option causes parse error on anonymous function definitio JDK-8080087 core-libs Nashorn $ENV.PWD is originally undefined JDK-8087136 core-libs regression: apply on $EXEC fails with ClassCastException JDK-8064956 core-libs Remove sun.misc.ExtensionInstallationProvider and relevant classes JDK-8085810 core-libs Return value of Objects.requireNonNull call can be used JDK-8081037 core-svc serviceability/sa/ tests time out on Windows JDK-8080774 globalization DateFormat for Singapore/English locale (en_SG) is M/d/yy instead of d JDK-8072913 hotspot [REDO] GCCause should distinguish jcmd GC.run from System.gc() JDK-8085805 hotspot aarch64: AdvancedThresholdPolicy lacks tuning of InlineSmallCode size JDK-8081682 hotspot AbstractWorkGang::_terminate is never used JDK-8080699 hotspot Assert failed: Not a Java pointer in JCK test JDK-8081320 hotspot Backout JDK-8059340: ConstantPool::_resolved_references is missing in JDK-8079135 hotspot C2 disables some optimizations when a large number of unique nodes exi JDK-8060036 hotspot C2: CmpU nodes can end up with wrong type information JDK-8079205 hotspot CallSite dependency tracking is broken after sun.misc.Cleaner became a JDK-8029567 hotspot Clean up linkResolver code JDK-8059340 hotspot ConstantPool::_resolved_references is missing in heap dump JDK-8076613 hotspot gc/TestSmallHeap.java failed with OOME JDK-8080156 hotspot Integer.toString(int value) sometimes throws NPE JDK-8076319 hotspot jstat verified class fix JDK-8072588 hotspot JVM crashes in JNI if toString is declared as an interface method JDK-8001622 hotspot loadUB2L_immI8 & loadUS2L_immI16 rules don't match some 8-bit/16-bit m JDK-8080718 hotspot Make -XX:CreateCoredumpOnCrash control core dumping in all cases JDK-8081508 hotspot metaspace/shrink_grow/CompressedClassSpaceSize fails with OOM: Compres JDK-8079093 hotspot Remove FakeRttiSupport workaround for spurious gcc -Wtype-limits JDK-8081475 hotspot SystemTap does not work when JDK is compiled with GCC 5 JDK-8080446 hotspot The change for 8074354 removed the server check when creating minidump JDK-8080976 hotspot Unexpected AIOOB thrown from 1.9.0-ea-b64 on (regression) JDK-8077504 hotspot Unsafe load can loose control dependency and cause crash JDK-8081616 infrastructure Remove hard-coded CFLAGS_WARNINGS_ARE_ERRORS to fully respect --disabl JDK-8087156 infrastructure SetupNativeCompilation ignores CFLAGS_release for cpp files JDK-7130985 other-libs Four helper classes missing in Sun JDK JDK-8076535 security-libs Deprecate the com.sun.jarsigner package JDK-8085979 security-libs Make some DTLS feature functional tests work also for TLS protocol JDK-8065942 security-libs Store PermissionCollection entries in a ConcurrentHashMap instead of a JDK-8056179 security-libs Store permissions in concurrent collections in PermissionCollection su JDK-8072515 security-libs Test Task: Develop new tests for JEP 219: Datagram Transport Layer Sec JDK-8081521 tools Compiler has trouble compiling nested diamond allocation constructs in JDK-8087115 tools Due to a javac type inference issue, sjavac doesn't compile with 8u31 JDK-8082311 tools NPE when compiling expression with "^" JDK-8054717 tools SJavac should track changes in the public apis of classpath classes! JDK-8080906 xml Develop test for Xerces Update: DOM L3 Serializer JDK-8080908 xml Develop test for Xerces Update: XPointer JDK-8072839 xml JAX-B Plugability Layer: using java.util.ServiceLoader From timo.kinnunen at gmail.com Wed Jun 17 09:11:05 2015 From: timo.kinnunen at gmail.com (=?utf-8?Q?Timo_Kinnunen?=) Date: Wed, 17 Jun 2015 09:11:05 +0000 Subject: =?utf-8?Q?Re:_Self-type?= In-Reply-To: <5580A8D0.3030206@oracle.com> References: <55809773.2853b40a.249d.ffff92ba@mx.google.com>, <5580A8D0.3030206@oracle.com> Message-ID: <55819972.89acc20a.1aab.ffffa5a2@mx.google.com> Hi, Maybe it could instead be made say that the receiver parameter is optional and that if it isn?t present its type is considered to be the type of the declaring class or interface, and otherwise treat its type like any other parameters?. It seems to me that the receiver type being treated as a special case from the types of the other parameters is an unnecessary inconsistency. Other than where other special cases might prohibit it, you could rewrite methods to add a duplicate of the receiver as a method?s first parameter, then inside the method assert that both are the same and move the rest of the method implementation into a static method: interface Set extends Iterable { default , T2> THIS addAll(THIS thiz, Iterable iterable) { assert this == thiz; return addAll_impl(thiz, iterable); } static , T2> THIS addAll_impl(THIS thiz, Iterable iterable) { THIS result = thiz; for(T2 item : iterable) { result = result.add(result, item); } return result; } , T2> THIS add(THIS thiz, T2 t); } Now the receiver is only used for method invocation and it along with its type is forgotten right after that. The type of the receiver duplicate is treated normally and things still work as expected. Given how small role the receiver now has why not then fold it and its duplicate parameter back into one parameter that provides the features of both of them? In addition to self-types, a thusly combined receiver parameter could also provide type-specialization. Here?s how you could have some containers provide flattening depending on what their types are. Simulated as in above to allow compiling with current compilers: default , C extends Set, T2> C flatten(THIS thiz) { assert this == thiz; return flatten_impl(thiz); } static , C extends Set, T2> C flatten_impl(THIS thiz) { C result = null; for(C items : thiz) { result = result == null ? items : result.addAll(result, items); } return result; } This works as expected: List> sets = //? Set set = sets.flatten(sets); Set> lists = //? List list = lists.flatten(lists); Or you could provide joining for a container of Strings: interface List extends Set { default , CS extends CharSequence> String join(THIS thiz, CharSequence delim) { assert this == thiz; return join_impl(thiz, delim); } static , CS extends CharSequence> String join_impl(THIS thiz, CharSequence delim) { return String.join(delim, thiz); } } Usable as expected: List> linesOfFiles = //? List lines = linesOfFiles.flatten(linesOfFiles); String file = lines.join(lines, "\n"); This form of type specialization is somewhat similar to what is being explored in Project Valhalla but I don?t think Valhalla is looking into fixing these kinds of receiver type inconsistencies. -- Have a nice day, Timo. Sent from Windows Mail From: Alex Buckley Sent: ?Wednesday?, ?June? ?17?, ?2015 ?0?:?53 To: Timo Kinnunen, jdk9-dev at openjdk.java.net Because the "B this" term in your method signature is a receiver parameter. Per JLS8 8.4.1, a receiver parameter "represents the object for which the method is invoked" and "exists solely to allow the type of the represented object to be denoted in source code, so that the type may be annotated." The only type permitted for a receiver parameter is the enclosing class, i.e., a self type but not with the generality you desire. Alex On 6/16/2015 2:23 AM, Timo Kinnunen wrote: > How come this simple and obvious thing doesn?t work? > > > B init(B this, T value) { > > this.item = value; > > return this; > > } > > > To me that says: ?whatever type you used as a receiver, you get the same back?, as simple as that. The equivalent static method version works as expected but isn?t as convenient to use for consumers: > > > static , T> B init2_OK(B thiz, T value) { > > thiz.item = value; > > return thiz; > > } > > > This similar construct works as well but requires extra discipline from the consumer: > > > B init3_OK(B thiz, T value) { > > this.item = value; > > return thiz; > > } > > > This is the closest I have gotten to a workaround, but it is obviously not completely type-safe: > > > > B init4_OKISH(T value) { > > this.item = value; > > return thiz(); > > } > > private > B thiz() { > > @SuppressWarnings("unchecked") > > B thiz = (B) this; > > return thiz; > > } > > > A little help from the language, please? > > > > > From john.r.rose at oracle.com Wed Jun 17 22:17:00 2015 From: john.r.rose at oracle.com (John Rose) Date: Wed, 17 Jun 2015 15:17:00 -0700 Subject: Self-type In-Reply-To: <55819972.89acc20a.1aab.ffffa5a2@mx.google.com> References: <55809773.2853b40a.249d.ffff92ba@mx.google.com> <5580A8D0.3030206@oracle.com> <55819972.89acc20a.1aab.ffffa5a2@mx.google.com> Message-ID: <7A720ABF-12EF-4665-9C35-4FF851978026@oracle.com> On Jun 17, 2015, at 2:11 AM, Timo Kinnunen wrote: > It seems to me that the receiver type being treated as a special case from the types of the other parameters is an unnecessary inconsistency. I get what you are saying here, though I would say more carefully "some special rules for the receiver argument are unnecessarily different from the rules for other arguments". Receivers will always be a little different from other arguments, because dynamic method selection introduces type shifting when an overloading is invoked, but those differences could be more carefully localized, in the Java of some parallel universe. I would prefer we were in a world where the difference between "a.m(b)" and "m(a,b)" is little more than surface syntax, to be tweaked by tasteful library designers. Here's my pet peeve in this vein: Type inference rules treat receiver types as less coupled to constraints than other types; this is why some design patterns can only be written using Java statics, and not using instance methods?which (as you note here) is a pain, since the language syntax clearly favors non-static methods (for fluent APIs, as you refer to). This irregularity weakens type inference in fluent builder expressions, when the thing being built has type variables. But. Pointing out the inconsistency is not even remotely close to deciding on a fix. Making receiver types work consistently like other types would almost certainly require deep and destabilizing changes to the JLS. Figuring out all the required changes and their impacts (on zillions of lines of code) is a long-term research project, somewhere (IMO) in complexity between inner classes and generics. (Volunteers?) ? John From timo.kinnunen at gmail.com Fri Jun 19 21:49:24 2015 From: timo.kinnunen at gmail.com (=?utf-8?Q?Timo_Kinnunen?=) Date: Fri, 19 Jun 2015 21:49:24 +0000 Subject: =?utf-8?Q?Re:_Self-type?= In-Reply-To: <7A720ABF-12EF-4665-9C35-4FF851978026@oracle.com> References: <55809773.2853b40a.249d.ffff92ba@mx.google.com> <5580A8D0.3030206@oracle.com> <55819972.89acc20a.1aab.ffffa5a2@mx.google.com>, <7A720ABF-12EF-4665-9C35-4FF851978026@oracle.com> Message-ID: <5584c95c.ca53c20a.6b5a.ffffb526@mx.google.com> I have been thinking about how this feature could be implemented while remaining cost-conscious. At one end would be fully unified receiver and parameter types. This would be akin to fully unified receiver and other parameters in general and could require changing method descriptors to have them include the receiver type. And if we are willing to do that, we could add generic types into the descriptor too, while we?re at it. This would be very costly -- like you mention -- but in return we might find things like fully generic overloading, unified static-instance-method dispatch and on-demand reified generics emerging at the end. Actually, I find the question about the other end more interesting. Here the goal would be to make some currently ill-formed programs well-formed while preventing the opposite and to reuse parts of the JLS where appropriate rather than starting a rewrite. And the chosen feature should be a proper subset of the ideal solution that won?t preclude an ideal solution from being implemented at some point in the future. Here?s what I think could be implemented. First, if the language generated receiver type and the annotation-less consumer-supplied receiver types are identical, disable the feature to retain source compatibility. At method declaration sites, reuse type checks from return types on the customized receiver types as both should be covariant. So with additional bounds considered, the first declaration would turn out to mean the same as the second: default String join(List this, String delim) {} default , T2 extends Object & String> String join(THIS this, String delim) {} The currently ill-formed T2 extends Object & String syntax is there to keep array component types erased to Object in overridden methods in concrete subclasses, e.g. in an ArrayList. Next in call sites, reuse type checks for normal parameter types and incorporate type bounds from the receiver, but don?t consider the receiver itself as an additional parameter for overloading. So no overloading by just the receiver, but no backwards compatibility problem either. Not a big problem as you can use differing method names as a workaround. Next within the method body, have the customized receiver type hide the language generated receiver type, fully or perhaps partially. Here the typing weirdness of arrays rears its ugly head in a brand new context as the bound of the same type variable can change from one instance method to the next. I don?t think there?s a general solution to this problem because the subclass could be using a generic array with its component type erased or not erased, and unfortunately the type system can?t differentiate between these cases. The best that can be done here may be to provide a few knobs to force the component type into one or the other and have API developers deal with this as they come across it. Finally here?s what the JVM view of this might look like. As test-case I?m using a minimal ArrayList extends List implementation. I?m encoding the language generated receiver type into method names so I can choose which bridge methods to generate myself. First case, overriding a self-typed superclass method: public interface List extends Iterable { @Generated(value = { "consumer" }) > THIS add_List(THIS thiz, T t); } public class ArrayList implements List { protected @SuppressWarnings("unchecked") T[] array = (T[]) new Object[0]; @Generated(value = { "javac" }) public @Override > THIS add_List(THIS thiz, T t) { ArrayList thiz2 = (ArrayList) thiz; @SuppressWarnings("unchecked") THIS thiz3 = (THIS) add_ArrayList(thiz2, t); return thiz3; } @Generated(value = { "consumer" }) public > THIS add_ArrayList(THIS thiz, T t) { assert this == thiz; thiz.array = Arrays.copyOf(thiz.array, thiz.array.length + 1); thiz.array[thiz.array.length - 1] = t; return thiz; } } You can see the bridge method javac would be generating. This is similar to what you get currently when overriding and using a covariant return type. Second case, not overriding a self-typed superclass method: @Generated(value = { "consumer" }) default , T2 extends T> THIS addAll_List(THIS thiz, Iterable iterable) { assert this == thiz; THIS result = thiz; for(T2 item : iterable) { result = result.add_List(result, item); } return result; } Naively we could again generate the first bridge method in the subclass and then generate another bridge method to call the superclass implementation: @Generated(value = { "javac" }) public @Override , T2 extends T> THIS addAll_List(THIS thiz, Iterable iterable) { ArrayList thiz2 = addAll_ArrayList((ArrayList) thiz, iterable); @SuppressWarnings("unchecked") THIS thiz3 = (THIS) thiz2; return thiz3; } @Generated(value = { "javac" }) public , T2 extends T> THIS addAll_ArrayList(THIS thiz, Iterable iterable) { return List.super.addAll_List(thiz, iterable); } But all this really amounts to is the one unstated checkcast instruction in the second generated method. Instead we can adjust the callers to call the superclass method directly. Making use of the extra type bounds from the receiver we then add the checkcasts to the call sites. So we don?t need these two new bridge methods after all and we still get the covariant return. This sounds like a win-win to me. It seems that the essence of self-types and even more could be implemented with what amounts to relatively minor changes to generated code within a restricted number of contexts, i.e. pretty cheaply. I?ve put the complete version of this code I?ve been playing it here: https://gist.github.com/Overruler/5a9990c609b9ad0adfe7 -- Have a nice day, Timo. Sent from Windows Mail From: John Rose Sent: ?Thursday?, ?June? ?18?, ?2015 ?0?:?17 To: Timo Kinnunen Cc: Alex Buckley, jdk9-dev at openjdk.java.net On Jun 17, 2015, at 2:11 AM, Timo Kinnunen wrote: > It seems to me that the receiver type being treated as a special case from the types of the other parameters is an unnecessary inconsistency. I get what you are saying here, though I would say more carefully "some special rules for the receiver argument are unnecessarily different from the rules for other arguments". Receivers will always be a little different from other arguments, because dynamic method selection introduces type shifting when an overloading is invoked, but those differences could be more carefully localized, in the Java of some parallel universe. I would prefer we were in a world where the difference between "a.m(b)" and "m(a,b)" is little more than surface syntax, to be tweaked by tasteful library designers. Here's my pet peeve in this vein: Type inference rules treat receiver types as less coupled to constraints than other types; this is why some design patterns can only be written using Java statics, and not using instance methods?which (as you note here) is a pain, since the language syntax clearly favors non-static methods (for fluent APIs, as you refer to). This irregularity weakens type inference in fluent builder expressions, when the thing being built has type variables. But. Pointing out the inconsistency is not even remotely close to deciding on a fix. Making receiver types work consistently like other types would almost certainly require deep and destabilizing changes to the JLS. Figuring out all the required changes and their impacts (on zillions of lines of code) is a long-term research project, somewhere (IMO) in complexity between inner classes and generics. (Volunteers?) ? John From lana.steuck at oracle.com Sat Jun 20 18:12:33 2015 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Sat, 20 Jun 2015 11:12:33 -0700 (PDT) Subject: jdk9-b70: dev Message-ID: <201506201812.t5KICXr1024215@sc11152554.us.oracle.com> http://hg.openjdk.java.net/jdk9/jdk9/rev/eed77fcd7771 http://hg.openjdk.java.net/jdk9/jdk9/nashorn/rev/3379235149c0 http://hg.openjdk.java.net/jdk9/jdk9/langtools/rev/d732d6dfa727 http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/a7f731125b7f http://hg.openjdk.java.net/jdk9/jdk9/jaxws/rev/94084caa27a3 http://hg.openjdk.java.net/jdk9/jdk9/jaxp/rev/42180703e0a3 http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/8672e9264db3 http://hg.openjdk.java.net/jdk9/jdk9/corba/rev/e7cf01990ed3 --- All the fixes will be tested during promotion (no PIT testing at this point): List of all fixes: =================== JDK-8035568 client-libs [macosx] Cursor management unification JDK-8023794 client-libs [macosx] LCD Rendering hints seems not working without FRACTIONALMETRI JDK-8061831 client-libs [OGL] "java.lang.InternalError: not implemented yet" during the blit o JDK-8079255 client-libs [TEST_BUG] [macosx] Test closed/java/awt/Robot/RobotWheelTest/RobotWhe JDK-8015900 client-libs [TEST_BUG] ScrollbarMouseWheelTest failed on ubuntu 12 with unity and JDK-8079450 client-libs [TESTBUG] javax/swing/plaf/nimbus/8041642/bug8041642.java fails JDK-8081315 client-libs 8077982 giflib upgrade breaks system giflib builds with earlier versio JDK-8081886 client-libs CGGlyphImages.m no longer builds with xcode 4.x JDK-8081019 client-libs Check peer to null in CPlatformWindow.checkZoom() method JDK-8078279 client-libs Closed tests should not use getPeer method JDK-8079652 client-libs Could not enable D3D pipeline JDK-8078606 client-libs Deadlock in awt clipboard JDK-8077409 client-libs Drawing deviates when validate() is invoked on java.awt.ScrollPane JDK-8068886 client-libs IDEA IntelliJ crashes in objc_msgSend when an accessibility tool is e JDK-8015368 client-libs javax/print/attribute/URLPDFPrinting.java fails on solaris with java.n JDK-8041470 client-libs JButtons stay pressed after they have lost focus if you use the mouse JDK-8081313 client-libs MultipleDocumentHandling.java: tidy warnings JDK-8085910 client-libs OGL text renderer: gamma lut cleanup JDK-8077036 client-libs swing docs: fix some tidy warnings JDK-8081447 client-libs System JPEG builds include in-tree jpeglib.h, resulting in build failu JDK-8080086 client-libs Test javax/imageio/plugins/png/ItxtUtf8Test.java fails on Linux with JDK-8076312 client-libs The behavior of the javax.swing.SwingContainer.delegate contradicts sp JDK-8087304 core-libs (ch) java/nio/channels/DatagramChannel/EmptyBuffer.java received 4 tim JDK-8081843 core-libs (fs) FileStore.getTotalSpace returns unexpected results with >2TB file JDK-8054304 core-libs Clarify treatment of bounds in j.l.r.Annotated{WildcardType,TypeVariab JDK-8098808 core-libs Convert Scope from interface to class JDK-8098546 core-libs eval within a 'with' leaks definitions into global scope JDK-8087288 core-libs File.get{Free,Total,Usable}Space may return unexpected results with >2 JDK-8098578 core-libs Global scope is not accessible with indirect load call JDK-8098790 core-libs Improve cross references and wording in java.lang.reflect.AnnotatedFoo JDK-8087211 core-libs Indirect evals should be strict with -strict option JDK-8086208 core-libs java/lang/ProcessHandle/OnExitTest.java: IllegalThreadStateException: JDK-8085978 core-libs LinkedTransferQueue.spliterator can report LTQ.Node object, not T JDK-8080933 core-libs LogManager.demandSystemLogger should accept a 'caller' argument. JDK-8085879 core-libs Mark intermittently failing: java/util/Arrays/ParallelPrefix.java JDK-8117883 core-libs nasgen prototype, instance member count calculation is wrong JDK-8098847 core-libs obj."prop" and obj.'prop' should result in SyntaxError JDK-8087312 core-libs PropertyMapWrapper.equals should compare className JDK-8081412 core-libs Remove MHIllegalAccess.java from the problem list JDK-8086052 core-libs Script evaluation should not return last function declaration JDK-8067005 core-libs Several java/lang/invoke tests fail due to exhausted code cache JDK-8098807 core-libs Strict eval throws ClassCastException with large scripts JDK-8062904 core-libs TEST_BUG: Tests java/lang/invoke/LFCaching fail when run with -Xcomp o JDK-8055464 deploy Add a URL scheme handler to reliably launch .jnlp files - java part JDK-8080955 deploy embedded_jnlp param requires also code or jnlp_href param or applet ar JDK-8080123 deploy StringIndexOutOfBoundsException in CertUtils.checkWildcardDomain JDK-8051030 deploy Web Start applet process fails to exit JDK-8080607 deploy Web Start does not honor height / width % values JDK-8087120 hotspot [GCC5] java.lang.StackOverflowError on Zero JVM initialization on non JDK-8081823 hotspot C2 performs unsigned comparison against -1 JDK-8078866 hotspot compiler/eliminateAutobox/6934604/TestIntBoxing.java assert(p_f->Opcod JDK-8085832 hotspot Optimize main and post loop out when pre loop is found empty JDK-8081778 hotspot Use Intel x64 CPU instructions for RSA acceleration JDK-8087208 infrastructure Add devkit creation script for windows JDK-8081295 infrastructure Build failed with GCC 5.1.1 JDK-8098579 infrastructure Remove non-existent javax.tools.annotation package from CORE_PKGS.gmk JDK-8087193 infrastructure Support building with devkits on Macosx JDK-8081423 install Improve naming consistency in make/installer/bundles/macosx/Makefile JDK-8075409 install jre8-40 fails to install on SuSE 11.3 JDK-8086029 other-libs Fix doclint reference warnings in org.omg.CORBA JDK-8060103 security-libs CheckBlacklistedCerts.java thinks its openjdk build JDK-8072692 security-libs Improve performance of SecurityManager.checkPackageAccess JDK-6826789 security-libs SecureClassLoader should not use CodeSource URLs as HashMap keys JDK-8064890 security-libs SecureClassLoader should use a ConcurrentHashMap JDK-8080826 tools Group 15: golden files for tests in tools/javac/generics/type* dirs JDK-8098850 tools Remove remaining native2ascii resource files and man pages JDK-8074346 tools type annotation on a qualified type causes spurious 'cannot find symbo JDK-8087283 xml Add support for the XML Signature here() function to the JDK XPath imp JDK-8080907 xml Develop test for Xerces Update: XML Schema Validation From erik.helin at oracle.com Mon Jun 22 14:14:05 2015 From: erik.helin at oracle.com (Erik Helin) Date: Mon, 22 Jun 2015 16:14:05 +0200 Subject: CFV: New JDK 9 Reviewer: Jesper Wilhelmsson Message-ID: <20150622141405.GB3266@ehelin.jrpg.bea.com> I hereby nominate Jesper Wilhelmsson to JDK 9 Reviewer. Jesper is a member of the HotSpot GC team and has contributed 51 patches to HotSpot [3]. Jesper has also been the gatekeeper for the jdk9/hs-gc repo for 8 months and is currently the gatekeeper for the combined gc and rt repository. Votes are due by July 6, 2015, 16:15 CEST. Only current JDK 9 Reviewers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Three-Vote Consensus voting instructions, see [2]. Erik Helin [1] http://openjdk.java.net/census [2] http://openjdk.java.net/projects/#reviewer-vote [3] List of patches: 8077842: Remove the level parameter passed around in GenCollectedHeap 8077315: Build failure on OSX after compiler upgrade 8077302: src/share/vm/oops/instanceRefKlass.inline.hpp has a doubble /* 8076267: Remove n_gens() 8075635: Remove GenerationSpec array 8076012: SA don't support flags of type size_t 8074459: Flags handling memory sizes should be of type size_t 8057632: Remove auxiliary code used to handle the generations array 8071335: gc/TestSmallHeap.java throw OOM 8073883: serviceability/dcmd/gc/RunGCTest.java should not run with -XX:+ExplicitGCInvokesConcurrent 8061802: REDO - Remove the generations array 8072688: Description of flag ExplicitGCInvokesConcurrent should mention G1 as well 8067947: Regression test for JDK-6522873 6522873: Java not print "Unrecognized option" when it is invalid option. 8065305: Make it possible to extend the G1CollectorPolicy 8062836: BACKOUT - Parallelize clearing the next mark bitmap 8061805: BACKOUT - Remove the generations array 8055702: Remove the generations array 8056056: Remove unnecessary inclusion of HS_ALT_MAKE from solaris Makefile 8055744: 8u-dev nightly solaris builds failed on 08/20 8055006: Store original value of Min/MaxHeapFreeRatio 8046715: Add a way to verify an extended set of command line options 8042298: Remove the names gen0 and gen1 from the GC code 8026396: Remove information duplication in the collector policy 8027643: Merge GenCollectorPolicy and TwoGenerationCollectorPolicy 8039089: List verification enabled in product builds 8036025: Sort the freelist in order to shrink the heap 8023899: Typo in TraceCPUTime message 8035822: Unable to test minimalVM 8026849: Fix typos in the GC code, part 2 8028391: Make the Min/MaxHeapFreeRatio flags manageable 8025856: Fix typos in the GC code 8028093: Initial young size is smaller than minimum young size 8027911: Assertion in the collector policy when running gc/arguments/TestMaxNewSize.java 8016309: assert(eden_size > 0 && survivor_size > 0) failed: just checking 8026853: Prepare GC code for collector policy regression fix 8026852: Use restricted_align_down in collector policy code 8026851: Remove unnecessary code in GenRemSet 8023643: G1 assert failed when NewSize was specified greater than MaxNewSize 8024776: Max/MinHeapFreeRatio descriptions should be more precise 8025854: Use "young gen" instead of "eden" 8025852: Remove unnecessary setters in collector policy classes 8025853: Remove unnecessary uses of GenerationSizer 8025855: Simplify GenRemSet code slightly 8024884: Test name changed, test list not updated 8008314: Unimplemented() Atomic::load breaks the applications 8006432: Ratio flags should be unsigned 8005849: JEP 167: Event-Based JVM Tracing 6348447: Specifying -XX:OldSize crashes 64-bit VMs 8000351: Tenuring threshold should be unsigned 6820066: Check that -XX:ParGCArrayScanChunk has a value larger than zero. From erik.helin at oracle.com Mon Jun 22 14:18:11 2015 From: erik.helin at oracle.com (Erik Helin) Date: Mon, 22 Jun 2015 16:18:11 +0200 Subject: CFV: New JDK 9 Reviewer: Jesper Wilhelmsson In-Reply-To: <20150622141405.GB3266@ehelin.jrpg.bea.com> References: <20150622141405.GB3266@ehelin.jrpg.bea.com> Message-ID: <20150622141811.GC3266@ehelin.jrpg.bea.com> Vote: yes Erik On 2015-06-22, Erik Helin wrote: > I hereby nominate Jesper Wilhelmsson to JDK 9 Reviewer. > > Jesper is a member of the HotSpot GC team and has contributed 51 patches > to HotSpot [3]. Jesper has also been the gatekeeper for the jdk9/hs-gc > repo for 8 months and is currently the gatekeeper for the combined gc > and rt repository. > > Votes are due by July 6, 2015, 16:15 CEST. > > Only current JDK 9 Reviewers [1] are eligible to vote > on this nomination. Votes must be cast in the open by replying > to this mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Erik Helin > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > [3] List of patches: > 8077842: Remove the level parameter passed around in GenCollectedHeap > 8077315: Build failure on OSX after compiler upgrade > 8077302: src/share/vm/oops/instanceRefKlass.inline.hpp has a doubble /* > 8076267: Remove n_gens() > 8075635: Remove GenerationSpec array > 8076012: SA don't support flags of type size_t > 8074459: Flags handling memory sizes should be of type size_t > 8057632: Remove auxiliary code used to handle the generations array > 8071335: gc/TestSmallHeap.java throw OOM > 8073883: serviceability/dcmd/gc/RunGCTest.java should not run with -XX:+ExplicitGCInvokesConcurrent > 8061802: REDO - Remove the generations array > 8072688: Description of flag ExplicitGCInvokesConcurrent should mention G1 as well > 8067947: Regression test for JDK-6522873 > 6522873: Java not print "Unrecognized option" when it is invalid option. > 8065305: Make it possible to extend the G1CollectorPolicy > 8062836: BACKOUT - Parallelize clearing the next mark bitmap > 8061805: BACKOUT - Remove the generations array > 8055702: Remove the generations array > 8056056: Remove unnecessary inclusion of HS_ALT_MAKE from solaris Makefile > 8055744: 8u-dev nightly solaris builds failed on 08/20 > 8055006: Store original value of Min/MaxHeapFreeRatio > 8046715: Add a way to verify an extended set of command line options > 8042298: Remove the names gen0 and gen1 from the GC code > 8026396: Remove information duplication in the collector policy > 8027643: Merge GenCollectorPolicy and TwoGenerationCollectorPolicy > 8039089: List verification enabled in product builds > 8036025: Sort the freelist in order to shrink the heap > 8023899: Typo in TraceCPUTime message > 8035822: Unable to test minimalVM > 8026849: Fix typos in the GC code, part 2 > 8028391: Make the Min/MaxHeapFreeRatio flags manageable > 8025856: Fix typos in the GC code > 8028093: Initial young size is smaller than minimum young size > 8027911: Assertion in the collector policy when running gc/arguments/TestMaxNewSize.java > 8016309: assert(eden_size > 0 && survivor_size > 0) failed: just checking > 8026853: Prepare GC code for collector policy regression fix > 8026852: Use restricted_align_down in collector policy code > 8026851: Remove unnecessary code in GenRemSet > 8023643: G1 assert failed when NewSize was specified greater than MaxNewSize > 8024776: Max/MinHeapFreeRatio descriptions should be more precise > 8025854: Use "young gen" instead of "eden" > 8025852: Remove unnecessary setters in collector policy classes > 8025853: Remove unnecessary uses of GenerationSizer > 8025855: Simplify GenRemSet code slightly > 8024884: Test name changed, test list not updated > 8008314: Unimplemented() Atomic::load breaks the applications > 8006432: Ratio flags should be unsigned > 8005849: JEP 167: Event-Based JVM Tracing > 6348447: Specifying -XX:OldSize crashes 64-bit VMs > 8000351: Tenuring threshold should be unsigned > 6820066: Check that -XX:ParGCArrayScanChunk has a value larger than zero. From volker.simonis at gmail.com Mon Jun 22 14:22:12 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 22 Jun 2015 16:22:12 +0200 Subject: CFV: New JDK 9 Reviewer: Jesper Wilhelmsson In-Reply-To: <20150622141405.GB3266@ehelin.jrpg.bea.com> References: <20150622141405.GB3266@ehelin.jrpg.bea.com> Message-ID: Vote: yes On Mon, Jun 22, 2015 at 4:14 PM, Erik Helin wrote: > I hereby nominate Jesper Wilhelmsson to JDK 9 Reviewer. > > Jesper is a member of the HotSpot GC team and has contributed 51 patches > to HotSpot [3]. Jesper has also been the gatekeeper for the jdk9/hs-gc > repo for 8 months and is currently the gatekeeper for the combined gc > and rt repository. > > Votes are due by July 6, 2015, 16:15 CEST. > > Only current JDK 9 Reviewers [1] are eligible to vote > on this nomination. Votes must be cast in the open by replying > to this mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Erik Helin > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > [3] List of patches: > 8077842: Remove the level parameter passed around in GenCollectedHeap > 8077315: Build failure on OSX after compiler upgrade > 8077302: src/share/vm/oops/instanceRefKlass.inline.hpp has a doubble /* > 8076267: Remove n_gens() > 8075635: Remove GenerationSpec array > 8076012: SA don't support flags of type size_t > 8074459: Flags handling memory sizes should be of type size_t > 8057632: Remove auxiliary code used to handle the generations array > 8071335: gc/TestSmallHeap.java throw OOM > 8073883: serviceability/dcmd/gc/RunGCTest.java should not run with -XX:+ExplicitGCInvokesConcurrent > 8061802: REDO - Remove the generations array > 8072688: Description of flag ExplicitGCInvokesConcurrent should mention G1 as well > 8067947: Regression test for JDK-6522873 > 6522873: Java not print "Unrecognized option" when it is invalid option. > 8065305: Make it possible to extend the G1CollectorPolicy > 8062836: BACKOUT - Parallelize clearing the next mark bitmap > 8061805: BACKOUT - Remove the generations array > 8055702: Remove the generations array > 8056056: Remove unnecessary inclusion of HS_ALT_MAKE from solaris Makefile > 8055744: 8u-dev nightly solaris builds failed on 08/20 > 8055006: Store original value of Min/MaxHeapFreeRatio > 8046715: Add a way to verify an extended set of command line options > 8042298: Remove the names gen0 and gen1 from the GC code > 8026396: Remove information duplication in the collector policy > 8027643: Merge GenCollectorPolicy and TwoGenerationCollectorPolicy > 8039089: List verification enabled in product builds > 8036025: Sort the freelist in order to shrink the heap > 8023899: Typo in TraceCPUTime message > 8035822: Unable to test minimalVM > 8026849: Fix typos in the GC code, part 2 > 8028391: Make the Min/MaxHeapFreeRatio flags manageable > 8025856: Fix typos in the GC code > 8028093: Initial young size is smaller than minimum young size > 8027911: Assertion in the collector policy when running gc/arguments/TestMaxNewSize.java > 8016309: assert(eden_size > 0 && survivor_size > 0) failed: just checking > 8026853: Prepare GC code for collector policy regression fix > 8026852: Use restricted_align_down in collector policy code > 8026851: Remove unnecessary code in GenRemSet > 8023643: G1 assert failed when NewSize was specified greater than MaxNewSize > 8024776: Max/MinHeapFreeRatio descriptions should be more precise > 8025854: Use "young gen" instead of "eden" > 8025852: Remove unnecessary setters in collector policy classes > 8025853: Remove unnecessary uses of GenerationSizer > 8025855: Simplify GenRemSet code slightly > 8024884: Test name changed, test list not updated > 8008314: Unimplemented() Atomic::load breaks the applications > 8006432: Ratio flags should be unsigned > 8005849: JEP 167: Event-Based JVM Tracing > 6348447: Specifying -XX:OldSize crashes 64-bit VMs > 8000351: Tenuring threshold should be unsigned > 6820066: Check that -XX:ParGCArrayScanChunk has a value larger than zero. From jaroslav.bachorik at oracle.com Mon Jun 22 14:23:34 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Mon, 22 Jun 2015 16:23:34 +0200 Subject: CFV: New JDK 9 Reviewer: Jesper Wilhelmsson In-Reply-To: <20150622141405.GB3266@ehelin.jrpg.bea.com> References: <20150622141405.GB3266@ehelin.jrpg.bea.com> Message-ID: <55881A66.1010201@oracle.com> Vote: yes -JB- On 22.6.2015 16:14, Erik Helin wrote: > I hereby nominate Jesper Wilhelmsson to JDK 9 Reviewer. > > Jesper is a member of the HotSpot GC team and has contributed 51 patches > to HotSpot [3]. Jesper has also been the gatekeeper for the jdk9/hs-gc > repo for 8 months and is currently the gatekeeper for the combined gc > and rt repository. > > Votes are due by July 6, 2015, 16:15 CEST. > > Only current JDK 9 Reviewers [1] are eligible to vote > on this nomination. Votes must be cast in the open by replying > to this mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Erik Helin > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > [3] List of patches: > 8077842: Remove the level parameter passed around in GenCollectedHeap > 8077315: Build failure on OSX after compiler upgrade > 8077302: src/share/vm/oops/instanceRefKlass.inline.hpp has a doubble /* > 8076267: Remove n_gens() > 8075635: Remove GenerationSpec array > 8076012: SA don't support flags of type size_t > 8074459: Flags handling memory sizes should be of type size_t > 8057632: Remove auxiliary code used to handle the generations array > 8071335: gc/TestSmallHeap.java throw OOM > 8073883: serviceability/dcmd/gc/RunGCTest.java should not run with -XX:+ExplicitGCInvokesConcurrent > 8061802: REDO - Remove the generations array > 8072688: Description of flag ExplicitGCInvokesConcurrent should mention G1 as well > 8067947: Regression test for JDK-6522873 > 6522873: Java not print "Unrecognized option" when it is invalid option. > 8065305: Make it possible to extend the G1CollectorPolicy > 8062836: BACKOUT - Parallelize clearing the next mark bitmap > 8061805: BACKOUT - Remove the generations array > 8055702: Remove the generations array > 8056056: Remove unnecessary inclusion of HS_ALT_MAKE from solaris Makefile > 8055744: 8u-dev nightly solaris builds failed on 08/20 > 8055006: Store original value of Min/MaxHeapFreeRatio > 8046715: Add a way to verify an extended set of command line options > 8042298: Remove the names gen0 and gen1 from the GC code > 8026396: Remove information duplication in the collector policy > 8027643: Merge GenCollectorPolicy and TwoGenerationCollectorPolicy > 8039089: List verification enabled in product builds > 8036025: Sort the freelist in order to shrink the heap > 8023899: Typo in TraceCPUTime message > 8035822: Unable to test minimalVM > 8026849: Fix typos in the GC code, part 2 > 8028391: Make the Min/MaxHeapFreeRatio flags manageable > 8025856: Fix typos in the GC code > 8028093: Initial young size is smaller than minimum young size > 8027911: Assertion in the collector policy when running gc/arguments/TestMaxNewSize.java > 8016309: assert(eden_size > 0 && survivor_size > 0) failed: just checking > 8026853: Prepare GC code for collector policy regression fix > 8026852: Use restricted_align_down in collector policy code > 8026851: Remove unnecessary code in GenRemSet > 8023643: G1 assert failed when NewSize was specified greater than MaxNewSize > 8024776: Max/MinHeapFreeRatio descriptions should be more precise > 8025854: Use "young gen" instead of "eden" > 8025852: Remove unnecessary setters in collector policy classes > 8025853: Remove unnecessary uses of GenerationSizer > 8025855: Simplify GenRemSet code slightly > 8024884: Test name changed, test list not updated > 8008314: Unimplemented() Atomic::load breaks the applications > 8006432: Ratio flags should be unsigned > 8005849: JEP 167: Event-Based JVM Tracing > 6348447: Specifying -XX:OldSize crashes 64-bit VMs > 8000351: Tenuring threshold should be unsigned > 6820066: Check that -XX:ParGCArrayScanChunk has a value larger than zero. > From daniel.daugherty at oracle.com Mon Jun 22 14:27:41 2015 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 22 Jun 2015 08:27:41 -0600 Subject: CFV: New JDK 9 Reviewer: Jesper Wilhelmsson In-Reply-To: <20150622141405.GB3266@ehelin.jrpg.bea.com> References: <20150622141405.GB3266@ehelin.jrpg.bea.com> Message-ID: <55881B5D.5010807@oracle.com> Vote: yes Dan On 6/22/15 8:14 AM, Erik Helin wrote: > I hereby nominate Jesper Wilhelmsson to JDK 9 Reviewer. > > Jesper is a member of the HotSpot GC team and has contributed 51 patches > to HotSpot [3]. Jesper has also been the gatekeeper for the jdk9/hs-gc > repo for 8 months and is currently the gatekeeper for the combined gc > and rt repository. > > Votes are due by July 6, 2015, 16:15 CEST. > > Only current JDK 9 Reviewers [1] are eligible to vote > on this nomination. Votes must be cast in the open by replying > to this mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Erik Helin > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > [3] List of patches: > 8077842: Remove the level parameter passed around in GenCollectedHeap > 8077315: Build failure on OSX after compiler upgrade > 8077302: src/share/vm/oops/instanceRefKlass.inline.hpp has a doubble /* > 8076267: Remove n_gens() > 8075635: Remove GenerationSpec array > 8076012: SA don't support flags of type size_t > 8074459: Flags handling memory sizes should be of type size_t > 8057632: Remove auxiliary code used to handle the generations array > 8071335: gc/TestSmallHeap.java throw OOM > 8073883: serviceability/dcmd/gc/RunGCTest.java should not run with -XX:+ExplicitGCInvokesConcurrent > 8061802: REDO - Remove the generations array > 8072688: Description of flag ExplicitGCInvokesConcurrent should mention G1 as well > 8067947: Regression test for JDK-6522873 > 6522873: Java not print "Unrecognized option" when it is invalid option. > 8065305: Make it possible to extend the G1CollectorPolicy > 8062836: BACKOUT - Parallelize clearing the next mark bitmap > 8061805: BACKOUT - Remove the generations array > 8055702: Remove the generations array > 8056056: Remove unnecessary inclusion of HS_ALT_MAKE from solaris Makefile > 8055744: 8u-dev nightly solaris builds failed on 08/20 > 8055006: Store original value of Min/MaxHeapFreeRatio > 8046715: Add a way to verify an extended set of command line options > 8042298: Remove the names gen0 and gen1 from the GC code > 8026396: Remove information duplication in the collector policy > 8027643: Merge GenCollectorPolicy and TwoGenerationCollectorPolicy > 8039089: List verification enabled in product builds > 8036025: Sort the freelist in order to shrink the heap > 8023899: Typo in TraceCPUTime message > 8035822: Unable to test minimalVM > 8026849: Fix typos in the GC code, part 2 > 8028391: Make the Min/MaxHeapFreeRatio flags manageable > 8025856: Fix typos in the GC code > 8028093: Initial young size is smaller than minimum young size > 8027911: Assertion in the collector policy when running gc/arguments/TestMaxNewSize.java > 8016309: assert(eden_size > 0 && survivor_size > 0) failed: just checking > 8026853: Prepare GC code for collector policy regression fix > 8026852: Use restricted_align_down in collector policy code > 8026851: Remove unnecessary code in GenRemSet > 8023643: G1 assert failed when NewSize was specified greater than MaxNewSize > 8024776: Max/MinHeapFreeRatio descriptions should be more precise > 8025854: Use "young gen" instead of "eden" > 8025852: Remove unnecessary setters in collector policy classes > 8025853: Remove unnecessary uses of GenerationSizer > 8025855: Simplify GenRemSet code slightly > 8024884: Test name changed, test list not updated > 8008314: Unimplemented() Atomic::load breaks the applications > 8006432: Ratio flags should be unsigned > 8005849: JEP 167: Event-Based JVM Tracing > 6348447: Specifying -XX:OldSize crashes 64-bit VMs > 8000351: Tenuring threshold should be unsigned > 6820066: Check that -XX:ParGCArrayScanChunk has a value larger than zero. > > From vladimir.x.ivanov at oracle.com Mon Jun 22 14:32:22 2015 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Mon, 22 Jun 2015 17:32:22 +0300 Subject: CFV: New JDK 9 Reviewer: Jesper Wilhelmsson In-Reply-To: <20150622141405.GB3266@ehelin.jrpg.bea.com> References: <20150622141405.GB3266@ehelin.jrpg.bea.com> Message-ID: <55881C76.8030609@oracle.com> Vote: yes Best regards, Vladimir Ivanov On 6/22/15 5:14 PM, Erik Helin wrote: > I hereby nominate Jesper Wilhelmsson to JDK 9 Reviewer. > > Jesper is a member of the HotSpot GC team and has contributed 51 patches > to HotSpot [3]. Jesper has also been the gatekeeper for the jdk9/hs-gc > repo for 8 months and is currently the gatekeeper for the combined gc > and rt repository. > > Votes are due by July 6, 2015, 16:15 CEST. > > Only current JDK 9 Reviewers [1] are eligible to vote > on this nomination. Votes must be cast in the open by replying > to this mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Erik Helin > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > [3] List of patches: > 8077842: Remove the level parameter passed around in GenCollectedHeap > 8077315: Build failure on OSX after compiler upgrade > 8077302: src/share/vm/oops/instanceRefKlass.inline.hpp has a doubble /* > 8076267: Remove n_gens() > 8075635: Remove GenerationSpec array > 8076012: SA don't support flags of type size_t > 8074459: Flags handling memory sizes should be of type size_t > 8057632: Remove auxiliary code used to handle the generations array > 8071335: gc/TestSmallHeap.java throw OOM > 8073883: serviceability/dcmd/gc/RunGCTest.java should not run with -XX:+ExplicitGCInvokesConcurrent > 8061802: REDO - Remove the generations array > 8072688: Description of flag ExplicitGCInvokesConcurrent should mention G1 as well > 8067947: Regression test for JDK-6522873 > 6522873: Java not print "Unrecognized option" when it is invalid option. > 8065305: Make it possible to extend the G1CollectorPolicy > 8062836: BACKOUT - Parallelize clearing the next mark bitmap > 8061805: BACKOUT - Remove the generations array > 8055702: Remove the generations array > 8056056: Remove unnecessary inclusion of HS_ALT_MAKE from solaris Makefile > 8055744: 8u-dev nightly solaris builds failed on 08/20 > 8055006: Store original value of Min/MaxHeapFreeRatio > 8046715: Add a way to verify an extended set of command line options > 8042298: Remove the names gen0 and gen1 from the GC code > 8026396: Remove information duplication in the collector policy > 8027643: Merge GenCollectorPolicy and TwoGenerationCollectorPolicy > 8039089: List verification enabled in product builds > 8036025: Sort the freelist in order to shrink the heap > 8023899: Typo in TraceCPUTime message > 8035822: Unable to test minimalVM > 8026849: Fix typos in the GC code, part 2 > 8028391: Make the Min/MaxHeapFreeRatio flags manageable > 8025856: Fix typos in the GC code > 8028093: Initial young size is smaller than minimum young size > 8027911: Assertion in the collector policy when running gc/arguments/TestMaxNewSize.java > 8016309: assert(eden_size > 0 && survivor_size > 0) failed: just checking > 8026853: Prepare GC code for collector policy regression fix > 8026852: Use restricted_align_down in collector policy code > 8026851: Remove unnecessary code in GenRemSet > 8023643: G1 assert failed when NewSize was specified greater than MaxNewSize > 8024776: Max/MinHeapFreeRatio descriptions should be more precise > 8025854: Use "young gen" instead of "eden" > 8025852: Remove unnecessary setters in collector policy classes > 8025853: Remove unnecessary uses of GenerationSizer > 8025855: Simplify GenRemSet code slightly > 8024884: Test name changed, test list not updated > 8008314: Unimplemented() Atomic::load breaks the applications > 8006432: Ratio flags should be unsigned > 8005849: JEP 167: Event-Based JVM Tracing > 6348447: Specifying -XX:OldSize crashes 64-bit VMs > 8000351: Tenuring threshold should be unsigned > 6820066: Check that -XX:ParGCArrayScanChunk has a value larger than zero. > From mikael.gerdin at oracle.com Mon Jun 22 14:40:47 2015 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Mon, 22 Jun 2015 16:40:47 +0200 Subject: CFV: New JDK 9 Reviewer: Jesper Wilhelmsson In-Reply-To: <20150622141405.GB3266@ehelin.jrpg.bea.com> References: <20150622141405.GB3266@ehelin.jrpg.bea.com> Message-ID: <55881E6F.8020900@oracle.com> Vote: yes On 2015-06-22 16:14, Erik Helin wrote: > I hereby nominate Jesper Wilhelmsson to JDK 9 Reviewer. > > Jesper is a member of the HotSpot GC team and has contributed 51 patches > to HotSpot [3]. Jesper has also been the gatekeeper for the jdk9/hs-gc > repo for 8 months and is currently the gatekeeper for the combined gc > and rt repository. > > Votes are due by July 6, 2015, 16:15 CEST. > > Only current JDK 9 Reviewers [1] are eligible to vote > on this nomination. Votes must be cast in the open by replying > to this mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Erik Helin > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > [3] List of patches: > 8077842: Remove the level parameter passed around in GenCollectedHeap > 8077315: Build failure on OSX after compiler upgrade > 8077302: src/share/vm/oops/instanceRefKlass.inline.hpp has a doubble /* > 8076267: Remove n_gens() > 8075635: Remove GenerationSpec array > 8076012: SA don't support flags of type size_t > 8074459: Flags handling memory sizes should be of type size_t > 8057632: Remove auxiliary code used to handle the generations array > 8071335: gc/TestSmallHeap.java throw OOM > 8073883: serviceability/dcmd/gc/RunGCTest.java should not run with -XX:+ExplicitGCInvokesConcurrent > 8061802: REDO - Remove the generations array > 8072688: Description of flag ExplicitGCInvokesConcurrent should mention G1 as well > 8067947: Regression test for JDK-6522873 > 6522873: Java not print "Unrecognized option" when it is invalid option. > 8065305: Make it possible to extend the G1CollectorPolicy > 8062836: BACKOUT - Parallelize clearing the next mark bitmap > 8061805: BACKOUT - Remove the generations array > 8055702: Remove the generations array > 8056056: Remove unnecessary inclusion of HS_ALT_MAKE from solaris Makefile > 8055744: 8u-dev nightly solaris builds failed on 08/20 > 8055006: Store original value of Min/MaxHeapFreeRatio > 8046715: Add a way to verify an extended set of command line options > 8042298: Remove the names gen0 and gen1 from the GC code > 8026396: Remove information duplication in the collector policy > 8027643: Merge GenCollectorPolicy and TwoGenerationCollectorPolicy > 8039089: List verification enabled in product builds > 8036025: Sort the freelist in order to shrink the heap > 8023899: Typo in TraceCPUTime message > 8035822: Unable to test minimalVM > 8026849: Fix typos in the GC code, part 2 > 8028391: Make the Min/MaxHeapFreeRatio flags manageable > 8025856: Fix typos in the GC code > 8028093: Initial young size is smaller than minimum young size > 8027911: Assertion in the collector policy when running gc/arguments/TestMaxNewSize.java > 8016309: assert(eden_size > 0 && survivor_size > 0) failed: just checking > 8026853: Prepare GC code for collector policy regression fix > 8026852: Use restricted_align_down in collector policy code > 8026851: Remove unnecessary code in GenRemSet > 8023643: G1 assert failed when NewSize was specified greater than MaxNewSize > 8024776: Max/MinHeapFreeRatio descriptions should be more precise > 8025854: Use "young gen" instead of "eden" > 8025852: Remove unnecessary setters in collector policy classes > 8025853: Remove unnecessary uses of GenerationSizer > 8025855: Simplify GenRemSet code slightly > 8024884: Test name changed, test list not updated > 8008314: Unimplemented() Atomic::load breaks the applications > 8006432: Ratio flags should be unsigned > 8005849: JEP 167: Event-Based JVM Tracing > 6348447: Specifying -XX:OldSize crashes 64-bit VMs > 8000351: Tenuring threshold should be unsigned > 6820066: Check that -XX:ParGCArrayScanChunk has a value larger than zero. > From vladimir.kozlov at oracle.com Mon Jun 22 14:52:03 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 22 Jun 2015 07:52:03 -0700 Subject: CFV: New JDK 9 Reviewer: Jesper Wilhelmsson In-Reply-To: <20150622141405.GB3266@ehelin.jrpg.bea.com> References: <20150622141405.GB3266@ehelin.jrpg.bea.com> Message-ID: <55882113.4000702@oracle.com> Vote: yes Vladimir On 6/22/15 7:14 AM, Erik Helin wrote: > I hereby nominate Jesper Wilhelmsson to JDK 9 Reviewer. > > Jesper is a member of the HotSpot GC team and has contributed 51 patches > to HotSpot [3]. Jesper has also been the gatekeeper for the jdk9/hs-gc > repo for 8 months and is currently the gatekeeper for the combined gc > and rt repository. > > Votes are due by July 6, 2015, 16:15 CEST. > > Only current JDK 9 Reviewers [1] are eligible to vote > on this nomination. Votes must be cast in the open by replying > to this mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Erik Helin > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > [3] List of patches: > 8077842: Remove the level parameter passed around in GenCollectedHeap > 8077315: Build failure on OSX after compiler upgrade > 8077302: src/share/vm/oops/instanceRefKlass.inline.hpp has a doubble /* > 8076267: Remove n_gens() > 8075635: Remove GenerationSpec array > 8076012: SA don't support flags of type size_t > 8074459: Flags handling memory sizes should be of type size_t > 8057632: Remove auxiliary code used to handle the generations array > 8071335: gc/TestSmallHeap.java throw OOM > 8073883: serviceability/dcmd/gc/RunGCTest.java should not run with -XX:+ExplicitGCInvokesConcurrent > 8061802: REDO - Remove the generations array > 8072688: Description of flag ExplicitGCInvokesConcurrent should mention G1 as well > 8067947: Regression test for JDK-6522873 > 6522873: Java not print "Unrecognized option" when it is invalid option. > 8065305: Make it possible to extend the G1CollectorPolicy > 8062836: BACKOUT - Parallelize clearing the next mark bitmap > 8061805: BACKOUT - Remove the generations array > 8055702: Remove the generations array > 8056056: Remove unnecessary inclusion of HS_ALT_MAKE from solaris Makefile > 8055744: 8u-dev nightly solaris builds failed on 08/20 > 8055006: Store original value of Min/MaxHeapFreeRatio > 8046715: Add a way to verify an extended set of command line options > 8042298: Remove the names gen0 and gen1 from the GC code > 8026396: Remove information duplication in the collector policy > 8027643: Merge GenCollectorPolicy and TwoGenerationCollectorPolicy > 8039089: List verification enabled in product builds > 8036025: Sort the freelist in order to shrink the heap > 8023899: Typo in TraceCPUTime message > 8035822: Unable to test minimalVM > 8026849: Fix typos in the GC code, part 2 > 8028391: Make the Min/MaxHeapFreeRatio flags manageable > 8025856: Fix typos in the GC code > 8028093: Initial young size is smaller than minimum young size > 8027911: Assertion in the collector policy when running gc/arguments/TestMaxNewSize.java > 8016309: assert(eden_size > 0 && survivor_size > 0) failed: just checking > 8026853: Prepare GC code for collector policy regression fix > 8026852: Use restricted_align_down in collector policy code > 8026851: Remove unnecessary code in GenRemSet > 8023643: G1 assert failed when NewSize was specified greater than MaxNewSize > 8024776: Max/MinHeapFreeRatio descriptions should be more precise > 8025854: Use "young gen" instead of "eden" > 8025852: Remove unnecessary setters in collector policy classes > 8025853: Remove unnecessary uses of GenerationSizer > 8025855: Simplify GenRemSet code slightly > 8024884: Test name changed, test list not updated > 8008314: Unimplemented() Atomic::load breaks the applications > 8006432: Ratio flags should be unsigned > 8005849: JEP 167: Event-Based JVM Tracing > 6348447: Specifying -XX:OldSize crashes 64-bit VMs > 8000351: Tenuring threshold should be unsigned > 6820066: Check that -XX:ParGCArrayScanChunk has a value larger than zero. > From harold.seigel at oracle.com Mon Jun 22 17:06:14 2015 From: harold.seigel at oracle.com (harold seigel) Date: Mon, 22 Jun 2015 13:06:14 -0400 Subject: CFV: New JDK 9 Reviewer: Jesper Wilhelmsson In-Reply-To: <20150622141405.GB3266@ehelin.jrpg.bea.com> References: <20150622141405.GB3266@ehelin.jrpg.bea.com> Message-ID: <55884086.1060801@oracle.com> Vote: yes Harold On 6/22/2015 10:14 AM, Erik Helin wrote: > I hereby nominate Jesper Wilhelmsson to JDK 9 Reviewer. > > Jesper is a member of the HotSpot GC team and has contributed 51 patches > to HotSpot [3]. Jesper has also been the gatekeeper for the jdk9/hs-gc > repo for 8 months and is currently the gatekeeper for the combined gc > and rt repository. > > Votes are due by July 6, 2015, 16:15 CEST. > > Only current JDK 9 Reviewers [1] are eligible to vote > on this nomination. Votes must be cast in the open by replying > to this mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Erik Helin > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > [3] List of patches: > 8077842: Remove the level parameter passed around in GenCollectedHeap > 8077315: Build failure on OSX after compiler upgrade > 8077302: src/share/vm/oops/instanceRefKlass.inline.hpp has a doubble /* > 8076267: Remove n_gens() > 8075635: Remove GenerationSpec array > 8076012: SA don't support flags of type size_t > 8074459: Flags handling memory sizes should be of type size_t > 8057632: Remove auxiliary code used to handle the generations array > 8071335: gc/TestSmallHeap.java throw OOM > 8073883: serviceability/dcmd/gc/RunGCTest.java should not run with -XX:+ExplicitGCInvokesConcurrent > 8061802: REDO - Remove the generations array > 8072688: Description of flag ExplicitGCInvokesConcurrent should mention G1 as well > 8067947: Regression test for JDK-6522873 > 6522873: Java not print "Unrecognized option" when it is invalid option. > 8065305: Make it possible to extend the G1CollectorPolicy > 8062836: BACKOUT - Parallelize clearing the next mark bitmap > 8061805: BACKOUT - Remove the generations array > 8055702: Remove the generations array > 8056056: Remove unnecessary inclusion of HS_ALT_MAKE from solaris Makefile > 8055744: 8u-dev nightly solaris builds failed on 08/20 > 8055006: Store original value of Min/MaxHeapFreeRatio > 8046715: Add a way to verify an extended set of command line options > 8042298: Remove the names gen0 and gen1 from the GC code > 8026396: Remove information duplication in the collector policy > 8027643: Merge GenCollectorPolicy and TwoGenerationCollectorPolicy > 8039089: List verification enabled in product builds > 8036025: Sort the freelist in order to shrink the heap > 8023899: Typo in TraceCPUTime message > 8035822: Unable to test minimalVM > 8026849: Fix typos in the GC code, part 2 > 8028391: Make the Min/MaxHeapFreeRatio flags manageable > 8025856: Fix typos in the GC code > 8028093: Initial young size is smaller than minimum young size > 8027911: Assertion in the collector policy when running gc/arguments/TestMaxNewSize.java > 8016309: assert(eden_size > 0 && survivor_size > 0) failed: just checking > 8026853: Prepare GC code for collector policy regression fix > 8026852: Use restricted_align_down in collector policy code > 8026851: Remove unnecessary code in GenRemSet > 8023643: G1 assert failed when NewSize was specified greater than MaxNewSize > 8024776: Max/MinHeapFreeRatio descriptions should be more precise > 8025854: Use "young gen" instead of "eden" > 8025852: Remove unnecessary setters in collector policy classes > 8025853: Remove unnecessary uses of GenerationSizer > 8025855: Simplify GenRemSet code slightly > 8024884: Test name changed, test list not updated > 8008314: Unimplemented() Atomic::load breaks the applications > 8006432: Ratio flags should be unsigned > 8005849: JEP 167: Event-Based JVM Tracing > 6348447: Specifying -XX:OldSize crashes 64-bit VMs > 8000351: Tenuring threshold should be unsigned > 6820066: Check that -XX:ParGCArrayScanChunk has a value larger than zero. From jon.masamitsu at oracle.com Mon Jun 22 17:15:43 2015 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Mon, 22 Jun 2015 10:15:43 -0700 Subject: CFV: New JDK 9 Reviewer: Jesper Wilhelmsson In-Reply-To: <20150622141405.GB3266@ehelin.jrpg.bea.com> References: <20150622141405.GB3266@ehelin.jrpg.bea.com> Message-ID: <558842BF.2050008@oracle.com> Vote: yes On 06/22/2015 07:14 AM, Erik Helin wrote: > I hereby nominate Jesper Wilhelmsson to JDK 9 Reviewer. > > Jesper is a member of the HotSpot GC team and has contributed 51 patches > to HotSpot [3]. Jesper has also been the gatekeeper for the jdk9/hs-gc > repo for 8 months and is currently the gatekeeper for the combined gc > and rt repository. > > Votes are due by July 6, 2015, 16:15 CEST. > > Only current JDK 9 Reviewers [1] are eligible to vote > on this nomination. Votes must be cast in the open by replying > to this mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Erik Helin > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > [3] List of patches: > 8077842: Remove the level parameter passed around in GenCollectedHeap > 8077315: Build failure on OSX after compiler upgrade > 8077302: src/share/vm/oops/instanceRefKlass.inline.hpp has a doubble /* > 8076267: Remove n_gens() > 8075635: Remove GenerationSpec array > 8076012: SA don't support flags of type size_t > 8074459: Flags handling memory sizes should be of type size_t > 8057632: Remove auxiliary code used to handle the generations array > 8071335: gc/TestSmallHeap.java throw OOM > 8073883: serviceability/dcmd/gc/RunGCTest.java should not run with -XX:+ExplicitGCInvokesConcurrent > 8061802: REDO - Remove the generations array > 8072688: Description of flag ExplicitGCInvokesConcurrent should mention G1 as well > 8067947: Regression test for JDK-6522873 > 6522873: Java not print "Unrecognized option" when it is invalid option. > 8065305: Make it possible to extend the G1CollectorPolicy > 8062836: BACKOUT - Parallelize clearing the next mark bitmap > 8061805: BACKOUT - Remove the generations array > 8055702: Remove the generations array > 8056056: Remove unnecessary inclusion of HS_ALT_MAKE from solaris Makefile > 8055744: 8u-dev nightly solaris builds failed on 08/20 > 8055006: Store original value of Min/MaxHeapFreeRatio > 8046715: Add a way to verify an extended set of command line options > 8042298: Remove the names gen0 and gen1 from the GC code > 8026396: Remove information duplication in the collector policy > 8027643: Merge GenCollectorPolicy and TwoGenerationCollectorPolicy > 8039089: List verification enabled in product builds > 8036025: Sort the freelist in order to shrink the heap > 8023899: Typo in TraceCPUTime message > 8035822: Unable to test minimalVM > 8026849: Fix typos in the GC code, part 2 > 8028391: Make the Min/MaxHeapFreeRatio flags manageable > 8025856: Fix typos in the GC code > 8028093: Initial young size is smaller than minimum young size > 8027911: Assertion in the collector policy when running gc/arguments/TestMaxNewSize.java > 8016309: assert(eden_size > 0 && survivor_size > 0) failed: just checking > 8026853: Prepare GC code for collector policy regression fix > 8026852: Use restricted_align_down in collector policy code > 8026851: Remove unnecessary code in GenRemSet > 8023643: G1 assert failed when NewSize was specified greater than MaxNewSize > 8024776: Max/MinHeapFreeRatio descriptions should be more precise > 8025854: Use "young gen" instead of "eden" > 8025852: Remove unnecessary setters in collector policy classes > 8025853: Remove unnecessary uses of GenerationSizer > 8025855: Simplify GenRemSet code slightly > 8024884: Test name changed, test list not updated > 8008314: Unimplemented() Atomic::load breaks the applications > 8006432: Ratio flags should be unsigned > 8005849: JEP 167: Event-Based JVM Tracing > 6348447: Specifying -XX:OldSize crashes 64-bit VMs > 8000351: Tenuring threshold should be unsigned > 6820066: Check that -XX:ParGCArrayScanChunk has a value larger than zero. From christian.thalinger at oracle.com Mon Jun 22 18:14:06 2015 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 22 Jun 2015 11:14:06 -0700 Subject: CFV: New JDK 9 Reviewer: Jesper Wilhelmsson In-Reply-To: <20150622141405.GB3266@ehelin.jrpg.bea.com> References: <20150622141405.GB3266@ehelin.jrpg.bea.com> Message-ID: Vote: yes > On Jun 22, 2015, at 7:14 AM, Erik Helin wrote: > > I hereby nominate Jesper Wilhelmsson to JDK 9 Reviewer. > > Jesper is a member of the HotSpot GC team and has contributed 51 patches > to HotSpot [3]. Jesper has also been the gatekeeper for the jdk9/hs-gc > repo for 8 months and is currently the gatekeeper for the combined gc > and rt repository. > > Votes are due by July 6, 2015, 16:15 CEST. > > Only current JDK 9 Reviewers [1] are eligible to vote > on this nomination. Votes must be cast in the open by replying > to this mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Erik Helin > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > [3] List of patches: > 8077842: Remove the level parameter passed around in GenCollectedHeap > 8077315: Build failure on OSX after compiler upgrade > 8077302: src/share/vm/oops/instanceRefKlass.inline.hpp has a doubble /* > 8076267: Remove n_gens() > 8075635: Remove GenerationSpec array > 8076012: SA don't support flags of type size_t > 8074459: Flags handling memory sizes should be of type size_t > 8057632: Remove auxiliary code used to handle the generations array > 8071335: gc/TestSmallHeap.java throw OOM > 8073883: serviceability/dcmd/gc/RunGCTest.java should not run with -XX:+ExplicitGCInvokesConcurrent > 8061802: REDO - Remove the generations array > 8072688: Description of flag ExplicitGCInvokesConcurrent should mention G1 as well > 8067947: Regression test for JDK-6522873 > 6522873: Java not print "Unrecognized option" when it is invalid option. > 8065305: Make it possible to extend the G1CollectorPolicy > 8062836: BACKOUT - Parallelize clearing the next mark bitmap > 8061805: BACKOUT - Remove the generations array > 8055702: Remove the generations array > 8056056: Remove unnecessary inclusion of HS_ALT_MAKE from solaris Makefile > 8055744: 8u-dev nightly solaris builds failed on 08/20 > 8055006: Store original value of Min/MaxHeapFreeRatio > 8046715: Add a way to verify an extended set of command line options > 8042298: Remove the names gen0 and gen1 from the GC code > 8026396: Remove information duplication in the collector policy > 8027643: Merge GenCollectorPolicy and TwoGenerationCollectorPolicy > 8039089: List verification enabled in product builds > 8036025: Sort the freelist in order to shrink the heap > 8023899: Typo in TraceCPUTime message > 8035822: Unable to test minimalVM > 8026849: Fix typos in the GC code, part 2 > 8028391: Make the Min/MaxHeapFreeRatio flags manageable > 8025856: Fix typos in the GC code > 8028093: Initial young size is smaller than minimum young size > 8027911: Assertion in the collector policy when running gc/arguments/TestMaxNewSize.java > 8016309: assert(eden_size > 0 && survivor_size > 0) failed: just checking > 8026853: Prepare GC code for collector policy regression fix > 8026852: Use restricted_align_down in collector policy code > 8026851: Remove unnecessary code in GenRemSet > 8023643: G1 assert failed when NewSize was specified greater than MaxNewSize > 8024776: Max/MinHeapFreeRatio descriptions should be more precise > 8025854: Use "young gen" instead of "eden" > 8025852: Remove unnecessary setters in collector policy classes > 8025853: Remove unnecessary uses of GenerationSizer > 8025855: Simplify GenRemSet code slightly > 8024884: Test name changed, test list not updated > 8008314: Unimplemented() Atomic::load breaks the applications > 8006432: Ratio flags should be unsigned > 8005849: JEP 167: Event-Based JVM Tracing > 6348447: Specifying -XX:OldSize crashes 64-bit VMs > 8000351: Tenuring threshold should be unsigned > 6820066: Check that -XX:ParGCArrayScanChunk has a value larger than zero. From coleen.phillimore at oracle.com Mon Jun 22 19:08:54 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 22 Jun 2015 15:08:54 -0400 Subject: CFV: New JDK 9 Reviewer: Jesper Wilhelmsson In-Reply-To: <20150622141405.GB3266@ehelin.jrpg.bea.com> References: <20150622141405.GB3266@ehelin.jrpg.bea.com> Message-ID: <55885D46.2090205@oracle.com> Vote: yes On 6/22/15 10:14 AM, Erik Helin wrote: > I hereby nominate Jesper Wilhelmsson to JDK 9 Reviewer. > > Jesper is a member of the HotSpot GC team and has contributed 51 patches > to HotSpot [3]. Jesper has also been the gatekeeper for the jdk9/hs-gc > repo for 8 months and is currently the gatekeeper for the combined gc > and rt repository. > > Votes are due by July 6, 2015, 16:15 CEST. > > Only current JDK 9 Reviewers [1] are eligible to vote > on this nomination. Votes must be cast in the open by replying > to this mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Erik Helin > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > [3] List of patches: > 8077842: Remove the level parameter passed around in GenCollectedHeap > 8077315: Build failure on OSX after compiler upgrade > 8077302: src/share/vm/oops/instanceRefKlass.inline.hpp has a doubble /* > 8076267: Remove n_gens() > 8075635: Remove GenerationSpec array > 8076012: SA don't support flags of type size_t > 8074459: Flags handling memory sizes should be of type size_t > 8057632: Remove auxiliary code used to handle the generations array > 8071335: gc/TestSmallHeap.java throw OOM > 8073883: serviceability/dcmd/gc/RunGCTest.java should not run with -XX:+ExplicitGCInvokesConcurrent > 8061802: REDO - Remove the generations array > 8072688: Description of flag ExplicitGCInvokesConcurrent should mention G1 as well > 8067947: Regression test for JDK-6522873 > 6522873: Java not print "Unrecognized option" when it is invalid option. > 8065305: Make it possible to extend the G1CollectorPolicy > 8062836: BACKOUT - Parallelize clearing the next mark bitmap > 8061805: BACKOUT - Remove the generations array > 8055702: Remove the generations array > 8056056: Remove unnecessary inclusion of HS_ALT_MAKE from solaris Makefile > 8055744: 8u-dev nightly solaris builds failed on 08/20 > 8055006: Store original value of Min/MaxHeapFreeRatio > 8046715: Add a way to verify an extended set of command line options > 8042298: Remove the names gen0 and gen1 from the GC code > 8026396: Remove information duplication in the collector policy > 8027643: Merge GenCollectorPolicy and TwoGenerationCollectorPolicy > 8039089: List verification enabled in product builds > 8036025: Sort the freelist in order to shrink the heap > 8023899: Typo in TraceCPUTime message > 8035822: Unable to test minimalVM > 8026849: Fix typos in the GC code, part 2 > 8028391: Make the Min/MaxHeapFreeRatio flags manageable > 8025856: Fix typos in the GC code > 8028093: Initial young size is smaller than minimum young size > 8027911: Assertion in the collector policy when running gc/arguments/TestMaxNewSize.java > 8016309: assert(eden_size > 0 && survivor_size > 0) failed: just checking > 8026853: Prepare GC code for collector policy regression fix > 8026852: Use restricted_align_down in collector policy code > 8026851: Remove unnecessary code in GenRemSet > 8023643: G1 assert failed when NewSize was specified greater than MaxNewSize > 8024776: Max/MinHeapFreeRatio descriptions should be more precise > 8025854: Use "young gen" instead of "eden" > 8025852: Remove unnecessary setters in collector policy classes > 8025853: Remove unnecessary uses of GenerationSizer > 8025855: Simplify GenRemSet code slightly > 8024884: Test name changed, test list not updated > 8008314: Unimplemented() Atomic::load breaks the applications > 8006432: Ratio flags should be unsigned > 8005849: JEP 167: Event-Based JVM Tracing > 6348447: Specifying -XX:OldSize crashes 64-bit VMs > 8000351: Tenuring threshold should be unsigned > 6820066: Check that -XX:ParGCArrayScanChunk has a value larger than zero. From serguei.spitsyn at oracle.com Mon Jun 22 20:05:14 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 22 Jun 2015 13:05:14 -0700 Subject: CFV: New JDK 9 Reviewer: Jesper Wilhelmsson In-Reply-To: <20150622141405.GB3266@ehelin.jrpg.bea.com> References: <20150622141405.GB3266@ehelin.jrpg.bea.com> Message-ID: <55886A7A.7080208@oracle.com> Vote: yes On 6/22/15 7:14 AM, Erik Helin wrote: > I hereby nominate Jesper Wilhelmsson to JDK 9 Reviewer. > > Jesper is a member of the HotSpot GC team and has contributed 51 patches > to HotSpot [3]. Jesper has also been the gatekeeper for the jdk9/hs-gc > repo for 8 months and is currently the gatekeeper for the combined gc > and rt repository. > > Votes are due by July 6, 2015, 16:15 CEST. > > Only current JDK 9 Reviewers [1] are eligible to vote > on this nomination. Votes must be cast in the open by replying > to this mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Erik Helin > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > [3] List of patches: > 8077842: Remove the level parameter passed around in GenCollectedHeap > 8077315: Build failure on OSX after compiler upgrade > 8077302: src/share/vm/oops/instanceRefKlass.inline.hpp has a doubble /* > 8076267: Remove n_gens() > 8075635: Remove GenerationSpec array > 8076012: SA don't support flags of type size_t > 8074459: Flags handling memory sizes should be of type size_t > 8057632: Remove auxiliary code used to handle the generations array > 8071335: gc/TestSmallHeap.java throw OOM > 8073883: serviceability/dcmd/gc/RunGCTest.java should not run with -XX:+ExplicitGCInvokesConcurrent > 8061802: REDO - Remove the generations array > 8072688: Description of flag ExplicitGCInvokesConcurrent should mention G1 as well > 8067947: Regression test for JDK-6522873 > 6522873: Java not print "Unrecognized option" when it is invalid option. > 8065305: Make it possible to extend the G1CollectorPolicy > 8062836: BACKOUT - Parallelize clearing the next mark bitmap > 8061805: BACKOUT - Remove the generations array > 8055702: Remove the generations array > 8056056: Remove unnecessary inclusion of HS_ALT_MAKE from solaris Makefile > 8055744: 8u-dev nightly solaris builds failed on 08/20 > 8055006: Store original value of Min/MaxHeapFreeRatio > 8046715: Add a way to verify an extended set of command line options > 8042298: Remove the names gen0 and gen1 from the GC code > 8026396: Remove information duplication in the collector policy > 8027643: Merge GenCollectorPolicy and TwoGenerationCollectorPolicy > 8039089: List verification enabled in product builds > 8036025: Sort the freelist in order to shrink the heap > 8023899: Typo in TraceCPUTime message > 8035822: Unable to test minimalVM > 8026849: Fix typos in the GC code, part 2 > 8028391: Make the Min/MaxHeapFreeRatio flags manageable > 8025856: Fix typos in the GC code > 8028093: Initial young size is smaller than minimum young size > 8027911: Assertion in the collector policy when running gc/arguments/TestMaxNewSize.java > 8016309: assert(eden_size > 0 && survivor_size > 0) failed: just checking > 8026853: Prepare GC code for collector policy regression fix > 8026852: Use restricted_align_down in collector policy code > 8026851: Remove unnecessary code in GenRemSet > 8023643: G1 assert failed when NewSize was specified greater than MaxNewSize > 8024776: Max/MinHeapFreeRatio descriptions should be more precise > 8025854: Use "young gen" instead of "eden" > 8025852: Remove unnecessary setters in collector policy classes > 8025853: Remove unnecessary uses of GenerationSizer > 8025855: Simplify GenRemSet code slightly > 8024884: Test name changed, test list not updated > 8008314: Unimplemented() Atomic::load breaks the applications > 8006432: Ratio flags should be unsigned > 8005849: JEP 167: Event-Based JVM Tracing > 6348447: Specifying -XX:OldSize crashes 64-bit VMs > 8000351: Tenuring threshold should be unsigned > 6820066: Check that -XX:ParGCArrayScanChunk has a value larger than zero. From mark.reinhold at oracle.com Mon Jun 22 21:41:58 2015 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Mon, 22 Jun 2015 14:41:58 -0700 Subject: JEPs proposed to target JDK 9 (2015/6/4) In-Reply-To: <20150604135016.960314@eggemoggin.niobe.net> References: <20150604135016.960314@eggemoggin.niobe.net> Message-ID: <20150622144158.450316@eggemoggin.niobe.net> 2015/6/4 1:50 -0700, mark.reinhold at oracle.com: > The following JEPs have been placed into the "Proposed to Target" > state by their owners after discussion and review: > > 256: BeanInfo Annotations > http://openjdk.java.net/jeps/256 > > 257: Update JavaFX/Media to Newer Version of GStreamer > http://openjdk.java.net/jeps/257 > > 258: HarfBuzz Font-Layout Engine > http://openjdk.java.net/jeps/258 > > Feedback on these proposals is more than welcome, as are reasoned > objections. If no such objections are raised by 21:00 UTC next > Thursday, 11 June, or if they're raised and then satisfactorily > answered, then per the JEP 2.0 process proposal [1] I'll target > these JEPs to JDK 9. Hearing no objections, I've targeted these JEPs to JDK 9. - Mark From mark.reinhold at oracle.com Mon Jun 22 22:01:58 2015 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Mon, 22 Jun 2015 15:01:58 -0700 Subject: JEPs proposed to target JDK 9 (2015/5/21) In-Reply-To: References: <20150521150533.791873@eggemoggin.niobe.net>, Message-ID: <20150622150158.958024@eggemoggin.niobe.net> 2015/5/21 5:15 -0700, benjamin.john.evans at gmail.com: > I've mostly been very pleased with the JEPs targeted at JDK 9. > However, I have to object to: > > 248: Make G1 the Default Garbage Collector > > My reasoning is as follows: > > ... An extensive discussion, mostly on the hotspot-dev list [1], resulted in a change to JEP 248 to note that there is some concern that G1 might not be ready to become the default, that making it the default now will allow us to get more feedback on it, and that if it proves to be not ready then we'll revert the default to the Parallel GC in time for JDK 9 GA [2][3]. With that, I think your concern has been addressed, so I've targeted this JEP to JDK 9. - Mark [1] http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-June/thread.html [2] http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-June/018804.html [3] http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-June/018809.html From mark.reinhold at oracle.com Mon Jun 22 23:08:08 2015 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Mon, 22 Jun 2015 16:08:08 -0700 Subject: JEPs proposed to target JDK 9 (2015/6/22) Message-ID: <20150622160808.393412@eggemoggin.niobe.net> The following JEPs have been placed into the "Proposed to Target" state by their owners after discussion and review: 251: Multi-Resolution Images http://openjdk.java.net/jeps/251 253: Prepare JavaFX UI Controls & CSS APIs for Modularization http://openjdk.java.net/jeps/253 254: Compact Strings http://openjdk.java.net/jeps/254 255: Merge Selected Xerces 2.11.0 Updates into JAXP http://openjdk.java.net/jeps/255 Feedback on these proposals is more than welcome, as are reasoned objections. If no such objections are raised by 23:59 UTC next Monday, 29 June, or if they're raised and then satisfactorily answered, then per the JEP 2.0 process proposal [1] I'll target these JEPs to JDK 9. (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 david.holmes at oracle.com Tue Jun 23 04:52:13 2015 From: david.holmes at oracle.com (David Holmes) Date: Tue, 23 Jun 2015 14:52:13 +1000 Subject: CFV: New JDK 9 Reviewer: Jesper Wilhelmsson In-Reply-To: <20150622141405.GB3266@ehelin.jrpg.bea.com> References: <20150622141405.GB3266@ehelin.jrpg.bea.com> Message-ID: <5588E5FD.2040202@oracle.com> Vote: yes David On 23/06/2015 12:14 AM, Erik Helin wrote: > I hereby nominate Jesper Wilhelmsson to JDK 9 Reviewer. > > Jesper is a member of the HotSpot GC team and has contributed 51 patches > to HotSpot [3]. Jesper has also been the gatekeeper for the jdk9/hs-gc > repo for 8 months and is currently the gatekeeper for the combined gc > and rt repository. > > Votes are due by July 6, 2015, 16:15 CEST. > > Only current JDK 9 Reviewers [1] are eligible to vote > on this nomination. Votes must be cast in the open by replying > to this mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Erik Helin > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > [3] List of patches: > 8077842: Remove the level parameter passed around in GenCollectedHeap > 8077315: Build failure on OSX after compiler upgrade > 8077302: src/share/vm/oops/instanceRefKlass.inline.hpp has a doubble /* > 8076267: Remove n_gens() > 8075635: Remove GenerationSpec array > 8076012: SA don't support flags of type size_t > 8074459: Flags handling memory sizes should be of type size_t > 8057632: Remove auxiliary code used to handle the generations array > 8071335: gc/TestSmallHeap.java throw OOM > 8073883: serviceability/dcmd/gc/RunGCTest.java should not run with -XX:+ExplicitGCInvokesConcurrent > 8061802: REDO - Remove the generations array > 8072688: Description of flag ExplicitGCInvokesConcurrent should mention G1 as well > 8067947: Regression test for JDK-6522873 > 6522873: Java not print "Unrecognized option" when it is invalid option. > 8065305: Make it possible to extend the G1CollectorPolicy > 8062836: BACKOUT - Parallelize clearing the next mark bitmap > 8061805: BACKOUT - Remove the generations array > 8055702: Remove the generations array > 8056056: Remove unnecessary inclusion of HS_ALT_MAKE from solaris Makefile > 8055744: 8u-dev nightly solaris builds failed on 08/20 > 8055006: Store original value of Min/MaxHeapFreeRatio > 8046715: Add a way to verify an extended set of command line options > 8042298: Remove the names gen0 and gen1 from the GC code > 8026396: Remove information duplication in the collector policy > 8027643: Merge GenCollectorPolicy and TwoGenerationCollectorPolicy > 8039089: List verification enabled in product builds > 8036025: Sort the freelist in order to shrink the heap > 8023899: Typo in TraceCPUTime message > 8035822: Unable to test minimalVM > 8026849: Fix typos in the GC code, part 2 > 8028391: Make the Min/MaxHeapFreeRatio flags manageable > 8025856: Fix typos in the GC code > 8028093: Initial young size is smaller than minimum young size > 8027911: Assertion in the collector policy when running gc/arguments/TestMaxNewSize.java > 8016309: assert(eden_size > 0 && survivor_size > 0) failed: just checking > 8026853: Prepare GC code for collector policy regression fix > 8026852: Use restricted_align_down in collector policy code > 8026851: Remove unnecessary code in GenRemSet > 8023643: G1 assert failed when NewSize was specified greater than MaxNewSize > 8024776: Max/MinHeapFreeRatio descriptions should be more precise > 8025854: Use "young gen" instead of "eden" > 8025852: Remove unnecessary setters in collector policy classes > 8025853: Remove unnecessary uses of GenerationSizer > 8025855: Simplify GenRemSet code slightly > 8024884: Test name changed, test list not updated > 8008314: Unimplemented() Atomic::load breaks the applications > 8006432: Ratio flags should be unsigned > 8005849: JEP 167: Event-Based JVM Tracing > 6348447: Specifying -XX:OldSize crashes 64-bit VMs > 8000351: Tenuring threshold should be unsigned > 6820066: Check that -XX:ParGCArrayScanChunk has a value larger than zero. > From bengt.rutisson at oracle.com Tue Jun 23 06:39:28 2015 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Tue, 23 Jun 2015 08:39:28 +0200 Subject: CFV: New JDK 9 Reviewer: Jesper Wilhelmsson In-Reply-To: <20150622141405.GB3266@ehelin.jrpg.bea.com> References: <20150622141405.GB3266@ehelin.jrpg.bea.com> Message-ID: Vote: yes Bengt > 22 jun 2015 kl. 16:14 skrev Erik Helin : > > I hereby nominate Jesper Wilhelmsson to JDK 9 Reviewer. > > Jesper is a member of the HotSpot GC team and has contributed 51 patches > to HotSpot [3]. Jesper has also been the gatekeeper for the jdk9/hs-gc > repo for 8 months and is currently the gatekeeper for the combined gc > and rt repository. > > Votes are due by July 6, 2015, 16:15 CEST. > > Only current JDK 9 Reviewers [1] are eligible to vote > on this nomination. Votes must be cast in the open by replying > to this mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Erik Helin > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > [3] List of patches: > 8077842: Remove the level parameter passed around in GenCollectedHeap > 8077315: Build failure on OSX after compiler upgrade > 8077302: src/share/vm/oops/instanceRefKlass.inline.hpp has a doubble /* > 8076267: Remove n_gens() > 8075635: Remove GenerationSpec array > 8076012: SA don't support flags of type size_t > 8074459: Flags handling memory sizes should be of type size_t > 8057632: Remove auxiliary code used to handle the generations array > 8071335: gc/TestSmallHeap.java throw OOM > 8073883: serviceability/dcmd/gc/RunGCTest.java should not run with -XX:+ExplicitGCInvokesConcurrent > 8061802: REDO - Remove the generations array > 8072688: Description of flag ExplicitGCInvokesConcurrent should mention G1 as well > 8067947: Regression test for JDK-6522873 > 6522873: Java not print "Unrecognized option" when it is invalid option. > 8065305: Make it possible to extend the G1CollectorPolicy > 8062836: BACKOUT - Parallelize clearing the next mark bitmap > 8061805: BACKOUT - Remove the generations array > 8055702: Remove the generations array > 8056056: Remove unnecessary inclusion of HS_ALT_MAKE from solaris Makefile > 8055744: 8u-dev nightly solaris builds failed on 08/20 > 8055006: Store original value of Min/MaxHeapFreeRatio > 8046715: Add a way to verify an extended set of command line options > 8042298: Remove the names gen0 and gen1 from the GC code > 8026396: Remove information duplication in the collector policy > 8027643: Merge GenCollectorPolicy and TwoGenerationCollectorPolicy > 8039089: List verification enabled in product builds > 8036025: Sort the freelist in order to shrink the heap > 8023899: Typo in TraceCPUTime message > 8035822: Unable to test minimalVM > 8026849: Fix typos in the GC code, part 2 > 8028391: Make the Min/MaxHeapFreeRatio flags manageable > 8025856: Fix typos in the GC code > 8028093: Initial young size is smaller than minimum young size > 8027911: Assertion in the collector policy when running gc/arguments/TestMaxNewSize.java > 8016309: assert(eden_size > 0 && survivor_size > 0) failed: just checking > 8026853: Prepare GC code for collector policy regression fix > 8026852: Use restricted_align_down in collector policy code > 8026851: Remove unnecessary code in GenRemSet > 8023643: G1 assert failed when NewSize was specified greater than MaxNewSize > 8024776: Max/MinHeapFreeRatio descriptions should be more precise > 8025854: Use "young gen" instead of "eden" > 8025852: Remove unnecessary setters in collector policy classes > 8025853: Remove unnecessary uses of GenerationSizer > 8025855: Simplify GenRemSet code slightly > 8024884: Test name changed, test list not updated > 8008314: Unimplemented() Atomic::load breaks the applications > 8006432: Ratio flags should be unsigned > 8005849: JEP 167: Event-Based JVM Tracing > 6348447: Specifying -XX:OldSize crashes 64-bit VMs > 8000351: Tenuring threshold should be unsigned > 6820066: Check that -XX:ParGCArrayScanChunk has a value larger than zero. From per.liden at oracle.com Tue Jun 23 07:37:05 2015 From: per.liden at oracle.com (Per Liden) Date: Tue, 23 Jun 2015 09:37:05 +0200 Subject: CFV: New JDK 9 Reviewer: Jesper Wilhelmsson In-Reply-To: <20150622141405.GB3266@ehelin.jrpg.bea.com> References: <20150622141405.GB3266@ehelin.jrpg.bea.com> Message-ID: <55890CA1.2080006@oracle.com> Vote: yes /Per On 2015-06-22 16:14, Erik Helin wrote: > I hereby nominate Jesper Wilhelmsson to JDK 9 Reviewer. > > Jesper is a member of the HotSpot GC team and has contributed 51 patches > to HotSpot [3]. Jesper has also been the gatekeeper for the jdk9/hs-gc > repo for 8 months and is currently the gatekeeper for the combined gc > and rt repository. > > Votes are due by July 6, 2015, 16:15 CEST. > > Only current JDK 9 Reviewers [1] are eligible to vote > on this nomination. Votes must be cast in the open by replying > to this mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Erik Helin > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > [3] List of patches: > 8077842: Remove the level parameter passed around in GenCollectedHeap > 8077315: Build failure on OSX after compiler upgrade > 8077302: src/share/vm/oops/instanceRefKlass.inline.hpp has a doubble /* > 8076267: Remove n_gens() > 8075635: Remove GenerationSpec array > 8076012: SA don't support flags of type size_t > 8074459: Flags handling memory sizes should be of type size_t > 8057632: Remove auxiliary code used to handle the generations array > 8071335: gc/TestSmallHeap.java throw OOM > 8073883: serviceability/dcmd/gc/RunGCTest.java should not run with -XX:+ExplicitGCInvokesConcurrent > 8061802: REDO - Remove the generations array > 8072688: Description of flag ExplicitGCInvokesConcurrent should mention G1 as well > 8067947: Regression test for JDK-6522873 > 6522873: Java not print "Unrecognized option" when it is invalid option. > 8065305: Make it possible to extend the G1CollectorPolicy > 8062836: BACKOUT - Parallelize clearing the next mark bitmap > 8061805: BACKOUT - Remove the generations array > 8055702: Remove the generations array > 8056056: Remove unnecessary inclusion of HS_ALT_MAKE from solaris Makefile > 8055744: 8u-dev nightly solaris builds failed on 08/20 > 8055006: Store original value of Min/MaxHeapFreeRatio > 8046715: Add a way to verify an extended set of command line options > 8042298: Remove the names gen0 and gen1 from the GC code > 8026396: Remove information duplication in the collector policy > 8027643: Merge GenCollectorPolicy and TwoGenerationCollectorPolicy > 8039089: List verification enabled in product builds > 8036025: Sort the freelist in order to shrink the heap > 8023899: Typo in TraceCPUTime message > 8035822: Unable to test minimalVM > 8026849: Fix typos in the GC code, part 2 > 8028391: Make the Min/MaxHeapFreeRatio flags manageable > 8025856: Fix typos in the GC code > 8028093: Initial young size is smaller than minimum young size > 8027911: Assertion in the collector policy when running gc/arguments/TestMaxNewSize.java > 8016309: assert(eden_size > 0 && survivor_size > 0) failed: just checking > 8026853: Prepare GC code for collector policy regression fix > 8026852: Use restricted_align_down in collector policy code > 8026851: Remove unnecessary code in GenRemSet > 8023643: G1 assert failed when NewSize was specified greater than MaxNewSize > 8024776: Max/MinHeapFreeRatio descriptions should be more precise > 8025854: Use "young gen" instead of "eden" > 8025852: Remove unnecessary setters in collector policy classes > 8025853: Remove unnecessary uses of GenerationSizer > 8025855: Simplify GenRemSet code slightly > 8024884: Test name changed, test list not updated > 8008314: Unimplemented() Atomic::load breaks the applications > 8006432: Ratio flags should be unsigned > 8005849: JEP 167: Event-Based JVM Tracing > 6348447: Specifying -XX:OldSize crashes 64-bit VMs > 8000351: Tenuring threshold should be unsigned > 6820066: Check that -XX:ParGCArrayScanChunk has a value larger than zero. > From erik.joelsson at oracle.com Tue Jun 23 07:54:44 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 23 Jun 2015 09:54:44 +0200 Subject: CFV: New JDK 9 Reviewer: Jesper Wilhelmsson In-Reply-To: <20150622141405.GB3266@ehelin.jrpg.bea.com> References: <20150622141405.GB3266@ehelin.jrpg.bea.com> Message-ID: <558910C4.7060600@oracle.com> Vote: yes /Erik On 2015-06-22 16:14, Erik Helin wrote: > I hereby nominate Jesper Wilhelmsson to JDK 9 Reviewer. > > Jesper is a member of the HotSpot GC team and has contributed 51 patches > to HotSpot [3]. Jesper has also been the gatekeeper for the jdk9/hs-gc > repo for 8 months and is currently the gatekeeper for the combined gc > and rt repository. > > Votes are due by July 6, 2015, 16:15 CEST. > > Only current JDK 9 Reviewers [1] are eligible to vote > on this nomination. Votes must be cast in the open by replying > to this mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Erik Helin > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > [3] List of patches: > 8077842: Remove the level parameter passed around in GenCollectedHeap > 8077315: Build failure on OSX after compiler upgrade > 8077302: src/share/vm/oops/instanceRefKlass.inline.hpp has a doubble /* > 8076267: Remove n_gens() > 8075635: Remove GenerationSpec array > 8076012: SA don't support flags of type size_t > 8074459: Flags handling memory sizes should be of type size_t > 8057632: Remove auxiliary code used to handle the generations array > 8071335: gc/TestSmallHeap.java throw OOM > 8073883: serviceability/dcmd/gc/RunGCTest.java should not run with -XX:+ExplicitGCInvokesConcurrent > 8061802: REDO - Remove the generations array > 8072688: Description of flag ExplicitGCInvokesConcurrent should mention G1 as well > 8067947: Regression test for JDK-6522873 > 6522873: Java not print "Unrecognized option" when it is invalid option. > 8065305: Make it possible to extend the G1CollectorPolicy > 8062836: BACKOUT - Parallelize clearing the next mark bitmap > 8061805: BACKOUT - Remove the generations array > 8055702: Remove the generations array > 8056056: Remove unnecessary inclusion of HS_ALT_MAKE from solaris Makefile > 8055744: 8u-dev nightly solaris builds failed on 08/20 > 8055006: Store original value of Min/MaxHeapFreeRatio > 8046715: Add a way to verify an extended set of command line options > 8042298: Remove the names gen0 and gen1 from the GC code > 8026396: Remove information duplication in the collector policy > 8027643: Merge GenCollectorPolicy and TwoGenerationCollectorPolicy > 8039089: List verification enabled in product builds > 8036025: Sort the freelist in order to shrink the heap > 8023899: Typo in TraceCPUTime message > 8035822: Unable to test minimalVM > 8026849: Fix typos in the GC code, part 2 > 8028391: Make the Min/MaxHeapFreeRatio flags manageable > 8025856: Fix typos in the GC code > 8028093: Initial young size is smaller than minimum young size > 8027911: Assertion in the collector policy when running gc/arguments/TestMaxNewSize.java > 8016309: assert(eden_size > 0 && survivor_size > 0) failed: just checking > 8026853: Prepare GC code for collector policy regression fix > 8026852: Use restricted_align_down in collector policy code > 8026851: Remove unnecessary code in GenRemSet > 8023643: G1 assert failed when NewSize was specified greater than MaxNewSize > 8024776: Max/MinHeapFreeRatio descriptions should be more precise > 8025854: Use "young gen" instead of "eden" > 8025852: Remove unnecessary setters in collector policy classes > 8025853: Remove unnecessary uses of GenerationSizer > 8025855: Simplify GenRemSet code slightly > 8024884: Test name changed, test list not updated > 8008314: Unimplemented() Atomic::load breaks the applications > 8006432: Ratio flags should be unsigned > 8005849: JEP 167: Event-Based JVM Tracing > 6348447: Specifying -XX:OldSize crashes 64-bit VMs > 8000351: Tenuring threshold should be unsigned > 6820066: Check that -XX:ParGCArrayScanChunk has a value larger than zero. From thomas.schatzl at oracle.com Tue Jun 23 07:56:04 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 23 Jun 2015 09:56:04 +0200 Subject: CFV: New JDK 9 Reviewer: Jesper Wilhelmsson In-Reply-To: <20150622141405.GB3266@ehelin.jrpg.bea.com> References: <20150622141405.GB3266@ehelin.jrpg.bea.com> Message-ID: <1435046164.2673.0.camel@oracle.com> Vote: yes From stefan.karlsson at oracle.com Tue Jun 23 14:58:36 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Tue, 23 Jun 2015 16:58:36 +0200 Subject: CFV: New JDK 9 Reviewer: Jesper Wilhelmsson In-Reply-To: <20150622141405.GB3266@ehelin.jrpg.bea.com> References: <20150622141405.GB3266@ehelin.jrpg.bea.com> Message-ID: <5589741C.6080608@oracle.com> Vote: yes StefanK On 2015-06-22 16:14, Erik Helin wrote: > I hereby nominate Jesper Wilhelmsson to JDK 9 Reviewer. > > Jesper is a member of the HotSpot GC team and has contributed 51 patches > to HotSpot [3]. Jesper has also been the gatekeeper for the jdk9/hs-gc > repo for 8 months and is currently the gatekeeper for the combined gc > and rt repository. > > Votes are due by July 6, 2015, 16:15 CEST. > > Only current JDK 9 Reviewers [1] are eligible to vote > on this nomination. Votes must be cast in the open by replying > to this mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Erik Helin > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > [3] List of patches: > 8077842: Remove the level parameter passed around in GenCollectedHeap > 8077315: Build failure on OSX after compiler upgrade > 8077302: src/share/vm/oops/instanceRefKlass.inline.hpp has a doubble /* > 8076267: Remove n_gens() > 8075635: Remove GenerationSpec array > 8076012: SA don't support flags of type size_t > 8074459: Flags handling memory sizes should be of type size_t > 8057632: Remove auxiliary code used to handle the generations array > 8071335: gc/TestSmallHeap.java throw OOM > 8073883: serviceability/dcmd/gc/RunGCTest.java should not run with -XX:+ExplicitGCInvokesConcurrent > 8061802: REDO - Remove the generations array > 8072688: Description of flag ExplicitGCInvokesConcurrent should mention G1 as well > 8067947: Regression test for JDK-6522873 > 6522873: Java not print "Unrecognized option" when it is invalid option. > 8065305: Make it possible to extend the G1CollectorPolicy > 8062836: BACKOUT - Parallelize clearing the next mark bitmap > 8061805: BACKOUT - Remove the generations array > 8055702: Remove the generations array > 8056056: Remove unnecessary inclusion of HS_ALT_MAKE from solaris Makefile > 8055744: 8u-dev nightly solaris builds failed on 08/20 > 8055006: Store original value of Min/MaxHeapFreeRatio > 8046715: Add a way to verify an extended set of command line options > 8042298: Remove the names gen0 and gen1 from the GC code > 8026396: Remove information duplication in the collector policy > 8027643: Merge GenCollectorPolicy and TwoGenerationCollectorPolicy > 8039089: List verification enabled in product builds > 8036025: Sort the freelist in order to shrink the heap > 8023899: Typo in TraceCPUTime message > 8035822: Unable to test minimalVM > 8026849: Fix typos in the GC code, part 2 > 8028391: Make the Min/MaxHeapFreeRatio flags manageable > 8025856: Fix typos in the GC code > 8028093: Initial young size is smaller than minimum young size > 8027911: Assertion in the collector policy when running gc/arguments/TestMaxNewSize.java > 8016309: assert(eden_size > 0 && survivor_size > 0) failed: just checking > 8026853: Prepare GC code for collector policy regression fix > 8026852: Use restricted_align_down in collector policy code > 8026851: Remove unnecessary code in GenRemSet > 8023643: G1 assert failed when NewSize was specified greater than MaxNewSize > 8024776: Max/MinHeapFreeRatio descriptions should be more precise > 8025854: Use "young gen" instead of "eden" > 8025852: Remove unnecessary setters in collector policy classes > 8025853: Remove unnecessary uses of GenerationSizer > 8025855: Simplify GenRemSet code slightly > 8024884: Test name changed, test list not updated > 8008314: Unimplemented() Atomic::load breaks the applications > 8006432: Ratio flags should be unsigned > 8005849: JEP 167: Event-Based JVM Tracing > 6348447: Specifying -XX:OldSize crashes 64-bit VMs > 8000351: Tenuring threshold should be unsigned > 6820066: Check that -XX:ParGCArrayScanChunk has a value larger than zero. From joe.darcy at oracle.com Tue Jun 23 22:48:47 2015 From: joe.darcy at oracle.com (joe darcy) Date: Tue, 23 Jun 2015 15:48:47 -0700 Subject: Test policy follow-up, third testing tier Message-ID: <5589E24F.1060804@oracle.com> Hello, As a reminder, JDK 9 is now using a tiered testing policy where about 9,000 tests have been placed into one of two tiers, with tier 1 tests having a stricter policy on passing than tier 2. [1] The overall policy is that tier 1 tests should always pass in master and that integrations, both dev -> master and hotspot main -> dev, should preserve the property that all tier 1 tests pass. In addition, only a limited number of tier 2 tests should fail. In related work, jtreg keywords are now used to mark tests as using randomness and/or being known to fail intermittently. A test using randomness which is also known to fail intermittently should be modified so that the random seed is recorded in the test log and so that the seed can be set to see if the test reproducibly fails with a particular seed value. [2] Analysis of a test failure of a test using randomness should include recording the seed value in a bug. There are a number of expectations for regression tests in the JDK. There is a general expectation that a test passes reliably and quickly across platforms. Tests specific to particular platform can indicate that using the jtreg @requires feature. [3] Tests must pass with assertions and system assertions enabled, as controlled by the jtreg options -ea and -esa, respectively. In addition, tests should pass when invoked under jtreg's agent vm mode with concurrency, jtreg options -agentvm and -conc:$NUMBER. If a test for technical reasons cannot be run in agentvm mode, it should be written to explicitly run in othervm mode (@run main/othervm TestName) or use other equivalent measures, such as including the directory hosting the test on the othervm.dirs property in TEST.ROOT. That way such a test will still pass when invoked by a jtreg command which otherwise uses agentvm mode. Developers should use a current version of jtreg for test runs as the test suite is relying on features in new jtreg versions. [4] The jdk repo is declared to require at least jtreg 4.1 b11; jtreg 4.1 b12 is the latest version as of writing this message. One or more additional jtreg version can be expected before JDK 9 ships. The next iteration of refining tiered testing is to add a third tier, tier 3. The initial tier 1 and tier 2 test definitions did not include any client library tests. As mentioned as a possibility in the earlier tiered testing proposal, tier 3 can start hosting client library tests, beginning with sets of tests which do not require a "headful" environment. [5] Detailed discussions about which test sets to include will be conducted with the appropriate client libs teams. Additionally, for areas with known intermittent test problems, tests can be moved down to a lower test tier to ease getting clean results on the higher tier. For example, despite many improvements made over the last several years to the speed and robustness of the rmi tests, the rmi tests are still prone to intermittent failures when run concurrently. Therefore, as follow-up work after tier 3 is added, I propose moving the rmi tests from tier 2 to tier 3. [6] Comments? Thanks, -Joe [1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2015-March/001991.html [2] http://mail.openjdk.java.net/pipermail/jdk9-dev/2015-April/002164.html [3] http://openjdk.java.net/jtreg/tag-spec.html#requires_names [4] For download information, see http://openjdk.java.net/jtreg/ [5] 8081547: Prepare client libs regression tests for running in a concurrent, headless jtreg environment [6] JDK-8129624: Move jdk_rmi test group from tier 2 to tier 3 From aph at redhat.com Wed Jun 24 09:24:24 2015 From: aph at redhat.com (Andrew Haley) Date: Wed, 24 Jun 2015 10:24:24 +0100 Subject: RFR: 8078521: AARCH64: Add AArch64 SA support In-Reply-To: <558A75AB.904@oracle.com> References: <55391C34.3070502@redhat.com> <553954D8.2070506@oracle.com> <553A012C.1070008@redhat.com> <553A8B20.9050109@oracle.com> <55408B69.8050108@redhat.com> <554A26D5.4040003@redhat.com> <554B9381.8090907@oracle.com> <554B9617.2090406@redhat.com> <555232C8.4000704@redhat.com> <55577859.5080406@oracle.com> <555B54AE.9050100@redhat.com> <557ADACB.4040206@oracle.com> <557AF3A2.4010508@redhat.com> <558A75AB.904@oracle.com> Message-ID: <558A7748.301@redhat.com> On 24/06/15 10:17, Dmitry Samersoff wrote: > Do you have an official jdk9 reviewer sign off? Not that I've seen. I will send this to JDK9-dev. JDK9-dev people: we've been through this on the serviceability-dev list. http://cr.openjdk.java.net/~aph/8078521-6/ Andrew. From dmitry.samersoff at oracle.com Wed Jun 24 09:26:58 2015 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Wed, 24 Jun 2015 12:26:58 +0300 Subject: RFR: 8078521: AARCH64: Add AArch64 SA support In-Reply-To: <558A7748.301@redhat.com> References: <55391C34.3070502@redhat.com> <553954D8.2070506@oracle.com> <553A012C.1070008@redhat.com> <553A8B20.9050109@oracle.com> <55408B69.8050108@redhat.com> <554A26D5.4040003@redhat.com> <554B9381.8090907@oracle.com> <554B9617.2090406@redhat.com> <555232C8.4000704@redhat.com> <55577859.5080406@oracle.com> <555B54AE.9050100@redhat.com> <557ADACB.4040206@oracle.com> <557AF3A2.4010508@redhat.com> <558A75AB.904@oracle.com> <558A7748.301@redhat.com> Message-ID: <558A77E2.2000601@oracle.com> David, Could you take a look? -Dmitry On 2015-06-24 12:24, Andrew Haley wrote: > On 24/06/15 10:17, Dmitry Samersoff wrote: >> Do you have an official jdk9 reviewer sign off? > > Not that I've seen. I will send this to JDK9-dev. > > JDK9-dev people: we've been through this on the serviceability-dev > list. > > http://cr.openjdk.java.net/~aph/8078521-6/ > > Andrew. > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From david.holmes at oracle.com Wed Jun 24 09:36:58 2015 From: david.holmes at oracle.com (David Holmes) Date: Wed, 24 Jun 2015 19:36:58 +1000 Subject: RFR: 8078521: AARCH64: Add AArch64 SA support In-Reply-To: <558A77E2.2000601@oracle.com> References: <55391C34.3070502@redhat.com> <553954D8.2070506@oracle.com> <553A012C.1070008@redhat.com> <553A8B20.9050109@oracle.com> <55408B69.8050108@redhat.com> <554A26D5.4040003@redhat.com> <554B9381.8090907@oracle.com> <554B9617.2090406@redhat.com> <555232C8.4000704@redhat.com> <55577859.5080406@oracle.com> <555B54AE.9050100@redhat.com> <557ADACB.4040206@oracle.com> <557AF3A2.4010508@redhat.com> <558A75AB.904@oracle.com> <558A7748.301@redhat.com> <558A77E2.2000601@oracle.com> Message-ID: <558A7A3A.2020704@oracle.com> On 24/06/2015 7:26 PM, Dmitry Samersoff wrote: > David, > > Could you take a look? Based on the serviceability review and not seeing anything blatantly more broken than it previously was (and obviously less broken for aarch64 :) ) this looks ok. Though I have one query about the new "agent/make/filelist" - is it really meant to be there ?? If not please don't commit it. If so, then okay. :) Reviewed. David > -Dmitry > > On 2015-06-24 12:24, Andrew Haley wrote: >> On 24/06/15 10:17, Dmitry Samersoff wrote: >>> Do you have an official jdk9 reviewer sign off? >> >> Not that I've seen. I will send this to JDK9-dev. >> >> JDK9-dev people: we've been through this on the serviceability-dev >> list. >> >> http://cr.openjdk.java.net/~aph/8078521-6/ >> >> Andrew. >> > > From adinn at redhat.com Wed Jun 24 09:45:05 2015 From: adinn at redhat.com (Andrew Dinn) Date: Wed, 24 Jun 2015 10:45:05 +0100 Subject: RFR: 8078521: AARCH64: Add AArch64 SA support In-Reply-To: <558A7748.301@redhat.com> References: <55391C34.3070502@redhat.com> <553954D8.2070506@oracle.com> <553A012C.1070008@redhat.com> <553A8B20.9050109@oracle.com> <55408B69.8050108@redhat.com> <554A26D5.4040003@redhat.com> <554B9381.8090907@oracle.com> <554B9617.2090406@redhat.com> <555232C8.4000704@redhat.com> <55577859.5080406@oracle.com> <555B54AE.9050100@redhat.com> <557ADACB.4040206@oracle.com> <557AF3A2.4010508@redhat.com> <558A75AB.904@oracle.com> <558A7748.301@redhat.com> Message-ID: <558A7C21.3090008@redhat.com> On 24/06/15 10:24, Andrew Haley wrote: > On 24/06/15 10:17, Dmitry Samersoff wrote: >> Do you have an official jdk9 reviewer sign off? > > Not that I've seen. I will send this to JDK9-dev. > > JDK9-dev people: we've been through this on the serviceability-dev > list. > > http://cr.openjdk.java.net/~aph/8078521-6/ Just by the by, the webrev includes an emacs backup file agent/src/share/classes/sun/jvm/hotspot/runtime/aarch64/AARCH64Frame.java~ which probably needs removing. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in UK and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (USA), Matt Parson (USA), Charlie Peters (USA), Michael O'Neill (Ireland) From asashour at yahoo.com Wed Jun 24 10:00:30 2015 From: asashour at yahoo.com (Ahmed Ashour) Date: Wed, 24 Jun 2015 10:00:30 +0000 (UTC) Subject: javax.script.ScriptEngineFactory: two spaces - coding style Message-ID: <263833289.216462.1435140030377.JavaMail.yahoo@mail.yahoo.com> Hi all, 1- There are two spaces after 'public' in javax.script.ScriptEngineFactory in the definition of: ? ? public ?ScriptEngine getScriptEngine(); 2- A broken link inside http://openjdk.java.net/guide/codeConventions.html 3- I wonder if there is coding style tool used. Since for example:? ? ? ?-?ScriptEngineFactory.getProgram() method is preceded by empty line? ? ? ?- "public interface ScriptEngine" is preceded and followed by empty lines, but ScriptEngineFactory is not. Thanks,Ahmed From aph at redhat.com Wed Jun 24 10:06:35 2015 From: aph at redhat.com (Andrew Haley) Date: Wed, 24 Jun 2015 11:06:35 +0100 Subject: RFR: 8078521: AARCH64: Add AArch64 SA support In-Reply-To: <558A7C21.3090008@redhat.com> References: <55391C34.3070502@redhat.com> <553954D8.2070506@oracle.com> <553A012C.1070008@redhat.com> <553A8B20.9050109@oracle.com> <55408B69.8050108@redhat.com> <554A26D5.4040003@redhat.com> <554B9381.8090907@oracle.com> <554B9617.2090406@redhat.com> <555232C8.4000704@redhat.com> <55577859.5080406@oracle.com> <555B54AE.9050100@redhat.com> <557ADACB.4040206@oracle.com> <557AF3A2.4010508@redhat.com> <558A75AB.904@oracle.com> <558A7748.301@redhat.com> <558A7C21.3090008@redhat.com> Message-ID: <558A812B.1030408@redhat.com> On 06/24/2015 10:45 AM, Andrew Dinn wrote: > On 24/06/15 10:24, Andrew Haley wrote: >> On 24/06/15 10:17, Dmitry Samersoff wrote: >>> Do you have an official jdk9 reviewer sign off? >> >> Not that I've seen. I will send this to JDK9-dev. >> >> JDK9-dev people: we've been through this on the serviceability-dev >> list. >> >> http://cr.openjdk.java.net/~aph/8078521-6/ > > Just by the by, the webrev includes an emacs backup file > > agent/src/share/classes/sun/jvm/hotspot/runtime/aarch64/AARCH64Frame.java~ > > which probably needs removing. Argh! I've been around this so many times that I didn't notice the spurious files. Will fix. Andrew. From martijnverburg at gmail.com Wed Jun 24 10:22:33 2015 From: martijnverburg at gmail.com (Martijn Verburg) Date: Wed, 24 Jun 2015 11:22:33 +0100 Subject: Test policy follow-up, third testing tier In-Reply-To: <5589E24F.1060804@oracle.com> References: <5589E24F.1060804@oracle.com> Message-ID: Hi Joe, Just a thought from the outside looking in (feel free to discard!). I'm seeing a reasonably strong trend to label these types of test suites/tiers as: Unit, Integration, System and Heisen. It's a very small thing, but perhaps OpenJDK as a project could use some of this (hopefully familiar) terminology. e.g. I know that if I was a new developer joining OpenJDK that if Tier 2 was re-labelled Heisen then I'd immediately know what that meant. Apart from that, I really like the proposal, I know it's been personally frustrating as a casual contributor to see a Heisen test fail when making a fairly trivial change. As an aside the Adoption Group has an unofficial nightly build of jtreg and some other code tools at: https://adopt-openjdk.ci.cloudbees.com/view/OpenJDK%20code-tools/ Cheers, Martijn On 23 June 2015 at 23:48, joe darcy wrote: > Hello, > > As a reminder, JDK 9 is now using a tiered testing policy where about > 9,000 tests have been placed into one of two tiers, with tier 1 tests > having a stricter policy on passing than tier 2. [1] The overall policy is > that tier 1 tests should always pass in master and that integrations, both > dev -> master and hotspot main -> dev, should preserve the property that > all tier 1 tests pass. In addition, only a limited number of tier 2 tests > should fail. > > In related work, jtreg keywords are now used to mark tests as using > randomness and/or being known to fail intermittently. A test using > randomness which is also known to fail intermittently should be modified so > that the random seed is recorded in the test log and so that the seed can > be set to see if the test reproducibly fails with a particular seed value. > [2] Analysis of a test failure of a test using randomness should include > recording the seed value in a bug. > > There are a number of expectations for regression tests in the JDK. There > is a general expectation that a test passes reliably and quickly across > platforms. Tests specific to particular platform can indicate that using > the jtreg @requires feature. [3] Tests must pass with assertions and system > assertions enabled, as controlled by the jtreg options -ea and -esa, > respectively. In addition, tests should pass when invoked under jtreg's > agent vm mode with concurrency, jtreg options -agentvm and -conc:$NUMBER. > If a test for technical reasons cannot be run in agentvm mode, it should be > written to explicitly run in othervm mode (@run main/othervm TestName) or > use other equivalent measures, such as including the directory hosting the > test on the othervm.dirs property in TEST.ROOT. That way such a test will > still pass when invoked by a jtreg command which otherwise uses agentvm > mode. > > Developers should use a current version of jtreg for test runs as the test > suite is relying on features in new jtreg versions. [4] The jdk repo is > declared to require at least jtreg 4.1 b11; jtreg 4.1 b12 is the latest > version as of writing this message. One or more additional jtreg version > can be expected before JDK 9 ships. > > The next iteration of refining tiered testing is to add a third tier, tier > 3. The initial tier 1 and tier 2 test definitions did not include any > client library tests. As mentioned as a possibility in the earlier tiered > testing proposal, tier 3 can start hosting client library tests, beginning > with sets of tests which do not require a "headful" environment. [5] > Detailed discussions about which test sets to include will be conducted > with the appropriate client libs teams. Additionally, for areas with known > intermittent test problems, tests can be moved down to a lower test tier to > ease getting clean results on the higher tier. For example, despite many > improvements made over the last several years to the speed and robustness > of the rmi tests, the rmi tests are still prone to intermittent failures > when run concurrently. Therefore, as follow-up work after tier 3 is added, > I propose moving the rmi tests from tier 2 to tier 3. [6] > > Comments? > > Thanks, > > -Joe > > [1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2015-March/001991.html > > [2] http://mail.openjdk.java.net/pipermail/jdk9-dev/2015-April/002164.html > > [3] http://openjdk.java.net/jtreg/tag-spec.html#requires_names > > [4] For download information, see http://openjdk.java.net/jtreg/ > > [5] 8081547: Prepare client libs regression tests for running in a > concurrent, headless jtreg environment > > [6] JDK-8129624: Move jdk_rmi test group from tier 2 to tier 3 > From aph at redhat.com Wed Jun 24 10:38:02 2015 From: aph at redhat.com (Andrew Haley) Date: Wed, 24 Jun 2015 11:38:02 +0100 Subject: Mercurial oddity [Was: RFR: 8078521: AARCH64: Add AArch64 SA support] In-Reply-To: <558A812B.1030408@redhat.com> References: <55391C34.3070502@redhat.com> <553954D8.2070506@oracle.com> <553A012C.1070008@redhat.com> <553A8B20.9050109@oracle.com> <55408B69.8050108@redhat.com> <554A26D5.4040003@redhat.com> <554B9381.8090907@oracle.com> <554B9617.2090406@redhat.com> <555232C8.4000704@redhat.com> <55577859.5080406@oracle.com> <555B54AE.9050100@redhat.com> <557ADACB.4040206@oracle.com> <557AF3A2.4010508@redhat.com> <558A75AB.904@oracle.com> <558A7748.301@redhat.com> <558A7C21.3090008@redhat.com> <558A812B.1030408@redhat.com> Message-ID: <558A888A.3050200@redhat.com> This problem was caused by the fact that "hg rollback" un-adds all the files added by the change set, so you have to add them all back manually. If you have many files it's easy to make a mistake. Does anybody know if there is a version of "hg rollback" which doesn't have this property? I guess I should have used "hg commit --amend" anyway. Thanks, Andrew. On 06/24/2015 11:06 AM, Andrew Haley wrote: > On 06/24/2015 10:45 AM, Andrew Dinn wrote: >> On 24/06/15 10:24, Andrew Haley wrote: >>> On 24/06/15 10:17, Dmitry Samersoff wrote: >>>> Do you have an official jdk9 reviewer sign off? >>> >>> Not that I've seen. I will send this to JDK9-dev. >>> >>> JDK9-dev people: we've been through this on the serviceability-dev >>> list. >>> >>> http://cr.openjdk.java.net/~aph/8078521-6/ >> >> Just by the by, the webrev includes an emacs backup file >> >> agent/src/share/classes/sun/jvm/hotspot/runtime/aarch64/AARCH64Frame.java~ >> >> which probably needs removing. > > Argh! I've been around this so many times that I didn't notice the spurious files. > > Will fix. > > Andrew. > > From aph at redhat.com Wed Jun 24 10:58:26 2015 From: aph at redhat.com (Andrew Haley) Date: Wed, 24 Jun 2015 11:58:26 +0100 Subject: RFR: 8078521: AARCH64: Add AArch64 SA support In-Reply-To: <558A812B.1030408@redhat.com> References: <55391C34.3070502@redhat.com> <553954D8.2070506@oracle.com> <553A012C.1070008@redhat.com> <553A8B20.9050109@oracle.com> <55408B69.8050108@redhat.com> <554A26D5.4040003@redhat.com> <554B9381.8090907@oracle.com> <554B9617.2090406@redhat.com> <555232C8.4000704@redhat.com> <55577859.5080406@oracle.com> <555B54AE.9050100@redhat.com> <557ADACB.4040206@oracle.com> <557AF3A2.4010508@redhat.com> <558A75AB.904@oracle.com> <558A7748.301@redhat.com> <558A7C21.3090008@redhat.com> <558A812B.1030408@redhat.com> Message-ID: <558A8D52.50006@redhat.com> On 06/24/2015 11:06 AM, Andrew Haley wrote: > On 06/24/2015 10:45 AM, Andrew Dinn wrote: >> On 24/06/15 10:24, Andrew Haley wrote: >>> On 24/06/15 10:17, Dmitry Samersoff wrote: >>>> Do you have an official jdk9 reviewer sign off? >>> >>> Not that I've seen. I will send this to JDK9-dev. >>> >>> JDK9-dev people: we've been through this on the serviceability-dev >>> list. >>> >>> http://cr.openjdk.java.net/~aph/8078521-6/ >> >> Just by the by, the webrev includes an emacs backup file >> >> agent/src/share/classes/sun/jvm/hotspot/runtime/aarch64/AARCH64Frame.java~ >> >> which probably needs removing. New webrev at http://cr.openjdk.java.net/~aph/8078521-7/ The only thing I did was to delete two files, agent/src/share/classes/sun/jvm/hotspot/runtime/aarch64/AARCH64Frame.java~ agent/make/filelist Andrew. From david.holmes at oracle.com Wed Jun 24 11:49:45 2015 From: david.holmes at oracle.com (David Holmes) Date: Wed, 24 Jun 2015 21:49:45 +1000 Subject: RFR: 8078521: AARCH64: Add AArch64 SA support In-Reply-To: <558A8D52.50006@redhat.com> References: <55391C34.3070502@redhat.com> <553954D8.2070506@oracle.com> <553A012C.1070008@redhat.com> <553A8B20.9050109@oracle.com> <55408B69.8050108@redhat.com> <554A26D5.4040003@redhat.com> <554B9381.8090907@oracle.com> <554B9617.2090406@redhat.com> <555232C8.4000704@redhat.com> <55577859.5080406@oracle.com> <555B54AE.9050100@redhat.com> <557ADACB.4040206@oracle.com> <557AF3A2.4010508@redhat.com> <558A75AB.904@oracle.com> <558A7748.301@redhat.com> <558A7C21.3090008@redhat.com> <558A812B.1030408@redhat.com> <558A8D52.50006@redhat.com> Message-ID: <558A9959.7010606@oracle.com> On 24/06/2015 8:58 PM, Andrew Haley wrote: > On 06/24/2015 11:06 AM, Andrew Haley wrote: >> On 06/24/2015 10:45 AM, Andrew Dinn wrote: >>> On 24/06/15 10:24, Andrew Haley wrote: >>>> On 24/06/15 10:17, Dmitry Samersoff wrote: >>>>> Do you have an official jdk9 reviewer sign off? >>>> >>>> Not that I've seen. I will send this to JDK9-dev. >>>> >>>> JDK9-dev people: we've been through this on the serviceability-dev >>>> list. >>>> >>>> http://cr.openjdk.java.net/~aph/8078521-6/ >>> >>> Just by the by, the webrev includes an emacs backup file >>> >>> agent/src/share/classes/sun/jvm/hotspot/runtime/aarch64/AARCH64Frame.java~ >>> >>> which probably needs removing. > > New webrev at > http://cr.openjdk.java.net/~aph/8078521-7/ > > The only thing I did was to delete two files, > > agent/src/share/classes/sun/jvm/hotspot/runtime/aarch64/AARCH64Frame.java~ > agent/make/filelist Thanks for cleaning that up. David > Andrew. > From dmitry.samersoff at oracle.com Wed Jun 24 16:37:57 2015 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Wed, 24 Jun 2015 19:37:57 +0300 Subject: RFR: 8078521: AARCH64: Add AArch64 SA support In-Reply-To: <558A7A3A.2020704@oracle.com> References: <55391C34.3070502@redhat.com> <553954D8.2070506@oracle.com> <553A012C.1070008@redhat.com> <553A8B20.9050109@oracle.com> <55408B69.8050108@redhat.com> <554A26D5.4040003@redhat.com> <554B9381.8090907@oracle.com> <554B9617.2090406@redhat.com> <555232C8.4000704@redhat.com> <55577859.5080406@oracle.com> <555B54AE.9050100@redhat.com> <557ADACB.4040206@oracle.com> <557AF3A2.4010508@redhat.com> <558A75AB.904@oracle.com> <558A7748.301@redhat.com> <558A77E2.2000601@oracle.com> <558A7A3A.2020704@oracle.com> Message-ID: <558ADCE5.6020306@oracle.com> Andrew, The fix is pushed. Please take a look at the changeset for sanity. http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/0032abb6e693 -Dmitry On 2015-06-24 12:36, David Holmes wrote: > On 24/06/2015 7:26 PM, Dmitry Samersoff wrote: >> David, >> >> Could you take a look? > > Based on the serviceability review and not seeing anything blatantly > more broken than it previously was (and obviously less broken for > aarch64 :) ) this looks ok. > > Though I have one query about the new "agent/make/filelist" - is it > really meant to be there ?? If not please don't commit it. If so, then > okay. :) > > Reviewed. > > David > >> -Dmitry >> >> On 2015-06-24 12:24, Andrew Haley wrote: >>> On 24/06/15 10:17, Dmitry Samersoff wrote: >>>> Do you have an official jdk9 reviewer sign off? >>> >>> Not that I've seen. I will send this to JDK9-dev. >>> >>> JDK9-dev people: we've been through this on the serviceability-dev >>> list. >>> >>> http://cr.openjdk.java.net/~aph/8078521-6/ >>> >>> Andrew. >>> >> >> -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From alejandro.murillo at oracle.com Wed Jun 24 21:00:04 2015 From: alejandro.murillo at oracle.com (Alejandro E Murillo) Date: Wed, 24 Jun 2015 15:00:04 -0600 Subject: Test policy follow-up, third testing tier In-Reply-To: <5589E24F.1060804@oracle.com> References: <5589E24F.1060804@oracle.com> Message-ID: <558B1A54.4060706@oracle.com> On 6/23/2015 4:48 PM, joe darcy wrote: > Hello, > > As a reminder, JDK 9 is now using a tiered testing policy where about > 9,000 tests have been placed into one of two tiers, with tier 1 tests > having a stricter policy on passing than tier 2. [1] The overall > policy is that tier 1 tests should always pass in master and that > integrations, both dev -> master and hotspot main -> dev, should > preserve the property that all tier 1 tests pass. In addition, only a > limited number of tier 2 tests should fail. Why is not everyone pushing to dev required to make sure tier1 is not broken? Alejandro > > In related work, jtreg keywords are now used to mark tests as using > randomness and/or being known to fail intermittently. A test using > randomness which is also known to fail intermittently should be > modified so that the random seed is recorded in the test log and so > that the seed can be set to see if the test reproducibly fails with a > particular seed value. [2] Analysis of a test failure of a test using > randomness should include recording the seed value in a bug. > > There are a number of expectations for regression tests in the JDK. > There is a general expectation that a test passes reliably and quickly > across platforms. Tests specific to particular platform can indicate > that using the jtreg @requires feature. [3] Tests must pass with > assertions and system assertions enabled, as controlled by the jtreg > options -ea and -esa, respectively. In addition, tests should pass > when invoked under jtreg's agent vm mode with concurrency, jtreg > options -agentvm and -conc:$NUMBER. If a test for technical reasons > cannot be run in agentvm mode, it should be written to explicitly run > in othervm mode (@run main/othervm TestName) or use other equivalent > measures, such as including the directory hosting the test on the > othervm.dirs property in TEST.ROOT. That way such a test will still > pass when invoked by a jtreg command which otherwise uses agentvm mode. > > Developers should use a current version of jtreg for test runs as the > test suite is relying on features in new jtreg versions. [4] The jdk > repo is declared to require at least jtreg 4.1 b11; jtreg 4.1 b12 is > the latest version as of writing this message. One or more additional > jtreg version can be expected before JDK 9 ships. > > The next iteration of refining tiered testing is to add a third tier, > tier 3. The initial tier 1 and tier 2 test definitions did not include > any client library tests. As mentioned as a possibility in the earlier > tiered testing proposal, tier 3 can start hosting client library > tests, beginning with sets of tests which do not require a "headful" > environment. [5] Detailed discussions about which test sets to include > will be conducted with the appropriate client libs teams. > Additionally, for areas with known intermittent test problems, tests > can be moved down to a lower test tier to ease getting clean results > on the higher tier. For example, despite many improvements made over > the last several years to the speed and robustness of the rmi tests, > the rmi tests are still prone to intermittent failures when run > concurrently. Therefore, as follow-up work after tier 3 is added, I > propose moving the rmi tests from tier 2 to tier 3. [6] > > Comments? > > Thanks, > > -Joe > > [1] > http://mail.openjdk.java.net/pipermail/jdk9-dev/2015-March/001991.html > > [2] > http://mail.openjdk.java.net/pipermail/jdk9-dev/2015-April/002164.html > > [3] http://openjdk.java.net/jtreg/tag-spec.html#requires_names > > [4] For download information, see http://openjdk.java.net/jtreg/ > > [5] 8081547: Prepare client libs regression tests for running in a > concurrent, headless jtreg environment > > [6] JDK-8129624: Move jdk_rmi test group from tier 2 to tier 3 -- Alejandro From joe.darcy at oracle.com Wed Jun 24 21:52:43 2015 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Wed, 24 Jun 2015 14:52:43 -0700 Subject: Test policy follow-up, third testing tier In-Reply-To: <558B1A54.4060706@oracle.com> References: <5589E24F.1060804@oracle.com> <558B1A54.4060706@oracle.com> Message-ID: <558B26AB.5050400@oracle.com> On 6/24/2015 2:00 PM, Alejandro E Murillo wrote: > > > On 6/23/2015 4:48 PM, joe darcy wrote: >> Hello, >> >> As a reminder, JDK 9 is now using a tiered testing policy where about >> 9,000 tests have been placed into one of two tiers, with tier 1 tests >> having a stricter policy on passing than tier 2. [1] The overall >> policy is that tier 1 tests should always pass in master and that >> integrations, both dev -> master and hotspot main -> dev, should >> preserve the property that all tier 1 tests pass. In addition, only a >> limited number of tier 2 tests should fail. > Why is not everyone pushing to dev required to make sure tier1 is not > broken? In part, because we don't have a generally available pre-push build and test system for the JDK. Second, the tree of integration forests is designed to isolate dev (and dev is meant to isolate master) from bad changes getting propagated. IMO, the notion of "bad change" should now explicitly include tier 1 test failures. Since integrations are involved procedures which already involve a lot of building and testing, I think this is a reasonable constraint to include. That said, another part of the policy is that if an bad individual changeset is pushed to dev by a developer, the situation is expected to be addressed promptly, within one day or less. Thanks, -Joe From zoltan.majo at oracle.com Thu Jun 25 11:49:17 2015 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Thu, 25 Jun 2015 13:49:17 +0200 Subject: [9] RFR(M): 8076112: Add @HotSpotIntrinsicCandidate annotation to indicate methods for which Java Runtime has intrinsics Message-ID: <558BEABD.7090907@oracle.com> Hi, please review the patch for JDK-8076112. Bug: https://bugs.openjdk.java.net/browse/JDK-8076112 Problem: There is need to indicate Java methods that are potentially intrinsified by JVM. Solution: Mark intrinsified methods with the jdk.internal.HotSpotIntrinsicCandidate annotation. Add checks that are omitted by VM-level intrinsics to the library code. Add a new diagnostic flag, CheckIntrinsics. If CheckIntrinsics is enabled, the VM performs the following checks when a class C is loaded: - all intrinsics defined by the VM for class C are present in the loaded class file and are marked; - an intrinsic is defined by the VM for all marked methods of C. If a mismatch is detected, the following is done: - a fastdebug VM prints a warning and then exits; - a product VM prints a warning and unmarked are not intrinsified. Webrev: - top: http://cr.openjdk.java.net/~zmajo/8076112/top/webrev.05/ - jdk: http://cr.openjdk.java.net/~zmajo/8076112/jdk/webrev.05/ - hotspot: http://cr.openjdk.java.net/~zmajo/8076112/hotspot/webrev.05/ Testing: - JPRT run with the 'hotspot' testset, all tests pass; - all JTREG hotspot tests, all tests pass that pass with a VM version that does not include the patch; all tests were run with -XX:+CheckIntrinsics. Thank you and best regards, Zoltan From sadhak001 at gmail.com Thu Jun 25 21:31:36 2015 From: sadhak001 at gmail.com (Mani Sarkar) Date: Thu, 25 Jun 2015 22:31:36 +0100 Subject: Test policy follow-up, third testing tier In-Reply-To: <558B26AB.5050400@oracle.com> References: <5589E24F.1060804@oracle.com> <558B1A54.4060706@oracle.com> <558B26AB.5050400@oracle.com> Message-ID: Thanks Martijn, Joe for your updates. Out of curiosity how do I run these tests from the command line: $ jtreg [runTier1 params] $ jtreg [runTier2 params] I mean whats the format to do so? When we do this: $ make test Are tests run in the same priority, tier1 tests, tier2 tests, etc... ? Any references to this will be appreciated - thanks guys. Cheers, Mani On Wed, Jun 24, 2015 at 10:52 PM, Joseph D. Darcy wrote: > On 6/24/2015 2:00 PM, Alejandro E Murillo wrote: > >> >> >> On 6/23/2015 4:48 PM, joe darcy wrote: >> >>> Hello, >>> >>> As a reminder, JDK 9 is now using a tiered testing policy where about >>> 9,000 tests have been placed into one of two tiers, with tier 1 tests >>> having a stricter policy on passing than tier 2. [1] The overall policy is >>> that tier 1 tests should always pass in master and that integrations, both >>> dev -> master and hotspot main -> dev, should preserve the property that >>> all tier 1 tests pass. In addition, only a limited number of tier 2 tests >>> should fail. >>> >> Why is not everyone pushing to dev required to make sure tier1 is not >> broken? >> > > In part, because we don't have a generally available pre-push build and > test system for the JDK. Second, the tree of integration forests is > designed to isolate dev (and dev is meant to isolate master) from bad > changes getting propagated. IMO, the notion of "bad change" should now > explicitly include tier 1 test failures. Since integrations are involved > procedures which already involve a lot of building and testing, I think > this is a reasonable constraint to include. That said, another part of the > policy is that if an bad individual changeset is pushed to dev by a > developer, the situation is expected to be addressed promptly, within one > day or less. > > Thanks, > > -Joe > -- @theNeomatrix369 * | **Blog ** | *LJC Associate & LJC Advocate (@adoptopenjdk & @adoptajsr programs) *Meet-a-Project - *MutabilityDetector * | **Bitbucket * * | **Github * * | **LinkedIn * *Come to Devoxx UK 2016:* http://www.devoxx.co.uk/ *Don't chase success, rather aim for "Excellence", and success will come chasing after you!* From joe.darcy at oracle.com Thu Jun 25 22:29:56 2015 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Thu, 25 Jun 2015 15:29:56 -0700 Subject: Test policy follow-up, third testing tier In-Reply-To: References: <5589E24F.1060804@oracle.com> <558B1A54.4060706@oracle.com> <558B26AB.5050400@oracle.com> Message-ID: <558C80E4.7080708@oracle.com> Hi Mani, On 6/25/2015 2:31 PM, Mani Sarkar wrote: > Thanks Martijn, Joe for your updates. > > Out of curiosity how do I run these tests from the command line: > > $ jtreg [runTier1 params] > $ jtreg [runTier2 params] $ jtreg [jtreg options] :tier1 More generally, the tiered test definitions are test groups and any test group can be specified for jtreg using ":$GROUP_NAME". For example, tier 1 for the jdk repo is itself composed of several other test groups, jdk_lang, jdk_util, and jdk_math; see the TEST.groups file in jdk/test for details. As discussed earlier in the thread, for "official" kinds of test runs, I would always recommend including the jtreg options -ea -esa -agentvm (enable assertions, enable system assertions, use agent vm mode) and probably also -conc:$N thrown in too. If nothing else, this is how we run the tests internally, so if a new test doesn't pass when run this way, it will get noticed :-) > > I mean whats the format to do so? > > When we do this: > > $ make test > > Are tests run in the same priority, tier1 tests, tier2 tests, etc... ? > > Any references to this will be appreciated - thanks guys. I have a change in progress to all the tiered targets to be issued via make: JDK-8075571: Support tiered testing make targets https://bugs.openjdk.java.net/browse/JDK-8075571 For this in-progress fix, if issued via make the tiered tests in different repos will *not* be run concurrently. If you want run them concurrently, jtreg supports invoking test from different repos in a single test run. HTH, -Joe From henri at tremblay.pro Sat Jun 27 00:54:22 2015 From: henri at tremblay.pro (Henri Tremblay) Date: Fri, 26 Jun 2015 20:54:22 -0400 Subject: Replacing Unsafe.allocateInstance Message-ID: Hi, I've started to follow the discussion about the Unsafe replacement. I would like to help if that is possible. I'm in fact only really interested in one method: allocateInstance. I've been implementing this magical method by myself since 2003 when I had the idea to "invent" class mocking. One of the requirement was to be able to bypass a constructor. This problematic was later solved by Objenesis (of which I am one of the 3 creators) which basically implements allocateInstance for all JVMs. It used to be done with ReflectionFactory.newConstructorForSerialization. Objenesis can now also use allocateInstance but in fact it is not the favored option on Hotspot. My latest benchmarks were showing it much slower than ReflectionFactory.newConstructorForSerialization. I must confess I haven't had the time to investigate correctly to see where the difference is coming from. And haven't try with JDK9 yet. The benchmark is here: https://github.com/easymock/objenesis/blob/master/Benchmarks.md So, my goals are: 1. Have a nice and standard way to allocate instances (without calling a constructor). Which would make Objenesis obsolete and my life easier 2. Make it as fast or faster than anything else 3. Ideally have only one official way to create an object like that The problems to solve seem to be: 1. Find a place to put the new method in the official java.* API 2. Make it fast Please tell me if anything seems worthy or it's just useless, annoying or already solved. Thanks, Henri From joe.darcy at oracle.com Sat Jun 27 03:45:13 2015 From: joe.darcy at oracle.com (joe darcy) Date: Fri, 26 Jun 2015 20:45:13 -0700 Subject: FYI, coming soon: doclint checking of references Message-ID: <558E1C49.5050602@oracle.com> Hello, The last remaining piece of JEP 212: "Resolve Lint and Doclint Warnings" is to enable the final doclint warning category "reference," which verifies the javadoc tags @see, @link, @throws, and the like have valid targets in the API. While the other four categories of doclint warnings are already turned on in the javac build of the sources [1] [2], the reference category cannot be enabled at present in the javac build due to how the modularized build works. (Briefly, an example of the issue is that when building the java.base module, only API references within java.base and recognized and javadoc in some java.base types references types in other modules.) To cope with this situation, the "reference" check will instead be enabled in the javadoc command. [3] Before that can happen, the javadoc command will need a package filter [4] analogous to the doclint package filter already in javac. (If such a filter were not added, over 1000 reference problems in the javadoc of generated corba code would need to be addressed!) Once the doclint check is enabled in the docs build, engineers making javadoc changes should run a docs build before doing a push to make sure the changes are valid, which is a good practice even today. Thanks, -Joe [1] "javac doclint checking now enabled in the JDK 9 build," http://mail.openjdk.java.net/pipermail/jdk9-dev/2015-March/001985.html [2] JDK-8075771: Enable "missing" doclint check in build of the java.desktop module, https://bugs.openjdk.java.net/browse/JDK-8075771 [3] JDK-8080722: Revisit how to check for doclint reference warning during the build, https://bugs.openjdk.java.net/browse/JDK-8080722 [4] JDK-8129909: Add -Xdoclint/packages: to javadoc, https://bugs.openjdk.java.net/browse/JDK-8129909 From paulddraper at gmail.com Sat Jun 27 07:36:20 2015 From: paulddraper at gmail.com (Paul Draper) Date: Sat, 27 Jun 2015 01:36:20 -0600 Subject: Thread-safe java.text.SimpleDateFormat format and parse Message-ID: While it's often understood that SimpleDateFormat isn't thread safe with its setters, etc. it is frequently incorrectly assumed (despite the docs) that since format() and parse() do not mutate the object in a visible way, they can be called from multiple threads. The rationale is akin to calling ArrayList#get or HashMap#get from multiple threads. The entire class is not thread-safe, but you can call that non-mutating accessor from multiple threads without issue. The trouble is that SimpleDateFormat has a private Calendar instance variable, which is mutated during the format() and parse() methods. This is a very common mistake. There is a project whose entire purpose is a thread-safe formatter: https://code.google.com/p/safe-simple-date-format/ And Apache Commons and Joda Time provide similar classes. Currently, users of SimpleDateFormat have to synchronize format() and parse(), or use a separate SimpleDateFormat for every thread. Or, too commonly, do neither and have a relatively unobvious race condition. Making format() and parse() calls thread-safe would require either using a local Calendar variable -- one instance per call -- or using a thread-local Calendar -- one instance per thread. The former option seems the best. The change would be fully backwards compatible. I have profiled a change with a local Calendar variable, and measured no difference in the performance (format and parse are by their nature rather involved methods to begin with). This change would improve the intuitive behavior of SimpleDateFormat and eliminate one of the most common mistakes of JDK users. From aph at redhat.com Sat Jun 27 08:05:34 2015 From: aph at redhat.com (Andrew Haley) Date: Sat, 27 Jun 2015 09:05:34 +0100 Subject: [9] RFR(M): 8076112: Add @HotSpotIntrinsicCandidate annotation to indicate methods for which Java Runtime has intrinsics In-Reply-To: <558BEABD.7090907@oracle.com> References: <558BEABD.7090907@oracle.com> Message-ID: <558E594E.7080906@redhat.com> On 25/06/15 12:49, Zolt?n Maj? wrote: > Problem: There is need to indicate Java methods that are potentially > intrinsified by JVM. It's a great idea but is it a good name? HotSpot is not the only Java VM. Do we expect people from to come along and add J9IntrinsicCandidate, CACAOIntrinsicCandidate, and so on? Andrew. From aph at redhat.com Sat Jun 27 14:52:39 2015 From: aph at redhat.com (Andrew Haley) Date: Sat, 27 Jun 2015 15:52:39 +0100 Subject: Replacing Unsafe.allocateInstance In-Reply-To: References: Message-ID: <558EB8B7.4000102@redhat.com> On 27/06/15 01:54, Henri Tremblay wrote: > The problems to solve seem to be: > > 1. Find a place to put the new method in the official java.* API > 2. Make it fast But Java is designed to stop people from creating objects without a constructor. There are several places where this is required in order to guarantee security. So I can't see much hope of it ever being part of the official API. As to why Unsafe.allocateInstance() is slow, I have to admit that's a mystery to me. allocateInstance() should inline quite nicely. I suppose it might be a little bit slower if HotSpot can't determine during compilation the class you're trying to create. But I'm looking at UnsafeFactoryInstantiator.java and it should be fine. The only thing to do is to do some measurements and look at the generated code. Mind you, 20ns is still pretty fast. Andrew. From jigarjm at gmail.com Mon Jun 29 07:02:22 2015 From: jigarjm at gmail.com (Jigar Joshi) Date: Mon, 29 Jun 2015 00:02:22 -0700 Subject: Thread-safe java.text.SimpleDateFormat format and parse In-Reply-To: References: Message-ID: +1 On Sat, Jun 27, 2015 at 12:36 AM, Paul Draper wrote: > While it's often understood that SimpleDateFormat isn't thread safe with > its setters, etc. it is frequently incorrectly assumed (despite the docs) > that since format() and parse() do not mutate the object in a visible way, > they can be called from multiple threads. > > The rationale is akin to calling ArrayList#get or HashMap#get from multiple > threads. The entire class is not thread-safe, but you can call that > non-mutating accessor from multiple threads without issue. > The trouble is that SimpleDateFormat has a private Calendar instance > variable, which is mutated during the format() and parse() methods. > > This is a very common mistake. There is a project whose entire purpose is a > thread-safe formatter: https://code.google.com/p/safe-simple-date-format/ > And Apache Commons and Joda Time provide similar classes. > > Currently, users of SimpleDateFormat have to synchronize format() and > parse(), or use a separate SimpleDateFormat for every thread. > Or, too commonly, do neither and have a relatively unobvious race > condition. > > Making format() and parse() calls thread-safe would require either using a > local Calendar variable -- one instance per call -- or using a thread-local > Calendar -- one instance per thread. The former option seems the best. > > The change would be fully backwards compatible. I have profiled a change > with a local Calendar variable, and measured no difference in the > performance (format and parse are by their nature rather involved methods > to begin with). > This change would improve the intuitive behavior of SimpleDateFormat and > eliminate one of the most common mistakes of JDK users. > -- -- Jigar From zoltan.majo at oracle.com Mon Jun 29 09:41:37 2015 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Mon, 29 Jun 2015 11:41:37 +0200 Subject: [9] RFR(M): 8076112: Add @HotSpotIntrinsicCandidate annotation to indicate methods for which Java Runtime has intrinsics In-Reply-To: <558E594E.7080906@redhat.com> References: <558BEABD.7090907@oracle.com> <558E594E.7080906@redhat.com> Message-ID: <559112D1.5000903@oracle.com> Hi Andrew, On 06/27/2015 10:05 AM, Andrew Haley wrote: > On 25/06/15 12:49, Zolt?n Maj? wrote: >> Problem: There is need to indicate Java methods that are potentially >> intrinsified by JVM. > It's a great idea but is it a good name? HotSpot is not the only Java > VM. Do we expect people from to come along and add > J9IntrinsicCandidate, CACAOIntrinsicCandidate, and so on? thank you bringing up this issue. The name HotSpotIntrinsicCandidate resulted from a private discussion with Joe Darcy, Brian Goetz, and John Rose. The reason this name was picked is to make clear that a marked method's interaction with the VM (specifically with the HotSpot VM implementation) needs special attention. Best regards, Zoltan > > Andrew. From aph at redhat.com Mon Jun 29 09:45:31 2015 From: aph at redhat.com (Andrew Haley) Date: Mon, 29 Jun 2015 10:45:31 +0100 Subject: [9] RFR(M): 8076112: Add @HotSpotIntrinsicCandidate annotation to indicate methods for which Java Runtime has intrinsics In-Reply-To: <559112D1.5000903@oracle.com> References: <558BEABD.7090907@oracle.com> <558E594E.7080906@redhat.com> <559112D1.5000903@oracle.com> Message-ID: <559113BB.1020106@redhat.com> Hi, On 29/06/15 10:41, Zolt?n Maj? wrote: > > On 06/27/2015 10:05 AM, Andrew Haley wrote: >> On 25/06/15 12:49, Zolt?n Maj? wrote: >>> Problem: There is need to indicate Java methods that are potentially >>> intrinsified by JVM. >> It's a great idea but is it a good name? HotSpot is not the only Java >> VM. Do we expect people from to come along and add >> J9IntrinsicCandidate, CACAOIntrinsicCandidate, and so on? > > thank you bringing up this issue. > > The name HotSpotIntrinsicCandidate resulted from a private discussion > with Joe Darcy, Brian Goetz, and John Rose. The reason this name was > picked is to make clear that a marked method's interaction with the VM > (specifically with the HotSpot VM implementation) needs special attention. OK, cool. So has any thought been given to the other VMs? Do you expect that, say, J9 will use the HotSpotIntrinsicCandidate annotattion, or do you expect we will have similar annotations for each VM which uses OpenJDK libraries? Or is the need for this annotation totally HotSpot-specific? Andrew. From konstantin.shefov at oracle.com Mon Jun 29 09:53:32 2015 From: konstantin.shefov at oracle.com (Konstantin Shefov) Date: Mon, 29 Jun 2015 12:53:32 +0300 Subject: CFV: New JDK9 Committer: Artem Smotrakov Message-ID: <5591159C.9000200@oracle.com> I hereby nominate Artem Smotrakov to jdk9 Committer. Artem is a member of the Java SE Security Libs SQE team. He has spent most of that time working on Java security tests. He has contributed 9 changes to jdk9 so far: 8129575: Equal DelegationPermission instances may return different hash codes http://hg.openjdk.java.net/jdk9/dev/jdk/rev/ad204c67c4a7 8078823: javax/net/ssl/ciphersuites/DisabledAlgorithms.java fails intermittently http://hg.openjdk.java.net/jdk9/dev/jdk/rev/d9a57d498a29 8050374: More Signature tests http://hg.openjdk.java.net/jdk9/dev/jdk/rev/2c827d6e90c4 8079140: IgnoreAllErrorHandler should use doPrivileged when it reads system properties http://hg.openjdk.java.net/jdk9/dev/jdk/rev/f717a1d287b0 8079138: Additional negative tests for XML signature processing http://hg.openjdk.java.net/jdk9/dev/jdk/rev/ce95c2b9b2cc 8076486: [TESTBUG] javax/security/auth/Subject/doAs/NestedActions.java fails if extra VM options are given http://hg.openjdk.java.net/jdk9/dev/jdk/rev/fff8ab918557 8075007: Additional tests for krb5-related cipher suites with unbound server http://hg.openjdk.java.net/jdk9/dev/jdk/rev/76b64929271b 8048138: Tests for JAAS callbacks http://hg.openjdk.java.net/jdk9/dev/jdk/rev/1e5cc55ae5d3 8076221: Disable RC4 cipher suites http://hg.openjdk.java.net/jdk9/dev/jdk/rev/23cde932f139 Votes are due by July 13, 2015. Only current JDK9 Committers [1] are eligible to vote on this nomination. For Lazy Consensus voting instructions, see [2]. Thanks, kshefov [1] http://openjdk.java.net/census#jdk9 [2] http://openjdk.java.net/projects#committer-vote From zoltan.majo at oracle.com Mon Jun 29 10:41:12 2015 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Mon, 29 Jun 2015 12:41:12 +0200 Subject: [9] RFR(M): 8076112: Add @HotSpotIntrinsicCandidate annotation to indicate methods for which Java Runtime has intrinsics In-Reply-To: <559113BB.1020106@redhat.com> References: <558BEABD.7090907@oracle.com> <558E594E.7080906@redhat.com> <559112D1.5000903@oracle.com> <559113BB.1020106@redhat.com> Message-ID: <559120C8.5070208@oracle.com> Hi, On 06/29/2015 11:45 AM, Andrew Haley wrote: > Hi, > > On 29/06/15 10:41, Zolt?n Maj? wrote: >> On 06/27/2015 10:05 AM, Andrew Haley wrote: >>> On 25/06/15 12:49, Zolt?n Maj? wrote: >>>> Problem: There is need to indicate Java methods that are potentially >>>> intrinsified by JVM. >>> It's a great idea but is it a good name? HotSpot is not the only Java >>> VM. Do we expect people from to come along and add >>> J9IntrinsicCandidate, CACAOIntrinsicCandidate, and so on? >> thank you bringing up this issue. >> >> The name HotSpotIntrinsicCandidate resulted from a private discussion >> with Joe Darcy, Brian Goetz, and John Rose. The reason this name was >> picked is to make clear that a marked method's interaction with the VM >> (specifically with the HotSpot VM implementation) needs special attention. > OK, cool. So has any thought been given to the other VMs? Do you > expect that, say, J9 will use the HotSpotIntrinsicCandidate > annotattion, or do you expect we will have similar annotations for > each VM which uses OpenJDK libraries? Or is the need for this > annotation totally HotSpot-specific? the need for this annotation resulted from the way HotSpot handles intrinsics. Here are the two main reasons: (1) Intrinsics in the HotSpot VM omit some checks (typically null checks and array bounds checks) that are instead performed in the JDK code. If HotSpot intrinsic code is changed, the matching JDK code must be changed as well (and vice versa). Otherwise we might run into correctness problems (e.g., the HotSpot intrinsic and the JDK method have different semantics) and/or performance problems (HotSpot suddenly not intrinsify a method because, e.g., the method's signature has changed and HotSpot's intrinsic list was not updated accordingly). Annotating intrinsified methods makes it less likely that a "mismatch" between a JDK method and its HotSpot-level intrinsic counterpart can be introduced. (2) With the newly added CheckIntrinsic flag, HotSpot verifies if all annotated methods are backed by intrinsics at the VM level and that all intrinsics are marked appropriately in the JDK. Other VM implementations will most likely intrinsify a different set of methods. So, if those methods were marked with the same annotation as HotSpot is looking for, it would be difficult for HotSpot to check the match between intrinsics and the JDK code they replace (Reason 2 from above). Also, if a JDK method is updated for which VM_A but not VM_B defines and intrinsic, only VM A's intrinsic code must be updated to match the JDK code, so it is maybe better to mark clearly which VM implementation intrinsifies an annotated method. So, the current design would require introducing a similar annotation for every VM that decided to implement what we just proposed for HotSpot with the current changeset. Thank you and best regards, Zoltan > > Andrew. From doug.simon at oracle.com Mon Jun 29 12:38:12 2015 From: doug.simon at oracle.com (Doug Simon) Date: Mon, 29 Jun 2015 14:38:12 +0200 Subject: [9] RFR(M): 8076112: Add @HotSpotIntrinsicCandidate annotation to indicate methods for which Java Runtime has intrinsics In-Reply-To: <559120C8.5070208@oracle.com> References: <558BEABD.7090907@oracle.com> <558E594E.7080906@redhat.com> <559112D1.5000903@oracle.com> <559113BB.1020106@redhat.com> <559120C8.5070208@oracle.com> Message-ID: > On Jun 29, 2015, at 12:41 PM, Zolt?n Maj? wrote: > > Hi, > > > On 06/29/2015 11:45 AM, Andrew Haley wrote: >> Hi, >> >> On 29/06/15 10:41, Zolt?n Maj? wrote: >>> On 06/27/2015 10:05 AM, Andrew Haley wrote: >>>> On 25/06/15 12:49, Zolt?n Maj? wrote: >>>>> Problem: There is need to indicate Java methods that are potentially >>>>> intrinsified by JVM. >>>> It's a great idea but is it a good name? HotSpot is not the only Java >>>> VM. Do we expect people from to come along and add >>>> J9IntrinsicCandidate, CACAOIntrinsicCandidate, and so on? >>> thank you bringing up this issue. >>> >>> The name HotSpotIntrinsicCandidate resulted from a private discussion >>> with Joe Darcy, Brian Goetz, and John Rose. The reason this name was >>> picked is to make clear that a marked method's interaction with the VM >>> (specifically with the HotSpot VM implementation) needs special attention. >> OK, cool. So has any thought been given to the other VMs? Do you >> expect that, say, J9 will use the HotSpotIntrinsicCandidate >> annotattion, or do you expect we will have similar annotations for >> each VM which uses OpenJDK libraries? Or is the need for this >> annotation totally HotSpot-specific? > > the need for this annotation resulted from the way HotSpot handles intrinsics. Here are the two main reasons: > > (1) Intrinsics in the HotSpot VM omit some checks (typically null checks and array bounds checks) that are instead performed in the JDK code. If HotSpot intrinsic code is changed, the matching JDK code must be changed as well (and vice versa). Otherwise we might run into correctness problems (e.g., the HotSpot intrinsic and the JDK method have different semantics) and/or performance problems (HotSpot suddenly not intrinsify a method because, e.g., the method's signature has changed and HotSpot's intrinsic list was not updated accordingly). Annotating intrinsified methods makes it less likely that a "mismatch" between a JDK method and its HotSpot-level intrinsic counterpart can be introduced. I seems just plain wrong for an intrinsic to not implement the same semantics as the intrinsified method. I would expect an intrinsic to perform all necessary runtime checks and only have the compiler omit them if it can prove they are unnecessary. If all intrinsics obeyed this contract, then there?s no need for the @HotSpotIntrinsicCandidate annotation from a semantics perspective. And in terms of the keeping HotSpot in sync with the JDK, the responsibility should fall entirely on HotSpot to check that its intrinsics correspond to existing methods. > (2) With the newly added CheckIntrinsic flag, HotSpot verifies if all annotated methods are backed by intrinsics at the VM level and that all intrinsics are marked appropriately in the JDK. > > Other VM implementations will most likely intrinsify a different set of methods. So, if those methods were marked with the same annotation as HotSpot is looking for, it would be difficult for HotSpot to check the match between intrinsics and the JDK code they replace (Reason 2 from above). Also, if a JDK method is updated for which VM_A but not VM_B defines and intrinsic, only VM A's intrinsic code must be updated to match the JDK code, so it is maybe better to mark clearly which VM implementation intrinsifies an annotated method. > > So, the current design would require introducing a similar annotation for every VM that decided to implement what we just proposed for HotSpot with the current changeset. That is true which is a great reason to avoid an annotation altogether if possible. -Doug From peter.brunet at oracle.com Mon Jun 29 12:46:44 2015 From: peter.brunet at oracle.com (Pete Brunet) Date: Mon, 29 Jun 2015 07:46:44 -0500 Subject: CFV: New JDK9 Committer: Artem Smotrakov In-Reply-To: <5591159C.9000200@oracle.com> References: <5591159C.9000200@oracle.com> Message-ID: <55913E34.2050902@oracle.com> +1 On 6/29/15 4:53 AM, Konstantin Shefov wrote: > I hereby nominate Artem Smotrakov to jdk9 Committer. > > Artem is a member of the Java SE Security Libs SQE team. > He has spent most of that time working on Java security tests. > > He has contributed 9 changes to jdk9 so far: > > 8129575: Equal DelegationPermission instances may return different > hash codes > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/ad204c67c4a7 > 8078823: javax/net/ssl/ciphersuites/DisabledAlgorithms.java fails > intermittently > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/d9a57d498a29 > 8050374: More Signature tests > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/2c827d6e90c4 > 8079140: IgnoreAllErrorHandler should use doPrivileged when it reads > system properties > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/f717a1d287b0 > 8079138: Additional negative tests for XML signature processing > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/ce95c2b9b2cc > 8076486: [TESTBUG] javax/security/auth/Subject/doAs/NestedActions.java > fails if extra VM options are given > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/fff8ab918557 > 8075007: Additional tests for krb5-related cipher suites with unbound > server > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/76b64929271b > 8048138: Tests for JAAS callbacks > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/1e5cc55ae5d3 > 8076221: Disable RC4 cipher suites > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/23cde932f139 > > Votes are due by July 13, 2015. > > Only current JDK9 Committers [1] are eligible to vote on this > nomination. > > For Lazy Consensus voting instructions, see [2]. > > Thanks, > kshefov > > [1] http://openjdk.java.net/census#jdk9 > [2] http://openjdk.java.net/projects#committer-vote > From xuelei.fan at oracle.com Mon Jun 29 12:48:52 2015 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 29 Jun 2015 20:48:52 +0800 Subject: CFV: New JDK9 Committer: Artem Smotrakov In-Reply-To: <5591159C.9000200@oracle.com> References: <5591159C.9000200@oracle.com> Message-ID: <55913EB4.7020502@oracle.com> Vote: yes Xuelei On 6/29/2015 5:53 PM, Konstantin Shefov wrote: > I hereby nominate Artem Smotrakov to jdk9 Committer. > > Artem is a member of the Java SE Security Libs SQE team. > He has spent most of that time working on Java security tests. > > He has contributed 9 changes to jdk9 so far: > > 8129575: Equal DelegationPermission instances may return different hash > codes > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/ad204c67c4a7 > 8078823: javax/net/ssl/ciphersuites/DisabledAlgorithms.java fails > intermittently > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/d9a57d498a29 > 8050374: More Signature tests > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/2c827d6e90c4 > 8079140: IgnoreAllErrorHandler should use doPrivileged when it reads > system properties > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/f717a1d287b0 > 8079138: Additional negative tests for XML signature processing > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/ce95c2b9b2cc > 8076486: [TESTBUG] javax/security/auth/Subject/doAs/NestedActions.java > fails if extra VM options are given > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/fff8ab918557 > 8075007: Additional tests for krb5-related cipher suites with unbound > server > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/76b64929271b > 8048138: Tests for JAAS callbacks > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/1e5cc55ae5d3 > 8076221: Disable RC4 cipher suites > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/23cde932f139 > > Votes are due by July 13, 2015. > > Only current JDK9 Committers [1] are eligible to vote on this > nomination. > > For Lazy Consensus voting instructions, see [2]. > > Thanks, > kshefov > > [1] http://openjdk.java.net/census#jdk9 > [2] http://openjdk.java.net/projects#committer-vote > From weijun.wang at oracle.com Mon Jun 29 12:59:03 2015 From: weijun.wang at oracle.com (Wang Weijun) Date: Mon, 29 Jun 2015 20:59:03 +0800 Subject: CFV: New JDK9 Committer: Artem Smotrakov In-Reply-To: <5591159C.9000200@oracle.com> References: <5591159C.9000200@oracle.com> Message-ID: <11647B89-8261-44F6-A0A0-1486B9D9C3C6@oracle.com> Vote: yes --Weijun > ? 2015?6?29??17:53?Konstantin Shefov ??? > > I hereby nominate Artem Smotrakov to jdk9 Committer. > From aph at redhat.com Mon Jun 29 13:01:55 2015 From: aph at redhat.com (Andrew Haley) Date: Mon, 29 Jun 2015 14:01:55 +0100 Subject: [9] RFR(M): 8076112: Add @HotSpotIntrinsicCandidate annotation to indicate methods for which Java Runtime has intrinsics In-Reply-To: References: <558BEABD.7090907@oracle.com> <558E594E.7080906@redhat.com> <559112D1.5000903@oracle.com> <559113BB.1020106@redhat.com> <559120C8.5070208@oracle.com> Message-ID: <559141C3.7000909@redhat.com> On 06/29/2015 01:38 PM, Doug Simon wrote: > I seems just plain wrong for an intrinsic to not implement the same > semantics as the intrinsified method. I would expect an intrinsic to > perform all necessary runtime checks and only have the compiler omit > them if it can prove they are unnecessary. If all intrinsics obeyed > this contract, then there?s no need for the > @HotSpotIntrinsicCandidate annotation from a semantics > perspective. And in terms of the keeping HotSpot in sync with the > JDK, the responsibility should fall entirely on HotSpot to check > that its intrinsics correspond to existing methods. Don't you think you're being rather idealistic? The other side of the argument is that it's much easier to write and maintain the arg-checking code if it's written in Java, and it also has the advantage that it benefits from profile data to guide the JIT. Andrew. From ivan.gerasimov at oracle.com Mon Jun 29 13:52:36 2015 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Mon, 29 Jun 2015 16:52:36 +0300 Subject: CFV: New JDK9 Committer: Artem Smotrakov In-Reply-To: <5591159C.9000200@oracle.com> References: <5591159C.9000200@oracle.com> Message-ID: <55914DA4.6000401@oracle.com> Vote: Yes On 29.06.2015 12:53, Konstantin Shefov wrote: > I hereby nominate Artem Smotrakov to jdk9 Committer. > > Artem is a member of the Java SE Security Libs SQE team. > He has spent most of that time working on Java security tests. > > He has contributed 9 changes to jdk9 so far: > > 8129575: Equal DelegationPermission instances may return different > hash codes > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/ad204c67c4a7 > 8078823: javax/net/ssl/ciphersuites/DisabledAlgorithms.java fails > intermittently > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/d9a57d498a29 > 8050374: More Signature tests > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/2c827d6e90c4 > 8079140: IgnoreAllErrorHandler should use doPrivileged when it reads > system properties > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/f717a1d287b0 > 8079138: Additional negative tests for XML signature processing > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/ce95c2b9b2cc > 8076486: [TESTBUG] javax/security/auth/Subject/doAs/NestedActions.java > fails if extra VM options are given > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/fff8ab918557 > 8075007: Additional tests for krb5-related cipher suites with unbound > server > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/76b64929271b > 8048138: Tests for JAAS callbacks > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/1e5cc55ae5d3 > 8076221: Disable RC4 cipher suites > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/23cde932f139 > > Votes are due by July 13, 2015. > > Only current JDK9 Committers [1] are eligible to vote on this > nomination. > > For Lazy Consensus voting instructions, see [2]. > > Thanks, > kshefov > > [1] http://openjdk.java.net/census#jdk9 > [2] http://openjdk.java.net/projects#committer-vote > > > From aleksej.efimov at oracle.com Mon Jun 29 13:59:04 2015 From: aleksej.efimov at oracle.com (Aleksej Efimov) Date: Mon, 29 Jun 2015 16:59:04 +0300 Subject: CFV: New JDK9 Committer: Artem Smotrakov In-Reply-To: <5591159C.9000200@oracle.com> References: <5591159C.9000200@oracle.com> Message-ID: <55914F28.4070205@oracle.com> Vote: Yes -Aleksej On 06/29/2015 12:53 PM, Konstantin Shefov wrote: > I hereby nominate Artem Smotrakov to jdk9 Committer. > > Artem is a member of the Java SE Security Libs SQE team. > He has spent most of that time working on Java security tests. > > He has contributed 9 changes to jdk9 so far: > > 8129575: Equal DelegationPermission instances may return different > hash codes > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/ad204c67c4a7 > 8078823: javax/net/ssl/ciphersuites/DisabledAlgorithms.java fails > intermittently > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/d9a57d498a29 > 8050374: More Signature tests > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/2c827d6e90c4 > 8079140: IgnoreAllErrorHandler should use doPrivileged when it reads > system properties > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/f717a1d287b0 > 8079138: Additional negative tests for XML signature processing > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/ce95c2b9b2cc > 8076486: [TESTBUG] javax/security/auth/Subject/doAs/NestedActions.java > fails if extra VM options are given > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/fff8ab918557 > 8075007: Additional tests for krb5-related cipher suites with unbound > server > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/76b64929271b > 8048138: Tests for JAAS callbacks > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/1e5cc55ae5d3 > 8076221: Disable RC4 cipher suites > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/23cde932f139 > > Votes are due by July 13, 2015. > > Only current JDK9 Committers [1] are eligible to vote on this > nomination. > > For Lazy Consensus voting instructions, see [2]. > > Thanks, > kshefov > > [1] http://openjdk.java.net/census#jdk9 > [2] http://openjdk.java.net/projects#committer-vote > From Abhi.Saha at Oracle.Com Mon Jun 29 14:21:58 2015 From: Abhi.Saha at Oracle.Com (Abhijit Saha) Date: Mon, 29 Jun 2015 07:21:58 -0700 Subject: CFV: New JDK9 Committer: Artem Smotrakov In-Reply-To: <5591159C.9000200@oracle.com> References: <5591159C.9000200@oracle.com> Message-ID: <55915486.8010204@Oracle.Com> Vote: Yes. On 6/29/2015 2:53 AM, Konstantin Shefov wrote: > I hereby nominate Artem Smotrakov to jdk9 Committer. > > Artem is a member of the Java SE Security Libs SQE team. > He has spent most of that time working on Java security tests. > > He has contributed 9 changes to jdk9 so far: > > 8129575: Equal DelegationPermission instances may return different > hash codes > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/ad204c67c4a7 > 8078823: javax/net/ssl/ciphersuites/DisabledAlgorithms.java fails > intermittently > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/d9a57d498a29 > 8050374: More Signature tests > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/2c827d6e90c4 > 8079140: IgnoreAllErrorHandler should use doPrivileged when it reads > system properties > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/f717a1d287b0 > 8079138: Additional negative tests for XML signature processing > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/ce95c2b9b2cc > 8076486: [TESTBUG] javax/security/auth/Subject/doAs/NestedActions.java > fails if extra VM options are given > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/fff8ab918557 > 8075007: Additional tests for krb5-related cipher suites with unbound > server > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/76b64929271b > 8048138: Tests for JAAS callbacks > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/1e5cc55ae5d3 > 8076221: Disable RC4 cipher suites > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/23cde932f139 > > Votes are due by July 13, 2015. > > Only current JDK9 Committers [1] are eligible to vote on this > nomination. > > For Lazy Consensus voting instructions, see [2]. > > Thanks, > kshefov > > [1] http://openjdk.java.net/census#jdk9 > [2] http://openjdk.java.net/projects#committer-vote > -- Java Platform Group Oracle Corporation. (408)276-7564 From vladimir.x.ivanov at oracle.com Mon Jun 29 14:36:02 2015 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Mon, 29 Jun 2015 17:36:02 +0300 Subject: CFV: New JDK9 Committer: Artem Smotrakov In-Reply-To: <5591159C.9000200@oracle.com> References: <5591159C.9000200@oracle.com> Message-ID: <559157D2.3030009@oracle.com> Vote: yes Best regards, Vladimir Ivanov On 6/29/15 12:53 PM, Konstantin Shefov wrote: > I hereby nominate Artem Smotrakov to jdk9 Committer. > > Artem is a member of the Java SE Security Libs SQE team. > He has spent most of that time working on Java security tests. > > He has contributed 9 changes to jdk9 so far: > > 8129575: Equal DelegationPermission instances may return different hash > codes > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/ad204c67c4a7 > 8078823: javax/net/ssl/ciphersuites/DisabledAlgorithms.java fails > intermittently > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/d9a57d498a29 > 8050374: More Signature tests > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/2c827d6e90c4 > 8079140: IgnoreAllErrorHandler should use doPrivileged when it reads > system properties > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/f717a1d287b0 > 8079138: Additional negative tests for XML signature processing > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/ce95c2b9b2cc > 8076486: [TESTBUG] javax/security/auth/Subject/doAs/NestedActions.java > fails if extra VM options are given > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/fff8ab918557 > 8075007: Additional tests for krb5-related cipher suites with unbound > server > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/76b64929271b > 8048138: Tests for JAAS callbacks > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/1e5cc55ae5d3 > 8076221: Disable RC4 cipher suites > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/23cde932f139 > > Votes are due by July 13, 2015. > > Only current JDK9 Committers [1] are eligible to vote on this > nomination. > > For Lazy Consensus voting instructions, see [2]. > > Thanks, > kshefov > > [1] http://openjdk.java.net/census#jdk9 > [2] http://openjdk.java.net/projects#committer-vote > From henri at tremblay.pro Mon Jun 29 16:02:57 2015 From: henri at tremblay.pro (Henri Tremblay) Date: Mon, 29 Jun 2015 12:02:57 -0400 Subject: Replacing Unsafe.allocateInstance In-Reply-To: <558EB8B7.4000102@redhat.com> References: <558EB8B7.4000102@redhat.com> Message-ID: I do understand this is not the classical way to do an object. So it might need to be protected even though the current way to do it are not that much. It needs to be in the official API, like other Unsafe methods because it is useful and needed. It is currently used by the serialization API. So other frameworks that want to emulate the serialization should also be allowed to. Right now they are hacking (for instance XStream) like Objenesis is doing. JMock, Mockito and EasyMock are also hacking (using Objenesis or something alike). It's been more than 10 years. So, being pragmatic, not having to hack around would be a great relief. *Note:* We do not need to advertise it too much ;-) I'm don't plan to add Object.allocateInstance. Maybe moving com.sun.deploy.util.ReflectionUtil to java.lang.reflect. I'm interested about performance because I do know some are using Objenesis to instantiate objects quickly. I had some requests about that in the past. However, I'm not sure that is still useful since my latest benchmarks are showing that "new" is as fast. But indeed, 20ns is pretty fast. On 27 June 2015 at 10:52, Andrew Haley wrote: > On 27/06/15 01:54, Henri Tremblay wrote: > > The problems to solve seem to be: > > > > 1. Find a place to put the new method in the official java.* API > > 2. Make it fast > > But Java is designed to stop people from creating objects without a > constructor. There are several places where this is required in order > to guarantee security. So I can't see much hope of it ever being part > of the official API. > > As to why Unsafe.allocateInstance() is slow, I have to admit that's a > mystery to me. allocateInstance() should inline quite nicely. I > suppose it might be a little bit slower if HotSpot can't determine > during compilation the class you're trying to create. But I'm looking > at UnsafeFactoryInstantiator.java and it should be fine. > > The only thing to do is to do some measurements and look at the > generated code. Mind you, 20ns is still pretty fast. > > Andrew. > From ciro.santilli at gmail.com Fri Jun 26 09:12:41 2015 From: ciro.santilli at gmail.com (Ciro Santilli) Date: Fri, 26 Jun 2015 11:12:41 +0200 Subject: Add javap option to show the original source code lines intermingled with the bytecode like objdump -S Message-ID: Sample input: public class New { public static void main(String[] args) { System.out.println(new Integer(1)); } } Actual `javap` output: 0: getstatic #2 // Field java/lang/System.out:Ljava/io/PrintStream; 3: new #3 // class java/lang/Integer 6: dup 7: iconst_1 8: invokespecial #4 // Method java/lang/Integer."":(I)V 11: invokevirtual #5 // Method java/io/PrintStream.println:(Ljava/lang/Object;)V 14: return LineNumberTable: line 3: 0 line 4: 14 Desired javap output with the new option: System.out.println(new Integer(1)); 0: getstatic #2 // Field java/lang/System.out:Ljava/io/PrintStream; 3: new #3 // class java/lang/Integer 6: dup 7: iconst_1 8: invokespecial #4 // Method java/lang/Integer."":(I)V 11: invokevirtual #5 // Method java/io/PrintStream.println:(Ljava/lang/Object;)V } 14: return LineNumberTable: line 3: 0 line 4: 14 That would make it much easier to interpret `javap` output. I know that this debug information is contained in the .class file when compiling with: javac -g Main.java and can be observed manually from the `LineNumberTable:` section of: javap -c -constants -private -verbose '$<' > '$@' From doug.simon at oracle.com Mon Jun 29 17:48:46 2015 From: doug.simon at oracle.com (Doug Simon) Date: Mon, 29 Jun 2015 19:48:46 +0200 Subject: [9] RFR(M): 8076112: Add @HotSpotIntrinsicCandidate annotation to indicate methods for which Java Runtime has intrinsics In-Reply-To: <559141C3.7000909@redhat.com> References: <558BEABD.7090907@oracle.com> <558E594E.7080906@redhat.com> <559112D1.5000903@oracle.com> <559113BB.1020106@redhat.com> <559120C8.5070208@oracle.com> <559141C3.7000909@redhat.com> Message-ID: <9CDED78E-AC52-444C-95E0-6453D6E8D86C@oracle.com> > On Jun 29, 2015, at 3:01 PM, Andrew Haley wrote: > > On 06/29/2015 01:38 PM, Doug Simon wrote: > >> I seems just plain wrong for an intrinsic to not implement the same >> semantics as the intrinsified method. I would expect an intrinsic to >> perform all necessary runtime checks and only have the compiler omit >> them if it can prove they are unnecessary. If all intrinsics obeyed >> this contract, then there?s no need for the >> @HotSpotIntrinsicCandidate annotation from a semantics >> perspective. And in terms of the keeping HotSpot in sync with the >> JDK, the responsibility should fall entirely on HotSpot to check >> that its intrinsics correspond to existing methods. > > Don't you think you're being rather idealistic? The other side of the > argument is that it's much easier to write and maintain the > arg-checking code if it's written in Java, and it also has the > advantage that it benefits from profile data to guide the JIT. As I understand it, part of this change is to split intrinsification into one method that does the checks that then calls a second method which the VM may intrinsify on the assumption all checks have been performed by the first method. What?s to prevent a direct call to the latter via reflection that by-passes the first method? I understand that writing the checking logic in Java is desirable. Indeed, it?s possible: http://hg.openjdk.java.net/graal/graal/file/tip/graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/AESCryptSubstitutions.java#l95 Adding these checks did not impact the score for the SPECjvm2008 crypto.aes benchmark on Graal. I?m not sure if this performance non-impact holds for all existing intrinsics but unless one can guarantee an intrinsified method will only be executed after the necessary checks have been performed, one is asking for trouble. Maybe hiding the intrinsifiable methods from reflection is sufficient? -Doug From chris.hegarty at oracle.com Mon Jun 29 18:17:22 2015 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 29 Jun 2015 19:17:22 +0100 Subject: Replacing Unsafe.allocateInstance In-Reply-To: References: <558EB8B7.4000102@redhat.com> Message-ID: Henri, As part of the investigation into replacements for current Unsafe usages, allocateInstance is on our list. We?re just not at the point of having anything to share yet. But it is, like anything else, being considered. On 29 Jun 2015, at 17:02, Henri Tremblay wrote: > I do understand this is not the classical way to do an object. So it might > need to be protected even though the current way to do it are not that much. > > It needs to be in the official API, like other Unsafe methods because it is > useful and needed. It is currently used by the serialization API. So other > frameworks that want to emulate the serialization should also be allowed > to. Right now they are hacking (for instance XStream) like Objenesis is > doing. JMock, Mockito and EasyMock are also hacking (using Objenesis or > something alike). I have taken a look at some of these libraries, and it is disappointing that they have had to resort to such ?hacks?. But as you say, that is the reality that they have been facing for the past 10+ years. I?m hopeful that we?ve moved on and can accept that this type of object creation happens in the real world, and work towards a supported ?safer? way in the future. > It's been more than 10 years. So, being pragmatic, not having to hack > around would be a great relief. > *Note:* We do not need to advertise it too much ;-) I'm don't plan to add > Object.allocateInstance. Maybe moving com.sun.deploy.util.ReflectionUtil to > java.lang.reflect. Core reflection seems like the best fit, with the appropriate security restrictions. > I'm interested about performance because I do know some are using Objenesis > to instantiate objects quickly. I had some requests about that in the past. > However, I'm not sure that is still useful since my latest benchmarks are > showing that "new" is as fast. But indeed, 20ns is pretty fast. Ah, I was not aware that performance was super critical here. ( I have not looked into your benchmark results yet ). newConstructorForSerialization() will do a ?new? followed by an invokespecial on the no-args (super)class constructor, or j.l.Object in some of your cases. -Chris. > On 27 June 2015 at 10:52, Andrew Haley wrote: > >> On 27/06/15 01:54, Henri Tremblay wrote: >>> The problems to solve seem to be: >>> >>> 1. Find a place to put the new method in the official java.* API >>> 2. Make it fast >> >> But Java is designed to stop people from creating objects without a >> constructor. There are several places where this is required in order >> to guarantee security. So I can't see much hope of it ever being part >> of the official API. >> >> As to why Unsafe.allocateInstance() is slow, I have to admit that's a >> mystery to me. allocateInstance() should inline quite nicely. I >> suppose it might be a little bit slower if HotSpot can't determine >> during compilation the class you're trying to create. But I'm looking >> at UnsafeFactoryInstantiator.java and it should be fine. >> >> The only thing to do is to do some measurements and look at the >> generated code. Mind you, 20ns is still pretty fast. >> >> Andrew. >> From konstantin.shefov at oracle.com Mon Jun 29 18:17:59 2015 From: konstantin.shefov at oracle.com (Konstantin Shefov) Date: Mon, 29 Jun 2015 21:17:59 +0300 Subject: CFV: New JDK9 Committer: Artem Smotrakov In-Reply-To: <5591159C.9000200@oracle.com> References: <5591159C.9000200@oracle.com> Message-ID: <55918BD7.6090200@oracle.com> I would like to add more Artem's changesets: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/021b47694183 http://hg.openjdk.java.net/jdk9/dev/jdk/rev/eafa41f4e9fd http://hg.openjdk.java.net/jdk9/dev/jdk/rev/d0a5383a63ad http://hg.openjdk.java.net/jdk9/dev/jdk/rev/3fca37c636be http://hg.openjdk.java.net/jdk9/dev/jdk/rev/89631a384ee6 -Konstantin 29.06.2015 12:53, Konstantin Shefov ?????: > I hereby nominate Artem Smotrakov to jdk9 Committer. > > Artem is a member of the Java SE Security Libs SQE team. > He has spent most of that time working on Java security tests. > > He has contributed 9 changes to jdk9 so far: > > 8129575: Equal DelegationPermission instances may return different > hash codes > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/ad204c67c4a7 > 8078823: javax/net/ssl/ciphersuites/DisabledAlgorithms.java fails > intermittently > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/d9a57d498a29 > 8050374: More Signature tests > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/2c827d6e90c4 > 8079140: IgnoreAllErrorHandler should use doPrivileged when it reads > system properties > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/f717a1d287b0 > 8079138: Additional negative tests for XML signature processing > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/ce95c2b9b2cc > 8076486: [TESTBUG] javax/security/auth/Subject/doAs/NestedActions.java > fails if extra VM options are given > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/fff8ab918557 > 8075007: Additional tests for krb5-related cipher suites with unbound > server > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/76b64929271b > 8048138: Tests for JAAS callbacks > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/1e5cc55ae5d3 > 8076221: Disable RC4 cipher suites > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/23cde932f139 > > Votes are due by July 13, 2015. > > Only current JDK9 Committers [1] are eligible to vote on this > nomination. > > For Lazy Consensus voting instructions, see [2]. > > Thanks, > kshefov > > [1] http://openjdk.java.net/census#jdk9 > [2] http://openjdk.java.net/projects#committer-vote > From Sergey.Bylokhov at oracle.com Mon Jun 29 18:22:20 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 29 Jun 2015 21:22:20 +0300 Subject: CFV: New JDK9 Committer: Artem Smotrakov In-Reply-To: <5591159C.9000200@oracle.com> References: <5591159C.9000200@oracle.com> Message-ID: <55918CDC.1010507@oracle.com> Vote: Yes On 29.06.15 12:53, Konstantin Shefov wrote: > I hereby nominate Artem Smotrakov to jdk9 Committer. > > Artem is a member of the Java SE Security Libs SQE team. > He has spent most of that time working on Java security tests. > > He has contributed 9 changes to jdk9 so far: > > 8129575: Equal DelegationPermission instances may return different > hash codes > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/ad204c67c4a7 > 8078823: javax/net/ssl/ciphersuites/DisabledAlgorithms.java fails > intermittently > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/d9a57d498a29 > 8050374: More Signature tests > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/2c827d6e90c4 > 8079140: IgnoreAllErrorHandler should use doPrivileged when it reads > system properties > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/f717a1d287b0 > 8079138: Additional negative tests for XML signature processing > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/ce95c2b9b2cc > 8076486: [TESTBUG] javax/security/auth/Subject/doAs/NestedActions.java > fails if extra VM options are given > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/fff8ab918557 > 8075007: Additional tests for krb5-related cipher suites with unbound > server > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/76b64929271b > 8048138: Tests for JAAS callbacks > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/1e5cc55ae5d3 > 8076221: Disable RC4 cipher suites > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/23cde932f139 > > Votes are due by July 13, 2015. > > Only current JDK9 Committers [1] are eligible to vote on this > nomination. > > For Lazy Consensus voting instructions, see [2]. > > Thanks, > kshefov > > [1] http://openjdk.java.net/census#jdk9 > [2] http://openjdk.java.net/projects#committer-vote > -- Best regards, Sergey. From konstantin.shefov at oracle.com Mon Jun 29 18:40:18 2015 From: konstantin.shefov at oracle.com (Konstantin Shefov) Date: Mon, 29 Jun 2015 21:40:18 +0300 Subject: CFV: New JDK9 Committer: Artem Smotrakov In-Reply-To: <55918BD7.6090200@oracle.com> References: <5591159C.9000200@oracle.com> <55918BD7.6090200@oracle.com> Message-ID: <55919112.1090602@oracle.com> And some more changesets: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/d0f7b627de0e http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/e073b47e1563 -Konstantin 29.06.2015 21:17, Konstantin Shefov ?????: > I would like to add more Artem's changesets: > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/021b47694183 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/eafa41f4e9fd > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/d0a5383a63ad > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/3fca37c636be > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/89631a384ee6 > > -Konstantin > > 29.06.2015 12:53, Konstantin Shefov ?????: >> I hereby nominate Artem Smotrakov to jdk9 Committer. >> >> Artem is a member of the Java SE Security Libs SQE team. >> He has spent most of that time working on Java security tests. >> >> He has contributed 9 changes to jdk9 so far: >> >> 8129575: Equal DelegationPermission instances may return different >> hash codes >> http://hg.openjdk.java.net/jdk9/dev/jdk/rev/ad204c67c4a7 >> 8078823: javax/net/ssl/ciphersuites/DisabledAlgorithms.java fails >> intermittently >> http://hg.openjdk.java.net/jdk9/dev/jdk/rev/d9a57d498a29 >> 8050374: More Signature tests >> http://hg.openjdk.java.net/jdk9/dev/jdk/rev/2c827d6e90c4 >> 8079140: IgnoreAllErrorHandler should use doPrivileged when it reads >> system properties >> http://hg.openjdk.java.net/jdk9/dev/jdk/rev/f717a1d287b0 >> 8079138: Additional negative tests for XML signature processing >> http://hg.openjdk.java.net/jdk9/dev/jdk/rev/ce95c2b9b2cc >> 8076486: [TESTBUG] >> javax/security/auth/Subject/doAs/NestedActions.java fails if extra VM >> options are given >> http://hg.openjdk.java.net/jdk9/dev/jdk/rev/fff8ab918557 >> 8075007: Additional tests for krb5-related cipher suites with unbound >> server >> http://hg.openjdk.java.net/jdk9/dev/jdk/rev/76b64929271b >> 8048138: Tests for JAAS callbacks >> http://hg.openjdk.java.net/jdk9/dev/jdk/rev/1e5cc55ae5d3 >> 8076221: Disable RC4 cipher suites >> http://hg.openjdk.java.net/jdk9/dev/jdk/rev/23cde932f139 >> >> Votes are due by July 13, 2015. >> >> Only current JDK9 Committers [1] are eligible to vote on this >> nomination. >> >> For Lazy Consensus voting instructions, see [2]. >> >> Thanks, >> kshefov >> >> [1] http://openjdk.java.net/census#jdk9 >> [2] http://openjdk.java.net/projects#committer-vote >> > From alexander.zvegintsev at oracle.com Mon Jun 29 18:59:09 2015 From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev) Date: Mon, 29 Jun 2015 21:59:09 +0300 Subject: CFV: New JDK9 Committer: Artem Smotrakov In-Reply-To: <5591159C.9000200@oracle.com> References: <5591159C.9000200@oracle.com> Message-ID: <5591957D.4090903@oracle.com> Vote: yes -- Thanks, Alexander. On 29.06.2015 12:53, Konstantin Shefov wrote: > I hereby nominate Artem Smotrakov to jdk9 Committer. > > Artem is a member of the Java SE Security Libs SQE team. > He has spent most of that time working on Java security tests. > > He has contributed 9 changes to jdk9 so far: > > 8129575: Equal DelegationPermission instances may return different > hash codes > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/ad204c67c4a7 > 8078823: javax/net/ssl/ciphersuites/DisabledAlgorithms.java fails > intermittently > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/d9a57d498a29 > 8050374: More Signature tests > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/2c827d6e90c4 > 8079140: IgnoreAllErrorHandler should use doPrivileged when it reads > system properties > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/f717a1d287b0 > 8079138: Additional negative tests for XML signature processing > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/ce95c2b9b2cc > 8076486: [TESTBUG] javax/security/auth/Subject/doAs/NestedActions.java > fails if extra VM options are given > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/fff8ab918557 > 8075007: Additional tests for krb5-related cipher suites with unbound > server > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/76b64929271b > 8048138: Tests for JAAS callbacks > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/1e5cc55ae5d3 > 8076221: Disable RC4 cipher suites > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/23cde932f139 > > Votes are due by July 13, 2015. > > Only current JDK9 Committers [1] are eligible to vote on this > nomination. > > For Lazy Consensus voting instructions, see [2]. > > Thanks, > kshefov > > [1] http://openjdk.java.net/census#jdk9 > [2] http://openjdk.java.net/projects#committer-vote > From henri at tremblay.pro Mon Jun 29 20:23:03 2015 From: henri at tremblay.pro (Henri Tremblay) Date: Mon, 29 Jun 2015 16:23:03 -0400 Subject: Replacing Unsafe.allocateInstance In-Reply-To: References: <558EB8B7.4000102@redhat.com> Message-ID: I'm really happy to read your answers :-) I'm looking forward for your feedback on the benchmark. I'll revisit it myself when I have time. I'm in fact hoping that my benchmark is plainly wrong. That would simplify things :-) On 29 June 2015 at 14:17, Chris Hegarty wrote: > Henri, > > As part of the investigation into replacements for current Unsafe usages, > allocateInstance is on our list. We?re just not at the point of having > anything to share yet. But it is, like anything else, being considered. > > On 29 Jun 2015, at 17:02, Henri Tremblay wrote: > > > I do understand this is not the classical way to do an object. So it > might > > need to be protected even though the current way to do it are not that > much. > > > > It needs to be in the official API, like other Unsafe methods because it > is > > useful and needed. It is currently used by the serialization API. So > other > > frameworks that want to emulate the serialization should also be allowed > > to. Right now they are hacking (for instance XStream) like Objenesis is > > doing. JMock, Mockito and EasyMock are also hacking (using Objenesis or > > something alike). > > I have taken a look at some of these libraries, and it is disappointing > that they have had to resort to such ?hacks?. But as you say, that is the > reality that they have been facing for the past 10+ years. I?m hopeful > that we?ve moved on and can accept that this type of object creation > happens in the real world, and work towards a supported ?safer? way in the > future. > > > It's been more than 10 years. So, being pragmatic, not having to hack > > around would be a great relief. > > > *Note:* We do not need to advertise it too much ;-) I'm don't plan to add > > Object.allocateInstance. Maybe moving com.sun.deploy.util.ReflectionUtil > to > > java.lang.reflect. > > Core reflection seems like the best fit, with the appropriate security > restrictions. > > > I'm interested about performance because I do know some are using > Objenesis > > to instantiate objects quickly. I had some requests about that in the > past. > > However, I'm not sure that is still useful since my latest benchmarks are > > showing that "new" is as fast. But indeed, 20ns is pretty fast. > > Ah, I was not aware that performance was super critical here. ( I have not > looked into your benchmark results yet ). > > newConstructorForSerialization() will do a ?new? followed by an > invokespecial on the no-args (super)class constructor, or j.l.Object in > some of your cases. > > -Chris. > > > On 27 June 2015 at 10:52, Andrew Haley wrote: > > > >> On 27/06/15 01:54, Henri Tremblay wrote: > >>> The problems to solve seem to be: > >>> > >>> 1. Find a place to put the new method in the official java.* API > >>> 2. Make it fast > >> > >> But Java is designed to stop people from creating objects without a > >> constructor. There are several places where this is required in order > >> to guarantee security. So I can't see much hope of it ever being part > >> of the official API. > >> > >> As to why Unsafe.allocateInstance() is slow, I have to admit that's a > >> mystery to me. allocateInstance() should inline quite nicely. I > >> suppose it might be a little bit slower if HotSpot can't determine > >> during compilation the class you're trying to create. But I'm looking > >> at UnsafeFactoryInstantiator.java and it should be fine. > >> > >> The only thing to do is to do some measurements and look at the > >> generated code. Mind you, 20ns is still pretty fast. > >> > >> Andrew. > >> > > From john.r.rose at oracle.com Mon Jun 29 20:47:41 2015 From: john.r.rose at oracle.com (John Rose) Date: Mon, 29 Jun 2015 13:47:41 -0700 Subject: [9] RFR(M): 8076112: Add @HotSpotIntrinsicCandidate annotation to indicate methods for which Java Runtime has intrinsics In-Reply-To: <9CDED78E-AC52-444C-95E0-6453D6E8D86C@oracle.com> References: <558BEABD.7090907@oracle.com> <558E594E.7080906@redhat.com> <559112D1.5000903@oracle.com> <559113BB.1020106@redhat.com> <559120C8.5070208@oracle.com> <559141C3.7000909@redhat.com> <9CDED78E-AC52-444C-95E0-6453D6E8D86C@oracle.com> Message-ID: On Jun 29, 2015, at 10:48 AM, Doug Simon wrote: > > As I understand it, part of this change is to split intrinsification into one method that does the checks that then calls a second method which the VM may intrinsify on the assumption all checks have been performed by the first method. What?s to prevent a direct call to the latter via reflection that by-passes the first method? The answer is simple: We mark the dangerous method private. I assume you are thinking about setAccessible, but if that's allowed there's nothing to prevent people from taking whole system down in a hundred different ways. At that point having a surprising intrinsic is the least of our problems. > I understand that writing the checking logic in Java is desirable. Indeed, that is the key compromise here. Coding the required checks in assembly code or compiler IR is (as we all know) a losing battle. You need Maxine/Graal snippets or real Java code to get it right. ? John From filipp.zhinkin at gmail.com Tue Jun 30 06:05:27 2015 From: filipp.zhinkin at gmail.com (Filipp Zhinkin) Date: Tue, 30 Jun 2015 09:05:27 +0300 Subject: CFV: New JDK9 Committer: Artem Smotrakov In-Reply-To: <5591159C.9000200@oracle.com> References: <5591159C.9000200@oracle.com> Message-ID: Vote: Yes On Mon, Jun 29, 2015 at 12:53 PM, Konstantin Shefov wrote: > I hereby nominate Artem Smotrakov to jdk9 Committer. > > Artem is a member of the Java SE Security Libs SQE team. > He has spent most of that time working on Java security tests. > > He has contributed 9 changes to jdk9 so far: > > 8129575: Equal DelegationPermission instances may return different hash > codes > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/ad204c67c4a7 > 8078823: javax/net/ssl/ciphersuites/DisabledAlgorithms.java fails > intermittently > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/d9a57d498a29 > 8050374: More Signature tests > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/2c827d6e90c4 > 8079140: IgnoreAllErrorHandler should use doPrivileged when it reads system > properties > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/f717a1d287b0 > 8079138: Additional negative tests for XML signature processing > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/ce95c2b9b2cc > 8076486: [TESTBUG] javax/security/auth/Subject/doAs/NestedActions.java fails > if extra VM options are given > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/fff8ab918557 > 8075007: Additional tests for krb5-related cipher suites with unbound server > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/76b64929271b > 8048138: Tests for JAAS callbacks > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/1e5cc55ae5d3 > 8076221: Disable RC4 cipher suites > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/23cde932f139 > > Votes are due by July 13, 2015. > > Only current JDK9 Committers [1] are eligible to vote on this > nomination. > > For Lazy Consensus voting instructions, see [2]. > > Thanks, > kshefov > > [1] http://openjdk.java.net/census#jdk9 > [2] http://openjdk.java.net/projects#committer-vote > From doug.simon at oracle.com Tue Jun 30 06:17:00 2015 From: doug.simon at oracle.com (Doug Simon) Date: Tue, 30 Jun 2015 08:17:00 +0200 Subject: [9] RFR(M): 8076112: Add @HotSpotIntrinsicCandidate annotation to indicate methods for which Java Runtime has intrinsics In-Reply-To: References: <558BEABD.7090907@oracle.com> <558E594E.7080906@redhat.com> <559112D1.5000903@oracle.com> <559113BB.1020106@redhat.com> <559120C8.5070208@oracle.com> <559141C3.7000909@redhat.com> <9CDED78E-AC52-444C-95E0-6453D6E8D86C@oracle.com> Message-ID: <9BC916B0-B9CF-42F7-8D94-BCF2AA351FA8@oracle.com> > On Jun 29, 2015, at 10:47 PM, John Rose wrote: > > On Jun 29, 2015, at 10:48 AM, Doug Simon wrote: >> >> As I understand it, part of this change is to split intrinsification into one method that does the checks that then calls a second method which the VM may intrinsify on the assumption all checks have been performed by the first method. What?s to prevent a direct call to the latter via reflection that by-passes the first method? > > The answer is simple: We mark the dangerous method private. > > I assume you are thinking about setAccessible, but if that's allowed there's nothing to prevent people from taking whole system down in a hundred different ways. At that point having a surprising intrinsic is the least of our problems. Ok, thanks for the clarification John. I?ll admit to occasionally forgetting that setAccessible is as unsafe as, well, Unsafe. >> I understand that writing the checking logic in Java is desirable. > > Indeed, that is the key compromise here. Coding the required checks in assembly code or compiler IR is (as we all know) a losing battle. You need Maxine/Graal snippets or real Java code to get it right. Snippets certainly make it easier. I?m surprised though that existing C2 IR logic for expressing runtime checks cannot be easily leveraged for some intrinsics. My perspective may shift rapidly though were I tasked with doing it ;-) -Doug From yuri.nesterenko at oracle.com Tue Jun 30 07:28:19 2015 From: yuri.nesterenko at oracle.com (Yuri Nesterenko) Date: Tue, 30 Jun 2015 10:28:19 +0300 Subject: CFV: New JDK9 Committer: Artem Smotrakov In-Reply-To: <5591159C.9000200@oracle.com> References: <5591159C.9000200@oracle.com> Message-ID: <55924513.6010303@oracle.com> Vote: yes -yan On 06/29/2015 12:53 PM, Konstantin Shefov wrote: > I hereby nominate Artem Smotrakov to jdk9 Committer. > > Artem is a member of the Java SE Security Libs SQE team. > He has spent most of that time working on Java security tests. > > He has contributed 9 changes to jdk9 so far: > > 8129575: Equal DelegationPermission instances may return different hash > codes > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/ad204c67c4a7 > 8078823: javax/net/ssl/ciphersuites/DisabledAlgorithms.java fails > intermittently > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/d9a57d498a29 > 8050374: More Signature tests > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/2c827d6e90c4 > 8079140: IgnoreAllErrorHandler should use doPrivileged when it reads > system properties > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/f717a1d287b0 > 8079138: Additional negative tests for XML signature processing > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/ce95c2b9b2cc > 8076486: [TESTBUG] javax/security/auth/Subject/doAs/NestedActions.java > fails if extra VM options are given > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/fff8ab918557 > 8075007: Additional tests for krb5-related cipher suites with unbound > server > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/76b64929271b > 8048138: Tests for JAAS callbacks > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/1e5cc55ae5d3 > 8076221: Disable RC4 cipher suites > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/23cde932f139 > > Votes are due by July 13, 2015. > > Only current JDK9 Committers [1] are eligible to vote on this > nomination. > > For Lazy Consensus voting instructions, see [2]. > > Thanks, > kshefov > > [1] http://openjdk.java.net/census#jdk9 > [2] http://openjdk.java.net/projects#committer-vote > From zoltan.majo at oracle.com Tue Jun 30 08:24:34 2015 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Tue, 30 Jun 2015 10:24:34 +0200 Subject: [9] RFR(M): 8076112: Add @HotSpotIntrinsicCandidate annotation to indicate methods for which Java Runtime has intrinsics In-Reply-To: References: <558BEABD.7090907@oracle.com> <558E594E.7080906@redhat.com> <559112D1.5000903@oracle.com> <559113BB.1020106@redhat.com> <559120C8.5070208@oracle.com> <559141C3.7000909@redhat.com> <9CDED78E-AC52-444C-95E0-6453D6E8D86C@oracle.com> Message-ID: <55925242.4070909@oracle.com> On 06/29/2015 10:47 PM, John Rose wrote: > On Jun 29, 2015, at 10:48 AM, Doug Simon > wrote: >> >> As I understand it, part of this change is to split intrinsification >> into one method that does the checks that then calls a second method >> which the VM may intrinsify on the assumption all checks have been >> performed by the first method. What?s to prevent a direct call to the >> latter via reflection that by-passes the first method? > > The answer is simple: We mark the dangerous method private. > > I assume you are thinking about setAccessible, but if that's allowed > there's nothing to prevent people from taking whole system down in a > hundred different ways. At that point having a surprising intrinsic > is the least of our problems. > >> I understand that writing the checking logic in Java is desirable. > > Indeed, that is the key compromise here. Coding the required checks > in assembly code or compiler IR is (as we all know) a losing battle. > You need Maxine/Graal snippets or real Java code to get it right. Thank you, Doug, for bringing up these issues. Thank you, John, for the clarifications. Best regards, Zoltan > > ? John From paul.sandoz at oracle.com Tue Jun 30 09:22:01 2015 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 30 Jun 2015 11:22:01 +0200 Subject: Replacing Unsafe.allocateInstance In-Reply-To: References: <558EB8B7.4000102@redhat.com> Message-ID: Hi Henri, Thanks for raising this discussion. Just to augment what Chris says here. We cannot directly expose Unsafe.allocateInstance in a public API and try and place in a little known corner and hope only the people who are meant to use it will and will do so responsibly :-) There are a bunch of general use-cases: 1) Mocking; 2) Proxying; and 3) Serialization. It should be possible to corral 3 (and possibly 2) in some safe mechanism. I dunno how to do that for 1. Constructing an object without calling its constructor is inherently integrity busting (unless somehow hidden or contained) and IIUC mocking by design is a form of semi-controlled integrity busting. Would i be correct in assuming that mocking is primarily used for testing and that if used in production would raise some eye brows? One approach we could consider for 1, trying to be pragmatic and recognising the reality here, is a method that constructs an object without calling it's constructor under the following conditions: 1) a security check is performed if a security manager is present; and 2) it would not be possible to construct any JDK class (e.g. classes loaded by the boot loader). That is not a definite proposal but i would be really interested in your feedback given your experience with Objenesis and mocking. Paul. From paul.sandoz at oracle.com Tue Jun 30 12:08:53 2015 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 30 Jun 2015 14:08:53 +0200 Subject: Replacing Unsafe.allocateInstance In-Reply-To: References: Message-ID: <6BFDC87C-C8AE-412A-83E2-67B2B75567F1@oracle.com> On Jun 27, 2015, at 2:54 AM, Henri Tremblay wrote: > My latest benchmarks were showing it much slower than > ReflectionFactory.newConstructorForSerialization. I must confess I haven't > had the time to investigate correctly to see where the difference is coming > from. And haven't try with JDK9 yet. > I observe similar performance results on JDK9. Place the type in a static final field and you should see similar performance to ordinary object construction. So in part it might be because HotSpot cannot constant fold certain operations associated with the type. You will also notice a difference if say java.util.ArrayList is used instead of java.lang.Object. The former is slightly faster. I dunno why. I suspect ReflectionFactory.newConstructorForSerialization is faster than Unsafe.allocateInstance because the former spins up a class that specifically constructs the type. Although it appears the wrapping Constructor around an instance of that spun up class may be susceptible to profile pollution. Paul. From stefan.sarne at oracle.com Tue Jun 30 12:54:25 2015 From: stefan.sarne at oracle.com (=?windows-1252?Q?Stefan_S=E4rne?=) Date: Tue, 30 Jun 2015 14:54:25 +0200 Subject: RFR(S): 6896810:TEST_BUG: java/lang/ref/SoftReference/Pin.java fails with OOME during System.out.println Message-ID: <55929181.3040201@oracle.com> Hi all, Please review and sponsor this fix. Bug: https://bugs.openjdk.java.net/browse/JDK-6896810 Webrev: http://cr.openjdk.java.net/~sjohanss/sponsor/ssarne/JDK-6896810/webrev.jdk.00/ The test fails since it run out of memory (again) when it tries to print that the expected OOME is received. Additional allocations are done during printing and the next OOME is thrown out of the test. By freeing the "chain" that hogs the memory on the heap, the test continues and the additional checks of checking that the blocks are empty are performed and pass. Tested: Run with all GC combinations. The test is part of tier1 for the jdk and this blocks integration from jdk9/hs to jdk9/dev and I therefore suggest it is integrated directly to jdk9/hs. Thanks, Stefan From stefan.karlsson at oracle.com Tue Jun 30 13:00:12 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Tue, 30 Jun 2015 15:00:12 +0200 Subject: RFR(S): 6896810:TEST_BUG: java/lang/ref/SoftReference/Pin.java fails with OOME during System.out.println In-Reply-To: <55929181.3040201@oracle.com> References: <55929181.3040201@oracle.com> Message-ID: <559292DC.1010808@oracle.com> Looks good. StefanK On 2015-06-30 14:54, Stefan S?rne wrote: > > Hi all, > > Please review and sponsor this fix. > > Bug: https://bugs.openjdk.java.net/browse/JDK-6896810 > Webrev: > http://cr.openjdk.java.net/~sjohanss/sponsor/ssarne/JDK-6896810/webrev.jdk.00/ > > The test fails since it run out of memory (again) when it tries to > print that the expected OOME is received. Additional allocations are > done during printing and the next OOME is thrown out of the test. By > freeing the "chain" that hogs the memory on the heap, the test > continues and the additional checks of checking that the blocks are > empty are performed and pass. > > Tested: Run with all GC combinations. > > The test is part of tier1 for the jdk and this blocks integration from > jdk9/hs to jdk9/dev and I therefore suggest it is integrated directly > to jdk9/hs. > > Thanks, > Stefan From david.holmes at oracle.com Tue Jun 30 13:05:48 2015 From: david.holmes at oracle.com (David Holmes) Date: Tue, 30 Jun 2015 23:05:48 +1000 Subject: RFR(S): 6896810:TEST_BUG: java/lang/ref/SoftReference/Pin.java fails with OOME during System.out.println In-Reply-To: <55929181.3040201@oracle.com> References: <55929181.3040201@oracle.com> Message-ID: <5592942C.2080003@oracle.com> cc'ing core-libs-dev as they own this test. On 30/06/2015 10:54 PM, Stefan S?rne wrote: > > Hi all, > > Please review and sponsor this fix. > > Bug: https://bugs.openjdk.java.net/browse/JDK-6896810 > Webrev: > http://cr.openjdk.java.net/~sjohanss/sponsor/ssarne/JDK-6896810/webrev.jdk.00/ > > > The test fails since it run out of memory (again) when it tries to print > that the expected OOME is received. Additional allocations are done > during printing and the next OOME is thrown out of the test. By freeing > the "chain" that hogs the memory on the heap, the test continues and the > additional checks of checking that the blocks are empty are performed > and pass. Seems a reasonable approach to free up the memory - or at least allow a GC to reclaim it. David ----- > Tested: Run with all GC combinations. > > The test is part of tier1 for the jdk and this blocks integration from > jdk9/hs to jdk9/dev and I therefore suggest it is integrated directly to > jdk9/hs. > > Thanks, > Stefan From chris.hegarty at oracle.com Tue Jun 30 13:37:45 2015 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 30 Jun 2015 14:37:45 +0100 Subject: RFR(S): 6896810:TEST_BUG: java/lang/ref/SoftReference/Pin.java fails with OOME during System.out.println In-Reply-To: <5592942C.2080003@oracle.com> References: <55929181.3040201@oracle.com> <5592942C.2080003@oracle.com> Message-ID: <75AD7326-FA7E-47CC-AE3E-25B3B6536E10@oracle.com> On 30 Jun 2015, at 14:05, David Holmes wrote: > cc'ing core-libs-dev as they own this test. > > On 30/06/2015 10:54 PM, Stefan S?rne wrote: >> >> Hi all, >> >> Please review and sponsor this fix. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-6896810 >> Webrev: >> http://cr.openjdk.java.net/~sjohanss/sponsor/ssarne/JDK-6896810/webrev.jdk.00/ >> >> >> The test fails since it run out of memory (again) when it tries to print >> that the expected OOME is received. Additional allocations are done >> during printing and the next OOME is thrown out of the test. By freeing >> the "chain" that hogs the memory on the heap, the test continues and the >> additional checks of checking that the blocks are empty are performed >> and pass. > > Seems a reasonable approach to free up the memory - or at least allow a GC to reclaim it. +1. Looks ok. -Chris. > David > ----- > >> Tested: Run with all GC combinations. >> >> The test is part of tier1 for the jdk and this blocks integration from >> jdk9/hs to jdk9/dev and I therefore suggest it is integrated directly to >> jdk9/hs. >> >> Thanks, >> Stefan From henri at tremblay.pro Tue Jun 30 14:10:39 2015 From: henri at tremblay.pro (Henri Tremblay) Date: Tue, 30 Jun 2015 10:10:39 -0400 Subject: Replacing Unsafe.allocateInstance In-Reply-To: <6BFDC87C-C8AE-412A-83E2-67B2B75567F1@oracle.com> References: <6BFDC87C-C8AE-412A-83E2-67B2B75567F1@oracle.com> Message-ID: I indeed noticed that having a constant class seems indeed to constant fold. So far, I was also suspecting that having a Constructor was allowing to cache part of the work. Then, if we want to keep things simple, we can just get rid of Unsafe.allocateInstance and keep ReflectionFactory. newConstructorForSerialization. On 30 June 2015 at 08:08, Paul Sandoz wrote: > On Jun 27, 2015, at 2:54 AM, Henri Tremblay wrote: > > My latest benchmarks were showing it much slower than > > ReflectionFactory.newConstructorForSerialization. I must confess I > haven't > > had the time to investigate correctly to see where the difference is > coming > > from. And haven't try with JDK9 yet. > > > > I observe similar performance results on JDK9. > > Place the type in a static final field and you should see similar > performance to ordinary object construction. So in part it might be because > HotSpot cannot constant fold certain operations associated with the type. > > You will also notice a difference if say java.util.ArrayList is used > instead of java.lang.Object. The former is slightly faster. I dunno why. > > I suspect ReflectionFactory.newConstructorForSerialization is faster than > Unsafe.allocateInstance because the former spins up a class that > specifically constructs the type. Although it appears the wrapping > Constructor around an instance of that spun up class may be susceptible to > profile pollution. > > Paul. > From paul.sandoz at oracle.com Tue Jun 30 14:28:35 2015 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 30 Jun 2015 16:28:35 +0200 Subject: Replacing Unsafe.allocateInstance In-Reply-To: References: <6BFDC87C-C8AE-412A-83E2-67B2B75567F1@oracle.com> Message-ID: On Jun 30, 2015, at 4:10 PM, Henri Tremblay wrote: > I indeed noticed that having a constant class seems indeed to constant fold. > > So far, I was also suspecting that having a Constructor was allowing to cache part of the work. > Certainly the class spinning can be viewed as part of that, since the type to construct is placed in the constant pool. > Then, if we want to keep things simple, we can just get rid of Unsafe.allocateInstance and keep ReflectionFactory.newConstructorForSerialization. > Yes, perhaps, but obviously not in it's current internal form. It does allow for calling a super constructor. A variant returning method handle might actually be more optimal in terms of handling any constructor parameters to avoid boxing and packing. Paul. From henri at tremblay.pro Tue Jun 30 15:03:32 2015 From: henri at tremblay.pro (Henri Tremblay) Date: Tue, 30 Jun 2015 11:03:32 -0400 Subject: Replacing Unsafe.allocateInstance In-Reply-To: References: <558EB8B7.4000102@redhat.com> Message-ID: Hi, You summarized the 3 usages well. Mocking should be allowed for any class since any class can be mocked. Even the JDK ones Mocking is mainly used for testing but can also be used for stubbing at runtime. Not in production but during development or QA. For instance, you can use a mock from EasyMock and inject it through dependency injection Proxying is indeed another use case. Of course, it is used in production code About serialization, there is one special feature. The Java serialization is in fact calling the default constructor of the first non-serializable parent class. So Objenesis has two kinds of instantiator: 1) Mocking and Proxying: No constructor called (or, to be accurate, only Object default constructor is called) 2) The default constructor of the first non-serializable parent class is called We should support both if we when to help alternate serialization frameworks I think. Unsafe.allocateInstance can't help us for that. Then, I want to make sure I got the security problem right. Right now, the ReflectionFactory isn't protected by anything apart the fact the it is in a sun.* package. So if we move it in a java.* package, we will need to provide a way to add security to it. Am I getting it? Being still pragmatic, I agree with the security side of it, however, I don't think we should put more security on it than what we already have. But I'm not an expert in that domain so I don't know exactly what security features are currently preventing using ReflectionFactory and Unsafe. On 30 June 2015 at 05:22, Paul Sandoz wrote: > Hi Henri, > > Thanks for raising this discussion. > > Just to augment what Chris says here. > > We cannot directly expose Unsafe.allocateInstance in a public API and try > and place in a little known corner and hope only the people who are meant > to use it will and will do so responsibly :-) > > There are a bunch of general use-cases: > > 1) Mocking; > 2) Proxying; and > 3) Serialization. > > It should be possible to corral 3 (and possibly 2) in some safe mechanism. > I dunno how to do that for 1. > > Constructing an object without calling its constructor is inherently > integrity busting (unless somehow hidden or contained) and IIUC mocking by > design is a form of semi-controlled integrity busting. > > Would i be correct in assuming that mocking is primarily used for testing > and that if used in production would raise some eye brows? > > One approach we could consider for 1, trying to be pragmatic and > recognising the reality here, is a method that constructs an object without > calling it's constructor under the following conditions: > > 1) a security check is performed if a security manager is present; and > > 2) it would not be possible to construct any JDK class (e.g. classes > loaded by the boot loader). > > That is not a definite proposal but i would be really interested in your > feedback given your experience with Objenesis and mocking. > > Paul. > From stefan.johansson at oracle.com Tue Jun 30 15:07:34 2015 From: stefan.johansson at oracle.com (Stefan Johansson) Date: Tue, 30 Jun 2015 17:07:34 +0200 Subject: RFR(S): 6896810:TEST_BUG: java/lang/ref/SoftReference/Pin.java fails with OOME during System.out.println In-Reply-To: <75AD7326-FA7E-47CC-AE3E-25B3B6536E10@oracle.com> References: <55929181.3040201@oracle.com> <5592942C.2080003@oracle.com> <75AD7326-FA7E-47CC-AE3E-25B3B6536E10@oracle.com> Message-ID: <5592B0B6.7030809@oracle.com> Looks good to me too, I will sponsor the change and push it to jdk9/hs directly. Stefan On 2015-06-30 15:37, Chris Hegarty wrote: > On 30 Jun 2015, at 14:05, David Holmes wrote: > >> cc'ing core-libs-dev as they own this test. >> >> On 30/06/2015 10:54 PM, Stefan S?rne wrote: >>> Hi all, >>> >>> Please review and sponsor this fix. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-6896810 >>> Webrev: >>> http://cr.openjdk.java.net/~sjohanss/sponsor/ssarne/JDK-6896810/webrev.jdk.00/ >>> >>> >>> The test fails since it run out of memory (again) when it tries to print >>> that the expected OOME is received. Additional allocations are done >>> during printing and the next OOME is thrown out of the test. By freeing >>> the "chain" that hogs the memory on the heap, the test continues and the >>> additional checks of checking that the blocks are empty are performed >>> and pass. >> Seems a reasonable approach to free up the memory - or at least allow a GC to reclaim it. > +1. Looks ok. > > -Chris. > >> David >> ----- >> >>> Tested: Run with all GC combinations. >>> >>> The test is part of tier1 for the jdk and this blocks integration from >>> jdk9/hs to jdk9/dev and I therefore suggest it is integrated directly to >>> jdk9/hs. >>> >>> Thanks, >>> Stefan From brian.goetz at oracle.com Tue Jun 30 15:58:54 2015 From: brian.goetz at oracle.com (Brian Goetz) Date: Tue, 30 Jun 2015 11:58:54 -0400 Subject: Replacing Unsafe.allocateInstance In-Reply-To: References: <558EB8B7.4000102@redhat.com> Message-ID: <5592BCBE.1030403@oracle.com> > Mocking should be allowed for any class since any class can be mocked. Even > the JDK ones An understandable user perspective :) Unfortunately, many serious security bugs can stem from being able to create a bogus instance of a JDK class that is loaded off the bootclasspath, and the existence of vectors for creating these exploits is a negative for the entire ecosystem. So, we may need to make some tradeoffs between security and convenience. (Many JDK APIs primarily expose interfaces anyway; these are easily mocked without magic.) From chris.hegarty at oracle.com Tue Jun 30 17:19:18 2015 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 30 Jun 2015 18:19:18 +0100 Subject: Replacing Unsafe.allocateInstance In-Reply-To: References: <558EB8B7.4000102@redhat.com> Message-ID: On 30 Jun 2015, at 16:03, Henri Tremblay wrote: ?. > Then, I want to make sure I got the security problem right. Right now, the > ReflectionFactory isn't protected by anything apart the fact the it is in a > sun.* package. So if we move it in a java.* package, we will need to > provide a way to add security to it. Am I getting it? sun.* is on the restricted package list and not directly accessible by untrusted code ( when running with a security manager ). -Chris From henri at tremblay.pro Tue Jun 30 17:25:12 2015 From: henri at tremblay.pro (Henri Tremblay) Date: Tue, 30 Jun 2015 13:25:12 -0400 Subject: Replacing Unsafe.allocateInstance In-Reply-To: References: <558EB8B7.4000102@redhat.com> Message-ID: Thanks. That was my understanding. So I would put the same kind of restriction on the new API. Something close to "suppressAccessChecks" used in setAccessible On 30 June 2015 at 13:19, Chris Hegarty wrote: > On 30 Jun 2015, at 16:03, Henri Tremblay wrote: > > ?. > > Then, I want to make sure I got the security problem right. Right now, > the > > ReflectionFactory isn't protected by anything apart the fact the it is > in a > > sun.* package. So if we move it in a java.* package, we will need to > > provide a way to add security to it. Am I getting it? > > sun.* is on the restricted package list and not directly accessible by > untrusted code ( when running with a security manager ). > > -Chris From henri at tremblay.pro Tue Jun 30 17:41:08 2015 From: henri at tremblay.pro (Henri Tremblay) Date: Tue, 30 Jun 2015 13:41:08 -0400 Subject: Replacing Unsafe.allocateInstance In-Reply-To: <5592BCBE.1030403@oracle.com> References: <558EB8B7.4000102@redhat.com> <5592BCBE.1030403@oracle.com> Message-ID: We currently have two valid ways to do it. It has been possible since the first version of Java. Both can be blocked by a security manager. So I really don't see why we should now limit the practice in scope. Creating a bogus class in Java is already quite easy. I can just hack around using reflection. This presentation (and variation of it) is one of my personal favorite: http://fr.slideshare.net/JAXLondon2014/reflection-madness-dr-heinz-kabutz My conclusion is that user should have two choices: - Use a security manager to prevent dangerous behavior. Knowingly disallow some performance hack and forcing to add unnecessary default constructor. This is the approach taken by Google App Engine for instance - Do not use a security manager and trust the code. This is the approach I must say I've seen everywhere for the last 15 years. I've worked for banks and some limited military stuff. I still need to check at nuclear power plant, fighter jets or space shuttles. I do hope they use a security manager ;-) On 30 June 2015 at 11:58, Brian Goetz wrote: > Mocking should be allowed for any class since any class can be mocked. Even >> the JDK ones >> > > An understandable user perspective :) > > Unfortunately, many serious security bugs can stem from being able to > create a bogus instance of a JDK class that is loaded off the > bootclasspath, and the existence of vectors for creating these exploits is > a negative for the entire ecosystem. So, we may need to make some > tradeoffs between security and convenience. > > (Many JDK APIs primarily expose interfaces anyway; these are easily mocked > without magic.) > > From alejandro.murillo at oracle.com Tue Jun 30 22:16:01 2015 From: alejandro.murillo at oracle.com (Alejandro E Murillo) Date: Tue, 30 Jun 2015 16:16:01 -0600 Subject: jdk9-dev: HotSpot Message-ID: <55931521.4060007@oracle.com> jdk9-hs-2015-06-25 has been integrated into jdk9-dev. http://hg.openjdk.java.net/jdk9/dev/rev/32f6be9541fa http://hg.openjdk.java.net/jdk9/dev/corba/rev/cd39ed501fb0 http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/aec5456c3e72 http://hg.openjdk.java.net/jdk9/dev/jaxp/rev/e4bc32cbffad http://hg.openjdk.java.net/jdk9/dev/jaxws/rev/61caeb7061bb http://hg.openjdk.java.net/jdk9/dev/jdk/rev/916aab7608cf http://hg.openjdk.java.net/jdk9/dev/langtools/rev/dc35e315436d http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/0b60cae91ec6 Component : VM Status : Go for integration Date : 06/29/2015 at 18:00 MSK Tested By : VM SQE &dmitry.fazunenko at oracle.com Bundles : 2015-06-27-021502.amurillo.jdk9-hs-2015-06-25-snapshot Testing: 59 new failures, 1959 known failures, 343380 passed. Issues and Notes: No detailed analysis. No stoppers have been detected so far. Go for integration CRs for testing: 7097567: G1: abstract and encapsulate collector phases and transitions between them 7169803: Usage of pretenured value is not correct 8015086: add interned strings to the shared archive. 8025608: GC trace events missing nursery size information 8026331: hs_err improvement: Print if we have seen any OutOfMemoryErrors or StackOverflowErrors 8026335: hs_err improvement: Print exact compressed oops mode and the heap base value. 8030076: remove unused runtime related code 8035074: hs_err improvement: Add time zone information in the hs_err file 8042041:https://bugs.openjdk.java.net/browse/JDK-8042041 8042668: GC Support for shared heap ranges in CDS 8054386: Allow Java debugging when CDS is enabled 8062045: Update svc regression tests to extend the default security policy instead of override 8072931: JEP-JDK-8059557: Test task: test framework development 8073108: Use x86 and SPARC CPU instructions for GHASH acceleration 8076110: VM crash when class is redefined with Instrumentation.redefineClasses 8076161: Runtime stub for throw_null_pointer_exception always constructs log messages 8077279: assert(ic->is_clean()) failed: IC should be clean 8077842: Remove the level parameter passed around in GenCollectedHeap 8078438: Interpreter should support conditional card marks (UseCondCardMark) on x86 and aarch64 8078513: [linux] Clean up code relevant to LinuxThreads implementation 8078521: AARCH64: Add AArch64 SA support 8078632: conflicts between open and closed SA ports 8078669: G1 applies SurvivorAlignmentInBytes to both survivor and old gen 8079134: [TESTBUG] Remove applicable_*gc and needs_*gc groups from TEST.groups 8079208: gc/g1/TestLargePageUseForAuxMemory.java fails due to not considering page allocation granularity for setup 8079315: UseCondCardMark broken in conjunction with CMS precleaning on x86 8079473: allow demangling to be optional in dll_address_to_function_name 8080138: sun/management/jmxremote/startstop/JMXStartStopTest.java failed with java.lang.Error intermittently 8080157: assert(allocates2(pc)) failed: not in CodeBuffer memory 8080325: SuperWord loop unrolling analysis 8080684: PPC64: Fix little-endian build after "8077838: Recent developments for ppc" 8080776: ARM 32 bit binaries do not run on 64 bit ARM v8 hardware 8081247: AVX 512 extended support 8081294: aarch64: fails to build on ubuntu wily 8081382: Make flags ParallelGCThreads and ConcGCThreads of type uint 8081576: serviceability/sa tests fail due to LingeredApp process fails to start 8081607: Change default GC for server configurations to G1 8081634: Concurrent usage of a StringBuilder causes test intermittent failures 8081771: ProcessTool.createJavaProcessBuilder() needs new addTestVmAndJavaOptions argument 8085813: The targeted processes in sun/tools tests should be launched with -XX:+UsePerfData flag in order to work on embedded platforms 8085865: hs_err improvement: Printing /proc/cpuinfo makes too long hs_err files 8085965: VM hangs in C2Compiler 8085973: The targeted processes in javax/management tests should be launched with -XX:+UsePerfData flag in order to work on embedded platforms 8085975: Fix warning "converting to jlong from double" of gcc 4.1.2 after 8079561 8085987: Vm crash "not long aligned" in nsk/stress/metaspace/jck60/jck6* tests 8086027: Multiple STATIC_ASSERTs at class scope doesn't work 8086073: Fix PrintStubCode for empty StubCodeGenerator. 8087121: bscmake fails when building inside VS2013 8087133: Improve sharing of native wrappers in SignatureHandlerLibrary 8087153: EXCEPTION_ACCESS_VIOLATION when CDS RO section vanished on win32 8087183: Fix call to inline function is_oop in header debugInfo.hpp. 8087195: Support building hotspot with devkits on Macosx 8098517: Unprotected PrintMalloc in os::realloc 8098552: 8079792 breaks Zero builds without precompiled headers. 8098815: Assertion failure in CDS shared string archive support on Windows 8098821: Crash in system dictionary initialization with shared strings 8098834: Update jprt.properties with property listing tests subtrees 8122937: [JEP 245] Validate JVM Command-Line Flag Arguments. 8129094: assert(is_java_primitive(bt)) failed: only primitive type vectors 8129332: Missing test case for JDK-8078438 8129423: Fix unlink() of LogCompilation tmp files lost in merge of 8007993 and 8060074. 8129446: crash when reporting corrupted classfile 8129518: Remove ParOldGC tests from the jprt hotspot testset 8129549: G1: Make sure the concurrent thread does not mix its logging with the STW pauses 8129584: Fix required for aarch64 after 8122937 8129607: Incorrect GPL header 8129757: ppc/aarch: Fix passing thread to runtime after "8073165: Contended Locking fast exit bucket." 8130008: compiler/codecache/jmx/UsageThresholdIncreasedTest.java should be quarantined -- Alejandro