From magnus.ihse.bursie at oracle.com Mon Feb 1 12:07:15 2016 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 1 Feb 2016 13:07:15 +0100 Subject: CFV: New JDK 9 Reviewer: David Lindholm In-Reply-To: <56A9DD3B.6020508@oracle.com> References: <56A9DD3B.6020508@oracle.com> Message-ID: <56AF4A73.5060001@oracle.com> Vote: yes /Magnus On 2016-01-28 10:19, Bengt Rutisson wrote: > > I hereby nominate David Lindholm to JDK 9 Reviewer. > > David is a member of the Hotspot GC team. He has contributed 45 > changesets in HotSpot [3] and one in the JDK [4]. David has worked on > large parts of the GC code but also made changes concerning all parts > of HotSpot, such as the changes to make the assert() macro a > varargs-macro that eliminates the need for err_msg(). David was also a > key reviewer of the large unified logging changes for the GC code. > > Votes are due by 11 February 2016, 11:00 CET. > > Only current jdk9 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]. > > Bengt Rutisson > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > [3] > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/log?revcount=1000&rev=author%28%22david%22%29+and+not+merge%28%29 > [4] > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/log?revcount=1000&rev=author%28%22david%22%29+and+not+merge%28%29 From alejandro.murillo at oracle.com Tue Feb 2 00:16:02 2016 From: alejandro.murillo at oracle.com (Alejandro E Murillo) Date: Mon, 01 Feb 2016 17:16:02 -0700 Subject: jdk9-dev: HotSpot Message-ID: <56AFF542.8030906@oracle.com> jdk9-hs-2016-01-28 has been integrated into jdk9-dev. http://hg.openjdk.java.net/jdk9/dev/rev/087c3103b32e http://hg.openjdk.java.net/jdk9/dev/corba/rev/e385e95e6101 http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/1edcfb47e131 http://hg.openjdk.java.net/jdk9/dev/jaxp/rev/58448465334e http://hg.openjdk.java.net/jdk9/dev/jaxws/rev/0f557aa096e2 http://hg.openjdk.java.net/jdk9/dev/jdk/rev/20069883ae86 http://hg.openjdk.java.net/jdk9/dev/langtools/rev/3f60a4808377 http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/a618d3e89fde Component : VM Status : Go for integration Date : 02/01/2016 at 21:00 MSK Tested By : VM SQE &dmitry.fazunenko at oracle.com Bundles : 2016-01-29-003204.amurillo.jdk9-hs-2016-01-28-snapshot Testing: 119 new failures, 3811 known failures, 424934 passed. Issues and Notes: It was a number of new crashes. After some analysis it was decided that there are no stoppers among them. CRs for testing: 6675699: need comprehensive fix for unconstrained ConvI2L with narrowed type 6985422: flush the output streams before OnError commands 8065334: CodeHeap expansion fails although there is uncommitted memory 8066599: Add methods to check VM mode to c.o.j.t.Platform 8071374: -XX:+PrintAssembly -XX:+PrintSignatureHandlers crash fastdebug VM with assert(limit == __null || limit <= nm->code_end()) in RelocIterator::initialize 8071864: compiler/c2/6772683/InterruptedTest.java failed in nightly 8072725: Provide more granular levels for GC verification 8077648: ARM: BREAKPOINT is wrong for thumb 8086053: Address inconsistencies regarding ZeroTLAB 8129419: heapDumper.cpp: assert(length_in_bytes > 0) failed: nothing to copy 8130063: Refactoring tmtools jstat and jstack tests to jtreg 8132717: Add tests checking that instances of j.l.Classes of a large size are allocated as Humongous 8132720: Add tests which checks that Humongous objects are not moved after Full GC 8133612: new clone logic added in 8042235 is missing from compiler intrinsics 8135198: Add -XX:VMOptionsFile support to JAVA_TOOL_OPTIONS and _JAVA_OPTIONS 8135250: Replace custom check/range functionality with check index/range methods in java.util.Objects 8136469: OptimizeStringConcat fails on pre-sized StringBuilder shapes 8139771: Eliminating CastPP nodes at Phis when they all come from a unique input may cause crash 8140001: _allocateInstance intrinsic does not throw InstantiationException for abstract classes and interfaces 8140659: C1: invokedynamic call patching violates JVMS-6.5.invokedynamic 8141557: TestResolvedJavaMethod.java times out after 1000 ms 8141564: Convert TraceItables and PrintVtables to Unified Logging 8141615: Add new public methods to sun.reflect.ConstantPool 8143317: jdk/lambda/vm/InterfaceAccessFlagsTest.java fails with IncompatibleClassChangeError 8143353: update for x86 sin and cos in the math lib 8143558: evaluate if thr_sigsetmask can be removed from hotspot (solaris) codebase 8143847: Remove REF_CLEANER reference category 8144212: JDK 9 b93 breaks Apache Lucene due to compact strings 8144527: NewSizeThreadIncrease would make an overflow 8144573: TLABWasteIncrement=max_jint fires an assert on SPARC for non-G1 GC mode 8144953: runtime/CommandLine/TraceExceptionsTest.java fails when exception is thrown in compiled code 8145000: TestOptionsWithRanges.java failure for XX:+UseNUMA -XX:+UseNUMAInterleaving -XX:NUMAInterleaveGranularity=65536 8145025: compiler/compilercontrol/commandfile/CompileOnlyTest.java and compiler/compilercontrol/commands/CompileOnlyTest.java fail: java.lang.RuntimeException: 8145037: Clean up FreeIdSet usage 8145038: Simplify mut_process_buffer worker id management 8145093: [TESTBUG] Remove test skip code for Solaris SPARC in runtime/SharedArchiveFile/SharedBaseAddress.java 8145127: VM warning: WaitForMultipleObjects timed out (0) ... 8145184: [aix] Implement os::platform_print_native_stack on AIX 8145322: Code generated from unsafe loops can be slightly improved 8145331: SEGV in DirectivesStack::release(DirectiveSet*) 8145336: PPC64: fix string intrinsics after CompactStrings change 8145442: Add the facility to verify remembered sets for G1 8145698: Memory leak in add_lib_info_fd of libproc_impl.c:174 8145788: JVM crashes with -XX:+EnableTracing 8145800: [Testbug] CompilerControl: inline message differs for not inlined methods 8145940: TempNewSymbol should have correct copy and assignment functions 8146015: JMXInterfaceBindingTest is failing intermittently for IPv6 addresses 8146222: assert(_initialized) failed: TLS not initialized yet! 8146244: compiler/jvmci/code/DataPatchTest.java crashes: SIGSEGV in (getConstClass)getConstClass 8146246: JVMCICompiler::abort_on_pending_exception: assert(!thread->owns_locks()) failed: must release all locks when leaving VM 8146364: Remove @ServiceProvider mechanism from JVMCI 8146399: Refactor the BlockOffsetTable classes. 8146401: Clean up oop.hpp: add inline directives and fix header files 8146409: TestPromotionFailedEventWithParallelScavenge.java failed with assert(_time_stamps != __null) failed: Sanity 8146410: Interpreter functions are declared and defined in the wrong files 8146424: runtime/ReservedStack/ReservedStackTest.java triggers: assert(thread->deopt_mark() == __null) failed: no stack overflow from deopt blob/uncommon trap 8146485: Add test for Unified Logging classresolve tag. 8146523: VirtualMemoryTracker::remove_released_region double count unmapped CDS shared memory 8146581: Minor corrections to the patch submitted for earlier bug id - 8143925 8146612: C2: Precedence edges specification violated 8146613: PPC64: C2 does no longer respect int to long conversion for stub calls 8146620: CodelistTest.java fails with "Test failed on: jdk.internal.misc.Unsafe.getUnsafe()Ljdk/internal/misc/Unsafe;" 8146629: Make phase->is_IterGVN() accessible from Node::Identity and Node::Value 8146653: Debug version missing in hs_err files and on internal version after Verona 8146678: aarch64: assertion failure: call instruction in an infinite loop 8146690: Make all classes in GC follow the naming convention. 8146694: Break out shared constants and static BOT functions. 8146695: FinalizeTest04 crashes VM with EXCEPTION_INT_DIVIDE_BY_ZERO 8146705: Improve JVMCI support for blocking compilation 8146709: AArch64: Incorrect use of ADRP for byte_map_base 8146751: jdk/test/tools/launcher/TooSmallStackSize.java failed on Mac OS 8146792: Predicate moved after partial peel may lead to broken graph 8146800: Reorganize logging alias code. 8146820: JVMCI options should not use System.getProperty directly 8146843: aarch64: add scheduling support for FP and vector instructions 8146855: Update hotspot sources to recognize Solaris Studio 12u4 compiler 8146871: Make the clean target silent in hotspot/test/Makefile 8146886: aarch64: fails to build following 8136525 and 8139864 8146889: Update @requires expression for GC tests to run if GC is default 8146891: AArch64 needs patch for 8032463 8146978: PPC64: Fix build after integration of C++ interpreter removal 8146983: C1: assert(appendix.not_null()) failed for invokehandle bytecode 8146985: Change output directory for hotspot's jtreg tests 8146990: Convert CollectorPolicy to use log_warning instead of warning 8146994: Move internal vm tests to a separate file 8146999: hotspot/test/compiler/c2/8007294/Test8007294.java test nightly failure 8147000: VM crashes during initialization trying to print log message 8147012: Fix includes in internalVMTests.cpp 8147075: Rename old GC JTreg tests to the new naming scheme 8147079: Add serviceability/logging folder to hotspot_serviceability test group 8147386: assert(size == calc_size) failed: incorrect size calculattion x86_32.ad 8147432: JVMCI should report bailouts in PrintCompilation output 8147433: PrintNMethods no longer works with JVMCI 8147441: Unchecked pending exceptions in the WhiteBox API's implementation 8147444: compiler/jsr292/NonInlinedCall/RedefineTest.java fails with NullPointerException in ClassFileInstaller 8147464: Use LogConfiguration::configure_stdout() instead of parse_log_arguments 8147470: update JVMCI mx extensions 8147475: compiler/jvmci/code/SimpleDebugInfoTest.java fails in Assembler::locate_operand: ShouldNotReachHere() 8147482: Zero build fails after 8144953 8147494: com/sun/management/HotSpotDiagnosticMXBean/CheckOrigin.java fails with "java.lang.IllegalArgumentException: VM option 'TraceExceptions' does not exist" 8147509: [aix] Newlines missing in register info printout 8147564: [JVMCI] remove unused method CodeCacheProvider.needsDataPatch 8147599: [JVMCI] simplify code installation interface 8147611: G1 - Missing memory barrier in start_cset_region_for_worker 8147791: Reenable tests that was temporarily quarantined in jdk9/hs 8147805: aarch64: C1 segmentation fault due to inline Unsafe.getAndSetObject 8147848: [TESTBUG] tmtools tests ported to JTREG need to be quarantined 8147853: "assert(t->meet(t0) == t) failed: Not monotonic" with sun/util/calendar/zi/TestZoneInfo310.java 8147876: ciTypeFlow::is_dominated_by() writes outside dominated array 8147937: Adapt SAP copyrights to new company name. 8148101: [JVMCI] Make CallingConvention.Type extensible 8148136: compile control tests have incorrect @build directives 8148161: quarantine compiler/loopopts/UseCountedLoopSafepoints.java 8148202: move lookup of Java class and hub from ResolvedJavaType to ConstantReflectionProvider 8148240: aarch64: random infrequent null pointer exceptions in javac -- Alejandro From lana.steuck at oracle.com Wed Feb 3 22:52:22 2016 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 3 Feb 2016 14:52:22 -0800 (PST) Subject: jdk9-b104: dev Message-ID: <201602032252.u13MqMqp025147@sc11152554.us.oracle.com> http://hg.openjdk.java.net/jdk9/jdk9/rev/9a38f8b4ba22 http://hg.openjdk.java.net/jdk9/jdk9/nashorn/rev/a618d3e89fde http://hg.openjdk.java.net/jdk9/jdk9/langtools/rev/3f60a4808377 http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/8faf1aec77a9 http://hg.openjdk.java.net/jdk9/jdk9/jaxws/rev/0f557aa096e2 http://hg.openjdk.java.net/jdk9/jdk9/jaxp/rev/58448465334e http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/534c50395957 http://hg.openjdk.java.net/jdk9/jdk9/corba/rev/e385e95e6101 --- All the fixes will be tested during promotion (no PIT testing at this point): List of all fixes: =================== JDK-8065076 core-libs java/net/SocketPermission/SocketPermissionTest.java fails intermittent JDK-8076458 core-libs java/util/stream/test/org/openjdk/tests/java/util/stream/FlatMapOpTest JDK-8144305 core-libs documentation of Queue interface contains reference to LinkedBlockingQ JDK-8144990 core-libs java/util/concurrent/forkjoin/FJExceptionTableLeak.java: OOM with Xcom JDK-8145164 core-libs Default implementation of ConcurrentMap::compute can throw NPE JDK-8146467 core-libs Integrate JSR 166 jck tests into JDK repo JDK-8147462 core-libs URI.toURL could be more efficient for most non-opaque URIs JDK-8147468 core-libs (bf) Allow users to bound the size of buffers cached in the per-thread JDK-8147591 core-libs Revisit Collection.toArray(new T[size]) calls in nashorn and dynalink JDK-8147962 core-libs URL should handle lower-casing of protocol locale-independently JDK-8148121 core-libs (fs) Typo in API , FileOwnerAttributeView.getOwner() and FileOwnerAttr JDK-8148174 core-libs NegativeArraySizeException in Vector.grow(int) JDK-8148214 core-libs Slow object allocation due to multiple synchronization JDK-8148220 core-libs Update TEST.groups to include jdk/internal/math and jdk/internal/misc JDK-8148617 core-libs top level make docs target does not generate javadocs for dynalink API JDK-8148626 core-libs URI.toURL needs to use protocol Handler to parse file URIs JDK-8148627 core-libs RestrictTestMaxCachedBufferSize.java to 64-bit platforms JDK-8148638 core-libs test failure in test/java/util/concurrent/tck JDK-8148730 core-libs Add @since tags in new String concat APIs JDK-8148120 infrastructure Incremental update from build-infra project JDK-8148351 infrastructure Only display resolved symlink for compiler, do not change path JDK-8148416 infrastructure Fix merge error in hotspot.m4 introduced in Merge changeset 8b46c6cecc JDK-8144539 security-libs Update PKCS11 tests to run with security manager JDK-8147400 security-libs Deprecate policytool JDK-8148497 security-libs Mark SSLSocketSSLEngineTemplate.java as failing intermittently JDK-8035473 tools [javadoc] Revamp the existing Doclet APIs JDK-8144168 tools No type annotations generated for nested lambdas JDK-8146427 tools "-nohelp" option issue JDK-8146475 tools "-helpfile" option issue JDK-8146529 tools Update the new Doclet API JDK-8148128 tools Regression: array constructor references marked as inexact JDK-8148154 tools Integrate JOpt Simple for internal usage by JDK tools JDK-8148213 tools Regression: nested unchecked call does not trigger erasure of return t JDK-8148399 tools Increase heap for langtools regression tests JDK-8148413 tools Memory leak in javadoc VisibleMemberMap JDK-8148417 tools Memory leak in javadoc DocFileFactory JDK-8148432 tools tools/javac/annotations/typeAnnotations/classfile/NestedLambdasCastedT JDK-8148483 tools JEP 280 Integration JDK-8145104 xml NPE is thrown when JAXBContextFactory implementation is specified in s JDK-8145112 xml newInstance(String, ClassLoader): java.lang.JAXBException should not b JDK-8147607 core-libs Remove test library dependency on sun.security.tools.jarsigner.Main From jesper.wilhelmsson at oracle.com Thu Feb 4 15:00:01 2016 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Thu, 4 Feb 2016 16:00:01 +0100 Subject: CFV: New JDK 9 Committer: Dmitry Fazunenko Message-ID: <56B36771.9000005@oracle.com> I hereby nominate Dmitry Fazunenko (dfazunen) for JDK 9 Committer. Dmitry is a member of the VM SQE team at Oracle and has contributed 13 changesets [3] to JDK 9. Votes are due by 18:00 MSK / 16:00 CET / 10.00 am EST / 7.00 am PT, Thursday February 18, 2016 Only current JDK 9 Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [2]. /Jesper [1] http://openjdk.java.net/census [2] http://openjdk.java.net/projects/#committer-vote [3] List of patches: 8132961: JEP 279: Improve Test-Failure Troubleshooting http://hg.openjdk.java.net/jdk9/hs-rt/rev/4aa2e64eff30 8147003: Move BubbleUpRef test into CMS directory http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/28dcfa2f0275 8134963: [Newtest] New stress test for changing the coarseness level of G1 remembered set http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/af014cb82e42 8147075: Rename old GC JTreg tests to the new naming scheme http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/c15c0bd51e1d 8146889: Update @requires expression for GC tests to run if GC is default http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/66aa15bcceff 8016752: [Newtest] regression test for PrintGCDetails and Verbose flags do not crash when ParOldGC has no memory http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/96cc87bb08f8 8132709: [TESTBUG] gc/g1/TestHumongousShrinkHeap.java might fail on embedded http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/d750cc39ed60 8073476: G1 logging ignores changes to PrintGC* flags via MXBeans http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/ce8df07dd074 8050464: G1 string deduplication tests hang/timeout and leave running processes consuming all resources http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/b515190809d5 8055284: sanity/WhiteBox.java fails with NPE http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/1662147c9ca3 8044673: Create jtreg groups to list GC specific tests http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/1abbc1e91ac5 8040250: The test test/gc/parallelScavenge/TestDynShrinkHeap.java fails with OOME http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/abd312cd8cc2 8039489: Refactor test framework for dynamic VM options http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/8ec72dcefd74 From igor.ignatyev at oracle.com Thu Feb 4 15:01:48 2016 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Thu, 4 Feb 2016 18:01:48 +0300 Subject: CFV: New JDK 9 Committer: Dmitry Fazunenko In-Reply-To: <56B36771.9000005@oracle.com> References: <56B36771.9000005@oracle.com> Message-ID: Vote: yes - Igor > On Feb 4, 2016, at 6:00 PM, Jesper Wilhelmsson wrote: > > I hereby nominate Dmitry Fazunenko (dfazunen) for JDK 9 Committer. > > Dmitry is a member of the VM SQE team at Oracle and has contributed 13 changesets [3] to JDK 9. > > Votes are due by 18:00 MSK / 16:00 CET / 10.00 am EST / 7.00 am PT, Thursday February 18, 2016 > > Only current JDK 9 Committers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > /Jesper > > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] List of patches: > > 8132961: JEP 279: Improve Test-Failure Troubleshooting > http://hg.openjdk.java.net/jdk9/hs-rt/rev/4aa2e64eff30 > > 8147003: Move BubbleUpRef test into CMS directory > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/28dcfa2f0275 > > 8134963: [Newtest] New stress test for changing the coarseness level of G1 remembered set > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/af014cb82e42 > > 8147075: Rename old GC JTreg tests to the new naming scheme > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/c15c0bd51e1d > > 8146889: Update @requires expression for GC tests to run if GC is default > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/66aa15bcceff > > 8016752: [Newtest] regression test for PrintGCDetails and Verbose flags do not crash when ParOldGC has no memory > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/96cc87bb08f8 > > 8132709: [TESTBUG] gc/g1/TestHumongousShrinkHeap.java might fail on embedded > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/d750cc39ed60 > > 8073476: G1 logging ignores changes to PrintGC* flags via MXBeans > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/ce8df07dd074 > > 8050464: G1 string deduplication tests hang/timeout and leave running processes consuming all resources > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/b515190809d5 > > 8055284: sanity/WhiteBox.java fails with NPE > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/1662147c9ca3 > > 8044673: Create jtreg groups to list GC specific tests > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/1abbc1e91ac5 > > 8040250: The test test/gc/parallelScavenge/TestDynShrinkHeap.java fails with OOME > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/abd312cd8cc2 > > 8039489: Refactor test framework for dynamic VM options > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/8ec72dcefd74 From pavel.punegov at oracle.com Thu Feb 4 15:04:05 2016 From: pavel.punegov at oracle.com (Pavel Punegov) Date: Thu, 4 Feb 2016 18:04:05 +0300 Subject: CFV: New JDK 9 Committer: Dmitry Fazunenko In-Reply-To: <56B36771.9000005@oracle.com> References: <56B36771.9000005@oracle.com> Message-ID: <691A4D3B-28BF-4653-8C22-D5FFBB0064D7@oracle.com> Vote: yes ? Pavel. > On 04 Feb 2016, at 18:00, Jesper Wilhelmsson wrote: > > I hereby nominate Dmitry Fazunenko (dfazunen) for JDK 9 Committer. > > Dmitry is a member of the VM SQE team at Oracle and has contributed 13 changesets [3] to JDK 9. > > Votes are due by 18:00 MSK / 16:00 CET / 10.00 am EST / 7.00 am PT, Thursday February 18, 2016 > > Only current JDK 9 Committers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > /Jesper > > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] List of patches: > > 8132961: JEP 279: Improve Test-Failure Troubleshooting > http://hg.openjdk.java.net/jdk9/hs-rt/rev/4aa2e64eff30 > > 8147003: Move BubbleUpRef test into CMS directory > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/28dcfa2f0275 > > 8134963: [Newtest] New stress test for changing the coarseness level of G1 remembered set > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/af014cb82e42 > > 8147075: Rename old GC JTreg tests to the new naming scheme > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/c15c0bd51e1d > > 8146889: Update @requires expression for GC tests to run if GC is default > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/66aa15bcceff > > 8016752: [Newtest] regression test for PrintGCDetails and Verbose flags do not crash when ParOldGC has no memory > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/96cc87bb08f8 > > 8132709: [TESTBUG] gc/g1/TestHumongousShrinkHeap.java might fail on embedded > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/d750cc39ed60 > > 8073476: G1 logging ignores changes to PrintGC* flags via MXBeans > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/ce8df07dd074 > > 8050464: G1 string deduplication tests hang/timeout and leave running processes consuming all resources > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/b515190809d5 > > 8055284: sanity/WhiteBox.java fails with NPE > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/1662147c9ca3 > > 8044673: Create jtreg groups to list GC specific tests > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/1abbc1e91ac5 > > 8040250: The test test/gc/parallelScavenge/TestDynShrinkHeap.java fails with OOME > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/abd312cd8cc2 > > 8039489: Refactor test framework for dynamic VM options > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/8ec72dcefd74 From konstantin.shefov at oracle.com Thu Feb 4 15:03:14 2016 From: konstantin.shefov at oracle.com (Konstantin Shefov) Date: Thu, 4 Feb 2016 18:03:14 +0300 Subject: CFV: New JDK 9 Committer: Dmitry Fazunenko In-Reply-To: <56B36771.9000005@oracle.com> References: <56B36771.9000005@oracle.com> Message-ID: <56B36832.3080500@oracle.com> Vote: yes -Konstantin On 02/04/2016 06:00 PM, Jesper Wilhelmsson wrote: > I hereby nominate Dmitry Fazunenko (dfazunen) for JDK 9 Committer. > > Dmitry is a member of the VM SQE team at Oracle and has contributed 13 > changesets [3] to JDK 9. > > Votes are due by 18:00 MSK / 16:00 CET / 10.00 am EST / 7.00 am PT, > Thursday February 18, 2016 > > Only current JDK 9 Committers [1] are eligible to vote on this > nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > /Jesper > > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] List of patches: > > 8132961: JEP 279: Improve Test-Failure Troubleshooting > http://hg.openjdk.java.net/jdk9/hs-rt/rev/4aa2e64eff30 > > 8147003: Move BubbleUpRef test into CMS directory > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/28dcfa2f0275 > > 8134963: [Newtest] New stress test for changing the coarseness level > of G1 remembered set > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/af014cb82e42 > > 8147075: Rename old GC JTreg tests to the new naming scheme > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/c15c0bd51e1d > > 8146889: Update @requires expression for GC tests to run if GC is default > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/66aa15bcceff > > 8016752: [Newtest] regression test for PrintGCDetails and Verbose > flags do not crash when ParOldGC has no memory > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/96cc87bb08f8 > > 8132709: [TESTBUG] gc/g1/TestHumongousShrinkHeap.java might fail on > embedded > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/d750cc39ed60 > > 8073476: G1 logging ignores changes to PrintGC* flags via MXBeans > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/ce8df07dd074 > > 8050464: G1 string deduplication tests hang/timeout and leave running > processes consuming all resources > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/b515190809d5 > > 8055284: sanity/WhiteBox.java fails with NPE > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/1662147c9ca3 > > 8044673: Create jtreg groups to list GC specific tests > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/1abbc1e91ac5 > > 8040250: The test test/gc/parallelScavenge/TestDynShrinkHeap.java > fails with OOME > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/abd312cd8cc2 > > 8039489: Refactor test framework for dynamic VM options > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/8ec72dcefd74 From aleksey.shipilev at oracle.com Thu Feb 4 15:10:31 2016 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Thu, 4 Feb 2016 18:10:31 +0300 Subject: CFV: New JDK 9 Committer: Dmitry Fazunenko In-Reply-To: <56B36771.9000005@oracle.com> References: <56B36771.9000005@oracle.com> Message-ID: <56B369E7.8030900@oracle.com> Vote: yes On 02/04/2016 06:00 PM, Jesper Wilhelmsson wrote: > I hereby nominate Dmitry Fazunenko (dfazunen) for JDK 9 Committer. > > Dmitry is a member of the VM SQE team at Oracle and has contributed 13 > changesets [3] to JDK 9. > > Votes are due by 18:00 MSK / 16:00 CET / 10.00 am EST / 7.00 am PT, > Thursday February 18, 2016 > > Only current JDK 9 Committers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > /Jesper > > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] List of patches: > > 8132961: JEP 279: Improve Test-Failure Troubleshooting > http://hg.openjdk.java.net/jdk9/hs-rt/rev/4aa2e64eff30 > > 8147003: Move BubbleUpRef test into CMS directory > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/28dcfa2f0275 > > 8134963: [Newtest] New stress test for changing the coarseness level of > G1 remembered set > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/af014cb82e42 > > 8147075: Rename old GC JTreg tests to the new naming scheme > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/c15c0bd51e1d > > 8146889: Update @requires expression for GC tests to run if GC is default > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/66aa15bcceff > > 8016752: [Newtest] regression test for PrintGCDetails and Verbose flags > do not crash when ParOldGC has no memory > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/96cc87bb08f8 > > 8132709: [TESTBUG] gc/g1/TestHumongousShrinkHeap.java might fail on > embedded > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/d750cc39ed60 > > 8073476: G1 logging ignores changes to PrintGC* flags via MXBeans > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/ce8df07dd074 > > 8050464: G1 string deduplication tests hang/timeout and leave running > processes consuming all resources > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/b515190809d5 > > 8055284: sanity/WhiteBox.java fails with NPE > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/1662147c9ca3 > > 8044673: Create jtreg groups to list GC specific tests > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/1abbc1e91ac5 > > 8040250: The test test/gc/parallelScavenge/TestDynShrinkHeap.java fails > with OOME > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/abd312cd8cc2 > > 8039489: Refactor test framework for dynamic VM options > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/8ec72dcefd74 From artem.ananiev at oracle.com Thu Feb 4 15:16:09 2016 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Thu, 4 Feb 2016 18:16:09 +0300 Subject: CFV: New JDK 9 Committer: Dmitry Fazunenko In-Reply-To: <56B36771.9000005@oracle.com> References: <56B36771.9000005@oracle.com> Message-ID: <56B36B39.9050605@oracle.com> Vote: yes Artem On 2/4/16 6:00 PM, Jesper Wilhelmsson wrote: > I hereby nominate Dmitry Fazunenko (dfazunen) for JDK 9 Committer. > > Dmitry is a member of the VM SQE team at Oracle and has contributed 13 > changesets [3] to JDK 9. > > Votes are due by 18:00 MSK / 16:00 CET / 10.00 am EST / 7.00 am PT, > Thursday February 18, 2016 > > Only current JDK 9 Committers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > /Jesper > > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] List of patches: > > 8132961: JEP 279: Improve Test-Failure Troubleshooting > http://hg.openjdk.java.net/jdk9/hs-rt/rev/4aa2e64eff30 > > 8147003: Move BubbleUpRef test into CMS directory > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/28dcfa2f0275 > > 8134963: [Newtest] New stress test for changing the coarseness level of > G1 remembered set > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/af014cb82e42 > > 8147075: Rename old GC JTreg tests to the new naming scheme > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/c15c0bd51e1d > > 8146889: Update @requires expression for GC tests to run if GC is default > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/66aa15bcceff > > 8016752: [Newtest] regression test for PrintGCDetails and Verbose flags > do not crash when ParOldGC has no memory > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/96cc87bb08f8 > > 8132709: [TESTBUG] gc/g1/TestHumongousShrinkHeap.java might fail on > embedded > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/d750cc39ed60 > > 8073476: G1 logging ignores changes to PrintGC* flags via MXBeans > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/ce8df07dd074 > > 8050464: G1 string deduplication tests hang/timeout and leave running > processes consuming all resources > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/b515190809d5 > > 8055284: sanity/WhiteBox.java fails with NPE > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/1662147c9ca3 > > 8044673: Create jtreg groups to list GC specific tests > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/1abbc1e91ac5 > > 8040250: The test test/gc/parallelScavenge/TestDynShrinkHeap.java fails > with OOME > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/abd312cd8cc2 > > 8039489: Refactor test framework for dynamic VM options > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/8ec72dcefd74 From vladimir.x.ivanov at oracle.com Thu Feb 4 15:15:00 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Thu, 4 Feb 2016 18:15:00 +0300 Subject: CFV: New JDK 9 Committer: Dmitry Fazunenko In-Reply-To: <56B36771.9000005@oracle.com> References: <56B36771.9000005@oracle.com> Message-ID: <56B36AF4.3010206@oracle.com> Vote: yes Best regards, Vladimir Ivanov On 2/4/16 6:00 PM, Jesper Wilhelmsson wrote: > I hereby nominate Dmitry Fazunenko (dfazunen) for JDK 9 Committer. > From jesper.wilhelmsson at oracle.com Thu Feb 4 15:22:27 2016 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Thu, 4 Feb 2016 16:22:27 +0100 Subject: CFV: New JDK 9 Committer: Dmitry Fazunenko In-Reply-To: <56B36771.9000005@oracle.com> References: <56B36771.9000005@oracle.com> Message-ID: <56B36CB3.9020009@oracle.com> Vote: Yes /Jesper Den 4/2/16 kl. 16:00, skrev Jesper Wilhelmsson: > I hereby nominate Dmitry Fazunenko (dfazunen) for JDK 9 Committer. > > Dmitry is a member of the VM SQE team at Oracle and has contributed 13 > changesets [3] to JDK 9. > > Votes are due by 18:00 MSK / 16:00 CET / 10.00 am EST / 7.00 am PT, Thursday > February 18, 2016 > > Only current JDK 9 Committers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > /Jesper > > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] List of patches: > > 8132961: JEP 279: Improve Test-Failure Troubleshooting > http://hg.openjdk.java.net/jdk9/hs-rt/rev/4aa2e64eff30 > > 8147003: Move BubbleUpRef test into CMS directory > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/28dcfa2f0275 > > 8134963: [Newtest] New stress test for changing the coarseness level of G1 > remembered set > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/af014cb82e42 > > 8147075: Rename old GC JTreg tests to the new naming scheme > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/c15c0bd51e1d > > 8146889: Update @requires expression for GC tests to run if GC is default > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/66aa15bcceff > > 8016752: [Newtest] regression test for PrintGCDetails and Verbose flags do not > crash when ParOldGC has no memory > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/96cc87bb08f8 > > 8132709: [TESTBUG] gc/g1/TestHumongousShrinkHeap.java might fail on embedded > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/d750cc39ed60 > > 8073476: G1 logging ignores changes to PrintGC* flags via MXBeans > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/ce8df07dd074 > > 8050464: G1 string deduplication tests hang/timeout and leave running processes > consuming all resources > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/b515190809d5 > > 8055284: sanity/WhiteBox.java fails with NPE > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/1662147c9ca3 > > 8044673: Create jtreg groups to list GC specific tests > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/1abbc1e91ac5 > > 8040250: The test test/gc/parallelScavenge/TestDynShrinkHeap.java fails with OOME > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/abd312cd8cc2 > > 8039489: Refactor test framework for dynamic VM options > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/8ec72dcefd74 From jonathan.gibbons at oracle.com Thu Feb 4 15:28:08 2016 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 04 Feb 2016 07:28:08 -0800 Subject: CFV: New JDK 9 Committer: Dmitry Fazunenko In-Reply-To: <56B36771.9000005@oracle.com> References: <56B36771.9000005@oracle.com> Message-ID: <56B36E08.7020907@oracle.com> Vote: yes On 02/04/2016 07:00 AM, Jesper Wilhelmsson wrote: > I hereby nominate Dmitry Fazunenko (dfazunen) for JDK 9 Committer. > > Dmitry is a member of the VM SQE team at Oracle and has contributed 13 > changesets [3] to JDK 9. > > Votes are due by 18:00 MSK / 16:00 CET / 10.00 am EST / 7.00 am PT, > Thursday February 18, 2016 > > Only current JDK 9 Committers [1] are eligible to vote on this > nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > /Jesper > > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] List of patches: > > 8132961: JEP 279: Improve Test-Failure Troubleshooting > http://hg.openjdk.java.net/jdk9/hs-rt/rev/4aa2e64eff30 > > 8147003: Move BubbleUpRef test into CMS directory > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/28dcfa2f0275 > > 8134963: [Newtest] New stress test for changing the coarseness level > of G1 remembered set > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/af014cb82e42 > > 8147075: Rename old GC JTreg tests to the new naming scheme > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/c15c0bd51e1d > > 8146889: Update @requires expression for GC tests to run if GC is default > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/66aa15bcceff > > 8016752: [Newtest] regression test for PrintGCDetails and Verbose > flags do not crash when ParOldGC has no memory > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/96cc87bb08f8 > > 8132709: [TESTBUG] gc/g1/TestHumongousShrinkHeap.java might fail on > embedded > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/d750cc39ed60 > > 8073476: G1 logging ignores changes to PrintGC* flags via MXBeans > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/ce8df07dd074 > > 8050464: G1 string deduplication tests hang/timeout and leave running > processes consuming all resources > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/b515190809d5 > > 8055284: sanity/WhiteBox.java fails with NPE > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/1662147c9ca3 > > 8044673: Create jtreg groups to list GC specific tests > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/1abbc1e91ac5 > > 8040250: The test test/gc/parallelScavenge/TestDynShrinkHeap.java > fails with OOME > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/abd312cd8cc2 > > 8039489: Refactor test framework for dynamic VM options > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/8ec72dcefd74 From eric.caspole at oracle.com Thu Feb 4 15:39:22 2016 From: eric.caspole at oracle.com (Eric Caspole) Date: Thu, 4 Feb 2016 10:39:22 -0500 Subject: CFV: New JDK 9 Committer: Dmitry Fazunenko In-Reply-To: <56B36771.9000005@oracle.com> References: <56B36771.9000005@oracle.com> Message-ID: <56B370AA.2010202@oracle.com> Vote: yes Eric On 02/04/2016 10:00 AM, Jesper Wilhelmsson wrote: > I hereby nominate Dmitry Fazunenko (dfazunen) for JDK 9 Committer. > > Dmitry is a member of the VM SQE team at Oracle and has contributed 13 > changesets [3] to JDK 9. > > Votes are due by 18:00 MSK / 16:00 CET / 10.00 am EST / 7.00 am PT, > Thursday February 18, 2016 > > Only current JDK 9 Committers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > /Jesper > > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] List of patches: > > 8132961: JEP 279: Improve Test-Failure Troubleshooting > http://hg.openjdk.java.net/jdk9/hs-rt/rev/4aa2e64eff30 > > 8147003: Move BubbleUpRef test into CMS directory > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/28dcfa2f0275 > > 8134963: [Newtest] New stress test for changing the coarseness level of > G1 remembered set > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/af014cb82e42 > > 8147075: Rename old GC JTreg tests to the new naming scheme > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/c15c0bd51e1d > > 8146889: Update @requires expression for GC tests to run if GC is default > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/66aa15bcceff > > 8016752: [Newtest] regression test for PrintGCDetails and Verbose flags > do not crash when ParOldGC has no memory > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/96cc87bb08f8 > > 8132709: [TESTBUG] gc/g1/TestHumongousShrinkHeap.java might fail on > embedded > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/d750cc39ed60 > > 8073476: G1 logging ignores changes to PrintGC* flags via MXBeans > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/ce8df07dd074 > > 8050464: G1 string deduplication tests hang/timeout and leave running > processes consuming all resources > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/b515190809d5 > > 8055284: sanity/WhiteBox.java fails with NPE > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/1662147c9ca3 > > 8044673: Create jtreg groups to list GC specific tests > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/1abbc1e91ac5 > > 8040250: The test test/gc/parallelScavenge/TestDynShrinkHeap.java fails > with OOME > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/abd312cd8cc2 > > 8039489: Refactor test framework for dynamic VM options > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/8ec72dcefd74 From harold.seigel at oracle.com Thu Feb 4 15:40:23 2016 From: harold.seigel at oracle.com (harold seigel) Date: Thu, 4 Feb 2016 10:40:23 -0500 Subject: CFV: New JDK 9 Committer: Dmitry Fazunenko In-Reply-To: <56B36771.9000005@oracle.com> References: <56B36771.9000005@oracle.com> Message-ID: <56B370E7.5000605@oracle.com> Vote: yes Harold On 2/4/2016 10:00 AM, Jesper Wilhelmsson wrote: > I hereby nominate Dmitry Fazunenko (dfazunen) for JDK 9 Committer. > > Dmitry is a member of the VM SQE team at Oracle and has contributed 13 > changesets [3] to JDK 9. > > Votes are due by 18:00 MSK / 16:00 CET / 10.00 am EST / 7.00 am PT, > Thursday February 18, 2016 > > Only current JDK 9 Committers [1] are eligible to vote on this > nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > /Jesper > > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] List of patches: > > 8132961: JEP 279: Improve Test-Failure Troubleshooting > http://hg.openjdk.java.net/jdk9/hs-rt/rev/4aa2e64eff30 > > 8147003: Move BubbleUpRef test into CMS directory > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/28dcfa2f0275 > > 8134963: [Newtest] New stress test for changing the coarseness level > of G1 remembered set > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/af014cb82e42 > > 8147075: Rename old GC JTreg tests to the new naming scheme > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/c15c0bd51e1d > > 8146889: Update @requires expression for GC tests to run if GC is default > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/66aa15bcceff > > 8016752: [Newtest] regression test for PrintGCDetails and Verbose > flags do not crash when ParOldGC has no memory > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/96cc87bb08f8 > > 8132709: [TESTBUG] gc/g1/TestHumongousShrinkHeap.java might fail on > embedded > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/d750cc39ed60 > > 8073476: G1 logging ignores changes to PrintGC* flags via MXBeans > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/ce8df07dd074 > > 8050464: G1 string deduplication tests hang/timeout and leave running > processes consuming all resources > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/b515190809d5 > > 8055284: sanity/WhiteBox.java fails with NPE > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/1662147c9ca3 > > 8044673: Create jtreg groups to list GC specific tests > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/1abbc1e91ac5 > > 8040250: The test test/gc/parallelScavenge/TestDynShrinkHeap.java > fails with OOME > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/abd312cd8cc2 > > 8039489: Refactor test framework for dynamic VM options > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/8ec72dcefd74 From Roger.Riggs at Oracle.com Thu Feb 4 16:14:56 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Thu, 4 Feb 2016 11:14:56 -0500 Subject: CFV: New JDK 9 Committer: Dmitry Fazunenko In-Reply-To: <56B36771.9000005@oracle.com> References: <56B36771.9000005@oracle.com> Message-ID: <56B37900.9050306@Oracle.com> Vote: yes On 2/4/2016 10:00 AM, Jesper Wilhelmsson wrote: > I hereby nominate Dmitry Fazunenko (dfazunen) for JDK 9 Committer. From joseph.provino at oracle.com Thu Feb 4 16:41:10 2016 From: joseph.provino at oracle.com (Joseph Provino) Date: Thu, 4 Feb 2016 11:41:10 -0500 Subject: CFV: New JDK 9 Committer: Dmitry Fazunenko In-Reply-To: <56B36771.9000005@oracle.com> References: <56B36771.9000005@oracle.com> Message-ID: <56B37F26.1090207@oracle.com> Vote: yes On 2/4/2016 10:00 AM, Jesper Wilhelmsson wrote: > I hereby nominate Dmitry Fazunenko (dfazunen) for JDK 9 Committer. > > Dmitry is a member of the VM SQE team at Oracle and has contributed 13 > changesets [3] to JDK 9. > > Votes are due by 18:00 MSK / 16:00 CET / 10.00 am EST / 7.00 am PT, > Thursday February 18, 2016 > > Only current JDK 9 Committers [1] are eligible to vote on this > nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > /Jesper > > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] List of patches: > > 8132961: JEP 279: Improve Test-Failure Troubleshooting > http://hg.openjdk.java.net/jdk9/hs-rt/rev/4aa2e64eff30 > > 8147003: Move BubbleUpRef test into CMS directory > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/28dcfa2f0275 > > 8134963: [Newtest] New stress test for changing the coarseness level > of G1 remembered set > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/af014cb82e42 > > 8147075: Rename old GC JTreg tests to the new naming scheme > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/c15c0bd51e1d > > 8146889: Update @requires expression for GC tests to run if GC is default > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/66aa15bcceff > > 8016752: [Newtest] regression test for PrintGCDetails and Verbose > flags do not crash when ParOldGC has no memory > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/96cc87bb08f8 > > 8132709: [TESTBUG] gc/g1/TestHumongousShrinkHeap.java might fail on > embedded > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/d750cc39ed60 > > 8073476: G1 logging ignores changes to PrintGC* flags via MXBeans > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/ce8df07dd074 > > 8050464: G1 string deduplication tests hang/timeout and leave running > processes consuming all resources > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/b515190809d5 > > 8055284: sanity/WhiteBox.java fails with NPE > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/1662147c9ca3 > > 8044673: Create jtreg groups to list GC specific tests > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/1abbc1e91ac5 > > 8040250: The test test/gc/parallelScavenge/TestDynShrinkHeap.java > fails with OOME > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/abd312cd8cc2 > > 8039489: Refactor test framework for dynamic VM options > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/8ec72dcefd74 From vladimir.kozlov at oracle.com Thu Feb 4 16:54:20 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 4 Feb 2016 08:54:20 -0800 Subject: CFV: New JDK 9 Committer: Dmitry Fazunenko In-Reply-To: <56B36771.9000005@oracle.com> References: <56B36771.9000005@oracle.com> Message-ID: <56B3823C.4070307@oracle.com> Vote: yes On 2/4/16 7:00 AM, Jesper Wilhelmsson wrote: > I hereby nominate Dmitry Fazunenko (dfazunen) for JDK 9 Committer. > > Dmitry is a member of the VM SQE team at Oracle and has contributed 13 changesets [3] to JDK 9. > > Votes are due by 18:00 MSK / 16:00 CET / 10.00 am EST / 7.00 am PT, Thursday February 18, 2016 > > Only current JDK 9 Committers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > /Jesper > > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] List of patches: > > 8132961: JEP 279: Improve Test-Failure Troubleshooting > http://hg.openjdk.java.net/jdk9/hs-rt/rev/4aa2e64eff30 > > 8147003: Move BubbleUpRef test into CMS directory > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/28dcfa2f0275 > > 8134963: [Newtest] New stress test for changing the coarseness level of G1 remembered set > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/af014cb82e42 > > 8147075: Rename old GC JTreg tests to the new naming scheme > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/c15c0bd51e1d > > 8146889: Update @requires expression for GC tests to run if GC is default > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/66aa15bcceff > > 8016752: [Newtest] regression test for PrintGCDetails and Verbose flags do not crash when ParOldGC has no memory > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/96cc87bb08f8 > > 8132709: [TESTBUG] gc/g1/TestHumongousShrinkHeap.java might fail on embedded > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/d750cc39ed60 > > 8073476: G1 logging ignores changes to PrintGC* flags via MXBeans > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/ce8df07dd074 > > 8050464: G1 string deduplication tests hang/timeout and leave running processes consuming all resources > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/b515190809d5 > > 8055284: sanity/WhiteBox.java fails with NPE > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/1662147c9ca3 > > 8044673: Create jtreg groups to list GC specific tests > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/1abbc1e91ac5 > > 8040250: The test test/gc/parallelScavenge/TestDynShrinkHeap.java fails with OOME > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/abd312cd8cc2 > > 8039489: Refactor test framework for dynamic VM options > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/8ec72dcefd74 From yumin.qi at oracle.com Thu Feb 4 17:06:09 2016 From: yumin.qi at oracle.com (Yumin Qi) Date: Thu, 4 Feb 2016 09:06:09 -0800 Subject: CFV: New JDK 9 Committer: Dmitry Fazunenko In-Reply-To: <56B36771.9000005@oracle.com> References: <56B36771.9000005@oracle.com> Message-ID: <56B38501.5010807@oracle.com> Vote: Yes On 2/4/2016 7:00 AM, Jesper Wilhelmsson wrote: > I hereby nominate Dmitry Fazunenko (dfazunen) for JDK 9 Committer. > > Dmitry is a member of the VM SQE team at Oracle and has contributed 13 > changesets [3] to JDK 9. > > Votes are due by 18:00 MSK / 16:00 CET / 10.00 am EST / 7.00 am PT, > Thursday February 18, 2016 > > Only current JDK 9 Committers [1] are eligible to vote on this > nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > /Jesper > > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] List of patches: > > 8132961: JEP 279: Improve Test-Failure Troubleshooting > http://hg.openjdk.java.net/jdk9/hs-rt/rev/4aa2e64eff30 > > 8147003: Move BubbleUpRef test into CMS directory > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/28dcfa2f0275 > > 8134963: [Newtest] New stress test for changing the coarseness level > of G1 remembered set > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/af014cb82e42 > > 8147075: Rename old GC JTreg tests to the new naming scheme > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/c15c0bd51e1d > > 8146889: Update @requires expression for GC tests to run if GC is default > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/66aa15bcceff > > 8016752: [Newtest] regression test for PrintGCDetails and Verbose > flags do not crash when ParOldGC has no memory > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/96cc87bb08f8 > > 8132709: [TESTBUG] gc/g1/TestHumongousShrinkHeap.java might fail on > embedded > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/d750cc39ed60 > > 8073476: G1 logging ignores changes to PrintGC* flags via MXBeans > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/ce8df07dd074 > > 8050464: G1 string deduplication tests hang/timeout and leave running > processes consuming all resources > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/b515190809d5 > > 8055284: sanity/WhiteBox.java fails with NPE > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/1662147c9ca3 > > 8044673: Create jtreg groups to list GC specific tests > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/1abbc1e91ac5 > > 8040250: The test test/gc/parallelScavenge/TestDynShrinkHeap.java > fails with OOME > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/abd312cd8cc2 > > 8039489: Refactor test framework for dynamic VM options > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/8ec72dcefd74 From coleen.phillimore at oracle.com Thu Feb 4 17:08:28 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 4 Feb 2016 12:08:28 -0500 Subject: CFV: New JDK 9 Committer: Dmitry Fazunenko In-Reply-To: <56B36771.9000005@oracle.com> References: <56B36771.9000005@oracle.com> Message-ID: <56B3858C.6020601@oracle.com> Vote: yes On 2/4/16 10:00 AM, Jesper Wilhelmsson wrote: > I hereby nominate Dmitry Fazunenko (dfazunen) for JDK 9 Committer. > > Dmitry is a member of the VM SQE team at Oracle and has contributed 13 > changesets [3] to JDK 9. > > Votes are due by 18:00 MSK / 16:00 CET / 10.00 am EST / 7.00 am PT, > Thursday February 18, 2016 > > Only current JDK 9 Committers [1] are eligible to vote on this > nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > /Jesper > > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] List of patches: > > 8132961: JEP 279: Improve Test-Failure Troubleshooting > http://hg.openjdk.java.net/jdk9/hs-rt/rev/4aa2e64eff30 > > 8147003: Move BubbleUpRef test into CMS directory > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/28dcfa2f0275 > > 8134963: [Newtest] New stress test for changing the coarseness level > of G1 remembered set > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/af014cb82e42 > > 8147075: Rename old GC JTreg tests to the new naming scheme > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/c15c0bd51e1d > > 8146889: Update @requires expression for GC tests to run if GC is default > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/66aa15bcceff > > 8016752: [Newtest] regression test for PrintGCDetails and Verbose > flags do not crash when ParOldGC has no memory > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/96cc87bb08f8 > > 8132709: [TESTBUG] gc/g1/TestHumongousShrinkHeap.java might fail on > embedded > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/d750cc39ed60 > > 8073476: G1 logging ignores changes to PrintGC* flags via MXBeans > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/ce8df07dd074 > > 8050464: G1 string deduplication tests hang/timeout and leave running > processes consuming all resources > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/b515190809d5 > > 8055284: sanity/WhiteBox.java fails with NPE > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/1662147c9ca3 > > 8044673: Create jtreg groups to list GC specific tests > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/1abbc1e91ac5 > > 8040250: The test test/gc/parallelScavenge/TestDynShrinkHeap.java > fails with OOME > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/abd312cd8cc2 > > 8039489: Refactor test framework for dynamic VM options > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/8ec72dcefd74 From alejandro.murillo at oracle.com Thu Feb 4 17:27:54 2016 From: alejandro.murillo at oracle.com (Alejandro E Murillo) Date: Thu, 04 Feb 2016 10:27:54 -0700 Subject: CFV: New JDK 9 Committer: Dmitry Fazunenko In-Reply-To: <56B36771.9000005@oracle.com> References: <56B36771.9000005@oracle.com> Message-ID: <56B38A1A.2090008@oracle.com> vote: yes On 2/4/2016 8:00 AM, Jesper Wilhelmsson wrote: > I hereby nominate Dmitry Fazunenko (dfazunen) for JDK 9 Committer. > -- Alejandro From sangheon.kim at oracle.com Thu Feb 4 17:34:03 2016 From: sangheon.kim at oracle.com (sangheon) Date: Thu, 4 Feb 2016 09:34:03 -0800 Subject: CFV: New JDK 9 Committer: Dmitry Fazunenko In-Reply-To: <56B36771.9000005@oracle.com> References: <56B36771.9000005@oracle.com> Message-ID: <56B38B8B.8070404@oracle.com> Vote: Yes Thanks, Sangheon On 02/04/2016 07:00 AM, Jesper Wilhelmsson wrote: > I hereby nominate Dmitry Fazunenko (dfazunen) for JDK 9 Committer. > > Dmitry is a member of the VM SQE team at Oracle and has contributed 13 > changesets [3] to JDK 9. > > Votes are due by 18:00 MSK / 16:00 CET / 10.00 am EST / 7.00 am PT, > Thursday February 18, 2016 > > Only current JDK 9 Committers [1] are eligible to vote on this > nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > /Jesper > > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] List of patches: > > 8132961: JEP 279: Improve Test-Failure Troubleshooting > http://hg.openjdk.java.net/jdk9/hs-rt/rev/4aa2e64eff30 > > 8147003: Move BubbleUpRef test into CMS directory > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/28dcfa2f0275 > > 8134963: [Newtest] New stress test for changing the coarseness level > of G1 remembered set > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/af014cb82e42 > > 8147075: Rename old GC JTreg tests to the new naming scheme > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/c15c0bd51e1d > > 8146889: Update @requires expression for GC tests to run if GC is default > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/66aa15bcceff > > 8016752: [Newtest] regression test for PrintGCDetails and Verbose > flags do not crash when ParOldGC has no memory > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/96cc87bb08f8 > > 8132709: [TESTBUG] gc/g1/TestHumongousShrinkHeap.java might fail on > embedded > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/d750cc39ed60 > > 8073476: G1 logging ignores changes to PrintGC* flags via MXBeans > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/ce8df07dd074 > > 8050464: G1 string deduplication tests hang/timeout and leave running > processes consuming all resources > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/b515190809d5 > > 8055284: sanity/WhiteBox.java fails with NPE > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/1662147c9ca3 > > 8044673: Create jtreg groups to list GC specific tests > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/1abbc1e91ac5 > > 8040250: The test test/gc/parallelScavenge/TestDynShrinkHeap.java > fails with OOME > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/abd312cd8cc2 > > 8039489: Refactor test framework for dynamic VM options > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/8ec72dcefd74 From bengt.rutisson at oracle.com Thu Feb 4 19:14:25 2016 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Thu, 4 Feb 2016 20:14:25 +0100 Subject: CFV: New JDK 9 Committer: Dmitry Fazunenko In-Reply-To: <56B36771.9000005@oracle.com> References: <56B36771.9000005@oracle.com> Message-ID: <56B3A311.70205@oracle.com> Vote: yes Bengt On 2016-02-04 16:00, Jesper Wilhelmsson wrote: > I hereby nominate Dmitry Fazunenko (dfazunen) for JDK 9 Committer. > > Dmitry is a member of the VM SQE team at Oracle and has contributed 13 > changesets [3] to JDK 9. > > Votes are due by 18:00 MSK / 16:00 CET / 10.00 am EST / 7.00 am PT, > Thursday February 18, 2016 > > Only current JDK 9 Committers [1] are eligible to vote on this > nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > /Jesper > > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] List of patches: > > 8132961: JEP 279: Improve Test-Failure Troubleshooting > http://hg.openjdk.java.net/jdk9/hs-rt/rev/4aa2e64eff30 > > 8147003: Move BubbleUpRef test into CMS directory > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/28dcfa2f0275 > > 8134963: [Newtest] New stress test for changing the coarseness level > of G1 remembered set > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/af014cb82e42 > > 8147075: Rename old GC JTreg tests to the new naming scheme > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/c15c0bd51e1d > > 8146889: Update @requires expression for GC tests to run if GC is default > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/66aa15bcceff > > 8016752: [Newtest] regression test for PrintGCDetails and Verbose > flags do not crash when ParOldGC has no memory > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/96cc87bb08f8 > > 8132709: [TESTBUG] gc/g1/TestHumongousShrinkHeap.java might fail on > embedded > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/d750cc39ed60 > > 8073476: G1 logging ignores changes to PrintGC* flags via MXBeans > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/ce8df07dd074 > > 8050464: G1 string deduplication tests hang/timeout and leave running > processes consuming all resources > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/b515190809d5 > > 8055284: sanity/WhiteBox.java fails with NPE > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/1662147c9ca3 > > 8044673: Create jtreg groups to list GC specific tests > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/1abbc1e91ac5 > > 8040250: The test test/gc/parallelScavenge/TestDynShrinkHeap.java > fails with OOME > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/abd312cd8cc2 > > 8039489: Refactor test framework for dynamic VM options > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/8ec72dcefd74 From jon.masamitsu at oracle.com Thu Feb 4 19:05:59 2016 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Thu, 4 Feb 2016 11:05:59 -0800 Subject: CFV: New JDK 9 Committer: Dmitry Fazunenko In-Reply-To: <56B36771.9000005@oracle.com> References: <56B36771.9000005@oracle.com> Message-ID: <56B3A117.3030909@oracle.com> Vote: yes On 02/04/2016 07:00 AM, Jesper Wilhelmsson wrote: > I hereby nominate Dmitry Fazunenko (dfazunen) for JDK 9 Committer. > > Dmitry is a member of the VM SQE team at Oracle and has contributed 13 > changesets [3] to JDK 9. > > Votes are due by 18:00 MSK / 16:00 CET / 10.00 am EST / 7.00 am PT, > Thursday February 18, 2016 > > Only current JDK 9 Committers [1] are eligible to vote on this > nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > /Jesper > > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] List of patches: > > 8132961: JEP 279: Improve Test-Failure Troubleshooting > http://hg.openjdk.java.net/jdk9/hs-rt/rev/4aa2e64eff30 > > 8147003: Move BubbleUpRef test into CMS directory > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/28dcfa2f0275 > > 8134963: [Newtest] New stress test for changing the coarseness level > of G1 remembered set > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/af014cb82e42 > > 8147075: Rename old GC JTreg tests to the new naming scheme > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/c15c0bd51e1d > > 8146889: Update @requires expression for GC tests to run if GC is default > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/66aa15bcceff > > 8016752: [Newtest] regression test for PrintGCDetails and Verbose > flags do not crash when ParOldGC has no memory > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/96cc87bb08f8 > > 8132709: [TESTBUG] gc/g1/TestHumongousShrinkHeap.java might fail on > embedded > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/d750cc39ed60 > > 8073476: G1 logging ignores changes to PrintGC* flags via MXBeans > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/ce8df07dd074 > > 8050464: G1 string deduplication tests hang/timeout and leave running > processes consuming all resources > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/b515190809d5 > > 8055284: sanity/WhiteBox.java fails with NPE > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/1662147c9ca3 > > 8044673: Create jtreg groups to list GC specific tests > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/1abbc1e91ac5 > > 8040250: The test test/gc/parallelScavenge/TestDynShrinkHeap.java > fails with OOME > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/abd312cd8cc2 > > 8039489: Refactor test framework for dynamic VM options > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/8ec72dcefd74 From alexander.zuev at oracle.com Thu Feb 4 20:46:46 2016 From: alexander.zuev at oracle.com (Alexander Zuev) Date: Thu, 4 Feb 2016 12:46:46 -0800 Subject: CFV: New JDK 9 Committer: Dmitry Fazunenko In-Reply-To: <56B36771.9000005@oracle.com> References: <56B36771.9000005@oracle.com> Message-ID: <56B3B8B6.70603@oracle.com> Vote: yes On 04/02/16 07:00, Jesper Wilhelmsson wrote: > I hereby nominate Dmitry Fazunenko (dfazunen) for JDK 9 Committer. > > Dmitry is a member of the VM SQE team at Oracle and has contributed 13 > changesets [3] to JDK 9. > > Votes are due by 18:00 MSK / 16:00 CET / 10.00 am EST / 7.00 am PT, > Thursday February 18, 2016 > > Only current JDK 9 Committers [1] are eligible to vote on this > nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > /Jesper > > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] List of patches: > > 8132961: JEP 279: Improve Test-Failure Troubleshooting > http://hg.openjdk.java.net/jdk9/hs-rt/rev/4aa2e64eff30 > > 8147003: Move BubbleUpRef test into CMS directory > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/28dcfa2f0275 > > 8134963: [Newtest] New stress test for changing the coarseness level > of G1 remembered set > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/af014cb82e42 > > 8147075: Rename old GC JTreg tests to the new naming scheme > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/c15c0bd51e1d > > 8146889: Update @requires expression for GC tests to run if GC is default > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/66aa15bcceff > > 8016752: [Newtest] regression test for PrintGCDetails and Verbose > flags do not crash when ParOldGC has no memory > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/96cc87bb08f8 > > 8132709: [TESTBUG] gc/g1/TestHumongousShrinkHeap.java might fail on > embedded > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/d750cc39ed60 > > 8073476: G1 logging ignores changes to PrintGC* flags via MXBeans > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/ce8df07dd074 > > 8050464: G1 string deduplication tests hang/timeout and leave running > processes consuming all resources > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/b515190809d5 > > 8055284: sanity/WhiteBox.java fails with NPE > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/1662147c9ca3 > > 8044673: Create jtreg groups to list GC specific tests > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/1abbc1e91ac5 > > 8040250: The test test/gc/parallelScavenge/TestDynShrinkHeap.java > fails with OOME > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/abd312cd8cc2 > > 8039489: Refactor test framework for dynamic VM options > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/8ec72dcefd74 From serguei.spitsyn at oracle.com Thu Feb 4 23:43:47 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 4 Feb 2016 15:43:47 -0800 Subject: CFV: New JDK 9 Committer: Dmitry Fazunenko In-Reply-To: <56B36771.9000005@oracle.com> References: <56B36771.9000005@oracle.com> Message-ID: <56B3E233.2060306@oracle.com> Vote: yes From stefan.johansson at oracle.com Fri Feb 5 07:46:12 2016 From: stefan.johansson at oracle.com (Stefan Johansson) Date: Fri, 5 Feb 2016 08:46:12 +0100 Subject: CFV: New JDK 9 Committer: Dmitry Fazunenko In-Reply-To: <56B36771.9000005@oracle.com> References: <56B36771.9000005@oracle.com> Message-ID: <56B45344.2010304@oracle.com> Vote: yes StefanJ On 2016-02-04 16:00, Jesper Wilhelmsson wrote: > I hereby nominate Dmitry Fazunenko (dfazunen) for JDK 9 Committer. > > Dmitry is a member of the VM SQE team at Oracle and has contributed 13 > changesets [3] to JDK 9. > > Votes are due by 18:00 MSK / 16:00 CET / 10.00 am EST / 7.00 am PT, > Thursday February 18, 2016 > > Only current JDK 9 Committers [1] are eligible to vote on this > nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > /Jesper > > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] List of patches: > > 8132961: JEP 279: Improve Test-Failure Troubleshooting > http://hg.openjdk.java.net/jdk9/hs-rt/rev/4aa2e64eff30 > > 8147003: Move BubbleUpRef test into CMS directory > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/28dcfa2f0275 > > 8134963: [Newtest] New stress test for changing the coarseness level > of G1 remembered set > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/af014cb82e42 > > 8147075: Rename old GC JTreg tests to the new naming scheme > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/c15c0bd51e1d > > 8146889: Update @requires expression for GC tests to run if GC is default > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/66aa15bcceff > > 8016752: [Newtest] regression test for PrintGCDetails and Verbose > flags do not crash when ParOldGC has no memory > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/96cc87bb08f8 > > 8132709: [TESTBUG] gc/g1/TestHumongousShrinkHeap.java might fail on > embedded > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/d750cc39ed60 > > 8073476: G1 logging ignores changes to PrintGC* flags via MXBeans > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/ce8df07dd074 > > 8050464: G1 string deduplication tests hang/timeout and leave running > processes consuming all resources > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/b515190809d5 > > 8055284: sanity/WhiteBox.java fails with NPE > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/1662147c9ca3 > > 8044673: Create jtreg groups to list GC specific tests > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/1abbc1e91ac5 > > 8040250: The test test/gc/parallelScavenge/TestDynShrinkHeap.java > fails with OOME > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/abd312cd8cc2 > > 8039489: Refactor test framework for dynamic VM options > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/8ec72dcefd74 From volker.simonis at gmail.com Fri Feb 5 08:15:54 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 5 Feb 2016 09:15:54 +0100 Subject: CFV: New JDK 9 Committer: Dmitry Fazunenko In-Reply-To: <56B36771.9000005@oracle.com> References: <56B36771.9000005@oracle.com> Message-ID: Vote: yes On Thu, Feb 4, 2016 at 4:00 PM, Jesper Wilhelmsson wrote: > I hereby nominate Dmitry Fazunenko (dfazunen) for JDK 9 Committer. > > Dmitry is a member of the VM SQE team at Oracle and has contributed 13 > changesets [3] to JDK 9. > > Votes are due by 18:00 MSK / 16:00 CET / 10.00 am EST / 7.00 am PT, Thursday > February 18, 2016 > > Only current JDK 9 Committers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > /Jesper > > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] List of patches: > > 8132961: JEP 279: Improve Test-Failure Troubleshooting > http://hg.openjdk.java.net/jdk9/hs-rt/rev/4aa2e64eff30 > > 8147003: Move BubbleUpRef test into CMS directory > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/28dcfa2f0275 > > 8134963: [Newtest] New stress test for changing the coarseness level of G1 > remembered set > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/af014cb82e42 > > 8147075: Rename old GC JTreg tests to the new naming scheme > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/c15c0bd51e1d > > 8146889: Update @requires expression for GC tests to run if GC is default > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/66aa15bcceff > > 8016752: [Newtest] regression test for PrintGCDetails and Verbose flags do > not crash when ParOldGC has no memory > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/96cc87bb08f8 > > 8132709: [TESTBUG] gc/g1/TestHumongousShrinkHeap.java might fail on embedded > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/d750cc39ed60 > > 8073476: G1 logging ignores changes to PrintGC* flags via MXBeans > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/ce8df07dd074 > > 8050464: G1 string deduplication tests hang/timeout and leave running > processes consuming all resources > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/b515190809d5 > > 8055284: sanity/WhiteBox.java fails with NPE > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/1662147c9ca3 > > 8044673: Create jtreg groups to list GC specific tests > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/1abbc1e91ac5 > > 8040250: The test test/gc/parallelScavenge/TestDynShrinkHeap.java fails with > OOME > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/abd312cd8cc2 > > 8039489: Refactor test framework for dynamic VM options > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/8ec72dcefd74 From dmitry.dmitriev at oracle.com Fri Feb 5 09:16:18 2016 From: dmitry.dmitriev at oracle.com (Dmitry Dmitriev) Date: Fri, 5 Feb 2016 12:16:18 +0300 Subject: CFV: New JDK 9 Committer: Dmitry Fazunenko In-Reply-To: <56B36771.9000005@oracle.com> References: <56B36771.9000005@oracle.com> Message-ID: <56B46862.2010004@oracle.com> Vote: yes Dmitry On 04.02.2016 18:00, Jesper Wilhelmsson wrote: > I hereby nominate Dmitry Fazunenko (dfazunen) for JDK 9 Committer. > > Dmitry is a member of the VM SQE team at Oracle and has contributed 13 > changesets [3] to JDK 9. > > Votes are due by 18:00 MSK / 16:00 CET / 10.00 am EST / 7.00 am PT, > Thursday February 18, 2016 > > Only current JDK 9 Committers [1] are eligible to vote on this > nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > /Jesper > > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] List of patches: > > 8132961: JEP 279: Improve Test-Failure Troubleshooting > http://hg.openjdk.java.net/jdk9/hs-rt/rev/4aa2e64eff30 > > 8147003: Move BubbleUpRef test into CMS directory > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/28dcfa2f0275 > > 8134963: [Newtest] New stress test for changing the coarseness level > of G1 remembered set > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/af014cb82e42 > > 8147075: Rename old GC JTreg tests to the new naming scheme > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/c15c0bd51e1d > > 8146889: Update @requires expression for GC tests to run if GC is default > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/66aa15bcceff > > 8016752: [Newtest] regression test for PrintGCDetails and Verbose > flags do not crash when ParOldGC has no memory > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/96cc87bb08f8 > > 8132709: [TESTBUG] gc/g1/TestHumongousShrinkHeap.java might fail on > embedded > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/d750cc39ed60 > > 8073476: G1 logging ignores changes to PrintGC* flags via MXBeans > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/ce8df07dd074 > > 8050464: G1 string deduplication tests hang/timeout and leave running > processes consuming all resources > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/b515190809d5 > > 8055284: sanity/WhiteBox.java fails with NPE > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/1662147c9ca3 > > 8044673: Create jtreg groups to list GC specific tests > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/1abbc1e91ac5 > > 8040250: The test test/gc/parallelScavenge/TestDynShrinkHeap.java > fails with OOME > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/abd312cd8cc2 > > 8039489: Refactor test framework for dynamic VM options > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/8ec72dcefd74 From michael.haupt at oracle.com Fri Feb 5 09:53:13 2016 From: michael.haupt at oracle.com (Michael Haupt) Date: Fri, 5 Feb 2016 10:53:13 +0100 Subject: CFV: New JDK 9 Committer: Dmitry Fazunenko In-Reply-To: <56B36771.9000005@oracle.com> References: <56B36771.9000005@oracle.com> Message-ID: Vote: yes Best, Michael > Am 04.02.2016 um 16:00 schrieb Jesper Wilhelmsson : > > I hereby nominate Dmitry Fazunenko (dfazunen) for JDK 9 Committer. -- Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331 200 7561 Oracle Java Platform Group | LangTools Team | Nashorn Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstra?e 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From zoltan.majo at oracle.com Fri Feb 5 09:55:04 2016 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Fri, 5 Feb 2016 10:55:04 +0100 Subject: CFV: New JDK 9 Committer: Dmitry Fazunenko In-Reply-To: <56B36771.9000005@oracle.com> References: <56B36771.9000005@oracle.com> Message-ID: <56B47178.3010900@oracle.com> Vote: yes. Best regards, Zoltan From aleksej.efimov at oracle.com Fri Feb 5 11:43:23 2016 From: aleksej.efimov at oracle.com (Aleksej Efimov) Date: Fri, 5 Feb 2016 14:43:23 +0300 Subject: CFV: New JDK 9 Committer: Dmitry Fazunenko In-Reply-To: <56B36771.9000005@oracle.com> References: <56B36771.9000005@oracle.com> Message-ID: <56B48ADB.3070105@oracle.com> Vote: yes Aleksej On 02/04/2016 06:00 PM, Jesper Wilhelmsson wrote: > I hereby nominate Dmitry Fazunenko (dfazunen) for JDK 9 Committer. > > Dmitry is a member of the VM SQE team at Oracle and has contributed 13 > changesets [3] to JDK 9. > > Votes are due by 18:00 MSK / 16:00 CET / 10.00 am EST / 7.00 am PT, > Thursday February 18, 2016 > > Only current JDK 9 Committers [1] are eligible to vote on this > nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > /Jesper > > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] List of patches: > > 8132961: JEP 279: Improve Test-Failure Troubleshooting > http://hg.openjdk.java.net/jdk9/hs-rt/rev/4aa2e64eff30 > > 8147003: Move BubbleUpRef test into CMS directory > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/28dcfa2f0275 > > 8134963: [Newtest] New stress test for changing the coarseness level > of G1 remembered set > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/af014cb82e42 > > 8147075: Rename old GC JTreg tests to the new naming scheme > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/c15c0bd51e1d > > 8146889: Update @requires expression for GC tests to run if GC is default > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/66aa15bcceff > > 8016752: [Newtest] regression test for PrintGCDetails and Verbose > flags do not crash when ParOldGC has no memory > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/96cc87bb08f8 > > 8132709: [TESTBUG] gc/g1/TestHumongousShrinkHeap.java might fail on > embedded > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/d750cc39ed60 > > 8073476: G1 logging ignores changes to PrintGC* flags via MXBeans > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/ce8df07dd074 > > 8050464: G1 string deduplication tests hang/timeout and leave running > processes consuming all resources > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/b515190809d5 > > 8055284: sanity/WhiteBox.java fails with NPE > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/1662147c9ca3 > > 8044673: Create jtreg groups to list GC specific tests > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/1abbc1e91ac5 > > 8040250: The test test/gc/parallelScavenge/TestDynShrinkHeap.java > fails with OOME > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/abd312cd8cc2 > > 8039489: Refactor test framework for dynamic VM options > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/8ec72dcefd74 From goetz.lindenmaier at sap.com Fri Feb 5 12:08:15 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 5 Feb 2016 12:08:15 +0000 Subject: New JDK 9 Committer: Dmitry Fazunenko In-Reply-To: <56B36771.9000005@oracle.com> References: <56B36771.9000005@oracle.com> Message-ID: Vote: yes Best regards, Goetz > -----Original Message----- > From: jdk9-dev [mailto:jdk9-dev-bounces at openjdk.java.net] On Behalf Of > Jesper Wilhelmsson > Sent: Donnerstag, 4. Februar 2016 16:00 > To: jdk9-dev at openjdk.java.net > Subject: CFV: New JDK 9 Committer: Dmitry Fazunenko > > I hereby nominate Dmitry Fazunenko (dfazunen) for JDK 9 Committer. > > Dmitry is a member of the VM SQE team at Oracle and has contributed 13 > changesets [3] to JDK 9. > > Votes are due by 18:00 MSK / 16:00 CET / 10.00 am EST / 7.00 am PT, Thursday > February 18, 2016 > > Only current JDK 9 Committers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > /Jesper > > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] List of patches: > > 8132961: JEP 279: Improve Test-Failure Troubleshooting > http://hg.openjdk.java.net/jdk9/hs-rt/rev/4aa2e64eff30 > > 8147003: Move BubbleUpRef test into CMS directory > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/28dcfa2f0275 > > 8134963: [Newtest] New stress test for changing the coarseness level of G1 > remembered set > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/af014cb82e42 > > 8147075: Rename old GC JTreg tests to the new naming scheme > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/c15c0bd51e1d > > 8146889: Update @requires expression for GC tests to run if GC is default > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/66aa15bcceff > > 8016752: [Newtest] regression test for PrintGCDetails and Verbose flags do > not > crash when ParOldGC has no memory > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/96cc87bb08f8 > > 8132709: [TESTBUG] gc/g1/TestHumongousShrinkHeap.java might fail on > embedded > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/d750cc39ed60 > > 8073476: G1 logging ignores changes to PrintGC* flags via MXBeans > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/ce8df07dd074 > > 8050464: G1 string deduplication tests hang/timeout and leave running > processes > consuming all resources > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/b515190809d5 > > 8055284: sanity/WhiteBox.java fails with NPE > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/1662147c9ca3 > > 8044673: Create jtreg groups to list GC specific tests > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/1abbc1e91ac5 > > 8040250: The test test/gc/parallelScavenge/TestDynShrinkHeap.java fails > with OOME > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/abd312cd8cc2 > > 8039489: Refactor test framework for dynamic VM options > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/8ec72dcefd74 From tobias.hartmann at oracle.com Fri Feb 5 12:38:01 2016 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Fri, 5 Feb 2016 13:38:01 +0100 Subject: CFV: New JDK 9 Committer: Dmitry Fazunenko In-Reply-To: <56B36771.9000005@oracle.com> References: <56B36771.9000005@oracle.com> Message-ID: <56B497A9.6030804@oracle.com> Vote: yes On 04.02.2016 16:00, Jesper Wilhelmsson wrote: > I hereby nominate Dmitry Fazunenko (dfazunen) for JDK 9 Committer. > > Dmitry is a member of the VM SQE team at Oracle and has contributed 13 changesets [3] to JDK 9. > > Votes are due by 18:00 MSK / 16:00 CET / 10.00 am EST / 7.00 am PT, Thursday February 18, 2016 > > Only current JDK 9 Committers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > /Jesper > > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] List of patches: > > 8132961: JEP 279: Improve Test-Failure Troubleshooting > http://hg.openjdk.java.net/jdk9/hs-rt/rev/4aa2e64eff30 > > 8147003: Move BubbleUpRef test into CMS directory > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/28dcfa2f0275 > > 8134963: [Newtest] New stress test for changing the coarseness level of G1 remembered set > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/af014cb82e42 > > 8147075: Rename old GC JTreg tests to the new naming scheme > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/c15c0bd51e1d > > 8146889: Update @requires expression for GC tests to run if GC is default > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/66aa15bcceff > > 8016752: [Newtest] regression test for PrintGCDetails and Verbose flags do not crash when ParOldGC has no memory > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/96cc87bb08f8 > > 8132709: [TESTBUG] gc/g1/TestHumongousShrinkHeap.java might fail on embedded > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/d750cc39ed60 > > 8073476: G1 logging ignores changes to PrintGC* flags via MXBeans > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/ce8df07dd074 > > 8050464: G1 string deduplication tests hang/timeout and leave running processes consuming all resources > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/b515190809d5 > > 8055284: sanity/WhiteBox.java fails with NPE > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/1662147c9ca3 > > 8044673: Create jtreg groups to list GC specific tests > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/1abbc1e91ac5 > > 8040250: The test test/gc/parallelScavenge/TestDynShrinkHeap.java fails with OOME > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/abd312cd8cc2 > > 8039489: Refactor test framework for dynamic VM options > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/8ec72dcefd74 From thomas.schatzl at oracle.com Fri Feb 5 12:51:53 2016 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Fri, 05 Feb 2016 13:51:53 +0100 Subject: New JDK 9 Committer: Dmitry Fazunenko In-Reply-To: References: <56B36771.9000005@oracle.com> Message-ID: <1454676713.2279.4.camel@oracle.com> Vote: yes Thomas From tatiana.pivovarova at oracle.com Fri Feb 5 13:20:25 2016 From: tatiana.pivovarova at oracle.com (Tatiana Pivovarova) Date: Fri, 5 Feb 2016 16:20:25 +0300 Subject: CFV: New JDK 9 Committer: Dmitry Fazunenko In-Reply-To: <56B36771.9000005@oracle.com> References: <56B36771.9000005@oracle.com> Message-ID: <56B4A199.2030607@oracle.com> Vote: yes Tatiana On 02/04/2016 06:00 PM, Jesper Wilhelmsson wrote: > I hereby nominate Dmitry Fazunenko (dfazunen) for JDK 9 Committer. > > Dmitry is a member of the VM SQE team at Oracle and has contributed 13 > changesets [3] to JDK 9. > > Votes are due by 18:00 MSK / 16:00 CET / 10.00 am EST / 7.00 am PT, > Thursday February 18, 2016 > > Only current JDK 9 Committers [1] are eligible to vote on this > nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > /Jesper > > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] List of patches: > > 8132961: JEP 279: Improve Test-Failure Troubleshooting > http://hg.openjdk.java.net/jdk9/hs-rt/rev/4aa2e64eff30 > > 8147003: Move BubbleUpRef test into CMS directory > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/28dcfa2f0275 > > 8134963: [Newtest] New stress test for changing the coarseness level > of G1 remembered set > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/af014cb82e42 > > 8147075: Rename old GC JTreg tests to the new naming scheme > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/c15c0bd51e1d > > 8146889: Update @requires expression for GC tests to run if GC is default > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/66aa15bcceff > > 8016752: [Newtest] regression test for PrintGCDetails and Verbose > flags do not crash when ParOldGC has no memory > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/96cc87bb08f8 > > 8132709: [TESTBUG] gc/g1/TestHumongousShrinkHeap.java might fail on > embedded > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/d750cc39ed60 > > 8073476: G1 logging ignores changes to PrintGC* flags via MXBeans > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/ce8df07dd074 > > 8050464: G1 string deduplication tests hang/timeout and leave running > processes consuming all resources > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/b515190809d5 > > 8055284: sanity/WhiteBox.java fails with NPE > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/1662147c9ca3 > > 8044673: Create jtreg groups to list GC specific tests > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/1abbc1e91ac5 > > 8040250: The test test/gc/parallelScavenge/TestDynShrinkHeap.java > fails with OOME > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/abd312cd8cc2 > > 8039489: Refactor test framework for dynamic VM options > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/8ec72dcefd74 From kim.barrett at oracle.com Fri Feb 5 23:26:56 2016 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 5 Feb 2016 18:26:56 -0500 Subject: CFV: New JDK 9 Committer: Dmitry Fazunenko In-Reply-To: <56B36771.9000005@oracle.com> References: <56B36771.9000005@oracle.com> Message-ID: <01FC569C-5FD5-4B67-B7E2-71B56F3D94AD@oracle.com> vote: yes > On Feb 4, 2016, at 10:00 AM, Jesper Wilhelmsson wrote: > > I hereby nominate Dmitry Fazunenko (dfazunen) for JDK 9 Committer. From sean.mullan at oracle.com Wed Feb 10 13:02:31 2016 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 10 Feb 2016 08:02:31 -0500 Subject: CFV: New JDK 9 Reviewer: Anthony Scarpino Message-ID: <56BB34E7.6040207@oracle.com> I hereby nominate Anthony Scarpino to JDK 9 Reviewer. Anthony Scarpino is a member of the security libraries team at Oracle. He has contributed 39 changesets to the JDK 9 Project [3]. He is also the Author and Owner of JEP 246 (Leverage CPU Instructions for GHASH and RSA) [4] which has significantly improved cryptographic performance and has been successfully integrated to JDK 9. Votes are due by 24 February 2016, 2:00 PM UTC. 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]. Sean Mullan [1] http://openjdk.java.net/census [2] http://openjdk.java.net/projects/#reviewer-vote [3] http://hg.openjdk.java.net/jdk9/dev/jdk/log?revcount=1000&rev=author%28%22ascarpin%22%29 [4] http://openjdk.java.net/jeps/246 From aph at redhat.com Wed Feb 10 13:06:10 2016 From: aph at redhat.com (Andrew Haley) Date: Wed, 10 Feb 2016 13:06:10 +0000 Subject: CFV: New JDK 9 Reviewer: Anthony Scarpino In-Reply-To: <56BB34E7.6040207@oracle.com> References: <56BB34E7.6040207@oracle.com> Message-ID: <56BB35C2.8070907@redhat.com> On 10/02/16 13:02, Sean Mullan wrote: > I hereby nominate Anthony Scarpino to JDK 9 Reviewer. Vote: yes From vladimir.x.ivanov at oracle.com Wed Feb 10 13:06:19 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 10 Feb 2016 16:06:19 +0300 Subject: CFV: New JDK 9 Reviewer: Anthony Scarpino In-Reply-To: <56BB34E7.6040207@oracle.com> References: <56BB34E7.6040207@oracle.com> Message-ID: <56BB35CB.80307@oracle.com> Vote: yes Best regards, Vladimir Ivanov On 2/10/16 4:02 PM, Sean Mullan wrote: > I hereby nominate Anthony Scarpino to JDK 9 Reviewer. From vincent.x.ryan at oracle.com Wed Feb 10 13:20:07 2016 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Wed, 10 Feb 2016 13:20:07 +0000 Subject: CFV: New JDK 9 Reviewer: Anthony Scarpino In-Reply-To: <56BB34E7.6040207@oracle.com> References: <56BB34E7.6040207@oracle.com> Message-ID: <95AC68F1-4226-41D0-B0B7-AABC11BF4454@oracle.com> Vote: yes > On 10 Feb 2016, at 13:02, Sean Mullan wrote: > > I hereby nominate Anthony Scarpino to JDK 9 Reviewer. > > Anthony Scarpino is a member of the security libraries team at Oracle. He has contributed 39 changesets to the JDK 9 Project [3]. He is also the Author and Owner of JEP 246 (Leverage CPU Instructions for GHASH and RSA) [4] which has significantly improved cryptographic performance and has been successfully integrated to JDK 9. > > Votes are due by 24 February 2016, 2:00 PM UTC. > > 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]. > > Sean Mullan > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > [3] http://hg.openjdk.java.net/jdk9/dev/jdk/log?revcount=1000&rev=author%28%22ascarpin%22%29 > [4] http://openjdk.java.net/jeps/246 From volker.simonis at gmail.com Wed Feb 10 13:31:58 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 10 Feb 2016 14:31:58 +0100 Subject: CFV: New JDK 9 Reviewer: Anthony Scarpino In-Reply-To: <56BB34E7.6040207@oracle.com> References: <56BB34E7.6040207@oracle.com> Message-ID: Vote: yes On Wed, Feb 10, 2016 at 2:02 PM, Sean Mullan wrote: > I hereby nominate Anthony Scarpino to JDK 9 Reviewer. > > Anthony Scarpino is a member of the security libraries team at Oracle. He > has contributed 39 changesets to the JDK 9 Project [3]. He is also the > Author and Owner of JEP 246 (Leverage CPU Instructions for GHASH and RSA) > [4] which has significantly improved cryptographic performance and has been > successfully integrated to JDK 9. > > Votes are due by 24 February 2016, 2:00 PM UTC. > > 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]. > > Sean Mullan > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > [3] > http://hg.openjdk.java.net/jdk9/dev/jdk/log?revcount=1000&rev=author%28%22ascarpin%22%29 > [4] http://openjdk.java.net/jeps/246 From sean.coffey at oracle.com Wed Feb 10 14:18:31 2016 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Wed, 10 Feb 2016 14:18:31 +0000 Subject: CFV: New JDK 9 Reviewer: Anthony Scarpino In-Reply-To: <56BB34E7.6040207@oracle.com> References: <56BB34E7.6040207@oracle.com> Message-ID: <56BB46B7.4030806@oracle.com> Vote: yes Regards, Sean. On 10/02/16 13:02, Sean Mullan wrote: > I hereby nominate Anthony Scarpino to JDK 9 Reviewer. > > Anthony Scarpino is a member of the security libraries team at Oracle. > He has contributed 39 changesets to the JDK 9 Project [3]. He is also > the Author and Owner of JEP 246 (Leverage CPU Instructions for GHASH > and RSA) [4] which has significantly improved cryptographic > performance and has been successfully integrated to JDK 9. > > Votes are due by 24 February 2016, 2:00 PM UTC. > > 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]. > > Sean Mullan > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > [3] > http://hg.openjdk.java.net/jdk9/dev/jdk/log?revcount=1000&rev=author%28%22ascarpin%22%29 > [4] http://openjdk.java.net/jeps/246 From xuelei.fan at oracle.com Wed Feb 10 15:24:01 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 10 Feb 2016 23:24:01 +0800 Subject: CFV: New JDK 9 Reviewer: Anthony Scarpino In-Reply-To: <56BB34E7.6040207@oracle.com> References: <56BB34E7.6040207@oracle.com> Message-ID: <56BB5611.5060504@oracle.com> Vote: yes On 2/10/2016 9:02 PM, Sean Mullan wrote: > I hereby nominate Anthony Scarpino to JDK 9 Reviewer. > > Anthony Scarpino is a member of the security libraries team at Oracle. > He has contributed 39 changesets to the JDK 9 Project [3]. He is also > the Author and Owner of JEP 246 (Leverage CPU Instructions for GHASH and > RSA) [4] which has significantly improved cryptographic performance and > has been successfully integrated to JDK 9. > > Votes are due by 24 February 2016, 2:00 PM UTC. > > 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]. > > Sean Mullan > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > [3] > http://hg.openjdk.java.net/jdk9/dev/jdk/log?revcount=1000&rev=author%28%22ascarpin%22%29 > > [4] http://openjdk.java.net/jeps/246 From weijun.wang at oracle.com Wed Feb 10 15:27:49 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Wed, 10 Feb 2016 23:27:49 +0800 Subject: CFV: New JDK 9 Reviewer: Anthony Scarpino In-Reply-To: <56BB34E7.6040207@oracle.com> References: <56BB34E7.6040207@oracle.com> Message-ID: <089E30AF-AB3A-480C-9DA3-12396C6A4136@oracle.com> Vote: yes --Weijun > On Feb 10, 2016, at 9:02 PM, Sean Mullan wrote: > > I hereby nominate Anthony Scarpino to JDK 9 Reviewer. > > Anthony Scarpino is a member of the security libraries team at Oracle. He has contributed 39 changesets to the JDK 9 Project [3]. He is also the Author and Owner of JEP 246 (Leverage CPU Instructions for GHASH and RSA) [4] which has significantly improved cryptographic performance and has been successfully integrated to JDK 9. > > Votes are due by 24 February 2016, 2:00 PM UTC. > > 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]. > > Sean Mullan > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > [3] http://hg.openjdk.java.net/jdk9/dev/jdk/log?revcount=1000&rev=author%28%22ascarpin%22%29 > [4] http://openjdk.java.net/jeps/246 From mandy.chung at oracle.com Wed Feb 10 16:40:09 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 10 Feb 2016 08:40:09 -0800 Subject: CFV: New JDK 9 Reviewer: Anthony Scarpino In-Reply-To: <56BB34E7.6040207@oracle.com> References: <56BB34E7.6040207@oracle.com> Message-ID: <8783C875-E438-43AD-AE52-8E3BE6714F3C@oracle.com> Vote: yes Mandy From huizhe.wang at oracle.com Wed Feb 10 17:12:18 2016 From: huizhe.wang at oracle.com (huizhe wang) Date: Wed, 10 Feb 2016 09:12:18 -0800 Subject: CFV: New JDK 9 Reviewer: Anthony Scarpino In-Reply-To: <56BB34E7.6040207@oracle.com> References: <56BB34E7.6040207@oracle.com> Message-ID: <56BB6F72.20106@oracle.com> Vote: yes Joe (java.net id: joehw) On 2/10/2016 5:02 AM, Sean Mullan wrote: > I hereby nominate Anthony Scarpino to JDK 9 Reviewer. From vladimir.kozlov at oracle.com Wed Feb 10 17:44:08 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 10 Feb 2016 09:44:08 -0800 Subject: CFV: New JDK 9 Reviewer: Anthony Scarpino In-Reply-To: <56BB34E7.6040207@oracle.com> References: <56BB34E7.6040207@oracle.com> Message-ID: <56BB76E8.5000605@oracle.com> Vote: yes On 2/10/16 5:02 AM, Sean Mullan wrote: > I hereby nominate Anthony Scarpino to JDK 9 Reviewer. > > Anthony Scarpino is a member of the security libraries team at Oracle. He has contributed 39 changesets to the JDK 9 > Project [3]. He is also the Author and Owner of JEP 246 (Leverage CPU Instructions for GHASH and RSA) [4] which has > significantly improved cryptographic performance and has been successfully integrated to JDK 9. > > Votes are due by 24 February 2016, 2:00 PM UTC. > > 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]. > > Sean Mullan > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > [3] http://hg.openjdk.java.net/jdk9/dev/jdk/log?revcount=1000&rev=author%28%22ascarpin%22%29 > [4] http://openjdk.java.net/jeps/246 From serguei.spitsyn at oracle.com Wed Feb 10 21:21:43 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 10 Feb 2016 13:21:43 -0800 Subject: CFV: New JDK 9 Reviewer: Anthony Scarpino In-Reply-To: <56BB34E7.6040207@oracle.com> References: <56BB34E7.6040207@oracle.com> Message-ID: <56BBA9E7.6010105@oracle.com> Vote: yes From lana.steuck at oracle.com Wed Feb 10 22:11:09 2016 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 10 Feb 2016 14:11:09 -0800 (PST) Subject: jdk9-b105: dev Message-ID: <201602102211.u1AMB9JU028255@sc11152554.us.oracle.com> http://hg.openjdk.java.net/jdk9/jdk9/rev/be58b02c11f9 http://hg.openjdk.java.net/jdk9/jdk9/nashorn/rev/4e9749cc32f1 http://hg.openjdk.java.net/jdk9/jdk9/langtools/rev/81bd82222f8a http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/55518739e399 http://hg.openjdk.java.net/jdk9/jdk9/jaxws/rev/45a666c58e4c http://hg.openjdk.java.net/jdk9/jdk9/jaxp/rev/5acf6071d4d6 http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/266fa9bb5297 http://hg.openjdk.java.net/jdk9/jdk9/corba/rev/64006ae915b3 --- All the fixes will be tested during promotion (no PIT testing at this point): List of all fixes: =================== JDK-4769772 client-libs JInternalFrame.setIcon(true) before JDesktopPane.add(JIF) causes wrong JDK-6459818 client-libs Audio A-law and law decoder skip() method not implemented JDK-6488522 client-libs PNG writer should permit setting compression level and iDAT chunk maxi JDK-6961123 client-libs setWMClass fails to null-terminate WM_CLASS string JDK-7035459 client-libs [TEST_BUG] java/awt/Focus/TranserFocusToWindow/TranserFocusToWindow.ja JDK-7087869 client-libs [TEST_BUG] [macosx] No mac os x support in test java/awt/Mouse/ExtraMo JDK-7104635 client-libs HTMLEditorKit fails to write down some html files JDK-8016665 client-libs [macosx] JComponent behaviour doesn't comply API documentation (setCom JDK-8023213 client-libs [macosx] closed/java/awt/FontClass/NaNTransform.java fails on MacOS X JDK-8040139 client-libs Test closed/javax/print/attribute/Services_getDocFl.java fails with Nu JDK-8041894 client-libs [macosx] Test javax/swing/JSpinner/8008657/bug8008657.java failed on M JDK-8041928 client-libs MouseEvent.getModifiersEx gives wrong result JDK-8064800 client-libs AudioSystem/WaveFileWriter can't write PCM_FLOAT, but writes it anyway JDK-8131974 client-libs AudioFileReader incorrectly handle EOFException JDK-8133039 client-libs Provide public API to sun.swing.UIAction#isEnabled(Object) JDK-8135088 client-libs Typo in AuFileReader JDK-8138838 client-libs docs cleanup for java.desktop JDK-8139213 client-libs [macosx] Mac OS X Aqua Look and Feel: JOptionPane can truncate the fir JDK-8143054 client-libs [macosx] KeyEvent modifiers do not contain information about mouse but JDK-8143150 client-libs DrawImagePipe can skip some unnecessary blits JDK-8143562 client-libs JPEG reader returns null for getRawImageType() JDK-8144488 client-libs Compilation fails on Jake for regtest javax/swing/JMenu/8067346/bug806 JDK-8144718 client-libs Pisces / Marlin Strokers may generate invalid curves with huge coordin JDK-8144744 client-libs ImageWriter.replacePixels() specification is incorrect regarding null JDK-8145060 client-libs Minimizing a JInternal frame not shifting focus to frame below it JDK-8145113 client-libs OutOfMemoryError when reading a 17KB corrupted TIFF image JDK-8145116 client-libs [TEST_BUG] Incorrect binary comparison in java/awt/event/KeyEvent/Exte JDK-8145584 client-libs java/awt/font/TextLayout/TestGetPixelBounds.java fails on Linux JDK-8145608 client-libs PNG writer should permit setting compression level and iDAT chunk max JDK-8145776 client-libs [TEST] add a test for multipage tiff creation JDK-8145785 client-libs [TEST_BUG] java/awt/Toolkit/GetSizeTest/GetScreenSizeTest.java: incorr JDK-8145808 client-libs [PIT] test java/awt/Graphics2D/MTGraphicsAccessTest/MTGraphicsAccessTe JDK-8146076 client-libs [TEST_BUG] Fail of sun/java2d/marlin/CeilAndFloorTests.java with Jigsa JDK-8146144 client-libs Incorrect behaviour of AudioSystem.getTargetFormats/getTargetEncodings JDK-8146168 client-libs [TEST_BUG] instability of java/awt/Frame/MaximizedToMaximized/Maximize JDK-8146276 client-libs Right aligned ToolBar component does not appear JDK-8146317 client-libs Memory leak in wcstombsdmp JDK-8146881 client-libs [TEST] update some imageio tests to affect TIFF format JDK-8147407 client-libs Provide support of WaveExtensible sound format JDK-8147443 client-libs Use Common Cleaner in Marlin OffHeapArray JDK-8147966 client-libs [TEST] add a test for multiresolution image properties JDK-8148891 client-libs Multiple failing javax/imageio/plugins after client integration JDK-8148916 client-libs Mark bug6400879.java as intermittently failing JDK-8148983 client-libs Fix extra comma in changes for JDK-8148916 JDK-8064466 core-libs (fs spec) Files.readAttributes(Path, String, LinkOption...) not clear JDK-8135250 core-libs Replace custom crypto check/range functionality with check index/range JDK-8138578 core-libs MethodHandles.Lookup.findSpecial() Javadoc fails to consider static me JDK-8141452 core-libs Convert between TimeUnit and ChronoUnit JDK-8143016 core-libs java/time/test/java/time/TestClock_System.java failed intermittently JDK-8143317 core-libs jdk/lambda/vm/InterfaceAccessFlagsTest.java fails with IncompatibleCla JDK-8146218 core-libs Add LocalDate.datesUntil method producing Stream JDK-8146249 core-libs libjimage should use delete[] with new[] JDK-8146747 core-libs java.time.Duration.toNanos() and toMillis() exception on negative dura JDK-8146773 core-libs java/lang/ref/CleanerTest.java CleanerTest.testRefSubtypes() fails wit JDK-8147912 core-libs test "parseWithZoneWithoutOffset" of java/time/tck/java/time/format/TC JDK-8148115 core-libs Stream.findFirst for unordered source optimization JDK-8148117 core-libs Move sun.misc.Cleaner to jdk.internal.ref JDK-8148250 core-libs Stream.limit() parallel tasks with ordered non-SUBSIZED source should JDK-8148352 core-libs CleanerTest fails: Cleanable should have been freed JDK-8148710 core-libs Remove FlatMapOpTest.java from ProblemList.txt JDK-8148787 core-libs StringConcatFactory exactness check produces bad bytecode when a non-a JDK-8148821 core-libs (fs) Path.getParent() javadoc error JDK-8148838 core-libs Stream.flatMap(...).spliterator() cannot properly split after tryAdvan JDK-8148869 core-libs StringConcatFactory MH_INLINE_SIZED_EXACT strategy does not work with JDK-8148926 core-libs Call site profiling fails on braces-wrapped anonymous function JDK-8148928 core-libs java/util/stream/test/**/SequentialOpTest.java timed out intermittentl JDK-8148936 core-libs Adapt UUID.toString() to Compact Strings JDK-8149003 core-libs Mark more jdk_core tests as intermittently failing JDK-8149044 core-libs jdk/internal/misc/JavaLangAccess/FormatUnsigned.java fails all platfor JDK-8149186 core-libs Don't use indy for optimistic arithmetic JDK-8149334 core-libs JSON.parse(JSON.stringify([])).push(10) creates an array containing tw JDK-6659240 core-svc Exceptions thrown by MXBeans wrongly documented in j.l.m.ManagementFac JDK-8146015 core-svc JMXInterfaceBindingTest is failing intermittently for IPv6 addresses JDK-6564138 deploy Cache: resources with parameters such as foo.jar;jsessionid=123456 are JDK-6945162 deploy DownloadService Ignores Jar Resources When URL Contains Params JDK-8139389 deploy Register a protocol handler for Java Webstart JDK-8145379 deploy [test] The DRS version attribute for 9 need to be updated in JawsLocal JDK-8145383 deploy ESL app signed by expired cert with sandbox permissions is not blocked JDK-8145384 deploy [test] Two cases in AssociationSuiteTest need to be updated due to JDK JDK-8145387 deploy [test] Association prompt will show up even test app with all permissi JDK-8145478 deploy [test]Need to update test code to adapt change in URL format of resour JDK-8145480 deploy [test]CacheViewerTest::testReInstallApp failed intermittently after re JDK-8145865 deploy [test] CacheViewerTest::testReInstallApp2 fails by timeout because it JDK-8145872 deploy [test] JawsOcspAndCrlCheckSSLCertTest::testSSLCertBadChainJNLP failed JDK-8145912 deploy Platform version of JDK9 is wrong (set product version 9-na) JDK-8146450 deploy Java Web Start resource cache doesn't store all HTTP response headers JDK-8146542 deploy [test] LSPvalidation cases failed in nightly JDK-8147054 deploy [test]JawsOcspAndCrlCheckTest::testMultiJarValidCert_extension need to JDK-8147055 deploy [test]The allowed range for PrintCMSStatistics is from 0 to 2 now JDK-8147439 deploy Need a test to cover JDK-8054393 JDK-6675699 hotspot need comprehensive fix for unconstrained ConvI2L with narrowed type JDK-6985422 hotspot flush the output streams before OnError commands JDK-8065334 hotspot CodeHeap expansion fails although there is uncommitted memory JDK-8066599 hotspot Add methods to check VM mode to c.o.j.t.Platform JDK-8071374 hotspot Native disassembler implementation may be not thread-safe JDK-8071864 hotspot compiler/c2/6772683/InterruptedTest.java failed in nightly JDK-8072725 hotspot Provide more granular levels for GC verification JDK-8086053 hotspot Address inconsistencies regarding ZeroTLAB JDK-8129419 hotspot heapDumper.cpp: assert(length_in_bytes > 0) failed: nothing to copy JDK-8130063 hotspot Refactoring tmtools jstat and jstack tests to jtreg JDK-8132717 hotspot Add tests checking that instances of j.l.Classes of a large size are a JDK-8132720 hotspot Add tests which checks that Humongous objects are not moved after Fu JDK-8133612 hotspot new clone logic added in 8042235 is missing from compiler intrinsics JDK-8135198 hotspot Add -XX:VMOptionsFile support to JAVA_TOOL_OPTIONS and _JAVA_OPTIONS JDK-8136469 hotspot OptimizeStringConcat fails on pre-sized StringBuilder shapes JDK-8139771 hotspot Eliminating CastPP nodes at Phis when they all come from a unique inpu JDK-8140001 hotspot _allocateInstance intrinsic does not throw InstantiationException for JDK-8140659 hotspot C1: invokedynamic call patching violates JVMS-6.5.invokedynamic JDK-8141557 hotspot TestResolvedJavaMethod.java times out after 1000 ms JDK-8141564 hotspot Convert TraceItables and PrintVtables to Unified Logging JDK-8141615 hotspot Add new public methods to sun.reflect.ConstantPool JDK-8143353 hotspot update for x86 sin and cos in the math lib JDK-8143558 hotspot evaluate if thr_sigsetmask can be removed from hotspot (solaris) codeb JDK-8143847 hotspot Remove REF_CLEANER reference category JDK-8144212 hotspot JDK 9 b93 breaks Apache Lucene due to compact strings JDK-8144527 hotspot NewSizeThreadIncrease would make an overflow JDK-8144573 hotspot TLABWasteIncrement=max_jint fires an assert on SPARC for non-G1 GC mod JDK-8144953 hotspot runtime/CommandLine/TraceExceptionsTest.java fails when exception is t JDK-8145000 hotspot TestOptionsWithRanges.java failure for XX:+UseNUMA -XX:+UseNUMAInterle JDK-8145025 hotspot compiler/compilercontrol/commandfile/CompileOnlyTest.java and compiler JDK-8145037 hotspot Clean up FreeIdSet usage JDK-8145038 hotspot Simplify mut_process_buffer worker id management JDK-8145093 hotspot [TESTBUG] Remove test skip code for Solaris SPARC in runtime/SharedArc JDK-8145184 hotspot [aix] Implement os::platform_print_native_stack on AIX JDK-8145322 hotspot Code generated from unsafe loops can be slightly improved JDK-8145331 hotspot SEGV in DirectivesStack::release(DirectiveSet*) JDK-8145336 hotspot PPC64: fix string intrinsics after CompactStrings change JDK-8145442 hotspot Add the facility to verify remembered sets for G1 JDK-8145788 hotspot JVM crashes with -XX:+EnableTracing JDK-8145940 hotspot TempNewSymbol should have correct copy and assignment functions JDK-8146222 hotspot assert(_initialized) failed: TLS not initialized yet! JDK-8146244 hotspot compiler/jvmci/code/DataPatchTest.java crashes: SIGSEGV in (getConstCl JDK-8146246 hotspot JVMCICompiler::abort_on_pending_exception: assert(!thread->owns_locks( JDK-8146364 hotspot Remove @ServiceProvider mechanism from JVMCI JDK-8146399 hotspot Refactor the BlockOffsetTable classes. JDK-8146401 hotspot Clean up oop.hpp: add inline directives and fix header files JDK-8146410 hotspot Interpreter functions are declared and defined in the wrong files JDK-8146424 hotspot runtime/ReservedStack/ReservedStackTest.java triggers: assert(thread-> JDK-8146485 hotspot Add test for classresolve logging tag JDK-8146523 hotspot VirtualMemoryTracker::remove_released_region double count unmapped CDS JDK-8146575 hotspot C1 fast TLAB refills can overflow with large minimum TLAB sizes JDK-8146581 hotspot Minor corrections to the patch submitted for earlier bug id - 8143925 JDK-8146612 hotspot C2: Precedence edges specification violated JDK-8146613 hotspot PPC64: C2 does no longer respect int to long conversion for stub calls JDK-8146620 hotspot CodelistTest.java fails with "Test failed on: jdk.internal.misc.Unsafe JDK-8146629 hotspot Make phase->is_IterGVN() accessible from Node::Identity and Node::Valu JDK-8146653 hotspot Debug version missing in hs_err files and on internal version after Ve JDK-8146678 hotspot aarch64: assertion failure: call instruction in an infinite loop JDK-8146690 hotspot Make all classes in GC follow the naming convention. JDK-8146694 hotspot Break out shared constants and static BOT functions. JDK-8146695 hotspot FinalizeTest04 crashes VM with EXCEPTION_INT_DIVIDE_BY_ZERO JDK-8146705 hotspot Improve JVMCI support for blocking compilation JDK-8146709 hotspot Incorrect use of ADRP for byte_map_base JDK-8146751 hotspot jdk/test/tools/launcher/TooSmallStackSize.java failed on Mac OS JDK-8146792 hotspot Predicate moved after partial peel may lead to broken graph JDK-8146800 hotspot Reorganize logging alias code. JDK-8146820 hotspot JVMCI options should not use System.getProperty directly JDK-8146843 hotspot aarch64: add scheduling support for FP and vector instructions JDK-8146855 hotspot Update hotspot sources to recognize Solaris Studio 12u4 compiler JDK-8146871 hotspot Make the clean target silent in hotspot/test/Makefile JDK-8146886 hotspot aarch64: fails to build following 8136525 and 8139864 JDK-8146889 hotspot Update @requires expression for GC tests to run if GC is default JDK-8146891 hotspot AArch64 needs patch for 8032463 JDK-8146978 hotspot PPC64: Fix build after integration of C++ interpreter removal JDK-8146983 hotspot C1: assert(appendix.not_null()) failed for invokehandle bytecode JDK-8146985 hotspot Change output directory for hotspot's jtreg tests JDK-8146990 hotspot Convert CollectorPolicy to use log_warning instead of warning JDK-8146994 hotspot Move internal vm tests to a separate file JDK-8146999 hotspot hotspot/test/compiler/c2/8007294/Test8007294.java test nightly failure JDK-8147000 hotspot VM crashes during initialization trying to print log message JDK-8147012 hotspot Fix includes in internalVMTests.cpp JDK-8147075 hotspot Rename old GC JTreg tests to the new naming scheme JDK-8147079 hotspot Add serviceability/logging folder to the hotspot_serviceability test g JDK-8147386 hotspot assert(size == calc_size) failed: incorrect size calculattion x86_32.a JDK-8147432 hotspot JVMCI should report bailouts in PrintCompilation output JDK-8147433 hotspot PrintNMethods no longer works with JVMCI JDK-8147441 hotspot Unchecked pending exceptions in the WhiteBox API's implementation JDK-8147444 hotspot compiler/jsr292/NonInlinedCall/RedefineTest.java fails with NullPointe JDK-8147464 hotspot Use LogConfiguration::configure_stdout() instead of parse_log_argument JDK-8147470 hotspot update JVMCI mx extensions JDK-8147475 hotspot compiler/jvmci/code/SimpleDebugInfoTest.java fails in Assembler::locat JDK-8147482 hotspot Zero build fails after 8144953 JDK-8147494 hotspot com/sun/management/HotSpotDiagnosticMXBean/CheckOrigin.java fails with JDK-8147509 hotspot [aix] Newlines missing in register info printout JDK-8147564 hotspot [JVMCI] remove unused method CodeCacheProvider.needsDataPatch JDK-8147599 hotspot [JVMCI] simplify code installation interface JDK-8147611 hotspot G1 - Missing memory barrier in start_cset_region_for_worker JDK-8147791 hotspot Reenable tests that were temporarily quarantined in jdk9/hs JDK-8147805 hotspot C1 segmentation fault due to inline Unsafe::getAndSetObject JDK-8147848 hotspot tmtools tests ported to JTREG need to be quarantined. JDK-8147853 hotspot "assert(t->meet(t0) == t) failed: Not monotonic" with sun/util/calenda JDK-8147876 hotspot ciTypeFlow::is_dominated_by() writes outside dominated array JDK-8147937 hotspot Adapt SAP copyrights to new company name. JDK-8148101 hotspot [JVMCI] Make CallingConvention.Type extensible JDK-8148136 hotspot compile control tests have incorrect @build directives JDK-8148155 hotspot Quarantine tests depending on AllocationStackTrace JDK-8148161 hotspot quarantine compiler/loopopts/UseCountedLoopSafepoints.java JDK-8148202 hotspot move lookup of Java class and hub from ResolvedJavaType to ConstantRef JDK-8148240 hotspot aarch64: random infrequent null pointer exceptions in javac JDK-8129395 infrastructure Configure should verify that -fstack-protector is valid - take 2 JDK-8148629 infrastructure Disable remaining warnings in awt/fontmanager JDK-8148655 infrastructure LOG=cmdlines and other build-infra fixes JDK-8148929 infrastructure Suboptimal code generated when setting sysroot include with Solaris St JDK-8145939 install Minor local windows build fixes JDK-8146650 install [windows] browsers.cpp: isInstalled(BrowserId browser, bool is32bit) h JDK-8072379 other-libs CoreLibs: Implement jdk.Version JDK-8098581 security-libs SecureRandom.nextBytes() hurts performance with small size requests JDK-8145344 security-libs Add SHA1 and SHA-224 to preferred provider list for solaris-sparc JDK-8080357 tools JShell: Only unqualified unresolved references should be corralled JDK-8081431 tools JShell: Dropping import should update dependencies JDK-8147949 tools NetBeans cannot open langtools repository because of the reserved word JDK-8148955 tools libjimage.so compiled with wrong flags JDK-8144593 xml Suppress not recognized property/feature warning messages from SAXPars From alejandro.murillo at oracle.com Wed Feb 10 23:01:45 2016 From: alejandro.murillo at oracle.com (Alejandro E Murillo) Date: Wed, 10 Feb 2016 16:01:45 -0700 Subject: jdk9-dev: HotSpot Message-ID: <56BBC159.60603@oracle.com> jdk9-hs-2016-02-04 has been integrated into jdk9-dev. http://hg.openjdk.java.net/jdk9/dev/rev/623fc617c3ef http://hg.openjdk.java.net/jdk9/dev/corba/rev/64006ae915b3 http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/e88fb420b623 http://hg.openjdk.java.net/jdk9/dev/jaxp/rev/5acf6071d4d6 http://hg.openjdk.java.net/jdk9/dev/jaxws/rev/45a666c58e4c http://hg.openjdk.java.net/jdk9/dev/jdk/rev/c03e561eaa15 http://hg.openjdk.java.net/jdk9/dev/langtools/rev/afb78d30c3f9 http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/1d7aaa18e5e5 Component : VM Status : Go for integration Date : 02/10/2016 at 16:20 MSK Tested By : VM SQE &dmitry.fazunenko at oracle.com Bundles : 2016-02-04-225017.amurillo.jdk9-hs-2016-02-04-snapshot Testing: 66 new failures, 2291 known failures, 387348 passed. Issues and Notes: No stoppers have been detected so far. Go for integration CRs for testing: 8003585: strength reduce or eliminate range checks for power-of-two sized arrays 8144239: [TESTBUG] InlineCommandTest.java: unknown compiler level 0 for commpile ID: 651 8146478: Node limit exceeded with -XX:AllocateInstancePrefetchLines=1073741823 8147645: get_ctrl_no_update() code is wrong 8148012: get rid of slash-dot-dot in @library directives 8148328: aarch64: redundant lsr instructions in stub code. 8148490: RegisterSaver::restore_live_registers() fails to restore xmm registers on 32 bit 8148751: [TESTBUG] compiler/whitebox/AllocationCodeBlobTest.java fails due to unexpected code cache allocation 8148753: Compilation fails due to field accesses on array types 8148970: Quarantine testlibrary_tests/whitebox/vm_flags/IntxTest.java -- Alejandro From bengt.rutisson at oracle.com Thu Feb 11 11:33:34 2016 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Thu, 11 Feb 2016 12:33:34 +0100 Subject: Result: CFV: New JDK 9 Reviewer: David Lindholm In-Reply-To: <56A9DD3B.6020508@oracle.com> References: <56A9DD3B.6020508@oracle.com> Message-ID: <56BC718E.3020403@oracle.com> Voting for David Lindholm is now closed. Yes: 22 Veto: 0 Abstain: 0 According to the Bylaws definition of Three-Vote Consensus [0], this is sufficient to approve the nomination. [0] http://openjdk.java.net/bylaws#three-vote-consensus Bengt On 2016-01-28 10:19, Bengt Rutisson wrote: > > I hereby nominate David Lindholm to JDK 9 Reviewer. > > David is a member of the Hotspot GC team. He has contributed 45 > changesets in HotSpot [3] and one in the JDK [4]. David has worked on > large parts of the GC code but also made changes concerning all parts > of HotSpot, such as the changes to make the assert() macro a > varargs-macro that eliminates the need for err_msg(). David was also a > key reviewer of the large unified logging changes for the GC code. > > Votes are due by 11 February 2016, 11:00 CET. > > Only current jdk9 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]. > > Bengt Rutisson > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > [3] > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/log?revcount=1000&rev=author%28%22david%22%29+and+not+merge%28%29 > [4] > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/log?revcount=1000&rev=author%28%22david%22%29+and+not+merge%28%29 From vladimir.x.ivanov at oracle.com Thu Feb 11 14:06:17 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Thu, 11 Feb 2016 17:06:17 +0300 Subject: CFV: New jdk9 Reviewer: Tobias Hartmann Message-ID: <56BC9559.8060906@oracle.com> I hereby nominate Tobias Hartmann (OpenJDK user name: thartmann) to JDK 9 Reviewer. Tobias is a member of the Hotspot JVM Compiler group. He contributed 68 changesets to jdk9 project [1] and he is qualified to be a Reviewer. While working on Hotspot JVM, Tobias implemented Segmented Code Cache [2] and compiler support for Compact Strings [3]. Votes are due by February, 25 2016. Only current JDK 9 Reviewers [4] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [5]. Best regards, Vladimir Ivanov [1] http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/search/?rev=thartmann&revcount=100 [2] https://bugs.openjdk.java.net/browse/JDK-8015774 [3] http://openjdk.java.net/jeps/254 [4] http://openjdk.java.net/census#jdk9 [5] http://openjdk.java.net/projects#committer-vote From vladimir.x.ivanov at oracle.com Thu Feb 11 14:07:17 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Thu, 11 Feb 2016 17:07:17 +0300 Subject: CFV: New jdk9 Reviewer: Tobias Hartmann In-Reply-To: <56BC9559.8060906@oracle.com> References: <56BC9559.8060906@oracle.com> Message-ID: <56BC9595.7080604@oracle.com> Vote: yes Best regards, Vladimir Ivanov On 2/11/16 5:06 PM, Vladimir Ivanov wrote: > I hereby nominate Tobias Hartmann (OpenJDK user name: thartmann) to JDK > 9 Reviewer. From volker.simonis at gmail.com Thu Feb 11 14:08:22 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 11 Feb 2016 15:08:22 +0100 Subject: CFV: New jdk9 Reviewer: Tobias Hartmann In-Reply-To: <56BC9559.8060906@oracle.com> References: <56BC9559.8060906@oracle.com> Message-ID: Vote: yes On Thu, Feb 11, 2016 at 3:06 PM, Vladimir Ivanov wrote: > I hereby nominate Tobias Hartmann (OpenJDK user name: thartmann) to JDK > 9 Reviewer. > > Tobias is a member of the Hotspot JVM Compiler group. He contributed 68 > changesets to jdk9 project [1] and he is qualified to be a Reviewer. > > While working on Hotspot JVM, Tobias implemented Segmented Code Cache [2] > and compiler support for Compact Strings [3]. > > Votes are due by February, 25 2016. > > Only current JDK 9 Reviewers [4] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [5]. > > Best regards, > Vladimir Ivanov > > [1] > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/search/?rev=thartmann&revcount=100 > [2] https://bugs.openjdk.java.net/browse/JDK-8015774 > [3] http://openjdk.java.net/jeps/254 > [4] http://openjdk.java.net/census#jdk9 > [5] http://openjdk.java.net/projects#committer-vote From roland.westrelin at oracle.com Thu Feb 11 14:10:15 2016 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Thu, 11 Feb 2016 15:10:15 +0100 Subject: CFV: New jdk9 Reviewer: Tobias Hartmann In-Reply-To: <56BC9559.8060906@oracle.com> References: <56BC9559.8060906@oracle.com> Message-ID: <37D171C7-655B-4927-9E66-34F2AB7983C4@oracle.com> Vote: yes Roland. From igor.ignatyev at oracle.com Thu Feb 11 14:16:26 2016 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Thu, 11 Feb 2016 17:16:26 +0300 Subject: CFV: New jdk9 Reviewer: Tobias Hartmann In-Reply-To: <56BC9559.8060906@oracle.com> References: <56BC9559.8060906@oracle.com> Message-ID: <9AEF7492-9B6D-434F-8D0F-AB0D480CC0D8@oracle.com> Vote: yes ? Igor From Alan.Bateman at oracle.com Thu Feb 11 14:19:09 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 11 Feb 2016 14:19:09 +0000 Subject: CFV: New jdk9 Reviewer: Tobias Hartmann In-Reply-To: <56BC9559.8060906@oracle.com> References: <56BC9559.8060906@oracle.com> Message-ID: <56BC985D.4000003@oracle.com> Vote: yes From jaroslav.bachorik at oracle.com Thu Feb 11 14:21:24 2016 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Thu, 11 Feb 2016 15:21:24 +0100 Subject: CFV: New jdk9 Reviewer: Tobias Hartmann In-Reply-To: <56BC9559.8060906@oracle.com> References: <56BC9559.8060906@oracle.com> Message-ID: <56BC98E4.50102@oracle.com> Vote: yes -JB- On 11.2.2016 15:06, Vladimir Ivanov wrote: > I hereby nominate Tobias Hartmann (OpenJDK user name: thartmann) to JDK > 9 Reviewer. > > Tobias is a member of the Hotspot JVM Compiler group. He contributed 68 > changesets to jdk9 project [1] and he is qualified to be a Reviewer. > > While working on Hotspot JVM, Tobias implemented Segmented Code Cache > [2] and compiler support for Compact Strings [3]. > > Votes are due by February, 25 2016. > > Only current JDK 9 Reviewers [4] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Lazy Consensus voting instructions, see [5]. > > Best regards, > Vladimir Ivanov > > [1] > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/search/?rev=thartmann&revcount=100 > > [2] https://bugs.openjdk.java.net/browse/JDK-8015774 > [3] http://openjdk.java.net/jeps/254 > [4] http://openjdk.java.net/census#jdk9 > [5] http://openjdk.java.net/projects#committer-vote From daniel.daugherty at oracle.com Thu Feb 11 14:29:33 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 11 Feb 2016 07:29:33 -0700 Subject: CFV: New jdk9 Reviewer: Tobias Hartmann In-Reply-To: <56BC9559.8060906@oracle.com> References: <56BC9559.8060906@oracle.com> Message-ID: <56BC9ACD.5060906@oracle.com> Vote: yes Dan On 2/11/16 7:06 AM, Vladimir Ivanov wrote: > I hereby nominate Tobias Hartmann (OpenJDK user name: thartmann) to JDK > 9 Reviewer. > > Tobias is a member of the Hotspot JVM Compiler group. He contributed > 68 changesets to jdk9 project [1] and he is qualified to be a Reviewer. > > While working on Hotspot JVM, Tobias implemented Segmented Code Cache > [2] and compiler support for Compact Strings [3]. > > Votes are due by February, 25 2016. > > Only current JDK 9 Reviewers [4] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Lazy Consensus voting instructions, see [5]. > > Best regards, > Vladimir Ivanov > > [1] > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/search/?rev=thartmann&revcount=100 > [2] https://bugs.openjdk.java.net/browse/JDK-8015774 > [3] http://openjdk.java.net/jeps/254 > [4] http://openjdk.java.net/census#jdk9 > [5] http://openjdk.java.net/projects#committer-vote > From staffan.larsen at oracle.com Thu Feb 11 14:35:05 2016 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 11 Feb 2016 15:35:05 +0100 Subject: CFV: New jdk9 Reviewer: Tobias Hartmann In-Reply-To: <56BC9559.8060906@oracle.com> References: <56BC9559.8060906@oracle.com> Message-ID: <261CAA2C-653D-47AF-AA3B-47859DBE9A16@oracle.com> Vote: yes > On 11 feb. 2016, at 15:06, Vladimir Ivanov wrote: > > I hereby nominate Tobias Hartmann (OpenJDK user name: thartmann) to JDK > 9 Reviewer. > > Tobias is a member of the Hotspot JVM Compiler group. He contributed 68 changesets to jdk9 project [1] and he is qualified to be a Reviewer. > > While working on Hotspot JVM, Tobias implemented Segmented Code Cache [2] and compiler support for Compact Strings [3]. > > Votes are due by February, 25 2016. > > Only current JDK 9 Reviewers [4] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [5]. > > Best regards, > Vladimir Ivanov > > [1] http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/search/?rev=thartmann&revcount=100 > [2] https://bugs.openjdk.java.net/browse/JDK-8015774 > [3] http://openjdk.java.net/jeps/254 > [4] http://openjdk.java.net/census#jdk9 > [5] http://openjdk.java.net/projects#committer-vote From harold.seigel at oracle.com Thu Feb 11 14:40:28 2016 From: harold.seigel at oracle.com (harold seigel) Date: Thu, 11 Feb 2016 09:40:28 -0500 Subject: CFV: New jdk9 Reviewer: Tobias Hartmann In-Reply-To: <56BC9559.8060906@oracle.com> References: <56BC9559.8060906@oracle.com> Message-ID: <56BC9D5C.8000706@oracle.com> Vote: yes Harold On 2/11/2016 9:06 AM, Vladimir Ivanov wrote: > I hereby nominate Tobias Hartmann (OpenJDK user name: thartmann) to JDK > 9 Reviewer. > > Tobias is a member of the Hotspot JVM Compiler group. He contributed > 68 changesets to jdk9 project [1] and he is qualified to be a Reviewer. > > While working on Hotspot JVM, Tobias implemented Segmented Code Cache > [2] and compiler support for Compact Strings [3]. > > Votes are due by February, 25 2016. > > Only current JDK 9 Reviewers [4] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Lazy Consensus voting instructions, see [5]. > > Best regards, > Vladimir Ivanov > > [1] > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/search/?rev=thartmann&revcount=100 > [2] https://bugs.openjdk.java.net/browse/JDK-8015774 > [3] http://openjdk.java.net/jeps/254 > [4] http://openjdk.java.net/census#jdk9 > [5] http://openjdk.java.net/projects#committer-vote From vladimir.x.ivanov at oracle.com Thu Feb 11 15:00:58 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Thu, 11 Feb 2016 18:00:58 +0300 Subject: CFV: New jdk9 Reviewer: Zoltan Majo Message-ID: <56BCA22A.7030300@oracle.com> I hereby nominate Zoltan Majo (OpenJDK user name: zmajo) to JDK 9 Reviewer. Zoltan is a member of the Hotspot JVM Compiler group. He contributed 51 changesets to jdk9 project [1] and he is qualified to be a Reviewer. Votes are due by February, 25 2016. Only current JDK 9 Reviewers [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [3]. Best regards, Vladimir Ivanov [1] http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/log?revcount=100&rev=author%28zmajo%29 [2] http://openjdk.java.net/census#jdk9 [3] http://openjdk.java.net/projects#committer-vote From jaroslav.bachorik at oracle.com Thu Feb 11 15:02:19 2016 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Thu, 11 Feb 2016 16:02:19 +0100 Subject: CFV: New jdk9 Reviewer: Zoltan Majo In-Reply-To: <56BCA22A.7030300@oracle.com> References: <56BCA22A.7030300@oracle.com> Message-ID: <56BCA27B.2020000@oracle.com> Vote: yes -JB- On 11.2.2016 16:00, Vladimir Ivanov wrote: > I hereby nominate Zoltan Majo (OpenJDK user name: zmajo) to JDK > 9 Reviewer. > > Zoltan is a member of the Hotspot JVM Compiler group. He contributed 51 > changesets to jdk9 project [1] and he is qualified to be a Reviewer. > > Votes are due by February, 25 2016. > > Only current JDK 9 Reviewers [2] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Lazy Consensus voting instructions, see [3]. > > Best regards, > Vladimir Ivanov > > [1] > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/log?revcount=100&rev=author%28zmajo%29 > > [2] http://openjdk.java.net/census#jdk9 > [3] http://openjdk.java.net/projects#committer-vote > From vladimir.x.ivanov at oracle.com Thu Feb 11 15:11:35 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Thu, 11 Feb 2016 18:11:35 +0300 Subject: CFV: New jdk9 Reviewer: Zoltan Majo In-Reply-To: <56BCA22A.7030300@oracle.com> References: <56BCA22A.7030300@oracle.com> Message-ID: <56BCA4A7.8040908@oracle.com> Vote: yes Best regards, Vladimir Ivanov On 2/11/16 6:00 PM, Vladimir Ivanov wrote: > I hereby nominate Zoltan Majo (OpenJDK user name: zmajo) to JDK > 9 Reviewer. From igor.ignatyev at oracle.com Thu Feb 11 15:15:24 2016 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Thu, 11 Feb 2016 18:15:24 +0300 Subject: CFV: New jdk9 Reviewer: Zoltan Majo In-Reply-To: <56BCA22A.7030300@oracle.com> References: <56BCA22A.7030300@oracle.com> Message-ID: <972913E7-6363-479E-B1C0-24B4C3238EB8@oracle.com> Vote: yes ? Igor From vladimir.x.ivanov at oracle.com Thu Feb 11 15:16:33 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Thu, 11 Feb 2016 18:16:33 +0300 Subject: CFV: New jdk9 Reviewer: Nils Eliasson Message-ID: <56BCA5D1.7020202@oracle.com> I hereby nominate Nils Eliasson (OpenJDK user name: neliasso to JDK 9 Reviewer. Nils is a member of the Hotspot JVM Compiler group. He contributed 52 changesets to jdk9 project [1] and he is qualified to be a Reviewer. Nils is the author of Compiler Control implementation [2] in HotSpot JVM. Votes are due by February, 25 2016. Only current JDK 9 Reviewers [3] 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 [4]. Best regards, Vladimir Ivanov [1] http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/log?revcount=100&rev=author%28neliasso%29 [2] http://openjdk.java.net/jeps/165 [3] http://openjdk.java.net/census#jdk9 [4] http://openjdk.java.net/projects#committer-vote From igor.ignatyev at oracle.com Thu Feb 11 15:23:06 2016 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Thu, 11 Feb 2016 18:23:06 +0300 Subject: CFV: New jdk9 Reviewer: Nils Eliasson In-Reply-To: <56BCA5D1.7020202@oracle.com> References: <56BCA5D1.7020202@oracle.com> Message-ID: Vote: yes ? Igor From daniel.daugherty at oracle.com Thu Feb 11 15:25:37 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 11 Feb 2016 08:25:37 -0700 Subject: CFV: New jdk9 Reviewer: Zoltan Majo In-Reply-To: <56BCA22A.7030300@oracle.com> References: <56BCA22A.7030300@oracle.com> Message-ID: <56BCA7F1.1010100@oracle.com> Vote: yes Dan On 2/11/16 8:00 AM, Vladimir Ivanov wrote: > I hereby nominate Zoltan Majo (OpenJDK user name: zmajo) to JDK > 9 Reviewer. > > Zoltan is a member of the Hotspot JVM Compiler group. He contributed > 51 changesets to jdk9 project [1] and he is qualified to be a Reviewer. > > Votes are due by February, 25 2016. > > Only current JDK 9 Reviewers [2] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Lazy Consensus voting instructions, see [3]. > > Best regards, > Vladimir Ivanov > > [1] > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/log?revcount=100&rev=author%28zmajo%29 > [2] http://openjdk.java.net/census#jdk9 > [3] http://openjdk.java.net/projects#committer-vote > > From daniel.daugherty at oracle.com Thu Feb 11 15:25:57 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 11 Feb 2016 08:25:57 -0700 Subject: CFV: New jdk9 Reviewer: Nils Eliasson In-Reply-To: <56BCA5D1.7020202@oracle.com> References: <56BCA5D1.7020202@oracle.com> Message-ID: <56BCA805.9000607@oracle.com> Vote: yes Dan On 2/11/16 8:16 AM, Vladimir Ivanov wrote: > I hereby nominate Nils Eliasson (OpenJDK user name: neliasso to JDK > 9 Reviewer. > > Nils is a member of the Hotspot JVM Compiler group. He contributed 52 > changesets to jdk9 project [1] and he is qualified to be a Reviewer. > > Nils is the author of Compiler Control implementation [2] in HotSpot JVM. > > Votes are due by February, 25 2016. > > Only current JDK 9 Reviewers [3] 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 [4]. > > Best regards, > Vladimir Ivanov > > [1] > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/log?revcount=100&rev=author%28neliasso%29 > [2] http://openjdk.java.net/jeps/165 > [3] http://openjdk.java.net/census#jdk9 > [4] http://openjdk.java.net/projects#committer-vote > From vladimir.x.ivanov at oracle.com Thu Feb 11 15:24:04 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Thu, 11 Feb 2016 18:24:04 +0300 Subject: CFV: New jdk9 Reviewer: Nils Eliasson In-Reply-To: <56BCA5D1.7020202@oracle.com> References: <56BCA5D1.7020202@oracle.com> Message-ID: <56BCA794.5060506@oracle.com> Vote: yes Best regards, Vladimir Ivanov On 2/11/16 6:16 PM, Vladimir Ivanov wrote: > I hereby nominate Nils Eliasson (OpenJDK user name: neliasso to JDK > 9 Reviewer. From jesper.wilhelmsson at oracle.com Thu Feb 11 15:33:14 2016 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Thu, 11 Feb 2016 16:33:14 +0100 Subject: CFV: New jdk9 Reviewer: Tobias Hartmann In-Reply-To: <56BC9559.8060906@oracle.com> References: <56BC9559.8060906@oracle.com> Message-ID: <56BCA9BA.6040904@oracle.com> Vote: Yes /Jesper Den 11/2/16 kl. 15:06, skrev Vladimir Ivanov: > I hereby nominate Tobias Hartmann (OpenJDK user name: thartmann) to JDK > 9 Reviewer. > > Tobias is a member of the Hotspot JVM Compiler group. He contributed 68 > changesets to jdk9 project [1] and he is qualified to be a Reviewer. > > While working on Hotspot JVM, Tobias implemented Segmented Code Cache [2] and > compiler support for Compact Strings [3]. > > Votes are due by February, 25 2016. > > Only current JDK 9 Reviewers [4] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [5]. > > Best regards, > Vladimir Ivanov > > [1] > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/search/?rev=thartmann&revcount=100 > [2] https://bugs.openjdk.java.net/browse/JDK-8015774 > [3] http://openjdk.java.net/jeps/254 > [4] http://openjdk.java.net/census#jdk9 > [5] http://openjdk.java.net/projects#committer-vote From jesper.wilhelmsson at oracle.com Thu Feb 11 15:33:29 2016 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Thu, 11 Feb 2016 16:33:29 +0100 Subject: CFV: New jdk9 Reviewer: Zoltan Majo In-Reply-To: <56BCA22A.7030300@oracle.com> References: <56BCA22A.7030300@oracle.com> Message-ID: <56BCA9C9.20800@oracle.com> Vote: Yes /Jesper Den 11/2/16 kl. 16:00, skrev Vladimir Ivanov: > I hereby nominate Zoltan Majo (OpenJDK user name: zmajo) to JDK > 9 Reviewer. > > Zoltan is a member of the Hotspot JVM Compiler group. He contributed 51 > changesets to jdk9 project [1] and he is qualified to be a Reviewer. > > Votes are due by February, 25 2016. > > Only current JDK 9 Reviewers [2] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Best regards, > Vladimir Ivanov > > [1] > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/log?revcount=100&rev=author%28zmajo%29 > > [2] http://openjdk.java.net/census#jdk9 > [3] http://openjdk.java.net/projects#committer-vote > From jesper.wilhelmsson at oracle.com Thu Feb 11 15:33:48 2016 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Thu, 11 Feb 2016 16:33:48 +0100 Subject: CFV: New jdk9 Reviewer: Nils Eliasson In-Reply-To: <56BCA5D1.7020202@oracle.com> References: <56BCA5D1.7020202@oracle.com> Message-ID: <56BCA9DC.7030001@oracle.com> Vote: Yes /Jesper Den 11/2/16 kl. 16:16, skrev Vladimir Ivanov: > I hereby nominate Nils Eliasson (OpenJDK user name: neliasso to JDK > 9 Reviewer. > > Nils is a member of the Hotspot JVM Compiler group. He contributed 52 changesets > to jdk9 project [1] and he is qualified to be a Reviewer. > > Nils is the author of Compiler Control implementation [2] in HotSpot JVM. > > Votes are due by February, 25 2016. > > Only current JDK 9 Reviewers [3] 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 [4]. > > Best regards, > Vladimir Ivanov > > [1] > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/log?revcount=100&rev=author%28neliasso%29 > > [2] http://openjdk.java.net/jeps/165 > [3] http://openjdk.java.net/census#jdk9 > [4] http://openjdk.java.net/projects#committer-vote From paul.sandoz at oracle.com Thu Feb 11 15:39:18 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 11 Feb 2016 16:39:18 +0100 Subject: RFR JDK-8149644 Integrate VarHandles Message-ID: <9C47EF6F-80D6-467E-A5CB-2FDD5FF6AE17@oracle.com> Hi, This is the implementation review request for VarHandles. Langtools: http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8149644-varhandles-integration/langtools/webrev/index.html Hotspot: http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8149644-varhandles-integration/hotspot/webrev/index.html JDK: http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8149644-varhandles-integration/jdk/webrev/index.html The spec/API review is proceeding here [1]. The patches depend on Unsafe changes [2] and ByteBuffer changes [3]. Recent (as of today) JPRT runs for core and hotspot tests pass without failure. Many parts of the code have been soaking in the Valhalla repo for over a year, and it?s been soaking in the sandbox for quite and many a JPRT run was performed. It is planned to push through hs-comp as is the case for the dependent patches, and thus minimise any delays due to integration between forests. The Langtools changes are small. Tweaks were made to support updates to signature polymorphic methods and where may be located, in addition to supporting compilation of calls to MethodHandle.link*. The Hotspot changes are not very large. It?s mostly a matter of augmenting checks for MethodHandle to include that for VarHandle. It?s tempting to generalise the ?invokehandle" invocation as i believe there are other use-cases where it might be useful, but i resisted temptation here. I wanted to focus on the minimal changes required. The JDK changes are more substantial, but a large proportion are new tests. The source compilation approach taken is to use templates, the same approach as for code in the nio package, to generate both implementation and test source code. The implementations are generated by the build, the tests are pre-generated. I believe the tests should have good coverage but we have yet to run any code coverage tool. The approach to invocation of VarHandle signature polymoprhic methods is slightly different to that of MethodHandles. I wanted to ensure that linking for the common cases avoids lambda form creation, compilation and therefore class spinning. That reduces start up costs and also potential circular dependencies that might be induced in the VM boot process if VarHandles are employed early on. For common basic (i.e. erased ref and widened primitive) method signatures, namely all those that matter for the efficient atomic operations there are pre-generated methods that would otherwise be generated from creating and compiling invoker lambda forms. Those methods reside on the VarHandleGuards class. When the VM makes an up call to MethodHandleNatives.linkMethod to link a call site then this up-called method will first check if an appropriate pre-generated method exists on VarHandleGuards and if so it links to that, otherwise it falls back to a method on a class generated from compiling a lambda form. For testing purposes there is a system property available to switch off this optimisation when linking [*]. Each VarHandle instance of the same variable type produced from the same factory will share an underlying immutable instance of a VarForm that contains a set of MemberName instances, one for each implementation of a signature polymorphic method (a value of null means unsupported). The invoke methods (on VarHandleGuards or on lambda forms) will statically link to such MemberName instances using a call to MethodHandle.linkToStatic. There are a couple of TODOs in comments, those are all on non-critical code paths and i plan to chase them up afterwards. C1 does not support constant folding for @Stable arrays hence why in certain cases we have exploded stuff into fields that are operated on using if/else loops. We can simplify such code if/when C1 support is added. Thanks, Paul. [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-January/038150.html [2] http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2016-January/020953.html http://mail.openjdk.java.net/pipermail/hotspot-dev/2016-January/021514.html [3] http://mail.openjdk.java.net/pipermail/nio-dev/2016-February/003535.html [*] This technique might be useful for common signatures of MH invokers to reduce associated costs of lambda form creation and compilation in the interim of something better. From mikael.gerdin at oracle.com Thu Feb 11 16:15:15 2016 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Thu, 11 Feb 2016 17:15:15 +0100 Subject: CFV: New jdk9 Reviewer: Tobias Hartmann In-Reply-To: <56BC9559.8060906@oracle.com> References: <56BC9559.8060906@oracle.com> Message-ID: <56BCB393.6000000@oracle.com> Vote: yes /Mikael On 2016-02-11 15:06, Vladimir Ivanov wrote: > I hereby nominate Tobias Hartmann (OpenJDK user name: thartmann) to JDK > 9 Reviewer. > > Tobias is a member of the Hotspot JVM Compiler group. He contributed 68 > changesets to jdk9 project [1] and he is qualified to be a Reviewer. > > While working on Hotspot JVM, Tobias implemented Segmented Code Cache > [2] and compiler support for Compact Strings [3]. > > Votes are due by February, 25 2016. > > Only current JDK 9 Reviewers [4] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Lazy Consensus voting instructions, see [5]. > > Best regards, > Vladimir Ivanov > > [1] > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/search/?rev=thartmann&revcount=100 > > [2] https://bugs.openjdk.java.net/browse/JDK-8015774 > [3] http://openjdk.java.net/jeps/254 > [4] http://openjdk.java.net/census#jdk9 > [5] http://openjdk.java.net/projects#committer-vote From mikael.gerdin at oracle.com Thu Feb 11 16:15:29 2016 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Thu, 11 Feb 2016 17:15:29 +0100 Subject: CFV: New jdk9 Reviewer: Zoltan Majo In-Reply-To: <56BCA22A.7030300@oracle.com> References: <56BCA22A.7030300@oracle.com> Message-ID: <56BCB3A1.6090803@oracle.com> Vote: yes /Mikael On 2016-02-11 16:00, Vladimir Ivanov wrote: > I hereby nominate Zoltan Majo (OpenJDK user name: zmajo) to JDK > 9 Reviewer. > > Zoltan is a member of the Hotspot JVM Compiler group. He contributed 51 > changesets to jdk9 project [1] and he is qualified to be a Reviewer. > > Votes are due by February, 25 2016. > > Only current JDK 9 Reviewers [2] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Lazy Consensus voting instructions, see [3]. > > Best regards, > Vladimir Ivanov > > [1] > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/log?revcount=100&rev=author%28zmajo%29 > > [2] http://openjdk.java.net/census#jdk9 > [3] http://openjdk.java.net/projects#committer-vote > From mikael.gerdin at oracle.com Thu Feb 11 16:15:44 2016 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Thu, 11 Feb 2016 17:15:44 +0100 Subject: CFV: New jdk9 Reviewer: Nils Eliasson In-Reply-To: <56BCA5D1.7020202@oracle.com> References: <56BCA5D1.7020202@oracle.com> Message-ID: <56BCB3B0.40302@oracle.com> Vote: yes /Mikael On 2016-02-11 16:16, Vladimir Ivanov wrote: > I hereby nominate Nils Eliasson (OpenJDK user name: neliasso to JDK > 9 Reviewer. > > Nils is a member of the Hotspot JVM Compiler group. He contributed 52 > changesets to jdk9 project [1] and he is qualified to be a Reviewer. > > Nils is the author of Compiler Control implementation [2] in HotSpot JVM. > > Votes are due by February, 25 2016. > > Only current JDK 9 Reviewers [3] 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 [4]. > > Best regards, > Vladimir Ivanov > > [1] > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/log?revcount=100&rev=author%28neliasso%29 > > [2] http://openjdk.java.net/jeps/165 > [3] http://openjdk.java.net/census#jdk9 > [4] http://openjdk.java.net/projects#committer-vote From vladimir.x.ivanov at oracle.com Thu Feb 11 16:30:46 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Thu, 11 Feb 2016 19:30:46 +0300 Subject: CFV: New jdk9 Reviewer: Claes Redestad Message-ID: <56BCB736.80804@oracle.com> I hereby nominate Claes Redestad (OpenJDK user name: redestad) to JDK 9 Reviewer. Claes is a member of the Java SE Performance team. He contributed 50 changesets to jdk9 project [1] [2] and he is qualified to be a Reviewer. Among other things, Claes did numerous performance improvements in java.lang.invoke implementation and Project Jigsaw [3]. Votes are due by February, 25 2016. Only current JDK 9 Reviewers [4] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [5]. Best regards, Vladimir Ivanov [1] http://hg.openjdk.java.net/jdk9/dev/jdk/search/?rev=author%28redestad%29&revcount=100 [2] http://hg.openjdk.java.net/jdk9/dev/hotspot/search/?rev=author%28redestad%29&revcount=100 [3] http://hg.openjdk.java.net/jigsaw/jake/jdk/log?rev=author%28redestad%29 [4] http://openjdk.java.net/census#jdk9 [5] http://openjdk.java.net/projects#committer-vote From vladimir.x.ivanov at oracle.com Thu Feb 11 16:31:14 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Thu, 11 Feb 2016 19:31:14 +0300 Subject: CFV: New jdk9 Reviewer: Claes Redestad In-Reply-To: <56BCB736.80804@oracle.com> References: <56BCB736.80804@oracle.com> Message-ID: <56BCB752.8020104@oracle.com> Vote: yes Best regards, Vladimir Ivanov On 2/11/16 7:30 PM, Vladimir Ivanov wrote: > I hereby nominate Claes Redestad (OpenJDK user name: redestad) to JDK > 9 Reviewer. From volker.simonis at gmail.com Thu Feb 11 16:50:39 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 11 Feb 2016 17:50:39 +0100 Subject: CFV: New jdk9 Reviewer: Nils Eliasson In-Reply-To: <56BCA5D1.7020202@oracle.com> References: <56BCA5D1.7020202@oracle.com> Message-ID: Vote: yes On Thu, Feb 11, 2016 at 4:16 PM, Vladimir Ivanov wrote: > I hereby nominate Nils Eliasson (OpenJDK user name: neliasso to JDK > 9 Reviewer. > > Nils is a member of the Hotspot JVM Compiler group. He contributed 52 > changesets to jdk9 project [1] and he is qualified to be a Reviewer. > > Nils is the author of Compiler Control implementation [2] in HotSpot JVM. > > Votes are due by February, 25 2016. > > Only current JDK 9 Reviewers [3] 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 [4]. > > Best regards, > Vladimir Ivanov > > [1] > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/log?revcount=100&rev=author%28neliasso%29 > [2] http://openjdk.java.net/jeps/165 > [3] http://openjdk.java.net/census#jdk9 > [4] http://openjdk.java.net/projects#committer-vote From volker.simonis at gmail.com Thu Feb 11 16:50:58 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 11 Feb 2016 17:50:58 +0100 Subject: CFV: New jdk9 Reviewer: Zoltan Majo In-Reply-To: <56BCA22A.7030300@oracle.com> References: <56BCA22A.7030300@oracle.com> Message-ID: Vote: yes On Thu, Feb 11, 2016 at 4:00 PM, Vladimir Ivanov wrote: > I hereby nominate Zoltan Majo (OpenJDK user name: zmajo) to JDK > 9 Reviewer. > > Zoltan is a member of the Hotspot JVM Compiler group. He contributed 51 > changesets to jdk9 project [1] and he is qualified to be a Reviewer. > > Votes are due by February, 25 2016. > > Only current JDK 9 Reviewers [2] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Best regards, > Vladimir Ivanov > > [1] > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/log?revcount=100&rev=author%28zmajo%29 > [2] http://openjdk.java.net/census#jdk9 > [3] http://openjdk.java.net/projects#committer-vote > From mikael.gerdin at oracle.com Thu Feb 11 17:30:42 2016 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Thu, 11 Feb 2016 18:30:42 +0100 Subject: CFV: New jdk9 Reviewer: Claes Redestad In-Reply-To: <56BCB736.80804@oracle.com> References: <56BCB736.80804@oracle.com> Message-ID: <56BCC542.3030206@oracle.com> Vote: yes /Mikael On 2016-02-11 17:30, Vladimir Ivanov wrote: > I hereby nominate Claes Redestad (OpenJDK user name: redestad) to JDK > 9 Reviewer. > > Claes is a member of the Java SE Performance team. He contributed 50 > changesets to jdk9 project [1] [2] and he is qualified to be a Reviewer. > > Among other things, Claes did numerous performance improvements in > java.lang.invoke implementation and Project Jigsaw [3]. > > Votes are due by February, 25 2016. > > Only current JDK 9 Reviewers [4] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Lazy Consensus voting instructions, see [5]. > > Best regards, > Vladimir Ivanov > > [1] > http://hg.openjdk.java.net/jdk9/dev/jdk/search/?rev=author%28redestad%29&revcount=100 > > [2] > http://hg.openjdk.java.net/jdk9/dev/hotspot/search/?rev=author%28redestad%29&revcount=100 > > [3] http://hg.openjdk.java.net/jigsaw/jake/jdk/log?rev=author%28redestad%29 > [4] http://openjdk.java.net/census#jdk9 > [5] http://openjdk.java.net/projects#committer-vote From chris.hegarty at oracle.com Thu Feb 11 17:34:49 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 11 Feb 2016 17:34:49 +0000 Subject: CFV: New jdk9 Reviewer: Claes Redestad In-Reply-To: <56BCB736.80804@oracle.com> References: <56BCB736.80804@oracle.com> Message-ID: Vote: YES -Chris. On 11 Feb 2016, at 16:30, Vladimir Ivanov wrote: > I hereby nominate Claes Redestad (OpenJDK user name: redestad) to JDK > 9 Reviewer. > > Claes is a member of the Java SE Performance team. He contributed 50 changesets to jdk9 project [1] [2] and he is qualified to be a Reviewer. > > Among other things, Claes did numerous performance improvements in java.lang.invoke implementation and Project Jigsaw [3]. > > Votes are due by February, 25 2016. > > Only current JDK 9 Reviewers [4] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [5]. > > Best regards, > Vladimir Ivanov > > [1] http://hg.openjdk.java.net/jdk9/dev/jdk/search/?rev=author%28redestad%29&revcount=100 > [2] http://hg.openjdk.java.net/jdk9/dev/hotspot/search/?rev=author%28redestad%29&revcount=100 > [3] http://hg.openjdk.java.net/jigsaw/jake/jdk/log?rev=author%28redestad%29 > [4] http://openjdk.java.net/census#jdk9 > [5] http://openjdk.java.net/projects#committer-vote From daniel.daugherty at oracle.com Thu Feb 11 17:44:08 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 11 Feb 2016 10:44:08 -0700 Subject: CFV: New jdk9 Reviewer: Claes Redestad In-Reply-To: <56BCB736.80804@oracle.com> References: <56BCB736.80804@oracle.com> Message-ID: <56BCC868.9000406@oracle.com> Vote: yes Dan On 2/11/16 9:30 AM, Vladimir Ivanov wrote: > I hereby nominate Claes Redestad (OpenJDK user name: redestad) to JDK > 9 Reviewer. > > Claes is a member of the Java SE Performance team. He contributed 50 > changesets to jdk9 project [1] [2] and he is qualified to be a Reviewer. > > Among other things, Claes did numerous performance improvements in > java.lang.invoke implementation and Project Jigsaw [3]. > > Votes are due by February, 25 2016. > > Only current JDK 9 Reviewers [4] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Lazy Consensus voting instructions, see [5]. > > Best regards, > Vladimir Ivanov > > [1] > http://hg.openjdk.java.net/jdk9/dev/jdk/search/?rev=author%28redestad%29&revcount=100 > [2] > http://hg.openjdk.java.net/jdk9/dev/hotspot/search/?rev=author%28redestad%29&revcount=100 > [3] > http://hg.openjdk.java.net/jigsaw/jake/jdk/log?rev=author%28redestad%29 > [4] http://openjdk.java.net/census#jdk9 > [5] http://openjdk.java.net/projects#committer-vote > From jesper.wilhelmsson at oracle.com Thu Feb 11 17:43:34 2016 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Thu, 11 Feb 2016 18:43:34 +0100 Subject: CFV: New jdk9 Reviewer: Claes Redestad In-Reply-To: <56BCB736.80804@oracle.com> References: <56BCB736.80804@oracle.com> Message-ID: <56BCC846.1040305@oracle.com> Vote: Yes /Jesper Den 11/2/16 kl. 17:30, skrev Vladimir Ivanov: > I hereby nominate Claes Redestad (OpenJDK user name: redestad) to JDK > 9 Reviewer. > > Claes is a member of the Java SE Performance team. He contributed 50 changesets > to jdk9 project [1] [2] and he is qualified to be a Reviewer. > > Among other things, Claes did numerous performance improvements in > java.lang.invoke implementation and Project Jigsaw [3]. > > Votes are due by February, 25 2016. > > Only current JDK 9 Reviewers [4] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [5]. > > Best regards, > Vladimir Ivanov > > [1] > http://hg.openjdk.java.net/jdk9/dev/jdk/search/?rev=author%28redestad%29&revcount=100 > > [2] > http://hg.openjdk.java.net/jdk9/dev/hotspot/search/?rev=author%28redestad%29&revcount=100 > > [3] http://hg.openjdk.java.net/jigsaw/jake/jdk/log?rev=author%28redestad%29 > [4] http://openjdk.java.net/census#jdk9 > [5] http://openjdk.java.net/projects#committer-vote From vladimir.kozlov at oracle.com Thu Feb 11 17:50:15 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 11 Feb 2016 09:50:15 -0800 Subject: CFV: New jdk9 Reviewer: Claes Redestad In-Reply-To: <56BCB736.80804@oracle.com> References: <56BCB736.80804@oracle.com> Message-ID: <56BCC9D7.4020307@oracle.com> Vote: yes On 2/11/16 8:30 AM, Vladimir Ivanov wrote: > I hereby nominate Claes Redestad (OpenJDK user name: redestad) to JDK > 9 Reviewer. > > Claes is a member of the Java SE Performance team. He contributed 50 changesets to jdk9 project [1] [2] and he is > qualified to be a Reviewer. > > Among other things, Claes did numerous performance improvements in java.lang.invoke implementation and Project Jigsaw [3]. > > Votes are due by February, 25 2016. > > Only current JDK 9 Reviewers [4] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [5]. > > Best regards, > Vladimir Ivanov > > [1] http://hg.openjdk.java.net/jdk9/dev/jdk/search/?rev=author%28redestad%29&revcount=100 > [2] http://hg.openjdk.java.net/jdk9/dev/hotspot/search/?rev=author%28redestad%29&revcount=100 > [3] http://hg.openjdk.java.net/jigsaw/jake/jdk/log?rev=author%28redestad%29 > [4] http://openjdk.java.net/census#jdk9 > [5] http://openjdk.java.net/projects#committer-vote From vladimir.kozlov at oracle.com Thu Feb 11 17:50:49 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 11 Feb 2016 09:50:49 -0800 Subject: CFV: New jdk9 Reviewer: Nils Eliasson In-Reply-To: <56BCA5D1.7020202@oracle.com> References: <56BCA5D1.7020202@oracle.com> Message-ID: <56BCC9F9.7020407@oracle.com> Vote: yes On 2/11/16 7:16 AM, Vladimir Ivanov wrote: > I hereby nominate Nils Eliasson (OpenJDK user name: neliasso to JDK > 9 Reviewer. > > Nils is a member of the Hotspot JVM Compiler group. He contributed 52 changesets to jdk9 project [1] and he is qualified > to be a Reviewer. > > Nils is the author of Compiler Control implementation [2] in HotSpot JVM. > > Votes are due by February, 25 2016. > > Only current JDK 9 Reviewers [3] 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 [4]. > > Best regards, > Vladimir Ivanov > > [1] http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/log?revcount=100&rev=author%28neliasso%29 > [2] http://openjdk.java.net/jeps/165 > [3] http://openjdk.java.net/census#jdk9 > [4] http://openjdk.java.net/projects#committer-vote From vladimir.kozlov at oracle.com Thu Feb 11 17:51:23 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 11 Feb 2016 09:51:23 -0800 Subject: CFV: New jdk9 Reviewer: Tobias Hartmann In-Reply-To: <56BC9559.8060906@oracle.com> References: <56BC9559.8060906@oracle.com> Message-ID: <56BCCA1B.8080309@oracle.com> Vote: yes On 2/11/16 6:06 AM, Vladimir Ivanov wrote: > I hereby nominate Tobias Hartmann (OpenJDK user name: thartmann) to JDK > 9 Reviewer. > > Tobias is a member of the Hotspot JVM Compiler group. He contributed 68 changesets to jdk9 project [1] and he is > qualified to be a Reviewer. > > While working on Hotspot JVM, Tobias implemented Segmented Code Cache [2] and compiler support for Compact Strings [3]. > > Votes are due by February, 25 2016. > > Only current JDK 9 Reviewers [4] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [5]. > > Best regards, > Vladimir Ivanov > > [1] http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/search/?rev=thartmann&revcount=100 > [2] https://bugs.openjdk.java.net/browse/JDK-8015774 > [3] http://openjdk.java.net/jeps/254 > [4] http://openjdk.java.net/census#jdk9 > [5] http://openjdk.java.net/projects#committer-vote From vladimir.kozlov at oracle.com Thu Feb 11 17:52:20 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 11 Feb 2016 09:52:20 -0800 Subject: CFV: New jdk9 Reviewer: Zoltan Majo In-Reply-To: <56BCA22A.7030300@oracle.com> References: <56BCA22A.7030300@oracle.com> Message-ID: <56BCCA54.8090702@oracle.com> Vote: yes On 2/11/16 7:00 AM, Vladimir Ivanov wrote: > I hereby nominate Zoltan Majo (OpenJDK user name: zmajo) to JDK > 9 Reviewer. > > Zoltan is a member of the Hotspot JVM Compiler group. He contributed 51 changesets to jdk9 project [1] and he is > qualified to be a Reviewer. > > Votes are due by February, 25 2016. > > Only current JDK 9 Reviewers [2] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Best regards, > Vladimir Ivanov > > [1] http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/log?revcount=100&rev=author%28zmajo%29 > [2] http://openjdk.java.net/census#jdk9 > [3] http://openjdk.java.net/projects#committer-vote > From huizhe.wang at oracle.com Thu Feb 11 17:52:35 2016 From: huizhe.wang at oracle.com (huizhe wang) Date: Thu, 11 Feb 2016 09:52:35 -0800 Subject: CFV: New jdk9 Reviewer: Tobias Hartmann In-Reply-To: <56BC9559.8060906@oracle.com> References: <56BC9559.8060906@oracle.com> Message-ID: <56BCCA63.2020107@oracle.com> vote: yes Joe (OpenJDK user name: joehw) On 2/11/2016 6:06 AM, Vladimir Ivanov wrote: > I hereby nominate Tobias Hartmann (OpenJDK user name: thartmann) to JDK > 9 Reviewer. From huizhe.wang at oracle.com Thu Feb 11 17:56:12 2016 From: huizhe.wang at oracle.com (huizhe wang) Date: Thu, 11 Feb 2016 09:56:12 -0800 Subject: CFV: New jdk9 Reviewer: Nils Eliasson In-Reply-To: <56BCA5D1.7020202@oracle.com> References: <56BCA5D1.7020202@oracle.com> Message-ID: <56BCCB3C.6010601@oracle.com> vote: yes Joe (OpenJDK user name: joehw) On 2/11/2016 7:16 AM, Vladimir Ivanov wrote: > I hereby nominate Nils Eliasson (OpenJDK user name: neliasso to JDK > 9 Reviewer. > > Nils is a member of the Hotspot JVM Compiler group. He contributed 52 > changesets to jdk9 project [1] and he is qualified to be a Reviewer. > > Nils is the author of Compiler Control implementation [2] in HotSpot JVM. > > Votes are due by February, 25 2016. > > Only current JDK 9 Reviewers [3] 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 [4]. > > Best regards, > Vladimir Ivanov > > [1] > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/log?revcount=100&rev=author%28neliasso%29 > [2] http://openjdk.java.net/jeps/165 > [3] http://openjdk.java.net/census#jdk9 > [4] http://openjdk.java.net/projects#committer-vote From stefan.karlsson at oracle.com Thu Feb 11 18:41:54 2016 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Thu, 11 Feb 2016 19:41:54 +0100 Subject: CFV: New jdk9 Reviewer: Claes Redestad In-Reply-To: <56BCB736.80804@oracle.com> References: <56BCB736.80804@oracle.com> Message-ID: <56BCD5F2.3070608@oracle.com> Vote: yes StefanK On 2016-02-11 17:30, Vladimir Ivanov wrote: > I hereby nominate Claes Redestad (OpenJDK user name: redestad) to JDK > 9 Reviewer. > > Claes is a member of the Java SE Performance team. He contributed 50 > changesets to jdk9 project [1] [2] and he is qualified to be a Reviewer. > > Among other things, Claes did numerous performance improvements in > java.lang.invoke implementation and Project Jigsaw [3]. > > Votes are due by February, 25 2016. > > Only current JDK 9 Reviewers [4] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Lazy Consensus voting instructions, see [5]. > > Best regards, > Vladimir Ivanov > > [1] > http://hg.openjdk.java.net/jdk9/dev/jdk/search/?rev=author%28redestad%29&revcount=100 > [2] > http://hg.openjdk.java.net/jdk9/dev/hotspot/search/?rev=author%28redestad%29&revcount=100 > [3] > http://hg.openjdk.java.net/jigsaw/jake/jdk/log?rev=author%28redestad%29 > [4] http://openjdk.java.net/census#jdk9 > [5] http://openjdk.java.net/projects#committer-vote From stefan.karlsson at oracle.com Thu Feb 11 18:42:09 2016 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Thu, 11 Feb 2016 19:42:09 +0100 Subject: CFV: New jdk9 Reviewer: Zoltan Majo In-Reply-To: <56BCA22A.7030300@oracle.com> References: <56BCA22A.7030300@oracle.com> Message-ID: <56BCD601.3090407@oracle.com> Vote: yes StefanK On 2016-02-11 16:00, Vladimir Ivanov wrote: > I hereby nominate Zoltan Majo (OpenJDK user name: zmajo) to JDK > 9 Reviewer. > > Zoltan is a member of the Hotspot JVM Compiler group. He contributed > 51 changesets to jdk9 project [1] and he is qualified to be a Reviewer. > > Votes are due by February, 25 2016. > > Only current JDK 9 Reviewers [2] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Lazy Consensus voting instructions, see [3]. > > Best regards, > Vladimir Ivanov > > [1] > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/log?revcount=100&rev=author%28zmajo%29 > [2] http://openjdk.java.net/census#jdk9 > [3] http://openjdk.java.net/projects#committer-vote > From stefan.karlsson at oracle.com Thu Feb 11 18:42:28 2016 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Thu, 11 Feb 2016 19:42:28 +0100 Subject: CFV: New jdk9 Reviewer: Tobias Hartmann In-Reply-To: <56BC9559.8060906@oracle.com> References: <56BC9559.8060906@oracle.com> Message-ID: <56BCD614.2000701@oracle.com> Vote: yes StefanK On 2016-02-11 15:06, Vladimir Ivanov wrote: > I hereby nominate Tobias Hartmann (OpenJDK user name: thartmann) to JDK > 9 Reviewer. > > Tobias is a member of the Hotspot JVM Compiler group. He contributed > 68 changesets to jdk9 project [1] and he is qualified to be a Reviewer. > > While working on Hotspot JVM, Tobias implemented Segmented Code Cache > [2] and compiler support for Compact Strings [3]. > > Votes are due by February, 25 2016. > > Only current JDK 9 Reviewers [4] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Lazy Consensus voting instructions, see [5]. > > Best regards, > Vladimir Ivanov > > [1] > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/search/?rev=thartmann&revcount=100 > [2] https://bugs.openjdk.java.net/browse/JDK-8015774 > [3] http://openjdk.java.net/jeps/254 > [4] http://openjdk.java.net/census#jdk9 > [5] http://openjdk.java.net/projects#committer-vote From stefan.karlsson at oracle.com Thu Feb 11 18:42:45 2016 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Thu, 11 Feb 2016 19:42:45 +0100 Subject: CFV: New jdk9 Reviewer: Nils Eliasson In-Reply-To: <56BCA5D1.7020202@oracle.com> References: <56BCA5D1.7020202@oracle.com> Message-ID: <56BCD625.6000602@oracle.com> Vote: yes StefanK On 2016-02-11 16:16, Vladimir Ivanov wrote: > I hereby nominate Nils Eliasson (OpenJDK user name: neliasso to JDK > 9 Reviewer. > > Nils is a member of the Hotspot JVM Compiler group. He contributed 52 > changesets to jdk9 project [1] and he is qualified to be a Reviewer. > > Nils is the author of Compiler Control implementation [2] in HotSpot JVM. > > Votes are due by February, 25 2016. > > Only current JDK 9 Reviewers [3] 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 [4]. > > Best regards, > Vladimir Ivanov > > [1] > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/log?revcount=100&rev=author%28neliasso%29 > [2] http://openjdk.java.net/jeps/165 > [3] http://openjdk.java.net/census#jdk9 > [4] http://openjdk.java.net/projects#committer-vote From stefan.karlsson at oracle.com Thu Feb 11 18:43:46 2016 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Thu, 11 Feb 2016 19:43:46 +0100 Subject: CFV: New JDK 9 Committer: Dmitry Fazunenko In-Reply-To: <56B36771.9000005@oracle.com> References: <56B36771.9000005@oracle.com> Message-ID: <56BCD662.1050004@oracle.com> Vote: yes StefanK On 2016-02-04 16:00, Jesper Wilhelmsson wrote: > I hereby nominate Dmitry Fazunenko (dfazunen) for JDK 9 Committer. > > Dmitry is a member of the VM SQE team at Oracle and has contributed 13 > changesets [3] to JDK 9. > > Votes are due by 18:00 MSK / 16:00 CET / 10.00 am EST / 7.00 am PT, > Thursday February 18, 2016 > > Only current JDK 9 Committers [1] are eligible to vote on this > nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > /Jesper > > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] List of patches: > > 8132961: JEP 279: Improve Test-Failure Troubleshooting > http://hg.openjdk.java.net/jdk9/hs-rt/rev/4aa2e64eff30 > > 8147003: Move BubbleUpRef test into CMS directory > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/28dcfa2f0275 > > 8134963: [Newtest] New stress test for changing the coarseness level > of G1 remembered set > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/af014cb82e42 > > 8147075: Rename old GC JTreg tests to the new naming scheme > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/c15c0bd51e1d > > 8146889: Update @requires expression for GC tests to run if GC is default > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/66aa15bcceff > > 8016752: [Newtest] regression test for PrintGCDetails and Verbose > flags do not crash when ParOldGC has no memory > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/96cc87bb08f8 > > 8132709: [TESTBUG] gc/g1/TestHumongousShrinkHeap.java might fail on > embedded > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/d750cc39ed60 > > 8073476: G1 logging ignores changes to PrintGC* flags via MXBeans > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/ce8df07dd074 > > 8050464: G1 string deduplication tests hang/timeout and leave running > processes consuming all resources > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/b515190809d5 > > 8055284: sanity/WhiteBox.java fails with NPE > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/1662147c9ca3 > > 8044673: Create jtreg groups to list GC specific tests > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/1abbc1e91ac5 > > 8040250: The test test/gc/parallelScavenge/TestDynShrinkHeap.java > fails with OOME > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/abd312cd8cc2 > > 8039489: Refactor test framework for dynamic VM options > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/8ec72dcefd74 From sean.mullan at oracle.com Thu Feb 11 18:50:34 2016 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 11 Feb 2016 13:50:34 -0500 Subject: CFV: New JDK 9 Reviewer: Anthony Scarpino In-Reply-To: <56BB34E7.6040207@oracle.com> References: <56BB34E7.6040207@oracle.com> Message-ID: <56BCD7FA.6000205@oracle.com> Vote: yes --Sean On 02/10/2016 08:02 AM, Sean Mullan wrote: > I hereby nominate Anthony Scarpino to JDK 9 Reviewer. > > Anthony Scarpino is a member of the security libraries team at Oracle. > He has contributed 39 changesets to the JDK 9 Project [3]. He is also > the Author and Owner of JEP 246 (Leverage CPU Instructions for GHASH and > RSA) [4] which has significantly improved cryptographic performance and > has been successfully integrated to JDK 9. > > Votes are due by 24 February 2016, 2:00 PM UTC. > > 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]. > > Sean Mullan > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > [3] > http://hg.openjdk.java.net/jdk9/dev/jdk/log?revcount=1000&rev=author%28%22ascarpin%22%29 > > [4] http://openjdk.java.net/jeps/246 From chris.hegarty at oracle.com Thu Feb 11 18:52:30 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 11 Feb 2016 18:52:30 +0000 Subject: CFV: New JDK 9 Reviewer: Anthony Scarpino In-Reply-To: <56BB76E8.5000605@oracle.com> References: <56BB34E7.6040207@oracle.com> <56BB76E8.5000605@oracle.com> Message-ID: Vote: YES -Chris. On 10 Feb 2016, at 17:44, Vladimir Kozlov wrote: > Vote: yes > > On 2/10/16 5:02 AM, Sean Mullan wrote: >> I hereby nominate Anthony Scarpino to JDK 9 Reviewer. >> >> Anthony Scarpino is a member of the security libraries team at Oracle. He has contributed 39 changesets to the JDK 9 >> Project [3]. He is also the Author and Owner of JEP 246 (Leverage CPU Instructions for GHASH and RSA) [4] which has >> significantly improved cryptographic performance and has been successfully integrated to JDK 9. >> >> Votes are due by 24 February 2016, 2:00 PM UTC. >> >> 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]. >> >> Sean Mullan >> >> [1] http://openjdk.java.net/census >> [2] http://openjdk.java.net/projects/#reviewer-vote >> [3] http://hg.openjdk.java.net/jdk9/dev/jdk/log?revcount=1000&rev=author%28%22ascarpin%22%29 >> [4] http://openjdk.java.net/jeps/246 From jon.masamitsu at oracle.com Thu Feb 11 19:02:31 2016 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Thu, 11 Feb 2016 11:02:31 -0800 Subject: CFV: New jdk9 Reviewer: Claes Redestad In-Reply-To: <56BCB736.80804@oracle.com> References: <56BCB736.80804@oracle.com> Message-ID: <56BCDAC7.2030302@oracle.com> Vote: yes On 2/11/2016 8:30 AM, Vladimir Ivanov wrote: > I hereby nominate Claes Redestad (OpenJDK user name: redestad) to JDK > 9 Reviewer. > > Claes is a member of the Java SE Performance team. He contributed 50 > changesets to jdk9 project [1] [2] and he is qualified to be a Reviewer. > > Among other things, Claes did numerous performance improvements in > java.lang.invoke implementation and Project Jigsaw [3]. > > Votes are due by February, 25 2016. > > Only current JDK 9 Reviewers [4] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Lazy Consensus voting instructions, see [5]. > > Best regards, > Vladimir Ivanov > > [1] > http://hg.openjdk.java.net/jdk9/dev/jdk/search/?rev=author%28redestad%29&revcount=100 > [2] > http://hg.openjdk.java.net/jdk9/dev/hotspot/search/?rev=author%28redestad%29&revcount=100 > [3] > http://hg.openjdk.java.net/jigsaw/jake/jdk/log?rev=author%28redestad%29 > [4] http://openjdk.java.net/census#jdk9 > [5] http://openjdk.java.net/projects#committer-vote From harold.seigel at oracle.com Thu Feb 11 19:26:52 2016 From: harold.seigel at oracle.com (harold seigel) Date: Thu, 11 Feb 2016 14:26:52 -0500 Subject: CFV: New jdk9 Reviewer: Claes Redestad In-Reply-To: <56BCB736.80804@oracle.com> References: <56BCB736.80804@oracle.com> Message-ID: <56BCE07C.2040704@oracle.com> Vote: yes Harold On 2/11/2016 11:30 AM, Vladimir Ivanov wrote: > I hereby nominate Claes Redestad (OpenJDK user name: redestad) to JDK > 9 Reviewer. > > Claes is a member of the Java SE Performance team. He contributed 50 > changesets to jdk9 project [1] [2] and he is qualified to be a Reviewer. > > Among other things, Claes did numerous performance improvements in > java.lang.invoke implementation and Project Jigsaw [3]. > > Votes are due by February, 25 2016. > > Only current JDK 9 Reviewers [4] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Lazy Consensus voting instructions, see [5]. > > Best regards, > Vladimir Ivanov > > [1] > http://hg.openjdk.java.net/jdk9/dev/jdk/search/?rev=author%28redestad%29&revcount=100 > [2] > http://hg.openjdk.java.net/jdk9/dev/hotspot/search/?rev=author%28redestad%29&revcount=100 > [3] > http://hg.openjdk.java.net/jigsaw/jake/jdk/log?rev=author%28redestad%29 > [4] http://openjdk.java.net/census#jdk9 > [5] http://openjdk.java.net/projects#committer-vote From openjdk at duigou.org Thu Feb 11 19:31:44 2016 From: openjdk at duigou.org (Mike Duigou) Date: Thu, 11 Feb 2016 11:31:44 -0800 Subject: CFV: New jdk9 Reviewer: Claes Redestad In-Reply-To: References: Message-ID: <9745c2e7620607cf4ee094407fe8516e@sonic.net> Vote : YES > I hereby nominate Claes Redestad (OpenJDK user name: redestad) to JDK > 9 Reviewer. > > Claes is a member of the Java SE Performance team. He contributed 50 > changesets to jdk9 project [1] [2] and he is qualified to be a > Reviewer. > > Among other things, Claes did numerous performance improvements in > java.lang.invoke implementation and Project Jigsaw [3]. > > Votes are due by February, 25 2016. > > Only current JDK 9 Reviewers [4] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Lazy Consensus voting instructions, see [5]. > > Best regards, > Vladimir Ivanov > > [1] > http://hg.openjdk.java.net/jdk9/dev/jdk/search/?rev=author%28redestad%29&revcount=100 > [2] > http://hg.openjdk.java.net/jdk9/dev/hotspot/search/?rev=author%28redestad%29&revcount=100 > [3] > http://hg.openjdk.java.net/jigsaw/jake/jdk/log?rev=author%28redestad%29 > [4] http://openjdk.java.net/census#jdk9 > [5] http://openjdk.java.net/projects#committer-vote From bengt.rutisson at oracle.com Thu Feb 11 19:48:30 2016 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Thu, 11 Feb 2016 20:48:30 +0100 Subject: CFV: New jdk9 Reviewer: Claes Redestad In-Reply-To: <56BCB736.80804@oracle.com> References: <56BCB736.80804@oracle.com> Message-ID: <56BCE58E.3000605@oracle.com> Vote: yes Bengt On 2016-02-11 17:30, Vladimir Ivanov wrote: > I hereby nominate Claes Redestad (OpenJDK user name: redestad) to JDK > 9 Reviewer. > > Claes is a member of the Java SE Performance team. He contributed 50 > changesets to jdk9 project [1] [2] and he is qualified to be a Reviewer. > > Among other things, Claes did numerous performance improvements in > java.lang.invoke implementation and Project Jigsaw [3]. From igor.ignatyev at oracle.com Thu Feb 11 19:49:31 2016 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Thu, 11 Feb 2016 22:49:31 +0300 Subject: CFV: New jdk9 Reviewer: Claes Redestad In-Reply-To: <56BCB736.80804@oracle.com> References: <56BCB736.80804@oracle.com> Message-ID: <1DF61696-3C89-40EC-BD2F-F6549BC7B9A2@oracle.com> Vote: yes ? Igor From bengt.rutisson at oracle.com Thu Feb 11 19:50:51 2016 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Thu, 11 Feb 2016 20:50:51 +0100 Subject: CFV: New jdk9 Reviewer: Nils Eliasson In-Reply-To: <56BCA5D1.7020202@oracle.com> References: <56BCA5D1.7020202@oracle.com> Message-ID: <56BCE61B.8080308@oracle.com> Vote: yes Bengt On 2016-02-11 16:16, Vladimir Ivanov wrote: > I hereby nominate Nils Eliasson (OpenJDK user name: neliasso to JDK > 9 Reviewer. > > Nils is a member of the Hotspot JVM Compiler group. He contributed 52 > changesets to jdk9 project [1] and he is qualified to be a Reviewer. > > Nils is the author of Compiler Control implementation [2] in HotSpot JVM. > > Votes are due by February, 25 2016. > > Only current JDK 9 Reviewers [3] 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 [4]. > > Best regards, > Vladimir Ivanov > > [1] > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/log?revcount=100&rev=author%28neliasso%29 > [2] http://openjdk.java.net/jeps/165 > [3] http://openjdk.java.net/census#jdk9 > [4] http://openjdk.java.net/projects#committer-vote From bengt.rutisson at oracle.com Thu Feb 11 19:51:47 2016 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Thu, 11 Feb 2016 20:51:47 +0100 Subject: CFV: New jdk9 Reviewer: Zoltan Majo In-Reply-To: <56BCA22A.7030300@oracle.com> References: <56BCA22A.7030300@oracle.com> Message-ID: <56BCE653.5080906@oracle.com> Vote: yes Bengt On 2016-02-11 16:00, Vladimir Ivanov wrote: > I hereby nominate Zoltan Majo (OpenJDK user name: zmajo) to JDK > 9 Reviewer. > > Zoltan is a member of the Hotspot JVM Compiler group. He contributed > 51 changesets to jdk9 project [1] and he is qualified to be a Reviewer. > > Votes are due by February, 25 2016. > > Only current JDK 9 Reviewers [2] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Lazy Consensus voting instructions, see [3]. > > Best regards, > Vladimir Ivanov > > [1] > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/log?revcount=100&rev=author%28zmajo%29 > [2] http://openjdk.java.net/census#jdk9 > [3] http://openjdk.java.net/projects#committer-vote > From bengt.rutisson at oracle.com Thu Feb 11 19:51:24 2016 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Thu, 11 Feb 2016 20:51:24 +0100 Subject: CFV: New jdk9 Reviewer: Tobias Hartmann In-Reply-To: <56BC9559.8060906@oracle.com> References: <56BC9559.8060906@oracle.com> Message-ID: <56BCE63C.8050107@oracle.com> Vote: yes Bengt On 2016-02-11 15:06, Vladimir Ivanov wrote: > I hereby nominate Tobias Hartmann (OpenJDK user name: thartmann) to JDK > 9 Reviewer. > > Tobias is a member of the Hotspot JVM Compiler group. He contributed > 68 changesets to jdk9 project [1] and he is qualified to be a Reviewer. > > While working on Hotspot JVM, Tobias implemented Segmented Code Cache > [2] and compiler support for Compact Strings [3]. > > Votes are due by February, 25 2016. > > Only current JDK 9 Reviewers [4] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Lazy Consensus voting instructions, see [5]. > > Best regards, > Vladimir Ivanov > > [1] > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/search/?rev=thartmann&revcount=100 > [2] https://bugs.openjdk.java.net/browse/JDK-8015774 > [3] http://openjdk.java.net/jeps/254 > [4] http://openjdk.java.net/census#jdk9 > [5] http://openjdk.java.net/projects#committer-vote From christian.thalinger at oracle.com Thu Feb 11 19:53:49 2016 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 11 Feb 2016 09:53:49 -1000 Subject: CFV: New jdk9 Reviewer: Zoltan Majo In-Reply-To: <56BCA22A.7030300@oracle.com> References: <56BCA22A.7030300@oracle.com> Message-ID: Vote: yes > On Feb 11, 2016, at 5:00 AM, Vladimir Ivanov wrote: > > I hereby nominate Zoltan Majo (OpenJDK user name: zmajo) to JDK > 9 Reviewer. > > Zoltan is a member of the Hotspot JVM Compiler group. He contributed 51 changesets to jdk9 project [1] and he is qualified to be a Reviewer. > > Votes are due by February, 25 2016. > > Only current JDK 9 Reviewers [2] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Best regards, > Vladimir Ivanov > > [1] http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/log?revcount=100&rev=author%28zmajo%29 > [2] http://openjdk.java.net/census#jdk9 > [3] http://openjdk.java.net/projects#committer-vote > From christian.thalinger at oracle.com Thu Feb 11 19:54:58 2016 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 11 Feb 2016 09:54:58 -1000 Subject: CFV: New jdk9 Reviewer: Tobias Hartmann In-Reply-To: <56BC9559.8060906@oracle.com> References: <56BC9559.8060906@oracle.com> Message-ID: Vote: yes > On Feb 11, 2016, at 4:06 AM, Vladimir Ivanov wrote: > > I hereby nominate Tobias Hartmann (OpenJDK user name: thartmann) to JDK > 9 Reviewer. > > Tobias is a member of the Hotspot JVM Compiler group. He contributed 68 changesets to jdk9 project [1] and he is qualified to be a Reviewer. > > While working on Hotspot JVM, Tobias implemented Segmented Code Cache [2] and compiler support for Compact Strings [3]. > > Votes are due by February, 25 2016. > > Only current JDK 9 Reviewers [4] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [5]. > > Best regards, > Vladimir Ivanov > > [1] http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/search/?rev=thartmann&revcount=100 > [2] https://bugs.openjdk.java.net/browse/JDK-8015774 > [3] http://openjdk.java.net/jeps/254 > [4] http://openjdk.java.net/census#jdk9 > [5] http://openjdk.java.net/projects#committer-vote From goetz.lindenmaier at sap.com Thu Feb 11 20:29:34 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 11 Feb 2016 20:29:34 +0000 Subject: New jdk9 Reviewer: Tobias Hartmann In-Reply-To: <56BC9559.8060906@oracle.com> References: <56BC9559.8060906@oracle.com> Message-ID: <63c7e8d53db444e7a79eaea01e0de5a1@DEWDFE13DE09.global.corp.sap> Vote: yes Best regards Goetz > -----Original Message----- > From: jdk9-dev [mailto:jdk9-dev-bounces at openjdk.java.net] On Behalf Of > Vladimir Ivanov > Sent: Donnerstag, 11. Februar 2016 15:06 > To: jdk9-dev at openjdk.java.net > Subject: CFV: New jdk9 Reviewer: Tobias Hartmann > > I hereby nominate Tobias Hartmann (OpenJDK user name: thartmann) to JDK > 9 Reviewer. > > Tobias is a member of the Hotspot JVM Compiler group. He contributed 68 > changesets to jdk9 project [1] and he is qualified to be a Reviewer. > > While working on Hotspot JVM, Tobias implemented Segmented Code Cache > [2] and compiler support for Compact Strings [3]. > > Votes are due by February, 25 2016. > > Only current JDK 9 Reviewers [4] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [5]. > > Best regards, > Vladimir Ivanov > > [1] > http://hg.openjdk.java.net/jdk9/hs- > comp/hotspot/search/?rev=thartmann&revcount=100 > [2] https://bugs.openjdk.java.net/browse/JDK-8015774 > [3] http://openjdk.java.net/jeps/254 > [4] http://openjdk.java.net/census#jdk9 > [5] http://openjdk.java.net/projects#committer-vote From xueming.shen at oracle.com Thu Feb 11 20:31:30 2016 From: xueming.shen at oracle.com (Xueming Shen) Date: Thu, 11 Feb 2016 12:31:30 -0800 Subject: New jdk9 Reviewer: Tobias Hartmann In-Reply-To: <63c7e8d53db444e7a79eaea01e0de5a1@DEWDFE13DE09.global.corp.sap> References: <56BC9559.8060906@oracle.com> <63c7e8d53db444e7a79eaea01e0de5a1@DEWDFE13DE09.global.corp.sap> Message-ID: <56BCEFA2.2020701@oracle.com> Vote: yes >> -----Original Message----- >> From: jdk9-dev [mailto:jdk9-dev-bounces at openjdk.java.net] On Behalf Of >> Vladimir Ivanov >> Sent: Donnerstag, 11. Februar 2016 15:06 >> To: jdk9-dev at openjdk.java.net >> Subject: CFV: New jdk9 Reviewer: Tobias Hartmann >> >> I hereby nominate Tobias Hartmann (OpenJDK user name: thartmann) to JDK >> 9 Reviewer. >> >> Tobias is a member of the Hotspot JVM Compiler group. He contributed 68 >> changesets to jdk9 project [1] and he is qualified to be a Reviewer. >> >> While working on Hotspot JVM, Tobias implemented Segmented Code Cache >> [2] and compiler support for Compact Strings [3]. >> >> Votes are due by February, 25 2016. >> >> Only current JDK 9 Reviewers [4] are eligible to vote on this >> nomination. Votes must be cast in the open by replying to this mailing list. >> >> For Lazy Consensus voting instructions, see [5]. >> >> Best regards, >> Vladimir Ivanov >> >> [1] >> http://hg.openjdk.java.net/jdk9/hs- >> comp/hotspot/search/?rev=thartmann&revcount=100 >> [2] https://bugs.openjdk.java.net/browse/JDK-8015774 >> [3] http://openjdk.java.net/jeps/254 >> [4] http://openjdk.java.net/census#jdk9 >> [5] http://openjdk.java.net/projects#committer-vote From bradford.wetmore at oracle.com Thu Feb 11 23:29:58 2016 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Thu, 11 Feb 2016 15:29:58 -0800 Subject: CFV: New JDK 9 Reviewer: Anthony Scarpino In-Reply-To: <56BB34E7.6040207@oracle.com> References: <56BB34E7.6040207@oracle.com> Message-ID: <56BD1976.2070705@oracle.com> Yes yes yes... Brad On 2/10/2016 5:02 AM, Sean Mullan wrote: > I hereby nominate Anthony Scarpino to JDK 9 Reviewer. > > Anthony Scarpino is a member of the security libraries team at Oracle. > He has contributed 39 changesets to the JDK 9 Project [3]. He is also > the Author and Owner of JEP 246 (Leverage CPU Instructions for GHASH and > RSA) [4] which has significantly improved cryptographic performance and > has been successfully integrated to JDK 9. > > Votes are due by 24 February 2016, 2:00 PM UTC. > > 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]. > > Sean Mullan > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > [3] > http://hg.openjdk.java.net/jdk9/dev/jdk/log?revcount=1000&rev=author%28%22ascarpin%22%29 > > [4] http://openjdk.java.net/jeps/246 From vladimir.kozlov at oracle.com Fri Feb 12 00:18:22 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 11 Feb 2016 16:18:22 -0800 Subject: RFR JDK-8149644 Integrate VarHandles In-Reply-To: <9C47EF6F-80D6-467E-A5CB-2FDD5FF6AE17@oracle.com> References: <9C47EF6F-80D6-467E-A5CB-2FDD5FF6AE17@oracle.com> Message-ID: <56BD24CE.8020405@oracle.com> I looked on Hotspot changes and changes are fine. My only complain is missing {} in if() statements. It was source for bugs for us before so we require to always have {}: in rewriter.cpp, method.cpp, methodHandles.cpp. Thanks, Vladimir On 2/11/16 7:39 AM, Paul Sandoz wrote: > Hi, > > This is the implementation review request for VarHandles. > > Langtools: > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8149644-varhandles-integration/langtools/webrev/index.html > > Hotspot: > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8149644-varhandles-integration/hotspot/webrev/index.html > > JDK: > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8149644-varhandles-integration/jdk/webrev/index.html > > The spec/API review is proceeding here [1]. > > The patches depend on Unsafe changes [2] and ByteBuffer changes [3]. > > Recent (as of today) JPRT runs for core and hotspot tests pass without failure. Many parts of the code have been soaking in the Valhalla repo for over a year, and it?s been soaking in the sandbox for quite and many a JPRT run was performed. > > It is planned to push through hs-comp as is the case for the dependent patches, and thus minimise any delays due to integration between forests. > > > The Langtools changes are small. Tweaks were made to support updates to signature polymorphic methods and where may be located, in addition to supporting compilation of calls to MethodHandle.link*. > > > The Hotspot changes are not very large. It?s mostly a matter of augmenting checks for MethodHandle to include that for VarHandle. It?s tempting to generalise the ?invokehandle" invocation as i believe there are other use-cases where it might be useful, but i resisted temptation here. I wanted to focus on the minimal changes required. > > > The JDK changes are more substantial, but a large proportion are new tests. The source compilation approach taken is to use templates, the same approach as for code in the nio package, to generate both implementation and test source code. The implementations are generated by the build, the tests are pre-generated. I believe the tests should have good coverage but we have yet to run any code coverage tool. > > The approach to invocation of VarHandle signature polymoprhic methods is slightly different to that of MethodHandles. I wanted to ensure that linking for the common cases avoids lambda form creation, compilation and therefore class spinning. That reduces start up costs and also potential circular dependencies that might be induced in the VM boot process if VarHandles are employed early on. > > For common basic (i.e. erased ref and widened primitive) method signatures, namely all those that matter for the efficient atomic operations there are pre-generated methods that would otherwise be generated from creating and compiling invoker lambda forms. Those methods reside on the VarHandleGuards class. When the VM makes an up call to MethodHandleNatives.linkMethod to link a call site then this up-called method will first check if an appropriate pre-generated method exists on VarHandleGuards and if so it links to that, otherwise it falls back to a method on a class generated from compiling a lambda form. For testing purposes there is a system property available to switch off this optimisation when linking [*]. > > Each VarHandle instance of the same variable type produced from the same factory will share an underlying immutable instance of a VarForm that contains a set of MemberName instances, one for each implementation of a signature polymorphic method (a value of null means unsupported). The invoke methods (on VarHandleGuards or on lambda forms) will statically link to such MemberName instances using a call to MethodHandle.linkToStatic. > > There are a couple of TODOs in comments, those are all on non-critical code paths and i plan to chase them up afterwards. > > C1 does not support constant folding for @Stable arrays hence why in certain cases we have exploded stuff into fields that are operated on using if/else loops. We can simplify such code if/when C1 support is added. > > > Thanks, > Paul. > > [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-January/038150.html > [2] http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2016-January/020953.html > http://mail.openjdk.java.net/pipermail/hotspot-dev/2016-January/021514.html > [3] http://mail.openjdk.java.net/pipermail/nio-dev/2016-February/003535.html > > [*] This technique might be useful for common signatures of MH invokers to reduce associated costs of lambda form creation and compilation in the interim of something better. > From serguei.spitsyn at oracle.com Fri Feb 12 04:28:53 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 11 Feb 2016 20:28:53 -0800 Subject: CFV: New jdk9 Reviewer: Tobias Hartmann In-Reply-To: <56BC9559.8060906@oracle.com> References: <56BC9559.8060906@oracle.com> Message-ID: <56BD5F85.5060609@oracle.com> Vote: yes From serguei.spitsyn at oracle.com Fri Feb 12 04:29:17 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 11 Feb 2016 20:29:17 -0800 Subject: CFV: New jdk9 Reviewer: Zoltan Majo In-Reply-To: <56BCA22A.7030300@oracle.com> References: <56BCA22A.7030300@oracle.com> Message-ID: <56BD5F9D.6030102@oracle.com> Vote: yes From serguei.spitsyn at oracle.com Fri Feb 12 04:29:52 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 11 Feb 2016 20:29:52 -0800 Subject: CFV: New jdk9 Reviewer: Nils Eliasson In-Reply-To: <56BCA5D1.7020202@oracle.com> References: <56BCA5D1.7020202@oracle.com> Message-ID: <56BD5FC0.5050408@oracle.com> Vote: yes From serguei.spitsyn at oracle.com Fri Feb 12 04:31:03 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 11 Feb 2016 20:31:03 -0800 Subject: CFV: New jdk9 Reviewer: Claes Redestad In-Reply-To: <56BCB736.80804@oracle.com> References: <56BCB736.80804@oracle.com> Message-ID: <56BD6007.9030004@oracle.com> Vote: yes From stefan.johansson at oracle.com Fri Feb 12 08:06:50 2016 From: stefan.johansson at oracle.com (Stefan Johansson) Date: Fri, 12 Feb 2016 09:06:50 +0100 Subject: CFV: New jdk9 Reviewer: Tobias Hartmann In-Reply-To: <56BC9559.8060906@oracle.com> References: <56BC9559.8060906@oracle.com> Message-ID: <56BD929A.3050408@oracle.com> Vote: yes StefanJ On 2016-02-11 15:06, Vladimir Ivanov wrote: > I hereby nominate Tobias Hartmann (OpenJDK user name: thartmann) to JDK > 9 Reviewer. > > Tobias is a member of the Hotspot JVM Compiler group. He contributed > 68 changesets to jdk9 project [1] and he is qualified to be a Reviewer. > > While working on Hotspot JVM, Tobias implemented Segmented Code Cache > [2] and compiler support for Compact Strings [3]. > > Votes are due by February, 25 2016. > > Only current JDK 9 Reviewers [4] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Lazy Consensus voting instructions, see [5]. > > Best regards, > Vladimir Ivanov > > [1] > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/search/?rev=thartmann&revcount=100 > [2] https://bugs.openjdk.java.net/browse/JDK-8015774 > [3] http://openjdk.java.net/jeps/254 > [4] http://openjdk.java.net/census#jdk9 > [5] http://openjdk.java.net/projects#committer-vote From stefan.johansson at oracle.com Fri Feb 12 08:07:16 2016 From: stefan.johansson at oracle.com (Stefan Johansson) Date: Fri, 12 Feb 2016 09:07:16 +0100 Subject: CFV: New jdk9 Reviewer: Zoltan Majo In-Reply-To: <56BCA22A.7030300@oracle.com> References: <56BCA22A.7030300@oracle.com> Message-ID: <56BD92B4.5050705@oracle.com> Vote: yes StefanJ On 2016-02-11 16:00, Vladimir Ivanov wrote: > I hereby nominate Zoltan Majo (OpenJDK user name: zmajo) to JDK > 9 Reviewer. > > Zoltan is a member of the Hotspot JVM Compiler group. He contributed > 51 changesets to jdk9 project [1] and he is qualified to be a Reviewer. > > Votes are due by February, 25 2016. > > Only current JDK 9 Reviewers [2] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Lazy Consensus voting instructions, see [3]. > > Best regards, > Vladimir Ivanov > > [1] > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/log?revcount=100&rev=author%28zmajo%29 > [2] http://openjdk.java.net/census#jdk9 > [3] http://openjdk.java.net/projects#committer-vote > From stefan.johansson at oracle.com Fri Feb 12 08:07:38 2016 From: stefan.johansson at oracle.com (Stefan Johansson) Date: Fri, 12 Feb 2016 09:07:38 +0100 Subject: CFV: New jdk9 Reviewer: Nils Eliasson In-Reply-To: <56BCA5D1.7020202@oracle.com> References: <56BCA5D1.7020202@oracle.com> Message-ID: <56BD92CA.2090103@oracle.com> Vote: yes StefanJ On 2016-02-11 16:16, Vladimir Ivanov wrote: > I hereby nominate Nils Eliasson (OpenJDK user name: neliasso to JDK > 9 Reviewer. > > Nils is a member of the Hotspot JVM Compiler group. He contributed 52 > changesets to jdk9 project [1] and he is qualified to be a Reviewer. > > Nils is the author of Compiler Control implementation [2] in HotSpot JVM. > > Votes are due by February, 25 2016. > > Only current JDK 9 Reviewers [3] 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 [4]. > > Best regards, > Vladimir Ivanov > > [1] > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/log?revcount=100&rev=author%28neliasso%29 > [2] http://openjdk.java.net/jeps/165 > [3] http://openjdk.java.net/census#jdk9 > [4] http://openjdk.java.net/projects#committer-vote From stefan.johansson at oracle.com Fri Feb 12 08:08:04 2016 From: stefan.johansson at oracle.com (Stefan Johansson) Date: Fri, 12 Feb 2016 09:08:04 +0100 Subject: CFV: New jdk9 Reviewer: Claes Redestad In-Reply-To: <56BCB736.80804@oracle.com> References: <56BCB736.80804@oracle.com> Message-ID: <56BD92E4.9010106@oracle.com> Vote: yes StefanJ On 2016-02-11 17:30, Vladimir Ivanov wrote: > I hereby nominate Claes Redestad (OpenJDK user name: redestad) to JDK > 9 Reviewer. > > Claes is a member of the Java SE Performance team. He contributed 50 > changesets to jdk9 project [1] [2] and he is qualified to be a Reviewer. > > Among other things, Claes did numerous performance improvements in > java.lang.invoke implementation and Project Jigsaw [3]. > > Votes are due by February, 25 2016. > > Only current JDK 9 Reviewers [4] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Lazy Consensus voting instructions, see [5]. > > Best regards, > Vladimir Ivanov > > [1] > http://hg.openjdk.java.net/jdk9/dev/jdk/search/?rev=author%28redestad%29&revcount=100 > [2] > http://hg.openjdk.java.net/jdk9/dev/hotspot/search/?rev=author%28redestad%29&revcount=100 > [3] > http://hg.openjdk.java.net/jigsaw/jake/jdk/log?rev=author%28redestad%29 > [4] http://openjdk.java.net/census#jdk9 > [5] http://openjdk.java.net/projects#committer-vote From thomas.schatzl at oracle.com Fri Feb 12 08:13:16 2016 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Fri, 12 Feb 2016 09:13:16 +0100 Subject: CFV: New jdk9 Reviewer: Claes Redestad In-Reply-To: <56BCB736.80804@oracle.com> References: <56BCB736.80804@oracle.com> Message-ID: <1455264796.2297.0.camel@oracle.com> Vote: yes On Thu, 2016-02-11 at 19:30 +0300, Vladimir Ivanov wrote: > I hereby nominate Claes Redestad (OpenJDK user name: redestad) to JDK > 9 Reviewer. > > Claes is a member of the Java SE Performance team. He contributed 50 > changesets to jdk9 project [1] [2] and he is qualified to be a > Reviewer. > > Among other things, Claes did numerous performance improvements in > java.lang.invoke implementation and Project Jigsaw [3]. > > Votes are due by February, 25 2016. > > Only current JDK 9 Reviewers [4] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [5]. > > Best regards, > Vladimir Ivanov > > [1] > http://hg.openjdk.java.net/jdk9/dev/jdk/search/?rev=author%28redestad > %29&revcount=100 > [2] > http://hg.openjdk.java.net/jdk9/dev/hotspot/search/?rev=author%28rede > stad%29&revcount=100 > [3] http://hg.openjdk.java.net/jigsaw/jake/jdk/log?rev=author%28redes > tad%29 > [4] http://openjdk.java.net/census#jdk9 > [5] http://openjdk.java.net/projects#committer-vote From staffan.larsen at oracle.com Fri Feb 12 09:30:16 2016 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 12 Feb 2016 10:30:16 +0100 Subject: CFV: New jdk9 Reviewer: Zoltan Majo In-Reply-To: <56BCA22A.7030300@oracle.com> References: <56BCA22A.7030300@oracle.com> Message-ID: <54C64D1F-80C7-4113-9A0D-04DFD305EC99@oracle.com> Vote: yes > On 11 feb. 2016, at 16:00, Vladimir Ivanov wrote: > > I hereby nominate Zoltan Majo (OpenJDK user name: zmajo) to JDK > 9 Reviewer. > > Zoltan is a member of the Hotspot JVM Compiler group. He contributed 51 changesets to jdk9 project [1] and he is qualified to be a Reviewer. > > Votes are due by February, 25 2016. > > Only current JDK 9 Reviewers [2] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Best regards, > Vladimir Ivanov > > [1] http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/log?revcount=100&rev=author%28zmajo%29 > [2] http://openjdk.java.net/census#jdk9 > [3] http://openjdk.java.net/projects#committer-vote > From staffan.larsen at oracle.com Fri Feb 12 09:30:35 2016 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 12 Feb 2016 10:30:35 +0100 Subject: CFV: New jdk9 Reviewer: Nils Eliasson In-Reply-To: <56BCA5D1.7020202@oracle.com> References: <56BCA5D1.7020202@oracle.com> Message-ID: <7855C891-96E3-4A67-B738-F4322B02A886@oracle.com> Vote: yes > On 11 feb. 2016, at 16:16, Vladimir Ivanov wrote: > > I hereby nominate Nils Eliasson (OpenJDK user name: neliasso to JDK > 9 Reviewer. > > Nils is a member of the Hotspot JVM Compiler group. He contributed 52 changesets to jdk9 project [1] and he is qualified to be a Reviewer. > > Nils is the author of Compiler Control implementation [2] in HotSpot JVM. > > Votes are due by February, 25 2016. > > Only current JDK 9 Reviewers [3] 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 [4]. > > Best regards, > Vladimir Ivanov > > [1] http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/log?revcount=100&rev=author%28neliasso%29 > [2] http://openjdk.java.net/jeps/165 > [3] http://openjdk.java.net/census#jdk9 > [4] http://openjdk.java.net/projects#committer-vote From staffan.larsen at oracle.com Fri Feb 12 09:30:50 2016 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 12 Feb 2016 10:30:50 +0100 Subject: CFV: New jdk9 Reviewer: Claes Redestad In-Reply-To: <56BCB736.80804@oracle.com> References: <56BCB736.80804@oracle.com> Message-ID: <3F353DE7-A4E5-4F78-A4CB-519618D79129@oracle.com> Vote: yes > On 11 feb. 2016, at 17:30, Vladimir Ivanov wrote: > > I hereby nominate Claes Redestad (OpenJDK user name: redestad) to JDK > 9 Reviewer. > > Claes is a member of the Java SE Performance team. He contributed 50 changesets to jdk9 project [1] [2] and he is qualified to be a Reviewer. > > Among other things, Claes did numerous performance improvements in java.lang.invoke implementation and Project Jigsaw [3]. > > Votes are due by February, 25 2016. > > Only current JDK 9 Reviewers [4] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [5]. > > Best regards, > Vladimir Ivanov > > [1] http://hg.openjdk.java.net/jdk9/dev/jdk/search/?rev=author%28redestad%29&revcount=100 > [2] http://hg.openjdk.java.net/jdk9/dev/hotspot/search/?rev=author%28redestad%29&revcount=100 > [3] http://hg.openjdk.java.net/jigsaw/jake/jdk/log?rev=author%28redestad%29 > [4] http://openjdk.java.net/census#jdk9 > [5] http://openjdk.java.net/projects#committer-vote From brian.goetz at oracle.com Fri Feb 12 10:08:05 2016 From: brian.goetz at oracle.com (Brian Goetz) Date: Fri, 12 Feb 2016 11:08:05 +0100 Subject: CFV: New jdk9 Reviewer: Claes Redestad In-Reply-To: <56BCB736.80804@oracle.com> References: <56BCB736.80804@oracle.com> Message-ID: Vote: yes On Feb 11, 2016, at 5:30 PM, Vladimir Ivanov wrote: > I hereby nominate Claes Redestad (OpenJDK user name: redestad) to JDK > 9 Reviewer. > > Claes is a member of the Java SE Performance team. He contributed 50 changesets to jdk9 project [1] [2] and he is qualified to be a Reviewer. > > Among other things, Claes did numerous performance improvements in java.lang.invoke implementation and Project Jigsaw [3]. > > Votes are due by February, 25 2016. > > Only current JDK 9 Reviewers [4] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [5]. > > Best regards, > Vladimir Ivanov > > [1] http://hg.openjdk.java.net/jdk9/dev/jdk/search/?rev=author%28redestad%29&revcount=100 > [2] http://hg.openjdk.java.net/jdk9/dev/hotspot/search/?rev=author%28redestad%29&revcount=100 > [3] http://hg.openjdk.java.net/jigsaw/jake/jdk/log?rev=author%28redestad%29 > [4] http://openjdk.java.net/census#jdk9 > [5] http://openjdk.java.net/projects#committer-vote From magnus.ihse.bursie at oracle.com Fri Feb 12 11:26:42 2016 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 12 Feb 2016 12:26:42 +0100 Subject: CFV: New jdk9 Reviewer: Claes Redestad In-Reply-To: <56BCB736.80804@oracle.com> References: <56BCB736.80804@oracle.com> Message-ID: <56BDC172.5040509@oracle.com> Vote: yes /Magnus On 2016-02-11 17:30, Vladimir Ivanov wrote: > I hereby nominate Claes Redestad (OpenJDK user name: redestad) to JDK > 9 Reviewer. > > Claes is a member of the Java SE Performance team. He contributed 50 > changesets to jdk9 project [1] [2] and he is qualified to be a Reviewer. > > Among other things, Claes did numerous performance improvements in > java.lang.invoke implementation and Project Jigsaw [3]. > > Votes are due by February, 25 2016. > > Only current JDK 9 Reviewers [4] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Lazy Consensus voting instructions, see [5]. > > Best regards, > Vladimir Ivanov > > [1] > http://hg.openjdk.java.net/jdk9/dev/jdk/search/?rev=author%28redestad%29&revcount=100 > [2] > http://hg.openjdk.java.net/jdk9/dev/hotspot/search/?rev=author%28redestad%29&revcount=100 > [3] > http://hg.openjdk.java.net/jigsaw/jake/jdk/log?rev=author%28redestad%29 > [4] http://openjdk.java.net/census#jdk9 > [5] http://openjdk.java.net/projects#committer-vote From magnus.ihse.bursie at oracle.com Fri Feb 12 11:27:52 2016 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 12 Feb 2016 12:27:52 +0100 Subject: CFV: New jdk9 Reviewer: Nils Eliasson In-Reply-To: <56BCA5D1.7020202@oracle.com> References: <56BCA5D1.7020202@oracle.com> Message-ID: <56BDC1B8.7080308@oracle.com> Vote: yes /Magnus On 2016-02-11 16:16, Vladimir Ivanov wrote: > I hereby nominate Nils Eliasson (OpenJDK user name: neliasso to JDK > 9 Reviewer. > > Nils is a member of the Hotspot JVM Compiler group. He contributed 52 > changesets to jdk9 project [1] and he is qualified to be a Reviewer. > > Nils is the author of Compiler Control implementation [2] in HotSpot JVM. > > Votes are due by February, 25 2016. > > Only current JDK 9 Reviewers [3] 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 [4]. > > Best regards, > Vladimir Ivanov > > [1] > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/log?revcount=100&rev=author%28neliasso%29 > [2] http://openjdk.java.net/jeps/165 > [3] http://openjdk.java.net/census#jdk9 > [4] http://openjdk.java.net/projects#committer-vote From Alan.Bateman at oracle.com Fri Feb 12 11:36:42 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 12 Feb 2016 11:36:42 +0000 Subject: CFV: New jdk9 Reviewer: Claes Redestad In-Reply-To: <56BCB736.80804@oracle.com> References: <56BCB736.80804@oracle.com> Message-ID: <56BDC3CA.8020003@oracle.com> Vote: yes From roland.westrelin at oracle.com Fri Feb 12 11:37:29 2016 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Fri, 12 Feb 2016 12:37:29 +0100 Subject: CFV: New jdk9 Reviewer: Nils Eliasson In-Reply-To: <56BCA5D1.7020202@oracle.com> References: <56BCA5D1.7020202@oracle.com> Message-ID: Vote: yes. Roland. From roland.westrelin at oracle.com Fri Feb 12 11:37:46 2016 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Fri, 12 Feb 2016 12:37:46 +0100 Subject: CFV: New jdk9 Reviewer: Zoltan Majo In-Reply-To: <56BCA22A.7030300@oracle.com> References: <56BCA22A.7030300@oracle.com> Message-ID: <0CC7E1BD-293B-48C2-A470-9153A83F026E@oracle.com> Vote: yes Roland. From daniel.fuchs at oracle.com Fri Feb 12 12:04:23 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 12 Feb 2016 13:04:23 +0100 Subject: CFV: New JDK 9 Reviewer: Anthony Scarpino In-Reply-To: <56BB34E7.6040207@oracle.com> References: <56BB34E7.6040207@oracle.com> Message-ID: <56BDCA47.4090805@oracle.com> Vote: yes On 10/02/16 14:02, Sean Mullan wrote: > I hereby nominate Anthony Scarpino to JDK 9 Reviewer. From daniel.fuchs at oracle.com Fri Feb 12 12:05:35 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 12 Feb 2016 13:05:35 +0100 Subject: CFV: New jdk9 Reviewer: Claes Redestad In-Reply-To: <56BCB736.80804@oracle.com> References: <56BCB736.80804@oracle.com> Message-ID: <56BDCA8F.3020805@oracle.com> Vote: yes On 11/02/16 17:30, Vladimir Ivanov wrote: > I hereby nominate Claes Redestad (OpenJDK user name: redestad) to JDK > 9 Reviewer. From paul.sandoz at oracle.com Fri Feb 12 13:36:35 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 12 Feb 2016 14:36:35 +0100 Subject: RFR JDK-8149644 Integrate VarHandles In-Reply-To: <56BD24CE.8020405@oracle.com> References: <9C47EF6F-80D6-467E-A5CB-2FDD5FF6AE17@oracle.com> <56BD24CE.8020405@oracle.com> Message-ID: <76FE8EAF-0359-464F-B1BE-D048B53FE8A7@oracle.com> > On 12 Feb 2016, at 01:18, Vladimir Kozlov wrote: > > I looked on Hotspot changes and changes are fine. My only complain is missing {} in if() statements. It was source for bugs for us before so we require to always have {}: in rewriter.cpp, method.cpp, methodHandles.cpp. > Thanks! updated in place. Paul. > Thanks, > Vladimir > > On 2/11/16 7:39 AM, Paul Sandoz wrote: >> Hi, >> >> This is the implementation review request for VarHandles. >> >> Langtools: >> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8149644-varhandles-integration/langtools/webrev/index.html >> >> Hotspot: >> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8149644-varhandles-integration/hotspot/webrev/index.html >> >> JDK: >> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8149644-varhandles-integration/jdk/webrev/index.html >> From paul.sandoz at oracle.com Fri Feb 12 13:39:17 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 12 Feb 2016 14:39:17 +0100 Subject: RFR JDK-8149644 Integrate VarHandles In-Reply-To: <9C47EF6F-80D6-467E-A5CB-2FDD5FF6AE17@oracle.com> References: <9C47EF6F-80D6-467E-A5CB-2FDD5FF6AE17@oracle.com> Message-ID: > On 11 Feb 2016, at 16:39, Paul Sandoz wrote: > > JDK: > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8149644-varhandles-integration/jdk/webrev/index.html > In case anyone is currently reviewing i inadvertently included some updates to classes in j.u.c.atomic. Those updates are now removed from the webrev. Martin and Doug will get to this area later on. Paul. From per.liden at oracle.com Fri Feb 12 14:53:47 2016 From: per.liden at oracle.com (Per Liden) Date: Fri, 12 Feb 2016 15:53:47 +0100 Subject: CFV: New JDK 9 Committer: Dmitry Fazunenko In-Reply-To: <56B36771.9000005@oracle.com> References: <56B36771.9000005@oracle.com> Message-ID: <56BDF1FB.3030702@oracle.com> Vote: yes /Per On 2016-02-04 16:00, Jesper Wilhelmsson wrote: > I hereby nominate Dmitry Fazunenko (dfazunen) for JDK 9 Committer. > > Dmitry is a member of the VM SQE team at Oracle and has contributed 13 > changesets [3] to JDK 9. > > Votes are due by 18:00 MSK / 16:00 CET / 10.00 am EST / 7.00 am PT, > Thursday February 18, 2016 > > Only current JDK 9 Committers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > /Jesper > > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] List of patches: > > 8132961: JEP 279: Improve Test-Failure Troubleshooting > http://hg.openjdk.java.net/jdk9/hs-rt/rev/4aa2e64eff30 > > 8147003: Move BubbleUpRef test into CMS directory > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/28dcfa2f0275 > > 8134963: [Newtest] New stress test for changing the coarseness level of > G1 remembered set > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/af014cb82e42 > > 8147075: Rename old GC JTreg tests to the new naming scheme > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/c15c0bd51e1d > > 8146889: Update @requires expression for GC tests to run if GC is default > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/66aa15bcceff > > 8016752: [Newtest] regression test for PrintGCDetails and Verbose flags > do not crash when ParOldGC has no memory > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/96cc87bb08f8 > > 8132709: [TESTBUG] gc/g1/TestHumongousShrinkHeap.java might fail on > embedded > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/d750cc39ed60 > > 8073476: G1 logging ignores changes to PrintGC* flags via MXBeans > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/ce8df07dd074 > > 8050464: G1 string deduplication tests hang/timeout and leave running > processes consuming all resources > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/b515190809d5 > > 8055284: sanity/WhiteBox.java fails with NPE > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/1662147c9ca3 > > 8044673: Create jtreg groups to list GC specific tests > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/1abbc1e91ac5 > > 8040250: The test test/gc/parallelScavenge/TestDynShrinkHeap.java fails > with OOME > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/abd312cd8cc2 > > 8039489: Refactor test framework for dynamic VM options > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/8ec72dcefd74 From per.liden at oracle.com Fri Feb 12 14:54:52 2016 From: per.liden at oracle.com (Per Liden) Date: Fri, 12 Feb 2016 15:54:52 +0100 Subject: CFV: New jdk9 Reviewer: Tobias Hartmann In-Reply-To: <56BC9559.8060906@oracle.com> References: <56BC9559.8060906@oracle.com> Message-ID: <56BDF23C.2060804@oracle.com> Vote: yes /Per On 2016-02-11 15:06, Vladimir Ivanov wrote: > I hereby nominate Tobias Hartmann (OpenJDK user name: thartmann) to JDK > 9 Reviewer. > > Tobias is a member of the Hotspot JVM Compiler group. He contributed 68 > changesets to jdk9 project [1] and he is qualified to be a Reviewer. > > While working on Hotspot JVM, Tobias implemented Segmented Code Cache > [2] and compiler support for Compact Strings [3]. > > Votes are due by February, 25 2016. > > Only current JDK 9 Reviewers [4] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Lazy Consensus voting instructions, see [5]. > > Best regards, > Vladimir Ivanov > > [1] > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/search/?rev=thartmann&revcount=100 > > [2] https://bugs.openjdk.java.net/browse/JDK-8015774 > [3] http://openjdk.java.net/jeps/254 > [4] http://openjdk.java.net/census#jdk9 > [5] http://openjdk.java.net/projects#committer-vote From per.liden at oracle.com Fri Feb 12 14:55:20 2016 From: per.liden at oracle.com (Per Liden) Date: Fri, 12 Feb 2016 15:55:20 +0100 Subject: CFV: New jdk9 Reviewer: Nils Eliasson In-Reply-To: <56BCA5D1.7020202@oracle.com> References: <56BCA5D1.7020202@oracle.com> Message-ID: <56BDF258.7010204@oracle.com> Vote: yes /Per On 2016-02-11 16:16, Vladimir Ivanov wrote: > I hereby nominate Nils Eliasson (OpenJDK user name: neliasso to JDK > 9 Reviewer. > > Nils is a member of the Hotspot JVM Compiler group. He contributed 52 > changesets to jdk9 project [1] and he is qualified to be a Reviewer. > > Nils is the author of Compiler Control implementation [2] in HotSpot JVM. > > Votes are due by February, 25 2016. > > Only current JDK 9 Reviewers [3] 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 [4]. > > Best regards, > Vladimir Ivanov > > [1] > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/log?revcount=100&rev=author%28neliasso%29 > > [2] http://openjdk.java.net/jeps/165 > [3] http://openjdk.java.net/census#jdk9 > [4] http://openjdk.java.net/projects#committer-vote From per.liden at oracle.com Fri Feb 12 14:57:15 2016 From: per.liden at oracle.com (Per Liden) Date: Fri, 12 Feb 2016 15:57:15 +0100 Subject: CFV: New jdk9 Reviewer: Zoltan Majo In-Reply-To: <56BCA22A.7030300@oracle.com> References: <56BCA22A.7030300@oracle.com> Message-ID: <56BDF2CB.6010308@oracle.com> Vote: yes /Per On 2016-02-11 16:00, Vladimir Ivanov wrote: > I hereby nominate Zoltan Majo (OpenJDK user name: zmajo) to JDK > 9 Reviewer. > > Zoltan is a member of the Hotspot JVM Compiler group. He contributed 51 > changesets to jdk9 project [1] and he is qualified to be a Reviewer. > > Votes are due by February, 25 2016. > > Only current JDK 9 Reviewers [2] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Lazy Consensus voting instructions, see [3]. > > Best regards, > Vladimir Ivanov > > [1] > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/log?revcount=100&rev=author%28zmajo%29 > > [2] http://openjdk.java.net/census#jdk9 > [3] http://openjdk.java.net/projects#committer-vote > From per.liden at oracle.com Fri Feb 12 14:57:56 2016 From: per.liden at oracle.com (Per Liden) Date: Fri, 12 Feb 2016 15:57:56 +0100 Subject: CFV: New jdk9 Reviewer: Claes Redestad In-Reply-To: <56BCB736.80804@oracle.com> References: <56BCB736.80804@oracle.com> Message-ID: <56BDF2F4.1050004@oracle.com> Vote: yes /Per On 2016-02-11 17:30, Vladimir Ivanov wrote: > I hereby nominate Claes Redestad (OpenJDK user name: redestad) to JDK > 9 Reviewer. > > Claes is a member of the Java SE Performance team. He contributed 50 > changesets to jdk9 project [1] [2] and he is qualified to be a Reviewer. > > Among other things, Claes did numerous performance improvements in > java.lang.invoke implementation and Project Jigsaw [3]. > > Votes are due by February, 25 2016. > > Only current JDK 9 Reviewers [4] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Lazy Consensus voting instructions, see [5]. > > Best regards, > Vladimir Ivanov > > [1] > http://hg.openjdk.java.net/jdk9/dev/jdk/search/?rev=author%28redestad%29&revcount=100 > > [2] > http://hg.openjdk.java.net/jdk9/dev/hotspot/search/?rev=author%28redestad%29&revcount=100 > > [3] http://hg.openjdk.java.net/jigsaw/jake/jdk/log?rev=author%28redestad%29 > [4] http://openjdk.java.net/census#jdk9 > [5] http://openjdk.java.net/projects#committer-vote From Roger.Riggs at Oracle.com Fri Feb 12 18:08:39 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Fri, 12 Feb 2016 13:08:39 -0500 Subject: CFV: New jdk9 Reviewer: Tobias Hartmann In-Reply-To: <56BC9559.8060906@oracle.com> References: <56BC9559.8060906@oracle.com> Message-ID: <56BE1FA7.8040200@Oracle.com> Vote: Yes On 2/11/2016 9:06 AM, Vladimir Ivanov wrote: > I hereby nominate Tobias Hartmann (OpenJDK user name: thartmann) to JDK > 9 Reviewer. > From ivan.gerasimov at oracle.com Fri Feb 12 18:52:04 2016 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Fri, 12 Feb 2016 21:52:04 +0300 Subject: CFV: New jdk9 Reviewer: Claes Redestad In-Reply-To: <56BCB736.80804@oracle.com> References: <56BCB736.80804@oracle.com> Message-ID: <56BE29D4.6010000@oracle.com> Vote: yes On 11.02.2016 19:30, Vladimir Ivanov wrote: > I hereby nominate Claes Redestad (OpenJDK user name: redestad) to JDK > 9 Reviewer. > > Claes is a member of the Java SE Performance team. He contributed 50 > changesets to jdk9 project [1] [2] and he is qualified to be a Reviewer. > > Among other things, Claes did numerous performance improvements in > java.lang.invoke implementation and Project Jigsaw [3]. > > Votes are due by February, 25 2016. > > Only current JDK 9 Reviewers [4] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Lazy Consensus voting instructions, see [5]. > > Best regards, > Vladimir Ivanov > > [1] > http://hg.openjdk.java.net/jdk9/dev/jdk/search/?rev=author%28redestad%29&revcount=100 > [2] > http://hg.openjdk.java.net/jdk9/dev/hotspot/search/?rev=author%28redestad%29&revcount=100 > [3] > http://hg.openjdk.java.net/jigsaw/jake/jdk/log?rev=author%28redestad%29 > [4] http://openjdk.java.net/census#jdk9 > [5] http://openjdk.java.net/projects#committer-vote > From ivan.gerasimov at oracle.com Fri Feb 12 18:52:47 2016 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Fri, 12 Feb 2016 21:52:47 +0300 Subject: CFV: New JDK 9 Reviewer: Anthony Scarpino In-Reply-To: <56BB34E7.6040207@oracle.com> References: <56BB34E7.6040207@oracle.com> Message-ID: <56BE29FF.3050800@oracle.com> Vote: yes On 10.02.2016 16:02, Sean Mullan wrote: > I hereby nominate Anthony Scarpino to JDK 9 Reviewer. > > Anthony Scarpino is a member of the security libraries team at Oracle. > He has contributed 39 changesets to the JDK 9 Project [3]. He is also > the Author and Owner of JEP 246 (Leverage CPU Instructions for GHASH > and RSA) [4] which has significantly improved cryptographic > performance and has been successfully integrated to JDK 9. > > Votes are due by 24 February 2016, 2:00 PM UTC. > > 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]. > > Sean Mullan > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > [3] > http://hg.openjdk.java.net/jdk9/dev/jdk/log?revcount=1000&rev=author%28%22ascarpin%22%29 > [4] http://openjdk.java.net/jeps/246 > From vladimir.kozlov at oracle.com Fri Feb 12 19:34:02 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 12 Feb 2016 11:34:02 -0800 Subject: RFR JDK-8149644 Integrate VarHandles In-Reply-To: <76FE8EAF-0359-464F-B1BE-D048B53FE8A7@oracle.com> References: <9C47EF6F-80D6-467E-A5CB-2FDD5FF6AE17@oracle.com> <56BD24CE.8020405@oracle.com> <76FE8EAF-0359-464F-B1BE-D048B53FE8A7@oracle.com> Message-ID: <56BE33AA.7090800@oracle.com> On 2/12/16 5:36 AM, Paul Sandoz wrote: > >> On 12 Feb 2016, at 01:18, Vladimir Kozlov wrote: >> >> I looked on Hotspot changes and changes are fine. My only complain is missing {} in if() statements. It was source for bugs for us before so we require to always have {}: in rewriter.cpp, method.cpp, methodHandles.cpp. >> > > Thanks! updated in place. > Paul. Good. Vladimir > >> Thanks, >> Vladimir >> >> On 2/11/16 7:39 AM, Paul Sandoz wrote: >>> Hi, >>> >>> This is the implementation review request for VarHandles. >>> >>> Langtools: >>> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8149644-varhandles-integration/langtools/webrev/index.html >>> >>> Hotspot: >>> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8149644-varhandles-integration/hotspot/webrev/index.html >>> >>> JDK: >>> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8149644-varhandles-integration/jdk/webrev/index.html >>> > From valerie.peng at oracle.com Sat Feb 13 00:48:44 2016 From: valerie.peng at oracle.com (Valerie Peng) Date: Fri, 12 Feb 2016 16:48:44 -0800 Subject: CFV: New JDK 9 Reviewer: Anthony Scarpino In-Reply-To: <56BE29FF.3050800@oracle.com> References: <56BB34E7.6040207@oracle.com> <56BE29FF.3050800@oracle.com> Message-ID: <56BE7D6C.3020503@oracle.com> Vote: yes On 2/12/2016 10:52 AM, Ivan Gerasimov wrote: > Vote: yes > > On 10.02.2016 16:02, Sean Mullan wrote: >> I hereby nominate Anthony Scarpino to JDK 9 Reviewer. >> >> Anthony Scarpino is a member of the security libraries team at >> Oracle. He has contributed 39 changesets to the JDK 9 Project [3]. He >> is also the Author and Owner of JEP 246 (Leverage CPU Instructions >> for GHASH and RSA) [4] which has significantly improved cryptographic >> performance and has been successfully integrated to JDK 9. >> >> Votes are due by 24 February 2016, 2:00 PM UTC. >> >> 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]. >> >> Sean Mullan >> >> [1] http://openjdk.java.net/census >> [2] http://openjdk.java.net/projects/#reviewer-vote >> [3] >> http://hg.openjdk.java.net/jdk9/dev/jdk/log?revcount=1000&rev=author%28%22ascarpin%22%29 >> [4] http://openjdk.java.net/jeps/246 >> > From james.laskey at oracle.com Sun Feb 14 14:13:38 2016 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Sun, 14 Feb 2016 10:13:38 -0400 Subject: RFR - JDK-8149776 - BSD license for jimage code Message-ID: <01051DD5-09AD-45F4-874D-99CBE665056D@oracle.com> http://cr.openjdk.java.net/~jlaskey/8149776/webrev/index.html https://bugs.openjdk.java.net/browse/JDK-8149776 From adinn at redhat.com Mon Feb 15 09:29:34 2016 From: adinn at redhat.com (Andrew Dinn) Date: Mon, 15 Feb 2016 09:29:34 +0000 Subject: RFR - JDK-8149776 - BSD license for jimage code In-Reply-To: <01051DD5-09AD-45F4-874D-99CBE665056D@oracle.com> References: <01051DD5-09AD-45F4-874D-99CBE665056D@oracle.com> Message-ID: <56C19A7E.5080305@redhat.com> On 14/02/16 14:13, Jim Laskey (Oracle) wrote: > http://cr.openjdk.java.net/~jlaskey/8149776/webrev/index.html > https://bugs.openjdk.java.net/browse/JDK-8149776 This change set appears to be changing the license for a slew of image related code files from GPL to BSD. However, the associated issue is not accessible (it looks like it is Oracle private). Can someone provide some context to explain why this is being done? regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in UK and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (US), Michael O'Neill (Ireland), Paul Argiry (US) From Alan.Bateman at oracle.com Mon Feb 15 10:51:45 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 15 Feb 2016 10:51:45 +0000 Subject: RFR - JDK-8149776 - BSD license for jimage code In-Reply-To: <56C19A7E.5080305@redhat.com> References: <01051DD5-09AD-45F4-874D-99CBE665056D@oracle.com> <56C19A7E.5080305@redhat.com> Message-ID: <56C1ADC1.9090400@oracle.com> On 15/02/2016 09:29, Andrew Dinn wrote: > : > > Can someone provide some context to explain why this is being done? > > This is to allow the code be used by VM implementations that are allergic to GPL or GPL + "Classpath" exception, nothing more. -Alan. From neugens.limasoftware at gmail.com Mon Feb 15 11:03:27 2016 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Mon, 15 Feb 2016 12:03:27 +0100 Subject: RFR - JDK-8149776 - BSD license for jimage code In-Reply-To: <56C1ADC1.9090400@oracle.com> References: <01051DD5-09AD-45F4-874D-99CBE665056D@oracle.com> <56C19A7E.5080305@redhat.com> <56C1ADC1.9090400@oracle.com> Message-ID: Hi Alan, I wanted to comment on that too, but Andrew beat me. Anyway this answer doesn't really tell anything useful and I would like some more context. I understand that Oracle *may* have the rights to change licensing at any time due to the OCA (although my assumption is more that Oracle has the right to dual license the code, not arbitrarily change it), but any change should be communicated in advance and perhaps discussed. I actually expect such change to be discussed by the legal body that drives OpenJDK development, not something trivially done with a secret bug report. In this case we are relaxing the licensing restriction may seem a generous and innocent change, and we could be fine with that, but again I still question the method used, an after the fact commit referencing a non accessible bug. On a side note, the GPL+Exception allows linkage of closed source, so unless one wants to modify the actual code, I don't understand why this change is needed at all. I'm worried that this makes a dangerous precedent. Cheers, Mario 2016-02-15 11:51 GMT+01:00 Alan Bateman : > > On 15/02/2016 09:29, Andrew Dinn wrote: >> >> : >> >> Can someone provide some context to explain why this is being done? >> >> > This is to allow the code be used by VM implementations that are allergic to > GPL or GPL + "Classpath" exception, nothing more. > > -Alan. -- pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens Proud GNU Classpath developer: http://www.classpath.org/ OpenJDK: http://openjdk.java.net/projects/caciocavallo/ Please, support open standards: http://endsoftpatents.org/ From Alan.Bateman at oracle.com Mon Feb 15 11:36:32 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 15 Feb 2016 11:36:32 +0000 Subject: RFR - JDK-8149776 - BSD license for jimage code In-Reply-To: References: <01051DD5-09AD-45F4-874D-99CBE665056D@oracle.com> <56C19A7E.5080305@redhat.com> <56C1ADC1.9090400@oracle.com> Message-ID: <56C1B840.9020502@oracle.com> On 15/02/2016 11:03, Mario Torre wrote: > Hi Alan, > > I wanted to comment on that too, but Andrew beat me. Anyway this > answer doesn't really tell anything useful and I would like some more context. > > I understand that Oracle *may* have the rights to change licensing at > any time due to the OCA (although my assumption is more that Oracle > has the right to dual license the code, not arbitrarily change it), > but any change should be communicated in advance and perhaps > discussed. I actually expect such change to be discussed by the legal > body that drives OpenJDK development, not something trivially done > with a secret bug report. > > In this case we are relaxing the licensing restriction may seem a > generous and innocent change, and we could be fine with that, but > again I still question the method used, an after the fact commit > referencing a non accessible bug. > Jim has fixed the JBS issue, it should not have been created as a restricted issue. To my knowledge, the due diligence has been done. -Alan From aleksey.shipilev at oracle.com Mon Feb 15 12:22:05 2016 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Mon, 15 Feb 2016 15:22:05 +0300 Subject: RFR #2 (M) 8148146: Integrate new internal Unsafe entry points, and basic intrinsic support for VarHandles Message-ID: <56C1C2ED.10702@oracle.com> Hi, I would like to solicit reviews for the slab of VM changes to support JEP 193 (VarHandles). This portion covers new Unsafe methods. The last review got fallen through the mailing list trenches with reposts, hopefully we will have more reviews now that we include hotspot-dev and jdk9-dev. Webrev: http://cr.openjdk.java.net/~shade/8148146/webrev.jdk.01/ http://cr.openjdk.java.net/~shade/8148146/webrev.hs.01/ These changes successfully pass JPRT -testset hotspot on all platforms. Eyeballing the generated code on x86 yields no obvious problems. Sanity microbenchmark runs do not show performance regressions on old methods, and show the expected performance on new methods: http://cr.openjdk.java.net/~shade/8148146/notes.txt A brief summary of changes: a) jdk.internal.misc.Unsafe has new methods. Since we now have split s.m.Unsafe and j.i.m.Unsafe, this change "safely" extends the private Unsafe, leaving the other one untouched. b) hotspot/test/compiler/unsafe tests are extended for newly added methods. c) unsafe.cpp gets the basic native method implementations. Most new operations are folded to their volatile (the strongest) counterparts, hoping that compilers would intrinsify them into more performant versions. d) C1 intrinsics are not present in this patch: we have some prototypes in VarHandles forest, but they are not ready to be pushed; e) C2 intrinsics for x86: * Most intrinsics code is covered by platform-independent LibraryCallKit changes, which means non-x86 architectures are also partially covered. * There are two classes of ops left for platform-dependent code: WeakCAS and CompareAndExchange nodes. Both seem simple enough to do, but there are details to be sorted out on each platform -- let's do those separately. * Both LibraryCallKit::inline_unsafe_access and LCK::inline_unsafe_load_store were modified to accept new access modes, and generally brushed up to accept the changes. * putOrdered intrinsic methods are purged in favor of put*Release operations. We still keep Unsafe.putOrdered for testability and compatibility reasons. Cheers, -Aleksey From adinn at redhat.com Mon Feb 15 12:53:16 2016 From: adinn at redhat.com (Andrew Dinn) Date: Mon, 15 Feb 2016 12:53:16 +0000 Subject: RFR - JDK-8149776 - BSD license for jimage code In-Reply-To: <56C1B840.9020502@oracle.com> References: <01051DD5-09AD-45F4-874D-99CBE665056D@oracle.com> <56C19A7E.5080305@redhat.com> <56C1ADC1.9090400@oracle.com> <56C1B840.9020502@oracle.com> Message-ID: <56C1CA3C.7020105@redhat.com> On 15/02/16 11:36, Alan Bateman wrote: > Jim has fixed the JBS issue, it should not have been created as a > restricted issue. To my knowledge, the due diligence has been done. I am afraid I am still none the wiser as to what the point is of allowing "more liberal use of jimage native code" as the JIRA states. Thta merely says what is being done which is ewvident from the change set itself. What I originally asked for was "some context to explain why this is being done?". That isn't addressed by the JIRA any more than it is by the posted change set. Whoever has instigated the JIRA ought to be doing it for a reason and I would like to know what that reason is. The issue here is not one of due diligence, rather of accountability for changes made to the open source code base. So, once again: Can someone provide some context to explain why this is being done? regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in UK and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (US), Michael O'Neill (Ireland), Paul Argiry (US) From adinn at redhat.com Mon Feb 15 13:23:03 2016 From: adinn at redhat.com (Andrew Dinn) Date: Mon, 15 Feb 2016 13:23:03 +0000 Subject: RFR #2 (M) 8148146: Integrate new internal Unsafe entry points, and basic intrinsic support for VarHandles In-Reply-To: <56C1C2ED.10702@oracle.com> References: <56C1C2ED.10702@oracle.com> Message-ID: <56C1D137.5020607@redhat.com> Hi Alexsey, On 15/02/16 12:22, Aleksey Shipilev wrote: > I would like to solicit reviews for the slab of VM changes to support > JEP 193 (VarHandles). This portion covers new Unsafe methods. The last > review got fallen through the mailing list trenches with reposts, > hopefully we will have more reviews now that we include hotspot-dev and > jdk9-dev. > > Webrev: > http://cr.openjdk.java.net/~shade/8148146/webrev.jdk.01/ > http://cr.openjdk.java.net/~shade/8148146/webrev.hs.01/ > > These changes successfully pass JPRT -testset hotspot on all platforms. Which platforms does that include? Specifically, does this include/exclude non-closed AArch64? > e) C2 intrinsics for x86: > > * Most intrinsics code is covered by platform-independent > LibraryCallKit changes, which means non-x86 architectures are also > partially covered. The volatile stuff looks ok for Aarch64 after a quick eyeball scan. However, I would like to check the code generated by the back end. I'm especially interested in any potential interaction with Roland's patch for 8087341 (which required associated AArch64 back end changes). I think the two patches should combine correctly (and probably commutatively) but it is worth checking. > * There are two classes of ops left for platform-dependent code: > WeakCAS and CompareAndExchange nodes. Both seem simple enough to do, but > there are details to be sorted out on each platform -- let's do those > separately. Agreed, this is probably best left as a separate step for AArch64. I think we will still be able to optimize the new CAS variants effectively in the back end using the same technique as is employed for volatile stores and standard CAS. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in UK and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (US), Michael O'Neill (Ireland), Paul Argiry (US) From aleksey.shipilev at oracle.com Mon Feb 15 13:49:24 2016 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Mon, 15 Feb 2016 16:49:24 +0300 Subject: RFR #2 (M) 8148146: Integrate new internal Unsafe entry points, and basic intrinsic support for VarHandles In-Reply-To: <56C1D137.5020607@redhat.com> References: <56C1C2ED.10702@oracle.com> <56C1D137.5020607@redhat.com> Message-ID: <56C1D764.6020100@oracle.com> Hi Andrew, On 02/15/2016 04:23 PM, Andrew Dinn wrote: > On 15/02/16 12:22, Aleksey Shipilev wrote: >> I would like to solicit reviews for the slab of VM changes to support >> JEP 193 (VarHandles). This portion covers new Unsafe methods. The last >> review got fallen through the mailing list trenches with reposts, >> hopefully we will have more reviews now that we include hotspot-dev and >> jdk9-dev. >> >> Webrev: >> http://cr.openjdk.java.net/~shade/8148146/webrev.jdk.01/ >> http://cr.openjdk.java.net/~shade/8148146/webrev.hs.01/ >> >> These changes successfully pass JPRT -testset hotspot on all platforms. > > Which platforms does that include? Specifically, does this > include/exclude non-closed AArch64? Yes, open AArch64 is included there. But now I realize new Unsafe tests have not been run there, let me manhandle our infra into doing that. If that is easy for you, can you check if AArch64 works with this patch in your scenarios? >> e) C2 intrinsics for x86: >> >> * Most intrinsics code is covered by platform-independent >> LibraryCallKit changes, which means non-x86 architectures are also >> partially covered. > > The volatile stuff looks ok for Aarch64 after a quick eyeball scan. > However, I would like to check the code generated by the back end. I'm > especially interested in any potential interaction with Roland's patch > for 8087341 (which required associated AArch64 back end changes). I > think the two patches should combine correctly (and probably > commutatively) but it is worth checking. The changes are supposed to generate the same code for old Unsafe methods -- the refactoring shuffles the compiler code around, but the sequence of accesses/barriers should stay the same. Eyeballing x86_64 assembly indeed shows it is the same, but I haven't looked beyond x86. So Roland's patch and those super-(awe|grue)some ARM64 .ad matchers should be unaffected. If they are affected, then I screwed up somewhere during refactoring. I'll wait for Roland's patch to land before pushing these Unsafe changes anyway, and beef up on testing. Thanks, -Aleksey From neugens.limasoftware at gmail.com Mon Feb 15 13:51:17 2016 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Mon, 15 Feb 2016 14:51:17 +0100 Subject: RFR - JDK-8149776 - BSD license for jimage code In-Reply-To: <56C1B840.9020502@oracle.com> References: <01051DD5-09AD-45F4-874D-99CBE665056D@oracle.com> <56C19A7E.5080305@redhat.com> <56C1ADC1.9090400@oracle.com> <56C1B840.9020502@oracle.com> Message-ID: 2016-02-15 12:36 GMT+01:00 Alan Bateman : > On 15/02/2016 11:03, Mario Torre wrote: >> >> Hi Alan, >> >> I wanted to comment on that too, but Andrew beat me. Anyway this >> answer doesn't really tell anything useful and I would like some more >> context. >> >> I understand that Oracle *may* have the rights to change licensing at >> any time due to the OCA (although my assumption is more that Oracle >> has the right to dual license the code, not arbitrarily change it), >> but any change should be communicated in advance and perhaps >> discussed. I actually expect such change to be discussed by the legal >> body that drives OpenJDK development, not something trivially done >> with a secret bug report. >> >> In this case we are relaxing the licensing restriction may seem a >> generous and innocent change, and we could be fine with that, but >> again I still question the method used, an after the fact commit >> referencing a non accessible bug. >> > Jim has fixed the JBS issue, it should not have been created as a restricted > issue. To my knowledge, the due diligence has been done. Hi Alan, A change in the License of the Project files should not be addressed as a restricted bug report. We are not talking about a mistakenly licensed test case or class file that is rightfully fixed back to the proper license, we are talking about a total change in License. As far as I can see, this is not even about dual licensing the files. I'm not fine to the approval of license changes to the OpenJDK Project without prior written notification from the Governing Board. So as an OpenJDK Member I respectfully ask to bring this change to the attention of the Governing Board. Cheers, Mario -- pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens Proud GNU Classpath developer: http://www.classpath.org/ OpenJDK: http://openjdk.java.net/projects/caciocavallo/ Please, support open standards: http://endsoftpatents.org/ From maurizio.cimadamore at oracle.com Mon Feb 15 13:58:11 2016 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 15 Feb 2016 13:58:11 +0000 Subject: RFR JDK-8149644 Integrate VarHandles In-Reply-To: <9C47EF6F-80D6-467E-A5CB-2FDD5FF6AE17@oracle.com> References: <9C47EF6F-80D6-467E-A5CB-2FDD5FF6AE17@oracle.com> Message-ID: <56C1D973.3060802@oracle.com> Langtools changes look ok to me. Would it make sense to file a follow up issue to add some tests in this area (i.e. bytecode tests using the classfile API) ? Cheers Maurizio On 11/02/16 15:39, Paul Sandoz wrote: > Hi, > > This is the implementation review request for VarHandles. > > Langtools: > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8149644-varhandles-integration/langtools/webrev/index.html > > Hotspot: > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8149644-varhandles-integration/hotspot/webrev/index.html > > JDK: > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8149644-varhandles-integration/jdk/webrev/index.html > > The spec/API review is proceeding here [1]. > > The patches depend on Unsafe changes [2] and ByteBuffer changes [3]. > > Recent (as of today) JPRT runs for core and hotspot tests pass without failure. Many parts of the code have been soaking in the Valhalla repo for over a year, and it?s been soaking in the sandbox for quite and many a JPRT run was performed. > > It is planned to push through hs-comp as is the case for the dependent patches, and thus minimise any delays due to integration between forests. > > > The Langtools changes are small. Tweaks were made to support updates to signature polymorphic methods and where may be located, in addition to supporting compilation of calls to MethodHandle.link*. > > > The Hotspot changes are not very large. It?s mostly a matter of augmenting checks for MethodHandle to include that for VarHandle. It?s tempting to generalise the ?invokehandle" invocation as i believe there are other use-cases where it might be useful, but i resisted temptation here. I wanted to focus on the minimal changes required. > > > The JDK changes are more substantial, but a large proportion are new tests. The source compilation approach taken is to use templates, the same approach as for code in the nio package, to generate both implementation and test source code. The implementations are generated by the build, the tests are pre-generated. I believe the tests should have good coverage but we have yet to run any code coverage tool. > > The approach to invocation of VarHandle signature polymoprhic methods is slightly different to that of MethodHandles. I wanted to ensure that linking for the common cases avoids lambda form creation, compilation and therefore class spinning. That reduces start up costs and also potential circular dependencies that might be induced in the VM boot process if VarHandles are employed early on. > > For common basic (i.e. erased ref and widened primitive) method signatures, namely all those that matter for the efficient atomic operations there are pre-generated methods that would otherwise be generated from creating and compiling invoker lambda forms. Those methods reside on the VarHandleGuards class. When the VM makes an up call to MethodHandleNatives.linkMethod to link a call site then this up-called method will first check if an appropriate pre-generated method exists on VarHandleGuards and if so it links to that, otherwise it falls back to a method on a class generated from compiling a lambda form. For testing purposes there is a system property available to switch off this optimisation when linking [*]. > > Each VarHandle instance of the same variable type produced from the same factory will share an underlying immutable instance of a VarForm that contains a set of MemberName instances, one for each implementation of a signature polymorphic method (a value of null means unsupported). The invoke methods (on VarHandleGuards or on lambda forms) will statically link to such MemberName instances using a call to MethodHandle.linkToStatic. > > There are a couple of TODOs in comments, those are all on non-critical code paths and i plan to chase them up afterwards. > > C1 does not support constant folding for @Stable arrays hence why in certain cases we have exploded stuff into fields that are operated on using if/else loops. We can simplify such code if/when C1 support is added. > > > Thanks, > Paul. > > [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-January/038150.html > [2] http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2016-January/020953.html > http://mail.openjdk.java.net/pipermail/hotspot-dev/2016-January/021514.html > [3] http://mail.openjdk.java.net/pipermail/nio-dev/2016-February/003535.html > > [*] This technique might be useful for common signatures of MH invokers to reduce associated costs of lambda form creation and compilation in the interim of something better. From adinn at redhat.com Mon Feb 15 14:13:56 2016 From: adinn at redhat.com (Andrew Dinn) Date: Mon, 15 Feb 2016 14:13:56 +0000 Subject: RFR #2 (M) 8148146: Integrate new internal Unsafe entry points, and basic intrinsic support for VarHandles In-Reply-To: <56C1D764.6020100@oracle.com> References: <56C1C2ED.10702@oracle.com> <56C1D137.5020607@redhat.com> <56C1D764.6020100@oracle.com> Message-ID: <56C1DD24.2060503@redhat.com> Hi Aleksey, On 15/02/16 13:49, Aleksey Shipilev wrote: > Yes, open AArch64 is included there. But now I realize new Unsafe > tests have not been run there, let me manhandle our infra into > doing that. If that is easy for you, can you check if AArch64 works > with this patch in your scenarios? It would be very good to run your Unsafe tests. However, they may still succeed but minus the desired optimizations. So, I'll apply the patch to my tree and check the generated code by eyeball. Can you detail any special magic to perform to run your tests? or is there a grimoire I can consult? > The changes are supposed to generate the same code for old Unsafe > methods -- the refactoring shuffles the compiler code around, but > the sequence of accesses/barriers should stay the same. Eyeballing > x86_64 assembly indeed shows it is the same, but I haven't looked > beyond x86. Ok, good. That was what I thought had been implemented last time I studied a posted change set. > So Roland's patch and those super-(awe|grue)some ARM64 .ad > matchers should be unaffected. If they are affected, then I screwed > up somewhere during refactoring. I'll wait for Roland's patch to > land before pushing these Unsafe changes anyway, and beef up on > testing. That's probably the better way to do it. Roland's change led to a significant lowering of the grue to awe ratio (/his/ awe allowed me to remove much of /my/ grue). regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in UK and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (US), Michael O'Neill (Ireland), Paul Argiry (US) From james.laskey at oracle.com Mon Feb 15 14:39:17 2016 From: james.laskey at oracle.com (James Laskey) Date: Mon, 15 Feb 2016 10:39:17 -0400 Subject: RFR - JDK-8149776 - BSD license for jimage code In-Reply-To: References: <01051DD5-09AD-45F4-874D-99CBE665056D@oracle.com> <56C19A7E.5080305@redhat.com> <56C1ADC1.9090400@oracle.com> <56C1B840.9020502@oracle.com> Message-ID: Mario, The "restricted bug report" was totally a green horn error made by me, the author of the code. I wanted to track the end of process approval for the licensing change by Oracle in the bug and marked it as confidential since it was an internal comment. Mark will likely address your concerns when available, but this was purely an error on my part. -- Jim Sent from my iPhone > On Feb 15, 2016, at 9:51 AM, Mario Torre wrote: > > 2016-02-15 12:36 GMT+01:00 Alan Bateman : >>> On 15/02/2016 11:03, Mario Torre wrote: >>> >>> Hi Alan, >>> >>> I wanted to comment on that too, but Andrew beat me. Anyway this >>> answer doesn't really tell anything useful and I would like some more >>> context. >>> >>> I understand that Oracle *may* have the rights to change licensing at >>> any time due to the OCA (although my assumption is more that Oracle >>> has the right to dual license the code, not arbitrarily change it), >>> but any change should be communicated in advance and perhaps >>> discussed. I actually expect such change to be discussed by the legal >>> body that drives OpenJDK development, not something trivially done >>> with a secret bug report. >>> >>> In this case we are relaxing the licensing restriction may seem a >>> generous and innocent change, and we could be fine with that, but >>> again I still question the method used, an after the fact commit >>> referencing a non accessible bug. >> Jim has fixed the JBS issue, it should not have been created as a restricted >> issue. To my knowledge, the due diligence has been done. > > Hi Alan, > > A change in the License of the Project files should not be addressed > as a restricted bug report. We are not talking about a mistakenly > licensed test case or class file that is rightfully fixed back to the > proper license, we are talking about a total change in License. > > As far as I can see, this is not even about dual licensing the files. > > I'm not fine to the approval of license changes to the OpenJDK Project > without prior written notification from the Governing Board. > > So as an OpenJDK Member I respectfully ask to bring this change to the > attention of the Governing Board. > > Cheers, > Mario > -- > pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF > Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF > > Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens > Proud GNU Classpath developer: http://www.classpath.org/ > OpenJDK: http://openjdk.java.net/projects/caciocavallo/ > > Please, support open standards: > http://endsoftpatents.org/ From paul.sandoz at oracle.com Mon Feb 15 14:52:31 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 15 Feb 2016 15:52:31 +0100 Subject: RFR JDK-8149644 Integrate VarHandles In-Reply-To: <56C1D973.3060802@oracle.com> References: <9C47EF6F-80D6-467E-A5CB-2FDD5FF6AE17@oracle.com> <56C1D973.3060802@oracle.com> Message-ID: <7E6EB6FE-2422-4544-80F9-9939923B4711@oracle.com> > On 15 Feb 2016, at 14:58, Maurizio Cimadamore wrote: > > Langtools changes look ok to me. Thanks! > Would it make sense to file a follow up issue to add some tests in this area (i.e. bytecode tests using the classfile API) ? > Yes, created https://bugs.openjdk.java.net/browse/JDK-8149821 . Paul. From aph at redhat.com Mon Feb 15 14:57:36 2016 From: aph at redhat.com (Andrew Haley) Date: Mon, 15 Feb 2016 14:57:36 +0000 Subject: RFR - JDK-8149776 - BSD license for jimage code In-Reply-To: References: <01051DD5-09AD-45F4-874D-99CBE665056D@oracle.com> <56C19A7E.5080305@redhat.com> <56C1ADC1.9090400@oracle.com> <56C1B840.9020502@oracle.com> Message-ID: <56C1E760.2040809@redhat.com> On 02/15/2016 02:39 PM, James Laskey wrote: > The "restricted bug report" was totally a green horn error made by > me, the author of the code. I wanted to track the end of process > approval for the licensing change by Oracle in the bug and marked it > as confidential since it was an internal comment. Mark will likely > address your concerns when available, but this was purely an error > on my part. Fair enough. But "Allow more liberal use of jimage native code" isn't really the sort of justification which will suffice for such a change. Andrew. From forax at univ-mlv.fr Mon Feb 15 14:58:42 2016 From: forax at univ-mlv.fr (Remi Forax) Date: Mon, 15 Feb 2016 15:58:42 +0100 (CET) Subject: RFR JDK-8149644 Integrate VarHandles In-Reply-To: <56C1D973.3060802@oracle.com> References: <9C47EF6F-80D6-467E-A5CB-2FDD5FF6AE17@oracle.com> <56C1D973.3060802@oracle.com> Message-ID: <1533888573.323371.1455548322267.JavaMail.zimbra@u-pem.fr> Hi all, The comment in Infer "//The return type for a polymorphic signature call" should be updated to reflect the new implementation. and this change in the way to do the inference (if the return type is not Object use the declared return type) is too ad hoc for me, we will need to do the same special case for the parameter types, soon, no ? R?mi ----- Mail original ----- > De: "Maurizio Cimadamore" > ?: "Paul Sandoz" , "hotspot-dev developers" , "jdk9-dev" > > Envoy?: Lundi 15 F?vrier 2016 14:58:11 > Objet: Re: RFR JDK-8149644 Integrate VarHandles > > Langtools changes look ok to me. Would it make sense to file a follow up > issue to add some tests in this area (i.e. bytecode tests using the > classfile API) ? > > Cheers > Maurizio > > On 11/02/16 15:39, Paul Sandoz wrote: > > Hi, > > > > This is the implementation review request for VarHandles. > > > > Langtools: > > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8149644-varhandles-integration/langtools/webrev/index.html > > > > Hotspot: > > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8149644-varhandles-integration/hotspot/webrev/index.html > > > > JDK: > > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8149644-varhandles-integration/jdk/webrev/index.html > > > > The spec/API review is proceeding here [1]. > > > > The patches depend on Unsafe changes [2] and ByteBuffer changes [3]. > > > > Recent (as of today) JPRT runs for core and hotspot tests pass without > > failure. Many parts of the code have been soaking in the Valhalla repo for > > over a year, and it?s been soaking in the sandbox for quite and many a > > JPRT run was performed. > > > > It is planned to push through hs-comp as is the case for the dependent > > patches, and thus minimise any delays due to integration between forests. > > > > > > The Langtools changes are small. Tweaks were made to support updates to > > signature polymorphic methods and where may be located, in addition to > > supporting compilation of calls to MethodHandle.link*. > > > > > > The Hotspot changes are not very large. It?s mostly a matter of augmenting > > checks for MethodHandle to include that for VarHandle. It?s tempting to > > generalise the ?invokehandle" invocation as i believe there are other > > use-cases where it might be useful, but i resisted temptation here. I > > wanted to focus on the minimal changes required. > > > > > > The JDK changes are more substantial, but a large proportion are new tests. > > The source compilation approach taken is to use templates, the same > > approach as for code in the nio package, to generate both implementation > > and test source code. The implementations are generated by the build, the > > tests are pre-generated. I believe the tests should have good coverage but > > we have yet to run any code coverage tool. > > > > The approach to invocation of VarHandle signature polymoprhic methods is > > slightly different to that of MethodHandles. I wanted to ensure that > > linking for the common cases avoids lambda form creation, compilation and > > therefore class spinning. That reduces start up costs and also potential > > circular dependencies that might be induced in the VM boot process if > > VarHandles are employed early on. > > > > For common basic (i.e. erased ref and widened primitive) method signatures, > > namely all those that matter for the efficient atomic operations there are > > pre-generated methods that would otherwise be generated from creating and > > compiling invoker lambda forms. Those methods reside on the > > VarHandleGuards class. When the VM makes an up call to > > MethodHandleNatives.linkMethod to link a call site then this up-called > > method will first check if an appropriate pre-generated method exists on > > VarHandleGuards and if so it links to that, otherwise it falls back to a > > method on a class generated from compiling a lambda form. For testing > > purposes there is a system property available to switch off this > > optimisation when linking [*]. > > > > Each VarHandle instance of the same variable type produced from the same > > factory will share an underlying immutable instance of a VarForm that > > contains a set of MemberName instances, one for each implementation of a > > signature polymorphic method (a value of null means unsupported). The > > invoke methods (on VarHandleGuards or on lambda forms) will statically > > link to such MemberName instances using a call to > > MethodHandle.linkToStatic. > > > > There are a couple of TODOs in comments, those are all on non-critical code > > paths and i plan to chase them up afterwards. > > > > C1 does not support constant folding for @Stable arrays hence why in > > certain cases we have exploded stuff into fields that are operated on > > using if/else loops. We can simplify such code if/when C1 support is > > added. > > > > > > Thanks, > > Paul. > > > > [1] > > http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-January/038150.html > > [2] > > http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2016-January/020953.html > > http://mail.openjdk.java.net/pipermail/hotspot-dev/2016-January/021514.html > > [3] > > http://mail.openjdk.java.net/pipermail/nio-dev/2016-February/003535.html > > > > [*] This technique might be useful for common signatures of MH invokers to > > reduce associated costs of lambda form creation and compilation in the > > interim of something better. > > From adinn at redhat.com Mon Feb 15 15:36:39 2016 From: adinn at redhat.com (Andrew Dinn) Date: Mon, 15 Feb 2016 15:36:39 +0000 Subject: RFR - JDK-8149776 - BSD license for jimage code In-Reply-To: References: <01051DD5-09AD-45F4-874D-99CBE665056D@oracle.com> <56C19A7E.5080305@redhat.com> <56C1ADC1.9090400@oracle.com> <56C1B840.9020502@oracle.com> Message-ID: <56C1F087.1080202@redhat.com> On 15/02/16 14:39, James Laskey wrote: > The "restricted bug report" was totally a green horn error made by > me, the author of the code. I wanted to track the end of process > approval for the licensing change by Oracle in the bug and marked it > as confidential since it was an internal comment. Mark will likely > address your concerns when available, but this was purely an error on > my part. Apologies if my post seemed to suggest that there was any error on your part. I had and have no desire to apportion blame or criticism here. I'll also note two other important things. Firstly, I have no reason in mind to object to this change. Also, I'm not thoroughly relaxed about Oracle employing private JIRAs for some tasks, whether they be changes to proprietary code or special case changes to open code such as security patches etc. There are lots of good reasons why that has to happen. The only general concern I have here -- i.e. beyond the basic request itself -- is that those of us who wish to contribute to the open source code can be aware of why changes are being made and have some confidence that the rationale for them is coherent. For the most part that need is answered by discussion and review on the relevant email lists and I am /very/ happy with how well that works. In any collaborative project such discussion provides a powerful check and balance against potential misunderstanding or error. So, I'm in no way wanting to impose some burdensome level of scrutiny or accountability that would end up making life harder for all of us (bureaucracy is an evil I am always happy to minimise :-). However, absent any prior discussion, I would hope that requesting some context to identify the point of a change is seen as reasonable. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in UK and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (US), Michael O'Neill (Ireland), Paul Argiry (US) From adinn at redhat.com Mon Feb 15 15:40:17 2016 From: adinn at redhat.com (Andrew Dinn) Date: Mon, 15 Feb 2016 15:40:17 +0000 Subject: RFR - JDK-8149776 - BSD license for jimage code In-Reply-To: <56C1F087.1080202@redhat.com> References: <01051DD5-09AD-45F4-874D-99CBE665056D@oracle.com> <56C19A7E.5080305@redhat.com> <56C1ADC1.9090400@oracle.com> <56C1B840.9020502@oracle.com> <56C1F087.1080202@redhat.com> Message-ID: <56C1F161.7070906@redhat.com> Oops excuse the erroneous "not"! On 15/02/16 15:36, Andrew Dinn wrote: > On 15/02/16 14:39, James Laskey wrote: >> The "restricted bug report" was totally a green horn error made by >> me, the author of the code. I wanted to track the end of process >> approval for the licensing change by Oracle in the bug and marked it >> as confidential since it was an internal comment. Mark will likely >> address your concerns when available, but this was purely an error on >> my part. > > Apologies if my post seemed to suggest that there was any error on your > part. I had and have no desire to apportion blame or criticism here. > > I'll also note two other important things. Firstly, I have no reason in > mind to object to this change. Also, I'm not thoroughly relaxed about Also, I'm thoroughly relaxed about > Oracle employing private JIRAs for some tasks, whether they be changes > to proprietary code or special case changes to open code such as > security patches etc. There are lots of good reasons why that has to happen. > > The only general concern I have here -- i.e. beyond the basic request > itself -- is that those of us who wish to contribute to the open source > code can be aware of why changes are being made and have some confidence > that the rationale for them is coherent. For the most part that need is > answered by discussion and review on the relevant email lists and I am > /very/ happy with how well that works. In any collaborative project such > discussion provides a powerful check and balance against potential > misunderstanding or error. So, I'm in no way wanting to impose some > burdensome level of scrutiny or accountability that would end up making > life harder for all of us (bureaucracy is an evil I am always happy to > minimise :-). However, absent any prior discussion, I would hope that > requesting some context to identify the point of a change is seen as > reasonable. > > regards, > > > Andrew Dinn > ----------- > Senior Principal Software Engineer > Red Hat UK Ltd > Registered in UK and Wales under Company Registration No. 3798903 > Directors: Michael Cunningham (US), Michael O'Neill (Ireland), Paul > Argiry (US) > -- regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in UK and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (US), Michael O'Neill (Ireland), Paul Argiry (US) From paul.sandoz at oracle.com Mon Feb 15 16:37:32 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 15 Feb 2016 17:37:32 +0100 Subject: RFR JDK-8149644 Integrate VarHandles In-Reply-To: <1533888573.323371.1455548322267.JavaMail.zimbra@u-pem.fr> References: <9C47EF6F-80D6-467E-A5CB-2FDD5FF6AE17@oracle.com> <56C1D973.3060802@oracle.com> <1533888573.323371.1455548322267.JavaMail.zimbra@u-pem.fr> Message-ID: Hi Remi, > On 15 Feb 2016, at 15:58, Remi Forax wrote: > > Hi all, > > The comment in Infer > "//The return type for a polymorphic signature call" > should be updated to reflect the new implementation. > That comment should really be folded into the first if block. I could do that as follows: // The return type of the polymorphic signature is polymorphic, // and is computed from the ... And then in the else block // The return type of the polymorphic signature is fixed (not polymorphic) ? > and this change in the way to do the inference (if the return type is not Object use the declared return type) is too ad hoc for me, > we will need to do the same special case for the parameter types, soon, no ? > Do you have any use-cases in mind? Rather than ad-hoc i would ague instead the enhancement of signature-polymorphic methods is limited to that required by the current use-cases. IIRC I did pull on that more significantly at one point when i had sub-types for array handles since the index need not be polymorphic. But we dialled back from that approach. Paul. From neugens.limasoftware at gmail.com Mon Feb 15 16:39:34 2016 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Mon, 15 Feb 2016 17:39:34 +0100 Subject: RFR - JDK-8149776 - BSD license for jimage code In-Reply-To: References: <01051DD5-09AD-45F4-874D-99CBE665056D@oracle.com> <56C19A7E.5080305@redhat.com> <56C1ADC1.9090400@oracle.com> <56C1B840.9020502@oracle.com> Message-ID: 2016-02-15 15:39 GMT+01:00 James Laskey : > Mario, > > The "restricted bug report" was totally a green horn error made by me, the author of the code. I wanted to track the end of process approval for the licensing change by Oracle in the bug and marked it as confidential since it was an internal comment. Mark will likely address your concerns when available, but this was purely an error on my part. Hi Jim, Sure, I'm sorry if I sounded overly conservative over this change. I didn't mean to question the change in itself really, and also, according to the bylaw - if I read it correctly - I believe the BSD falls into the list of pre-approved licenses for the Project: http://openjdk.java.net/bylaws#_A So probably this is ok anyway. What I questioned was the way the change has been addressed without context, and I appreciate your statement that this is just a simple mistake. I had an interesting discussion with my colleagues if a License change (specifically one that falls over the pre-approved list of licenses) falls into "normal business", like any other code change or fix, or if it should instead be handled specially as I asked by the GB, so I would still like to have this authoritative answer. That being said, I still would like context for the actual change if possible, I just quote Andrew Dinn reply as to why this is needed: """ The only general concern I have here -- i.e. beyond the basic request itself -- is that those of us who wish to contribute to the open source code can be aware of why changes are being made and have some confidence that the rationale for them is coherent. """ Cheers, Mario > -- Jim > > Sent from my iPhone > >> On Feb 15, 2016, at 9:51 AM, Mario Torre wrote: >> >> 2016-02-15 12:36 GMT+01:00 Alan Bateman : >>>> On 15/02/2016 11:03, Mario Torre wrote: >>>> >>>> Hi Alan, >>>> >>>> I wanted to comment on that too, but Andrew beat me. Anyway this >>>> answer doesn't really tell anything useful and I would like some more >>>> context. >>>> >>>> I understand that Oracle *may* have the rights to change licensing at >>>> any time due to the OCA (although my assumption is more that Oracle >>>> has the right to dual license the code, not arbitrarily change it), >>>> but any change should be communicated in advance and perhaps >>>> discussed. I actually expect such change to be discussed by the legal >>>> body that drives OpenJDK development, not something trivially done >>>> with a secret bug report. >>>> >>>> In this case we are relaxing the licensing restriction may seem a >>>> generous and innocent change, and we could be fine with that, but >>>> again I still question the method used, an after the fact commit >>>> referencing a non accessible bug. >>> Jim has fixed the JBS issue, it should not have been created as a restricted >>> issue. To my knowledge, the due diligence has been done. >> >> Hi Alan, >> >> A change in the License of the Project files should not be addressed >> as a restricted bug report. We are not talking about a mistakenly >> licensed test case or class file that is rightfully fixed back to the >> proper license, we are talking about a total change in License. >> >> As far as I can see, this is not even about dual licensing the files. >> >> I'm not fine to the approval of license changes to the OpenJDK Project >> without prior written notification from the Governing Board. >> >> So as an OpenJDK Member I respectfully ask to bring this change to the >> attention of the Governing Board. >> >> Cheers, >> Mario >> -- >> pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF >> Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF >> >> Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens >> Proud GNU Classpath developer: http://www.classpath.org/ >> OpenJDK: http://openjdk.java.net/projects/caciocavallo/ >> >> Please, support open standards: >> http://endsoftpatents.org/ -- pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens Proud GNU Classpath developer: http://www.classpath.org/ OpenJDK: http://openjdk.java.net/projects/caciocavallo/ Please, support open standards: http://endsoftpatents.org/ From maurizio.cimadamore at oracle.com Mon Feb 15 17:10:35 2016 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 15 Feb 2016 17:10:35 +0000 Subject: RFR JDK-8149644 Integrate VarHandles In-Reply-To: <7E6EB6FE-2422-4544-80F9-9939923B4711@oracle.com> References: <9C47EF6F-80D6-467E-A5CB-2FDD5FF6AE17@oracle.com> <56C1D973.3060802@oracle.com> <7E6EB6FE-2422-4544-80F9-9939923B4711@oracle.com> Message-ID: <56C2068B.5080908@oracle.com> On 15/02/16 14:52, Paul Sandoz wrote: >> On 15 Feb 2016, at 14:58, Maurizio Cimadamore wrote: >> >> Langtools changes look ok to me. > Thanks! > > >> Would it make sense to file a follow up issue to add some tests in this area (i.e. bytecode tests using the classfile API) ? >> > Yes, created https://bugs.openjdk.java.net/browse/JDK-8149821 . > > Paul. Thanks! Maurizio From alejandro.murillo at oracle.com Mon Feb 15 21:46:31 2016 From: alejandro.murillo at oracle.com (Alejandro E Murillo) Date: Mon, 15 Feb 2016 14:46:31 -0700 Subject: jdk9-dev: HotSpot Message-ID: <56C24737.3060206@oracle.com> jdk9-hs-2016-02-11 has been integrated into jdk9-dev. http://hg.openjdk.java.net/jdk9/dev/rev/54575d8783b3 http://hg.openjdk.java.net/jdk9/dev/corba/rev/8ec4f97943fe http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/e37297fef203 http://hg.openjdk.java.net/jdk9/dev/jaxp/rev/65d615f71e81 http://hg.openjdk.java.net/jdk9/dev/jaxws/rev/c072c572d149 http://hg.openjdk.java.net/jdk9/dev/jdk/rev/b3ff4bce9d63 http://hg.openjdk.java.net/jdk9/dev/langtools/rev/dd05d3761a34 http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/d99fa86747ee Component : VM Status : Go for integration Date : 02/16/2016 at 19:00 MSK Tested By : VM SQE &dmitry.fazunenko at oracle.com Bundles : 2016-02-11-215959.amurillo.jdk9-hs-2016-02-11-snapshot Testing: 27 new failures, 323 known failures, 503226 passed. Issues and Notes: No detailed analysis. No stoppers have been detected so far. Go for integration CRs for testing: 6515172: Runtime.availableProcessors() ignores Linux taskset command 8063112: Compiler diagnostic commands should have locking instead of safepoint 8072777: java/lang/ref/ReferenceEnqueuePending.java: some references aren't queued 8079408: Reimplement TraceClassLoading, TraceClassUnloading, and TraceClassLoaderData with Unified Logging. 8132721: Add tests which check that heap counters work as expected during Humongous allocations 8134963: [Newtest] New stress test for changing the coarseness level of G1 remembered set 8135206: VM permits illegal flags for abstract methods in interfaces, versions 45.3 - 51.0 8137049: Code quality: reducing an trivial integer loop does not produce an optimal code 8137314: vm crash from test java/security/Policy/SignedJar/SignedJarTest.java 8138562: Event based tracing should cover monitor inflation 8141278: New tests for PLAB testing 8141421: Various test fail with OOME on win x86 8143608: Don't 64-bit align start of InstanceKlass vtable, itable, and nonstatic_oopmap on 32-bit systems 8143897: Weblogic12medrec assert(handler_address == SharedRuntime::compute_compiled_exc_handler(nm, pc, exception, force_unwind, true)) failed: Must be the same 8144695: --disable-warnings-as-errors does not work for HotSpot build 8144916: Decrease PerfDataMemorySize back to 32K 8145180: Add back PrintGC, PrintGCDetails and -Xloggc 8145190: MinTLABSize can cause overflow problem with CMS GC 8145192: 'count' variable can overflow in PSMarkSweep::invoke on 64 bit JVM 8145628: hotspot metadata classes shouldn't use HeapWordSize or heap related macros like align_object_size 8145740: Visual Studio pragmas should be guarded by ifdef _MSC_VER 8146137: runtime/logging/ExceptionsTest.java fails on embedded and ARM test 8146395: Add inline qualifier in oop.hpp and fix inlining in gc files 8146435: [TESTBUG] Logging tests are failing intermittently on windows when executed by JPRT 8146608: [JVMCI] DebugInfo Tests on DeoptimizeALot runs fails in assert(_pc == *pc_addr || pc == *pc_addr) frame::patch_pc() /frame_x86.cpp:285 8146616: VM exit path throws fatal error: Thread holding lock at safepoint that vm can block on: BeforeExit_lock 8146793: logStream::write re-formats string 8146905: cleanup ostream, staticBufferStream 8146984: SIGBUS: bool Method::has_method_vptr(const void*)+0xc 8146987: Improve Parallel GC Full GC by caching results of live_words_in_range() 8147003: Move BubbleUpRef test into CMS directory 8147087: Race when reusing PerRegionTable bitmaps may result in dropped remembered set entries 8147348: LogTagLevelExpression not properly initialized in configure_stdout 8147447: serviceability/tmtools/jstack/WaitNotifyThreadTest.java test fails 8147461: Use byte offsets for vtable start and vtable length offsets 8147477: com/sun/management/HotSpotDiagnosticMXBean/CheckOrigin.java is failing for the jdk9/hs snapshot control job 8147500: The HashtableTextDump::get_num() should check for integer overflow 8147510: [windows] no text locations shown for register info in hs-err file 8147609: [TESTBUG] Correct the @build statements in the serviceability/dcmd/gc/HeapDumpAllTest.java and HeapDumpTest.java tests 8147814: Move verification code out of g1collectedheap 8147847: [TESTBUG] serviceability/tmtools/jstat test ported to JTREG are failing with -XX:+ExplicitGCInvokesConcurrent 8147884: Names of GC threads should be set before the threads start 8147906: G1 use of os::processor_count() 8147913: Some runtime/CompressedOops tests fail on ARM64 product builds 8147918: Rename develop_log_is_enabled() to log_develop_is_enabled() 8147940: Test gc/g1/TestG1TraceEagerReclaimHumongousObjects.java fails 8148005: One byte may be corrupted by get_datetime_string() 8148047: Move the vtable length field to Klass 8148053: Remove unused log tags 8148104: HSDB could not terminate when launched on CLI 8148141: Remove fixed level padding in UL 8148467: Consistent use of : in the logging 8148470: Metadata print routines should not print to tty 8148481: Devirtualize Klass::vtable 8148507: [JVMCI] mitigate deadlocks related to JVMCI compiler under -Xbatch 8148696: Race loading hsdis may cause SIGSEGV 8148733: G1: Add log message to print the heap region size 8148734: G1: Make G1GCPhaseTimes keep track of the start GC time 8148736: Let the G1 heap transition log regions instead of bytes 8148741: compiler/jvmci/code/SimpleDebugInfoTest.java fails in 'frame::sender_for_compiled_frame' 8148745: [testbug] Test gc/g1/plab/TestPLABPromotion.java fails in nightly 8148747: [TESTBUG] runtime/Unsafe/AllocateMemory.java fails with OOM during compilation 8148752: Compiled StringBuilder code throws StringIndexOutOfBoundsException 8148755: -XX:+HeapDumpAfterFullGC creates heap dump both before and after Full GC 8148758: Compilation fails with "this call site should not be polymorphic" 8148766: Test AvailableProcessors.java got wrong number of processors 8148771: os::active_processor_count() returns garbage which causes VM to crash 8148783: aarch64: SEGV running SpecJBB2013 8148785: Update class file version to 53 for JDK-9 8148844: Update run_unit_test macro for InternalVMTests 8148864: Quarantine CompilerControl tests 8148944: CollectorPolicy methods for memory allocations are specific to GenCollectorPolicy 8148945: JDK-8148481: Devirtualize Klass::vtable breaks Zero build 8148948: aarch64: generate_copy_longs calls align() incorrectly 8148951: Remove unused method Generation::performs_in_place_marking() 8148960: Humongous mis-spelled in log output 8148973: Rename g1/concurrentMark.{hpp,cpp,inline.hpp} to g1/g1ConcurrentMark.{hpp,cpp,inline.hpp} 8148981: remove ResolvedJavaType.getClassFilePath() 8149019: remove redundant modifiers 8149025: JFR - Event based tracing should cover monitor inflation 8149035: Make the full_gc_dump() calls be recorded as part of the GC 8149038: SIGSEGV at frame::is_interpreted_frame_valid -> StubRoutines::SafeFetchN 8149062: Remove misplaced integration of test code after 8149025 8149076: [JVMCI] missing ResourceMark in JVMCIRuntime::initialize_HotSpotJVMCIRuntime 8149080: AArch64: Recognise disjoint array copy in stub code 8149099: jcmd -help mention non-existent option 8149100: AArch64: "bad AD file" for LL enconding AryEq Node matching 8149105: typo in jvmciCodeInstaller.cpp 8149109: [TESTBUG] TestRegisterRestoring.java fails with "VM option 'SafepointALot' is develop" 8149112: configure_stdout test depends on VM arguments 8149135: [jittester] Makefile copies JitTesterDriver in incorrect directory and always uses default value for number-of-tests and seed 8149174: [TESTBUG] TestJcmdDefaults.java: ouput should contain all content of jcmd/usage.out 8149184: os::is_server_class_machine() could return incorrect result if a host's cpu have a few logical cores 8149364: Quarantine TestSelectDefaultGC.java test 8149365: aarch64: memory copy does not prefetch on backwards copy -- Alejandro From forax at univ-mlv.fr Mon Feb 15 22:45:28 2016 From: forax at univ-mlv.fr (Remi Forax) Date: Mon, 15 Feb 2016 23:45:28 +0100 (CET) Subject: RFR JDK-8149644 Integrate VarHandles In-Reply-To: References: <9C47EF6F-80D6-467E-A5CB-2FDD5FF6AE17@oracle.com> <56C1D973.3060802@oracle.com> <1533888573.323371.1455548322267.JavaMail.zimbra@u-pem.fr> Message-ID: <531723180.551702.1455576328083.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Paul Sandoz" > Cc: "jdk9-dev" , "hotspot-dev developers" > Envoy?: Lundi 15 F?vrier 2016 17:37:32 > Objet: Re: RFR JDK-8149644 Integrate VarHandles > > Hi Remi, > > > On 15 Feb 2016, at 15:58, Remi Forax wrote: > > > > Hi all, > > > > The comment in Infer > > "//The return type for a polymorphic signature call" > > should be updated to reflect the new implementation. > > > > That comment should really be folded into the first if block. > > I could do that as follows: > > // The return type of the polymorphic signature is polymorphic, > // and is computed from the ... > > And then in the else block > > // The return type of the polymorphic signature is fixed (not polymorphic) > > ? yes, good idea. > > > > and this change in the way to do the inference (if the return type is not > > Object use the declared return type) is too ad hoc for me, > > we will need to do the same special case for the parameter types, soon, no > > ? > > > > Do you have any use-cases in mind? > > Rather than ad-hoc i would argue instead the enhancement of > signature-polymorphic methods is limited to that required by the current > use-cases. > > IIRC I did pull on that more significantly at one point when i had sub-types > for array handles since the index need not be polymorphic. But we dialled > back from that approach. as you said one use case is to be able to fix an index, but perhaps a more interesting case is to be able to bound the number of parameters, by example for compareAndSet boolean compareAndSet(Object expected, Object value) is better than boolean compareAndSet(Object... args); > > Paul. > R?mi From paul.sandoz at oracle.com Tue Feb 16 09:33:35 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 16 Feb 2016 10:33:35 +0100 Subject: RFR JDK-8149644 Integrate VarHandles In-Reply-To: <531723180.551702.1455576328083.JavaMail.zimbra@u-pem.fr> References: <9C47EF6F-80D6-467E-A5CB-2FDD5FF6AE17@oracle.com> <56C1D973.3060802@oracle.com> <1533888573.323371.1455548322267.JavaMail.zimbra@u-pem.fr> <531723180.551702.1455576328083.JavaMail.zimbra@u-pem.fr> Message-ID: <5ABD11CF-407C-4BAD-95A7-E267C5F1682D@oracle.com> > On 15 Feb 2016, at 23:45, Remi Forax wrote: > >>> The comment in Infer >>> "//The return type for a polymorphic signature call" >>> should be updated to reflect the new implementation. >>> >> >> That comment should really be folded into the first if block. >> >> I could do that as follows: >> >> // The return type of the polymorphic signature is polymorphic, >> // and is computed from the ... >> >> And then in the else block >> >> // The return type of the polymorphic signature is fixed (not polymorphic) >> >> ? > > yes, good idea. > Updated in place. >> >> >>> and this change in the way to do the inference (if the return type is not >>> Object use the declared return type) is too ad hoc for me, >>> we will need to do the same special case for the parameter types, soon, no >>> ? >>> >> >> Do you have any use-cases in mind? >> >> Rather than ad-hoc i would argue instead the enhancement of >> signature-polymorphic methods is limited to that required by the current >> use-cases. >> >> IIRC I did pull on that more significantly at one point when i had sub-types >> for array handles since the index need not be polymorphic. But we dialled >> back from that approach. > > as you said one use case is to be able to fix an index, but perhaps a more interesting case is to be able to bound the number of parameters, > by example for compareAndSet > boolean compareAndSet(Object expected, Object value) > is better than > boolean compareAndSet(Object... args); > That ain?t gonna work because the shape is defined by the factory method producing the var handle, there could be zero or more coordinate arguments preceding zero or more explicit value arguments. We cannot declare a varargs parameter preceding other parameters and declaring Object[] is an awkward fit. It?s more that i would care to bite off in terms of tweaking the definition of signature-polymorphism. Paul.. From dalibor.topic at oracle.com Tue Feb 16 11:13:53 2016 From: dalibor.topic at oracle.com (dalibor topic) Date: Tue, 16 Feb 2016 12:13:53 +0100 Subject: CFV: New JDK 9 Committer: Dmitry Fazunenko In-Reply-To: <56B36771.9000005@oracle.com> References: <56B36771.9000005@oracle.com> Message-ID: <56C30471.4050502@oracle.com> Vote: Yes. -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From adinn at redhat.com Tue Feb 16 21:29:04 2016 From: adinn at redhat.com (Andrew Dinn) Date: Tue, 16 Feb 2016 21:29:04 +0000 Subject: RFR #2 (M) 8148146: Integrate new internal Unsafe entry points, and basic intrinsic support for VarHandles In-Reply-To: <56C1DD24.2060503@redhat.com> References: <56C1C2ED.10702@oracle.com> <56C1D137.5020607@redhat.com> <56C1D764.6020100@oracle.com> <56C1DD24.2060503@redhat.com> Message-ID: <56C394A0.2010606@redhat.com> Hi Aleksey, On 15/02/16 14:13, Andrew Dinn wrote: > It would be very good to run your Unsafe tests. However, they may > still succeed but minus the desired optimizations. So, I'll apply the > patch to my tree and check the generated code by eyeball. I ran the tests with Roland's patch and yours combined and they all passed but I am afraid that's not the full story. The AArch64 optimizations to use stlr for a volatile put and ldar for a volatile get were not performed (the CAS optimzation is still working). What is more the change you have made is actually causing invalid code to be generated for the get operation. This does not relate to Roland's patch. The same result will happen with the code as it was prior to Roland's patch. >> The changes are supposed to generate the same code for old Unsafe >> methods -- the refactoring shuffles the compiler code around, but >> the sequence of accesses/barriers should stay the same. Eyeballing >> x86_64 assembly indeed shows it is the same, but I haven't looked >> beyond x86. Unfortunately, the graphs are not quite the same and that affects the generated code on AArch64 even though it has no visible effect on x86. The critical difference is that for volatile puts and gets you have omitted to insert the MemBarRelease and MemBarAcquire nodes. Note that, unlike x86, AArch64 relies on these barriers to control whether or not memory barrier instructions are inserted. Thats true whether or not the optimization rules are used (by setting -X::+/-UseBarriersForVolatile). If the optimization to use stlr and ldar is switched off (UseBarriersForVolatile=true) then MemBarRelease and MemBarAcquire are translated to the dmb instructions which enforce memory synchronzation. If the optimization is switched on then they are must still be present in order to detect cases where the dmb can be elided and an stlr or ldar used instead. So, unfortunately, your change breaks AArch64 with or without the ldar/stlr optimization scheme. Details of what is wrong and a potential fix are included below. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in UK and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (US), Michael O'Neill (Ireland), Paul Argiry (US) Your changes to the graph layout are as follows: Ignoring GC barriers, the old code generated the following subgraph for an inlined Unsafe.putObjectVolatile A) MemBarRelease MemBarCPUOrder StoreX[mo_release] MemBarVolatile Your new code generates this subgraph B) MemBarCPUOrder StoreX[mo_release] MemBarVolatile Subgraph A is consistent with the following subgraph generated from a Java source level assignment of a volatile field C) MemBarRelease StoreX[mo_release] MemBarVolatile whereas subgraph B is not consistent with C Similarly, for an inlined volatile get the old code generated this subgraph A) MemBarCPUOrder || \\ MemBarAcquire LoadX[mo_acquire] MemBarCPUOrder (the double bars represent control and memory links) Your new code generates the following subgraph B) MemBarCPUOrder || \\ MemBarCPUOrder LoadX[mo_acquire] By contrast the subgraph generated from a Java source level read of a volatile field is C) LoadX[mo_acquire] MemBarAcquire or the minor variant D) LoadX[mo_acquire] DecodeN MemBarAcquire The first change explains why the put tests pass but the optimization fails. The AArch64 predicates which optimize volatile puts look for a StoreX bracketed by a MemBarRelease and MemBarVolatile (they ignore any intervening MemBarCPUOrder). Without the optimization this gets translated to dmb ish {Release} str dmb ish {Volatile} With the optimization generation of both dmbs is inhibited and it gets translated to stlr With your patch the optimizaton fails to apply and the result is str dmb ish {Volatile} which just happens to work but only because the non-optimized code is less than optimal -- in the absence of knowledge as to where the Release or Volatile membars have come from it has to generate two dmb instructions for a volatile put. Now, I could probably tweak the put optimization to recognize your put subgraph B. However, I'm not at all sure that would be valid. I believe that the presence of the MemBarRelease or MemBarAcquire is important because there may potentially be other circumstances where a subgraph of type B might arise. One might simply assume that put subgraph B is fine i.e. the presence of a MemBarCPUOrder and MemBarVolatile bracketing a releasing store is all that is needed to say "yes this is a volatile put". Well, the first gotcha is that the is_release() test will actually return true for certain stores to non-volatile fields. Puts in constructors can be marked as releasing. The second gotcha is that a CPUOrder membar might just happen to turn up as the tail of some other subgraph and a Volatile membar might also appear as head of a third subgraph. So, if they both happened to appear either side of the store you have a false positive for a volatile put. With the get subgraph the problem is more serious. I'm not sure why the tests pass since a required dmb instruction is missing. If my get optimization is switched off both graphs A and C (also variant D) get translated to ldr dmb ish The load is generated as a normal ldr and the Acquire membar is converted to a dmb ish without attempting to see if it can be elided. If the get optimization is enabled the predicate for the LoadX rules detects subgraph A or C (or D) and generates ldar. Similarly, the predicate for the MemBarAcquire rule detects these same 3 subgraphs and elides the dmb. The problem with your subgraph B is that it contains no MemBarAcquire. So the LoadX translates to ldr but nothing triggers the MemBarAcquire rule and no dmb ish is emitted. We end up with a plain ldr which does not enforce the required memory ordering. If you think there is a good reason to change the graph shape the way you have done then I'd be interested to understand your reasoning. It seems reasonable to me for each of the missing memory barriers to be present. I would have said that a volatile put should be releasing and a volatile get should be acquiring so the generated subgraphs should include a MemBarRelease and MemBarAcquire, respectively. If this was just an oversight then the small patch below, when applied over your posted patch, restores both missing barriers (I added 16 lines of context to locate it for you) and also restores the AArch64 optimization. n.b. luckily (or so it would seem given my current possibly misguided understanding of your plans) it turns out that the leading MemBarRelease is not critical as an element of the CAS signature. That's because a CAS is only ever generated by inlining. So, we can be sure that any leading CPUOrder membar (or indeed Release membar if that occurs instead) is only there because it was put there by the inliner. I think that's important for implementing the various flavours of CAS. If we want a CAS which omits either the Release or Acquire semantics then we should be able to omit the leading Release MemBar or tariling Acquire membar (so long as we retain the CPUOrder membars). I'm hoping this fact is going to allow us to implement the optimized CAS variants on AArch64 at least. ----- 8< -------- 8< -------- 8< -------- 8< -------- 8< -------- 8< --- diff -r e51ab854285b src/share/vm/opto/library_call.cpp --- a/src/share/vm/opto/library_call.cpp Tue Feb 16 06:47:18 2016 -0500 +++ b/src/share/vm/opto/library_call.cpp Tue Feb 16 12:46:37 2016 -0500 @@ -2498,32 +2498,35 @@ // We need to emit leading and trailing CPU membars (see below) in // addition to memory membars for special access modes. This is a little // too strong, but avoids the need to insert per-alias-type // volatile membars (for stores; compare Parse::do_put_xxx), which // we cannot do effectively here because we probably only have a // rough approximation of type. switch(kind) { case Relaxed: case Opaque: case Acquire: break; case Release: insert_mem_bar(Op_MemBarRelease); break; case Volatile: + if (is_store) { + insert_mem_bar(Op_MemBarRelease); + } if (!is_store && support_IRIW_for_not_multiple_copy_atomic_cpu) { insert_mem_bar(Op_MemBarVolatile); } break; default: ShouldNotReachHere(); } // Memory barrier to prevent normal and 'unsafe' accesses from // bypassing each other. Happens after null checks, so the // exception paths do not take memory state from the memory barrier, // so there's no problems making a strong assert about mixing users // of safe & unsafe memory. if (need_mem_bar) insert_mem_bar(Op_MemBarCPUOrder); assert(alias_type->adr_type() == TypeRawPtr::BOTTOM || alias_type->adr_type() == TypeOopPtr::BOTTOM || @@ -2636,32 +2639,35 @@ // Final sync IdealKit and GraphKit. final_sync(ideal); #undef __ } } } switch(kind) { case Relaxed: case Opaque: case Release: break; case Acquire: insert_mem_bar(Op_MemBarAcquire); break; case Volatile: + if (!is_store) { + insert_mem_bar(Op_MemBarAcquire); + } if (is_store && !support_IRIW_for_not_multiple_copy_atomic_cpu) { insert_mem_bar(Op_MemBarVolatile); } break; default: ShouldNotReachHere(); } if (need_mem_bar) insert_mem_bar(Op_MemBarCPUOrder); return true; } //----------------------------inline_unsafe_load_store---------------------------- // This method serves a couple of different customers (depending on LoadStoreKind): // From kumar.x.srinivasan at oracle.com Tue Feb 16 21:41:19 2016 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Tue, 16 Feb 2016 13:41:19 -0800 Subject: Feedback on the new doclet. Message-ID: <56C3977F.9000008@oracle.com> Hello everyone, The JEP 221 [1] was integrated into jdk9 b104. This feature significantly changes the javadoc tool and replaces the HTML doclet. Please try it out and let us know, if you observe anything amiss in the generated docs at javadoc-dev at openjdk.java.net. Thanks in advance Kumar Srinivasan [1] http://openjdk.java.net/jeps/221 From kumar.x.srinivasan at oracle.com Tue Feb 16 22:29:21 2016 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Tue, 16 Feb 2016 14:29:21 -0800 Subject: CFV: New JDK 9 Committer: Dmitry Fazunenko In-Reply-To: <56B36771.9000005@oracle.com> References: <56B36771.9000005@oracle.com> Message-ID: <56C3A2C1.1050608@oracle.com> Vote: yes On 2/4/2016 7:00 AM, Jesper Wilhelmsson wrote: > I hereby nominate Dmitry Fazunenko (dfazunen) for JDK 9 Committer. > > Dmitry is a member of the VM SQE team at Oracle and has contributed 13 > changesets [3] to JDK 9. > > Votes are due by 18:00 MSK / 16:00 CET / 10.00 am EST / 7.00 am PT, > Thursday February 18, 2016 > > Only current JDK 9 Committers [1] are eligible to vote on this > nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > /Jesper > > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] List of patches: > > 8132961: JEP 279: Improve Test-Failure Troubleshooting > http://hg.openjdk.java.net/jdk9/hs-rt/rev/4aa2e64eff30 > > 8147003: Move BubbleUpRef test into CMS directory > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/28dcfa2f0275 > > 8134963: [Newtest] New stress test for changing the coarseness level > of G1 remembered set > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/af014cb82e42 > > 8147075: Rename old GC JTreg tests to the new naming scheme > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/c15c0bd51e1d > > 8146889: Update @requires expression for GC tests to run if GC is default > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/66aa15bcceff > > 8016752: [Newtest] regression test for PrintGCDetails and Verbose > flags do not crash when ParOldGC has no memory > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/96cc87bb08f8 > > 8132709: [TESTBUG] gc/g1/TestHumongousShrinkHeap.java might fail on > embedded > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/d750cc39ed60 > > 8073476: G1 logging ignores changes to PrintGC* flags via MXBeans > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/ce8df07dd074 > > 8050464: G1 string deduplication tests hang/timeout and leave running > processes consuming all resources > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/b515190809d5 > > 8055284: sanity/WhiteBox.java fails with NPE > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/1662147c9ca3 > > 8044673: Create jtreg groups to list GC specific tests > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/1abbc1e91ac5 > > 8040250: The test test/gc/parallelScavenge/TestDynShrinkHeap.java > fails with OOME > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/abd312cd8cc2 > > 8039489: Refactor test framework for dynamic VM options > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/8ec72dcefd74 From kumar.x.srinivasan at oracle.com Tue Feb 16 22:29:58 2016 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Tue, 16 Feb 2016 14:29:58 -0800 Subject: CFV: New JDK 9 Reviewer: Anthony Scarpino In-Reply-To: <56BB34E7.6040207@oracle.com> References: <56BB34E7.6040207@oracle.com> Message-ID: <56C3A2E6.2020807@oracle.com> Vote: yes On 2/10/2016 5:02 AM, Sean Mullan wrote: > I hereby nominate Anthony Scarpino to JDK 9 Reviewer. > > Anthony Scarpino is a member of the security libraries team at Oracle. > He has contributed 39 changesets to the JDK 9 Project [3]. He is also > the Author and Owner of JEP 246 (Leverage CPU Instructions for GHASH > and RSA) [4] which has significantly improved cryptographic > performance and has been successfully integrated to JDK 9. > > Votes are due by 24 February 2016, 2:00 PM UTC. > > 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]. > > Sean Mullan > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > [3] > http://hg.openjdk.java.net/jdk9/dev/jdk/log?revcount=1000&rev=author%28%22ascarpin%22%29 > [4] http://openjdk.java.net/jeps/246 From john.r.rose at oracle.com Wed Feb 17 03:30:47 2016 From: john.r.rose at oracle.com (John Rose) Date: Tue, 16 Feb 2016 19:30:47 -0800 Subject: RFR #2 (M) 8148146: Integrate new internal Unsafe entry points, and basic intrinsic support for VarHandles In-Reply-To: <56C1C2ED.10702@oracle.com> References: <56C1C2ED.10702@oracle.com> Message-ID: <3175C589-834C-473B-89BD-8AAD9CBC094B@oracle.com> On Feb 15, 2016, at 4:22 AM, Aleksey Shipilev wrote: > > c) unsafe.cpp gets the basic native method implementations. Most new > operations are folded to their volatile (the strongest) counterparts, > hoping that compilers would intrinsify them into more performant versions. A simpler way to accomplish this would be to give the folded API points non-native method bodies, redirecting to whatever native they are folded to. This will move most of the folding choices up to Java code. A fair amount of movement in unsafe.cpp will disappear. The non-native folded methods would still be marked @HSIC and be optimized accordingly. ? John From erik.joelsson at oracle.com Wed Feb 17 10:02:15 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 17 Feb 2016 11:02:15 +0100 Subject: CFV: New jdk9 Reviewer: Claes Redestad In-Reply-To: <56BCB736.80804@oracle.com> References: <56BCB736.80804@oracle.com> Message-ID: <56C44527.70403@oracle.com> Vote: yes /Erik From erik.joelsson at oracle.com Wed Feb 17 10:02:40 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 17 Feb 2016 11:02:40 +0100 Subject: CFV: New jdk9 Reviewer: Nils Eliasson In-Reply-To: <56BCA5D1.7020202@oracle.com> References: <56BCA5D1.7020202@oracle.com> Message-ID: <56C44540.6080801@oracle.com> Vote: yes /Erik From aleksey.shipilev at oracle.com Wed Feb 17 11:24:58 2016 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Wed, 17 Feb 2016 14:24:58 +0300 Subject: RFR #2 (M) 8148146: Integrate new internal Unsafe entry points, and basic intrinsic support for VarHandles In-Reply-To: <56C394A0.2010606@redhat.com> References: <56C1C2ED.10702@oracle.com> <56C1D137.5020607@redhat.com> <56C1D764.6020100@oracle.com> <56C1DD24.2060503@redhat.com> <56C394A0.2010606@redhat.com> Message-ID: <56C4588A.4070505@oracle.com> On 02/17/2016 12:29 AM, Andrew Dinn wrote: > On 15/02/16 14:13, Andrew Dinn wrote: >>> The changes are supposed to generate the same code for old Unsafe >>> methods -- the refactoring shuffles the compiler code around, but >>> the sequence of accesses/barriers should stay the same. Eyeballing >>> x86_64 assembly indeed shows it is the same, but I haven't looked >>> beyond x86. > > Unfortunately, the graphs are not quite the same and that affects the > generated code on AArch64 even though it has no visible effect on x86. > The critical difference is that for volatile puts and gets you have > omitted to insert the MemBarRelease and MemBarAcquire nodes. Dang. You are right, I have mistranslated the original code. Thanks for catching this one! New version that includes a variant of your fix, and also trims down on Unsafe changes, as John suggested in a separate thread: http://cr.openjdk.java.net/~shade/8148146/webrev.hs.02/ http://cr.openjdk.java.net/~shade/8148146/webrev.jdk.02/ This version still passes JPRT, microbenchmark results are fine. I am respinning other tests to see if anything is broken. Cheers, -Aleksey P.S. Andrew, if you have before/after builds for AArch64 and a suitable physical rig, you might be interested to run Unsafe benchmarks (this is a JMH runnable JAR): http://cr.openjdk.java.net/~shade/varhandles/unsafe-bench.jar From adinn at redhat.com Wed Feb 17 11:30:02 2016 From: adinn at redhat.com (Andrew Dinn) Date: Wed, 17 Feb 2016 11:30:02 +0000 Subject: RFR #2 (M) 8148146: Integrate new internal Unsafe entry points, and basic intrinsic support for VarHandles In-Reply-To: <56C4588A.4070505@oracle.com> References: <56C1C2ED.10702@oracle.com> <56C1D137.5020607@redhat.com> <56C1D764.6020100@oracle.com> <56C1DD24.2060503@redhat.com> <56C394A0.2010606@redhat.com> <56C4588A.4070505@oracle.com> Message-ID: <56C459BA.20509@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 17/02/16 11:24, Aleksey Shipilev wrote: > On 02/17/2016 12:29 AM, Andrew Dinn wrote: >> Unfortunately, the graphs are not quite the same and that >> affects the generated code on AArch64 even though it has no >> visible effect on x86. The critical difference is that for >> volatile puts and gets you have omitted to insert the >> MemBarRelease and MemBarAcquire nodes. > > Dang. You are right, I have mistranslated the original code. > Thanks for catching this one! > > New version that includes a variant of your fix, and also trims > down on Unsafe changes, as John suggested in a separate thread: > http://cr.openjdk.java.net/~shade/8148146/webrev.hs.02/ > http://cr.openjdk.java.net/~shade/8148146/webrev.jdk.02/ > > This version still passes JPRT, microbenchmark results are fine. I > am respinning other tests to see if anything is broken. Thanks, Aleksey. I'll rerun with this new patch and report back. > P.S. Andrew, if you have before/after builds for AArch64 and a > suitable physical rig, you might be interested to run Unsafe > benchmarks (this is a JMH runnable JAR): > http://cr.openjdk.java.net/~shade/varhandles/unsafe-bench.jar Sure, I'll do that too. regards, Andrew Dinn - ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in UK and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (US), Michael O'Neill (Ireland), Paul Argiry (US) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJWxFmwAAoJEGnaNq4xxcSzJgwH/1lGXyxT922uAybjNkv7nhox FbjH/yZndlTlEEq7LkWVISolHg2nudvD65d0PBPMuBU90jRayhLrF3rHCjJy7k6M aD5Elk/rje/p88ZD54sPwfDGJdVGFXQCAx0u/eV6jOhbvGNARlH0EnVtnsV1ADpC BVOsfKOMb55PJWWslaZ9p0vL4zUHDanbcQgUWBpFMg44CDyln4UmyY/xRtPNbWKQ lG7wYc0XAwmG4EKLFDRa2N6PmKSfwubXDOToXR03R/tU5orhWVm7wq+C0FZewodN +91GQvIPlQS4iQ/TZpjX8jAgowFBNxHHAerv1LJcZC7Ji7zGmJnG/Dn5NDKutOw= =oLN2 -----END PGP SIGNATURE----- From adinn at redhat.com Wed Feb 17 12:50:26 2016 From: adinn at redhat.com (Andrew Dinn) Date: Wed, 17 Feb 2016 12:50:26 +0000 Subject: RFR #2 (M) 8148146: Integrate new internal Unsafe entry points, and basic intrinsic support for VarHandles In-Reply-To: <56C459BA.20509@redhat.com> References: <56C1C2ED.10702@oracle.com> <56C1D137.5020607@redhat.com> <56C1D764.6020100@oracle.com> <56C1DD24.2060503@redhat.com> <56C394A0.2010606@redhat.com> <56C4588A.4070505@oracle.com> <56C459BA.20509@redhat.com> Message-ID: <56C46C92.9050609@redhat.com> On 17/02/16 11:30, Andrew Dinn wrote: >> This version still passes JPRT, microbenchmark results are fine. >> I am respinning other tests to see if anything is broken. > > Thanks, Aleksey. I'll rerun with this new patch and report back. This does indeed now generate the correct code on AArch64. As far as I am concerned the patches is fine to ship (with regard to the AArch64 port, that is -- not an official JDK9 review). regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in UK and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (US), Michael O'Neill (Ireland), Paul Argiry (US) From pbenedict at apache.org Wed Feb 17 18:42:26 2016 From: pbenedict at apache.org (Paul Benedict) Date: Wed, 17 Feb 2016 12:42:26 -0600 Subject: Feedback on the new doclet. In-Reply-To: <56C3977F.9000008@oracle.com> References: <56C3977F.9000008@oracle.com> Message-ID: In the new doclet, I can no longer resize the "frames". I know they aren't HTML frames but the ability to resize them is important; the functionality should be restored via scripting. There are long package and class names in the wild. Cheers, Paul On Tue, Feb 16, 2016 at 3:41 PM, Kumar Srinivasan < kumar.x.srinivasan at oracle.com> wrote: > Hello everyone, > > The JEP 221 [1] was integrated into jdk9 b104. This feature > significantly changes the javadoc tool and replaces the HTML doclet. > > Please try it out and let us know, if you observe anything > amiss in the generated docs at javadoc-dev at openjdk.java.net. > > Thanks in advance > Kumar Srinivasan > > [1] http://openjdk.java.net/jeps/221 > > > From vladimir.kozlov at oracle.com Wed Feb 17 19:16:06 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 17 Feb 2016 11:16:06 -0800 Subject: RFR #2 (M) 8148146: Integrate new internal Unsafe entry points, and basic intrinsic support for VarHandles In-Reply-To: <56C4588A.4070505@oracle.com> References: <56C1C2ED.10702@oracle.com> <56C1D137.5020607@redhat.com> <56C1D764.6020100@oracle.com> <56C1DD24.2060503@redhat.com> <56C394A0.2010606@redhat.com> <56C4588A.4070505@oracle.com> Message-ID: <56C4C6F6.8040709@oracle.com> In general it looks good to me. My main question is about implementation of new functionality on other platforms. When it will be done? Yes, it works now because you have guard match_rule_supported(). But we usually do implementation on platforms at least as separate RFE. What is your plan? SAP guys should also test it on PPC64. What test/compiler/unsafe/generate-unsafe-tests.sh is for? It is not used by regression testing as far as I see. And please, push it into hs-comp for nightly testing. Thanks, Vladimir On 2/17/16 3:24 AM, Aleksey Shipilev wrote: > On 02/17/2016 12:29 AM, Andrew Dinn wrote: >> On 15/02/16 14:13, Andrew Dinn wrote: >>>> The changes are supposed to generate the same code for old Unsafe >>>> methods -- the refactoring shuffles the compiler code around, but >>>> the sequence of accesses/barriers should stay the same. Eyeballing >>>> x86_64 assembly indeed shows it is the same, but I haven't looked >>>> beyond x86. >> >> Unfortunately, the graphs are not quite the same and that affects the >> generated code on AArch64 even though it has no visible effect on x86. >> The critical difference is that for volatile puts and gets you have >> omitted to insert the MemBarRelease and MemBarAcquire nodes. > > Dang. You are right, I have mistranslated the original code. Thanks for > catching this one! > > New version that includes a variant of your fix, and also trims down on > Unsafe changes, as John suggested in a separate thread: > http://cr.openjdk.java.net/~shade/8148146/webrev.hs.02/ > http://cr.openjdk.java.net/~shade/8148146/webrev.jdk.02/ > > This version still passes JPRT, microbenchmark results are fine. I am > respinning other tests to see if anything is broken. > > Cheers, > -Aleksey > > P.S. Andrew, if you have before/after builds for AArch64 and a suitable > physical rig, you might be interested to run Unsafe benchmarks (this is > a JMH runnable JAR): > http://cr.openjdk.java.net/~shade/varhandles/unsafe-bench.jar > > From john.r.rose at oracle.com Wed Feb 17 19:42:02 2016 From: john.r.rose at oracle.com (John Rose) Date: Wed, 17 Feb 2016 11:42:02 -0800 Subject: RFR #2 (M) 8148146: Integrate new internal Unsafe entry points, and basic intrinsic support for VarHandles In-Reply-To: <3175C589-834C-473B-89BD-8AAD9CBC094B@oracle.com> References: <56C1C2ED.10702@oracle.com> <3175C589-834C-473B-89BD-8AAD9CBC094B@oracle.com> Message-ID: <2A54ABA8-83ED-46F0-B95D-FD48F1DAB771@oracle.com> One other point: As long as you are massaging the library_call code, you could flush the *_raw versions of all the intrinsics: All we need are the normal intrinsics (GETPUTOOP), not the one-address ones (GETPUTNATIVE), as long as Unsafe class (both of them) redirects one call to the other. The *_raw (NATIVE) intrinsics should have been GC-ed a long time ago, given that the two-address version (OOP) is all anybody needs. To avoid mishaps, a @ForceInline is needed on that kind of wrapper. Mikael's forthcoming Unsafe changes are another place we could handle this cleanup. ? John > On Feb 16, 2016, at 7:30 PM, John Rose wrote: > > On Feb 15, 2016, at 4:22 AM, Aleksey Shipilev wrote: >> >> c) unsafe.cpp gets the basic native method implementations. Most new >> operations are folded to their volatile (the strongest) counterparts, >> hoping that compilers would intrinsify them into more performant versions. > > A simpler way to accomplish this would be to give the folded API points non-native method bodies, redirecting to whatever native they are folded to. > > This will move most of the folding choices up to Java code. A fair amount of movement in unsafe.cpp will disappear. > > The non-native folded methods would still be marked @HSIC and be optimized accordingly. > > ? John From aleksey.shipilev at oracle.com Wed Feb 17 19:42:34 2016 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Wed, 17 Feb 2016 22:42:34 +0300 Subject: RFR #2 (M) 8148146: Integrate new internal Unsafe entry points, and basic intrinsic support for VarHandles In-Reply-To: <56C4C6F6.8040709@oracle.com> References: <56C1C2ED.10702@oracle.com> <56C1D137.5020607@redhat.com> <56C1D764.6020100@oracle.com> <56C1DD24.2060503@redhat.com> <56C394A0.2010606@redhat.com> <56C4588A.4070505@oracle.com> <56C4C6F6.8040709@oracle.com> Message-ID: <56C4CD2A.1000701@oracle.com> On 02/17/2016 10:16 PM, Vladimir Kozlov wrote: > In general it looks good to me. Thanks Vladimir! > My main question is about implementation of new functionality on > other platforms. When it will be done? Yes, it works now because you > have guard match_rule_supported(). But we usually do implementation > on platforms at least as separate RFE. What is your plan? We have multiple subtasks for AArch64, SPARC and Power under VarHandles umbrella: https://bugs.openjdk.java.net/browse/JDK-8080588 Hopefully we will address them after/concurrently-with the bulk of VarHandles changes settle into mainline. But we need to get some basic code in mainline to build on. > SAP guys should also test it on PPC64. Volker, Goetz, I would appreciate if you can give it a spin! > What test/compiler/unsafe/generate-unsafe-tests.sh is for? It is not > used by regression testing as far as I see. The script (re)generates the tests from the template, and is supposed to be run manually when test template had changed. The test/compiler/unsafe/ tests you see in the webrev were generated by that script. > And please, push it into hs-comp for nightly testing. That's was the plan, I should have said that from the beginning. Cheers, -Aleksey From aleksey.shipilev at oracle.com Wed Feb 17 19:46:09 2016 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Wed, 17 Feb 2016 22:46:09 +0300 Subject: RFR #2 (M) 8148146: Integrate new internal Unsafe entry points, and basic intrinsic support for VarHandles In-Reply-To: <2A54ABA8-83ED-46F0-B95D-FD48F1DAB771@oracle.com> References: <56C1C2ED.10702@oracle.com> <3175C589-834C-473B-89BD-8AAD9CBC094B@oracle.com> <2A54ABA8-83ED-46F0-B95D-FD48F1DAB771@oracle.com> Message-ID: <56C4CE01.7060805@oracle.com> Our hands were itching to remove these "duplicate" Unsafe methods for a while now. But I think these cleanups should really be done separately to catch mistakes. I'd like to keep this particular RFR for VarHandle-specific entries only. Cheers, -Aleksey On 02/17/2016 10:42 PM, John Rose wrote: > One other point: As long as you are massaging the library_call code, > you could flush the *_raw versions of all the intrinsics: All we need > are the normal intrinsics (GETPUTOOP), not the one-address ones > (GETPUTNATIVE), as long as Unsafe class (both of them) redirects > one call to the other. > > The *_raw (NATIVE) intrinsics should have been GC-ed a long time ago, > given that the two-address version (OOP) is all anybody needs. > > To avoid mishaps, a @ForceInline is needed on that kind of wrapper. > > Mikael's forthcoming Unsafe changes are another place we could > handle this cleanup. > > ? John > >> On Feb 16, 2016, at 7:30 PM, John Rose wrote: >> >> On Feb 15, 2016, at 4:22 AM, Aleksey Shipilev wrote: >>> >>> c) unsafe.cpp gets the basic native method implementations. Most new >>> operations are folded to their volatile (the strongest) counterparts, >>> hoping that compilers would intrinsify them into more performant versions. >> >> A simpler way to accomplish this would be to give the folded API points non-native method bodies, redirecting to whatever native they are folded to. >> >> This will move most of the folding choices up to Java code. A fair amount of movement in unsafe.cpp will disappear. >> >> The non-native folded methods would still be marked @HSIC and be optimized accordingly. >> >> ? John > From vladimir.kozlov at oracle.com Wed Feb 17 19:48:00 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 17 Feb 2016 11:48:00 -0800 Subject: RFR #2 (M) 8148146: Integrate new internal Unsafe entry points, and basic intrinsic support for VarHandles In-Reply-To: <56C4CE01.7060805@oracle.com> References: <56C1C2ED.10702@oracle.com> <3175C589-834C-473B-89BD-8AAD9CBC094B@oracle.com> <2A54ABA8-83ED-46F0-B95D-FD48F1DAB771@oracle.com> <56C4CE01.7060805@oracle.com> Message-ID: <56C4CE70.7030203@oracle.com> I agree with Aleksey. Clean up should be done separately, please, file RFE. This changes are already big. Thanks, Vladimir On 2/17/16 11:46 AM, Aleksey Shipilev wrote: > Our hands were itching to remove these "duplicate" Unsafe methods for a > while now. But I think these cleanups should really be done separately > to catch mistakes. I'd like to keep this particular RFR for > VarHandle-specific entries only. > > Cheers, > -Aleksey > > On 02/17/2016 10:42 PM, John Rose wrote: >> One other point: As long as you are massaging the library_call code, >> you could flush the *_raw versions of all the intrinsics: All we need >> are the normal intrinsics (GETPUTOOP), not the one-address ones >> (GETPUTNATIVE), as long as Unsafe class (both of them) redirects >> one call to the other. >> >> The *_raw (NATIVE) intrinsics should have been GC-ed a long time ago, >> given that the two-address version (OOP) is all anybody needs. >> >> To avoid mishaps, a @ForceInline is needed on that kind of wrapper. >> >> Mikael's forthcoming Unsafe changes are another place we could >> handle this cleanup. >> >> ? John >> >>> On Feb 16, 2016, at 7:30 PM, John Rose wrote: >>> >>> On Feb 15, 2016, at 4:22 AM, Aleksey Shipilev wrote: >>>> >>>> c) unsafe.cpp gets the basic native method implementations. Most new >>>> operations are folded to their volatile (the strongest) counterparts, >>>> hoping that compilers would intrinsify them into more performant versions. >>> >>> A simpler way to accomplish this would be to give the folded API points non-native method bodies, redirecting to whatever native they are folded to. >>> >>> This will move most of the folding choices up to Java code. A fair amount of movement in unsafe.cpp will disappear. >>> >>> The non-native folded methods would still be marked @HSIC and be optimized accordingly. >>> >>> ? John >> > > From lana.steuck at oracle.com Wed Feb 17 20:52:19 2016 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 17 Feb 2016 12:52:19 -0800 (PST) Subject: jdk9-b106: dev Message-ID: <201602172052.u1HKqJvU019752@sc11152554.us.oracle.com> http://hg.openjdk.java.net/jdk9/jdk9/rev/54575d8783b3 http://hg.openjdk.java.net/jdk9/jdk9/nashorn/rev/cfb316745693 http://hg.openjdk.java.net/jdk9/jdk9/langtools/rev/dd05d3761a34 http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/6e9ecae50b4e http://hg.openjdk.java.net/jdk9/jdk9/jaxws/rev/c072c572d149 http://hg.openjdk.java.net/jdk9/jdk9/jaxp/rev/65d615f71e81 http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/7232de4c17c3 http://hg.openjdk.java.net/jdk9/jdk9/corba/rev/8ec4f97943fe --- All the fixes will be tested during promotion (no PIT testing at this point): List of all fixes: =================== JDK-7071819 core-libs To support Extended Grapheme Clusters in Regex JDK-8046339 core-libs sun.rmi.transport.DGCAckHandler leaks memory JDK-8071368 core-libs Use more concrete types for NamedFunction constants in the code JDK-8134424 core-libs BlockDataInputStream.readUTFBody: size local StringBuffer with the giv JDK-8138884 core-libs MethodHandles.Lookup.findVirtual() Javadoc fails to consider private i JDK-8139529 core-libs java.time.temporal.ChronoUnit.FOREVER typo JDK-8140211 core-libs Example in the Documentation is wrong for java.time.ZonedDateTime.minu JDK-8141209 core-libs $EXEC should allow streaming JDK-8142539 core-libs Incorrect definition of ZoneOffset.MIN JDK-8147531 core-libs To add named character construct \N{...} to support Unicode name prope JDK-8148446 core-libs (tz) Support tzdata2016a JDK-8148570 core-libs TzdbZoneRulesCompiler.java throws Null Pointer Exception While Compili JDK-8149391 core-libs Fix module dependences in java/util tests JDK-8149459 core-libs StringConcatFactory should be synced up with LambdaMetafactory JDK-8149462 core-libs revert changes for 8149186 JDK-8149492 core-libs Problem list CheckEncodings.sh JDK-8149529 core-libs Adapt SAP copyrights to new company name in jdk repository JDK-8149653 core-libs Move sun.misc.InnocuousThread to jdk.internal.misc JDK-8149656 core-libs Examine usages of sun.misc.LRUCache JDK-8149665 core-libs $EXEC changes clean up JDK-8149744 core-libs fix testng.jar delivery in Nashorn build.xml JDK-8149787 core-libs test/java/util/regex/GraphemeTest.java source file has non-ascii chara JDK-8149616 core-svc Problem list RmiSslBootstrapTest.sh JDK-8003585 hotspot strength reduce or eliminate range checks for power-of-two sized array JDK-8146478 hotspot Node limit exceeded with -XX:AllocateInstancePrefetchLines=1073741823 JDK-8147645 hotspot get_ctrl_no_update() code is wrong JDK-8148012 hotspot get rid of slash-dot-dot in @library directives JDK-8148328 hotspot aarch64: redundant lsr instructions in stub code JDK-8148490 hotspot RegisterSaver::restore_live_registers() fails to restore xmm registers JDK-8148751 hotspot [TESTBUG] compiler/whitebox/AllocationCodeBlobTest.java fails due to u JDK-8148753 hotspot Compilation fails due to field accesses on array types JDK-8148970 hotspot Quarantine testlibrary_tests/whitebox/vm_flags/IntxTest.java JDK-8145789 infrastructure Switch JDK 9 to use Jib in JPRT JDK-8147754 infrastructure Configure fails to detect freetype installed by XQuartz on OSX 10.11 JDK-8149116 infrastructure Make test/Makefile more silent JDK-8149479 infrastructure Fix compare.sh to have a clean baseline with COMPARE_BUILD JDK-8149647 infrastructure Incremental enhancements from build-infra JDK-8149601 other-libs Update references from "1.9" to "9" JDK-8059212 security-libs Modify sun/security/smartcardio manual regression tests so that they d JDK-8146138 tools jshell tool: add /help JDK-8147495 tools jshell tool: correctly handle arguments on /seteditor command JDK-8147801 tools java.nio.file.ClosedFileSystemException when using Javadoc API's in JD JDK-8147886 tools jshell tool: commands don't allow reference to start-up or explicit id JDK-8147887 tools jshell tool: /list start -- fails JDK-8147898 tools jshell tool: /reload quiet -- should quiet echo JDK-8148400 tools Decrease the regression test heap. JDK-8148808 tools javac, remove unused options, step 1 JDK-8149160 tools use StringJoiner in sjavac option handling JDK-8149776 tools BSD license for jimage code JDK-8148861 xml Update jaxws to use the new non-inheriting thread-local Thread constru From volker.simonis at gmail.com Thu Feb 18 07:47:36 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 18 Feb 2016 08:47:36 +0100 Subject: RFR #2 (M) 8148146: Integrate new internal Unsafe entry points, and basic intrinsic support for VarHandles In-Reply-To: <56C4CD2A.1000701@oracle.com> References: <56C1C2ED.10702@oracle.com> <56C1D137.5020607@redhat.com> <56C1D764.6020100@oracle.com> <56C1DD24.2060503@redhat.com> <56C394A0.2010606@redhat.com> <56C4588A.4070505@oracle.com> <56C4C6F6.8040709@oracle.com> <56C4CD2A.1000701@oracle.com> Message-ID: On Wed, Feb 17, 2016 at 8:42 PM, Aleksey Shipilev wrote: > On 02/17/2016 10:16 PM, Vladimir Kozlov wrote: >> In general it looks good to me. > > Thanks Vladimir! > >> My main question is about implementation of new functionality on >> other platforms. When it will be done? Yes, it works now because you >> have guard match_rule_supported(). But we usually do implementation >> on platforms at least as separate RFE. What is your plan? > > We have multiple subtasks for AArch64, SPARC and Power under VarHandles > umbrella: > https://bugs.openjdk.java.net/browse/JDK-8080588 > > Hopefully we will address them after/concurrently-with the bulk of > VarHandles changes settle into mainline. But we need to get some basic > code in mainline to build on. > > >> SAP guys should also test it on PPC64. > > Volker, Goetz, I would appreciate if you can give it a spin! > Sorry, I only saw this thread yesterday. I'll start now right away with looking into it and testing it on ppc64. Regards, Volker > >> What test/compiler/unsafe/generate-unsafe-tests.sh is for? It is not >> used by regression testing as far as I see. > > The script (re)generates the tests from the template, and is supposed to > be run manually when test template had changed. The > test/compiler/unsafe/ tests you see in the webrev were generated by that > script. > >> And please, push it into hs-comp for nightly testing. > > That's was the plan, I should have said that from the beginning. > > Cheers, > -Aleksey > From mikael.vidstedt at oracle.com Thu Feb 18 19:22:47 2016 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Thu, 18 Feb 2016 11:22:47 -0800 Subject: RFR (M): 8149159: Clean up Unsafe Message-ID: <56C61A07.4010604@oracle.com> Please review the following change which does some relatively significant cleaning up of the Unsafe implementation. Bug: https://bugs.openjdk.java.net/browse/JDK-8149159 Webrev (hotspot): http://cr.openjdk.java.net/~mikael/webrevs/8149159_unsafecleanup/hotspot/webrev.00/webrev/ Webrev (jdk): http://cr.openjdk.java.net/~mikael/webrevs/8149159_unsafecleanup/jdk/webrev.00/webrev/ Summary: * To avoid code duplication sun.misc.Unsafe now delegates all work to jdk.internal.misc.Unsafe. This also means that the VM - and unsafe.cpp specifically - no longer needs to know or care about s.m.Unsafe. * The s.m.Unsafe delegation methods have all been decorated with @ForceInline to minimize the risk of performance regressions, though it is highly likely that they will be inlined even without the annotations. * The documentation has been updated to reflect that it is the responsibility of the user of Unsafe to make sure arguments are valid. * The argument checking has, to the extent possible, been moved from unsafe.cpp up to Java to simplify the native code and allow the JIT to optimize it. * Some of the argument checks have been relaxed. For example, the recently introduced U.copySwapMemory does not check for null pointers anymore. See docs for j.i.m.U.checkPointer for the complete reasoning behind this. Note that the Unsafe methods today, apart from U.copySwapMemory, do not perform the NULL related check(s). * A test was added for j.i.m.U.copyMemory, based on U.copySwapMemory. Feel free to point out that I should merge them (because I should). Also, unsafe.cpp was cleaned up rather dramatically. Some specific highlights: * Unsafe_ functions are now declared static, as are the other unsafe.cpp local functions. * Created unsafe.hpp and moved some functions used in other parts of the VM to that. Removed some "extern" function declarations (extern is bad, kittens die when extern is (over-)used). * Remove scary looking comment about UNSAFE_LEAF not being possible to use - there's nothing special about it, it's just a JVM_LEAF. * Used UNSAFE_LEAF for a few simple leaf methods * Added helpful braces around UNSAFE_ENTRY/UNSAFE_END to help auto-indent * Removed unused Unsafe_<...>##140 functions/macros * Updated macro argument names to be consistent throughout unsafe.cpp macro definitions * Replaced some checks with asserts - as per above the checks are now performed in j.i.m.Unsafe instead. * Removed all the s.m.Unsafe related code Testing: * jtreg: hotspot_jprt group, jdk/internal * JPRT: hotspot testset * Perf: JMH unsafe-bench.jar (no significant changes) I'm taking suggestions on additional things to test. Cheers, Mikael From vladimir.kozlov at oracle.com Thu Feb 18 21:52:33 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 18 Feb 2016 13:52:33 -0800 Subject: RFR (M): 8149159: Clean up Unsafe In-Reply-To: <56C61A07.4010604@oracle.com> References: <56C61A07.4010604@oracle.com> Message-ID: <56C63D21.8000403@oracle.com> Hotspot changes looks fine. Nice cleanup! What was changed in interfaceSupport.hpp (it is empty in webrev)? Thanks, Vladimir On 2/18/16 11:22 AM, Mikael Vidstedt wrote: > > Please review the following change which does some relatively significant cleaning up of the Unsafe implementation. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8149159 > Webrev (hotspot): http://cr.openjdk.java.net/~mikael/webrevs/8149159_unsafecleanup/hotspot/webrev.00/webrev/ > Webrev (jdk): http://cr.openjdk.java.net/~mikael/webrevs/8149159_unsafecleanup/jdk/webrev.00/webrev/ > > Summary: > > * To avoid code duplication sun.misc.Unsafe now delegates all work to jdk.internal.misc.Unsafe. This also means that the > VM - and unsafe.cpp specifically - no longer needs to know or care about s.m.Unsafe. > * The s.m.Unsafe delegation methods have all been decorated with @ForceInline to minimize the risk of performance > regressions, though it is highly likely that they will be inlined even without the annotations. > * The documentation has been updated to reflect that it is the responsibility of the user of Unsafe to make sure > arguments are valid. > * The argument checking has, to the extent possible, been moved from unsafe.cpp up to Java to simplify the native code > and allow the JIT to optimize it. > * Some of the argument checks have been relaxed. For example, the recently introduced U.copySwapMemory does not check > for null pointers anymore. See docs for j.i.m.U.checkPointer for the complete reasoning behind this. Note that the > Unsafe methods today, apart from U.copySwapMemory, do not perform the NULL related check(s). > * A test was added for j.i.m.U.copyMemory, based on U.copySwapMemory. Feel free to point out that I should merge them > (because I should). > > Also, unsafe.cpp was cleaned up rather dramatically. Some specific highlights: > > * Unsafe_ functions are now declared static, as are the other unsafe.cpp local functions. > * Created unsafe.hpp and moved some functions used in other parts of the VM to that. Removed some "extern" function > declarations (extern is bad, kittens die when extern is (over-)used). > * Remove scary looking comment about UNSAFE_LEAF not being possible to use - there's nothing special about it, it's just > a JVM_LEAF. > * Used UNSAFE_LEAF for a few simple leaf methods > * Added helpful braces around UNSAFE_ENTRY/UNSAFE_END to help auto-indent > * Removed unused Unsafe_<...>##140 functions/macros > * Updated macro argument names to be consistent throughout unsafe.cpp macro definitions > * Replaced some checks with asserts - as per above the checks are now performed in j.i.m.Unsafe instead. > * Removed all the s.m.Unsafe related code > > > Testing: > > * jtreg: hotspot_jprt group, jdk/internal > * JPRT: hotspot testset > * Perf: JMH unsafe-bench.jar (no significant changes) > > I'm taking suggestions on additional things to test. > > Cheers, > Mikael > From mikael.vidstedt at oracle.com Thu Feb 18 22:13:52 2016 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Thu, 18 Feb 2016 14:13:52 -0800 Subject: RFR (M): 8149159: Clean up Unsafe In-Reply-To: <56C63D21.8000403@oracle.com> References: <56C61A07.4010604@oracle.com> <56C63D21.8000403@oracle.com> Message-ID: <56C64220.3070209@oracle.com> There's are indentation changes of two of the backslashes for the JNI_ENTRY_NO_PRESERVE macro definition to align them with the other backslashes. I noticed that a similar change is needed for JNI_QUICK_ENTRY and JNI_LEAF. Arguably it should be done as a separate change, but I'm not sure it's worth the overhead... Cheers, Mikael On 2016-02-18 13:52, Vladimir Kozlov wrote: > Hotspot changes looks fine. Nice cleanup! What was changed in > interfaceSupport.hpp (it is empty in webrev)? > > Thanks, > Vladimir > > On 2/18/16 11:22 AM, Mikael Vidstedt wrote: >> >> Please review the following change which does some relatively >> significant cleaning up of the Unsafe implementation. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8149159 >> Webrev (hotspot): >> http://cr.openjdk.java.net/~mikael/webrevs/8149159_unsafecleanup/hotspot/webrev.00/webrev/ >> Webrev (jdk): >> http://cr.openjdk.java.net/~mikael/webrevs/8149159_unsafecleanup/jdk/webrev.00/webrev/ >> >> Summary: >> >> * To avoid code duplication sun.misc.Unsafe now delegates all work to >> jdk.internal.misc.Unsafe. This also means that the >> VM - and unsafe.cpp specifically - no longer needs to know or care >> about s.m.Unsafe. >> * The s.m.Unsafe delegation methods have all been decorated with >> @ForceInline to minimize the risk of performance >> regressions, though it is highly likely that they will be inlined >> even without the annotations. >> * The documentation has been updated to reflect that it is the >> responsibility of the user of Unsafe to make sure >> arguments are valid. >> * The argument checking has, to the extent possible, been moved from >> unsafe.cpp up to Java to simplify the native code >> and allow the JIT to optimize it. >> * Some of the argument checks have been relaxed. For example, the >> recently introduced U.copySwapMemory does not check >> for null pointers anymore. See docs for j.i.m.U.checkPointer for the >> complete reasoning behind this. Note that the >> Unsafe methods today, apart from U.copySwapMemory, do not perform the >> NULL related check(s). >> * A test was added for j.i.m.U.copyMemory, based on U.copySwapMemory. >> Feel free to point out that I should merge them >> (because I should). >> >> Also, unsafe.cpp was cleaned up rather dramatically. Some specific >> highlights: >> >> * Unsafe_ functions are now declared static, as are the other >> unsafe.cpp local functions. >> * Created unsafe.hpp and moved some functions used in other parts of >> the VM to that. Removed some "extern" function >> declarations (extern is bad, kittens die when extern is (over-)used). >> * Remove scary looking comment about UNSAFE_LEAF not being possible >> to use - there's nothing special about it, it's just >> a JVM_LEAF. >> * Used UNSAFE_LEAF for a few simple leaf methods >> * Added helpful braces around UNSAFE_ENTRY/UNSAFE_END to help >> auto-indent >> * Removed unused Unsafe_<...>##140 functions/macros >> * Updated macro argument names to be consistent throughout unsafe.cpp >> macro definitions >> * Replaced some checks with asserts - as per above the checks are now >> performed in j.i.m.Unsafe instead. >> * Removed all the s.m.Unsafe related code >> >> >> Testing: >> >> * jtreg: hotspot_jprt group, jdk/internal >> * JPRT: hotspot testset >> * Perf: JMH unsafe-bench.jar (no significant changes) >> >> I'm taking suggestions on additional things to test. >> >> Cheers, >> Mikael >> From john.r.rose at oracle.com Fri Feb 19 03:09:22 2016 From: john.r.rose at oracle.com (John Rose) Date: Thu, 18 Feb 2016 19:09:22 -0800 Subject: RFR (M): 8149159: Clean up Unsafe In-Reply-To: <56C61A07.4010604@oracle.com> References: <56C61A07.4010604@oracle.com> Message-ID: <1E1E7B1F-516C-413E-95CC-7EFCAF3B546B@oracle.com> This is good. Reviewed, except for any further discussion (if needed) on extra checks in copyMemory. The copyMemory intrinsic gets a little extra error checking, since copyMemory0 is the intrinsic, but cannot be accessed without the copyMemoryChecks. (I see it's tested by CopyMemory.testNegative.) It should not be a performance problem, except perhaps for very short arrays. If there's a problem we can consider putting the @HSIC annotation on the wrapper (in which case the testNegative will also have to go away). I'm *not* in favor of any systematic upgrade of argument testing on the Unsafe API. If you sign up for Unsafe coding, you check your arguments yourself, or take the consequences, as your new Javadoc so eloquently states. This could be a separate bug, but these one-address access methods are totally obsolete: @ForceInline public float getFloat(long address) { return theInternalUnsafe.getFloat(address); } They should be recoded in terms of their more "modern" two-address equivalents: @ForceInline public float getFloat(long address) { return theInternalUnsafe.getFloat(null, address); } And then (soon please?) we can remove them from the "real" Unsafe and from the vmIntrinsics list, and nuke all the DEFINE_GETSETNATIVE entry points in unsafe.cpp. (?And their place shall know them no more.) BTW, for Panama we want the two-address versions for loading and storing machine words: getAddress(oop,long) and putAddress(oop,long,long), but not the old one-address versions. (This will allow us to work with native data structures both on-heap and off-heap.) ? John On Feb 18, 2016, at 11:22 AM, Mikael Vidstedt wrote: > > > Please review the following change which does some relatively significant cleaning up of the Unsafe implementation. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8149159 > Webrev (hotspot): http://cr.openjdk.java.net/~mikael/webrevs/8149159_unsafecleanup/hotspot/webrev.00/webrev/ > Webrev (jdk): http://cr.openjdk.java.net/~mikael/webrevs/8149159_unsafecleanup/jdk/webrev.00/webrev/ > > Summary: > > * To avoid code duplication sun.misc.Unsafe now delegates all work to jdk.internal.misc.Unsafe. This also means that the VM - and unsafe.cpp specifically - no longer needs to know or care about s.m.Unsafe. > * The s.m.Unsafe delegation methods have all been decorated with @ForceInline to minimize the risk of performance regressions, though it is highly likely that they will be inlined even without the annotations. > * The documentation has been updated to reflect that it is the responsibility of the user of Unsafe to make sure arguments are valid. > * The argument checking has, to the extent possible, been moved from unsafe.cpp up to Java to simplify the native code and allow the JIT to optimize it. > * Some of the argument checks have been relaxed. For example, the recently introduced U.copySwapMemory does not check for null pointers anymore. See docs for j.i.m.U.checkPointer for the complete reasoning behind this. Note that the Unsafe methods today, apart from U.copySwapMemory, do not perform the NULL related check(s). > * A test was added for j.i.m.U.copyMemory, based on U.copySwapMemory. Feel free to point out that I should merge them (because I should). > > Also, unsafe.cpp was cleaned up rather dramatically. Some specific highlights: > > * Unsafe_ functions are now declared static, as are the other unsafe.cpp local functions. > * Created unsafe.hpp and moved some functions used in other parts of the VM to that. Removed some "extern" function declarations (extern is bad, kittens die when extern is (over-)used). > * Remove scary looking comment about UNSAFE_LEAF not being possible to use - there's nothing special about it, it's just a JVM_LEAF. > * Used UNSAFE_LEAF for a few simple leaf methods > * Added helpful braces around UNSAFE_ENTRY/UNSAFE_END to help auto-indent > * Removed unused Unsafe_<...>##140 functions/macros > * Updated macro argument names to be consistent throughout unsafe.cpp macro definitions > * Replaced some checks with asserts - as per above the checks are now performed in j.i.m.Unsafe instead. > * Removed all the s.m.Unsafe related code > > > Testing: > > * jtreg: hotspot_jprt group, jdk/internal > * JPRT: hotspot testset > * Perf: JMH unsafe-bench.jar (no significant changes) > > I'm taking suggestions on additional things to test. > > Cheers, > Mikael > From aliedperezmartinez at gmail.com Fri Feb 19 01:51:47 2016 From: aliedperezmartinez at gmail.com (=?UTF-8?Q?Alied_P=c3=a9rez_Mart=c3=adnez?=) Date: Thu, 18 Feb 2016 22:51:47 -0300 Subject: corrupted reposirory? Message-ID: <56C67533.7050004@gmail.com> Hi: I'mtrying to clone the jdk repository but I'm unable to do so. Is there any issue? alied at development:~/NetBeansProjects$ hg clone http://hg.openjdk.java.net/jdk9/jdk9 jdk9 requesting all changes adding changesets adding manifests adding file changes transaction abort! rollback completed abort: stream ended unexpectedly (got 18609 bytes, expected 207386) the got bytes vary each time. Regards. Saludos desde la Argentina Alied From david.holmes at oracle.com Fri Feb 19 04:04:48 2016 From: david.holmes at oracle.com (David Holmes) Date: Fri, 19 Feb 2016 14:04:48 +1000 Subject: corrupted reposirory? In-Reply-To: <56C67533.7050004@gmail.com> References: <56C67533.7050004@gmail.com> Message-ID: <56C69460.8080302@oracle.com> On 19/02/2016 11:51 AM, Alied P?rez Mart?nez wrote: > Hi: > I'mtrying to clone the jdk repository but I'm unable to do so. Is there > any issue? Seems to be fine now. Probably just a transient error with the network. David > alied at development:~/NetBeansProjects$ hg clone > http://hg.openjdk.java.net/jdk9/jdk9 jdk9 > requesting all changes > adding changesets > adding manifests > adding file > changes > transaction > abort! > rollback > completed > abort: stream ended unexpectedly (got 18609 bytes, expected 207386) > > > the got bytes vary each time. > > Regards. > Saludos desde la Argentina > Alied > From chris.hegarty at oracle.com Fri Feb 19 07:20:40 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 19 Feb 2016 07:20:40 +0000 Subject: RFR (M): 8149159: Clean up Unsafe In-Reply-To: <56C61A07.4010604@oracle.com> References: <56C61A07.4010604@oracle.com> Message-ID: Thanks for doing this Mikael. The removal of explicit knowledge of sun.misc.Unsafe from the VM, and the delegation to the ?real? Unsafe is a nice cleanup ( arguably could have been done this way originally ;-) ). Making it clear that argument checking is the callers responsibility seems like the right thing to do. -Chris. On 18 Feb 2016, at 19:22, Mikael Vidstedt wrote: > > Please review the following change which does some relatively significant cleaning up of the Unsafe implementation. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8149159 > Webrev (hotspot): http://cr.openjdk.java.net/~mikael/webrevs/8149159_unsafecleanup/hotspot/webrev.00/webrev/ > Webrev (jdk): http://cr.openjdk.java.net/~mikael/webrevs/8149159_unsafecleanup/jdk/webrev.00/webrev/ > > Summary: > > * To avoid code duplication sun.misc.Unsafe now delegates all work to jdk.internal.misc.Unsafe. This also means that the VM - and unsafe.cpp specifically - no longer needs to know or care about s.m.Unsafe. > * The s.m.Unsafe delegation methods have all been decorated with @ForceInline to minimize the risk of performance regressions, though it is highly likely that they will be inlined even without the annotations. > * The documentation has been updated to reflect that it is the responsibility of the user of Unsafe to make sure arguments are valid. > * The argument checking has, to the extent possible, been moved from unsafe.cpp up to Java to simplify the native code and allow the JIT to optimize it. > * Some of the argument checks have been relaxed. For example, the recently introduced U.copySwapMemory does not check for null pointers anymore. See docs for j.i.m.U.checkPointer for the complete reasoning behind this. Note that the Unsafe methods today, apart from U.copySwapMemory, do not perform the NULL related check(s). > * A test was added for j.i.m.U.copyMemory, based on U.copySwapMemory. Feel free to point out that I should merge them (because I should). > > Also, unsafe.cpp was cleaned up rather dramatically. Some specific highlights: > > * Unsafe_ functions are now declared static, as are the other unsafe.cpp local functions. > * Created unsafe.hpp and moved some functions used in other parts of the VM to that. Removed some "extern" function declarations (extern is bad, kittens die when extern is (over-)used). > * Remove scary looking comment about UNSAFE_LEAF not being possible to use - there's nothing special about it, it's just a JVM_LEAF. > * Used UNSAFE_LEAF for a few simple leaf methods > * Added helpful braces around UNSAFE_ENTRY/UNSAFE_END to help auto-indent > * Removed unused Unsafe_<...>##140 functions/macros > * Updated macro argument names to be consistent throughout unsafe.cpp macro definitions > * Replaced some checks with asserts - as per above the checks are now performed in j.i.m.Unsafe instead. > * Removed all the s.m.Unsafe related code > > > Testing: > > * jtreg: hotspot_jprt group, jdk/internal > * JPRT: hotspot testset > * Perf: JMH unsafe-bench.jar (no significant changes) > > I'm taking suggestions on additional things to test. > > Cheers, > Mikael > From david.lindholm at oracle.com Fri Feb 19 08:13:11 2016 From: david.lindholm at oracle.com (David Lindholm) Date: Fri, 19 Feb 2016 09:13:11 +0100 Subject: CFV: New jdk9 Reviewer: Claes Redestad In-Reply-To: <56BCB736.80804@oracle.com> References: <56BCB736.80804@oracle.com> Message-ID: <56C6CE97.2050109@oracle.com> Vote: yes /David On 2016-02-11 17:30, Vladimir Ivanov wrote: > I hereby nominate Claes Redestad (OpenJDK user name: redestad) to JDK > 9 Reviewer. > > Claes is a member of the Java SE Performance team. He contributed 50 > changesets to jdk9 project [1] [2] and he is qualified to be a Reviewer. > > Among other things, Claes did numerous performance improvements in > java.lang.invoke implementation and Project Jigsaw [3]. > > Votes are due by February, 25 2016. > > Only current JDK 9 Reviewers [4] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Lazy Consensus voting instructions, see [5]. > > Best regards, > Vladimir Ivanov > > [1] > http://hg.openjdk.java.net/jdk9/dev/jdk/search/?rev=author%28redestad%29&revcount=100 > [2] > http://hg.openjdk.java.net/jdk9/dev/hotspot/search/?rev=author%28redestad%29&revcount=100 > [3] > http://hg.openjdk.java.net/jigsaw/jake/jdk/log?rev=author%28redestad%29 > [4] http://openjdk.java.net/census#jdk9 > [5] http://openjdk.java.net/projects#committer-vote From david.lindholm at oracle.com Fri Feb 19 08:14:11 2016 From: david.lindholm at oracle.com (David Lindholm) Date: Fri, 19 Feb 2016 09:14:11 +0100 Subject: CFV: New jdk9 Reviewer: Nils Eliasson In-Reply-To: <56BCA5D1.7020202@oracle.com> References: <56BCA5D1.7020202@oracle.com> Message-ID: <56C6CED3.60501@oracle.com> Vote: yes /David On 2016-02-11 16:16, Vladimir Ivanov wrote: > I hereby nominate Nils Eliasson (OpenJDK user name: neliasso to JDK > 9 Reviewer. > > Nils is a member of the Hotspot JVM Compiler group. He contributed 52 > changesets to jdk9 project [1] and he is qualified to be a Reviewer. > > Nils is the author of Compiler Control implementation [2] in HotSpot JVM. > > Votes are due by February, 25 2016. > > Only current JDK 9 Reviewers [3] 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 [4]. > > Best regards, > Vladimir Ivanov > > [1] > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/log?revcount=100&rev=author%28neliasso%29 > [2] http://openjdk.java.net/jeps/165 > [3] http://openjdk.java.net/census#jdk9 > [4] http://openjdk.java.net/projects#committer-vote From aph at redhat.com Fri Feb 19 09:41:58 2016 From: aph at redhat.com (Andrew Haley) Date: Fri, 19 Feb 2016 09:41:58 +0000 Subject: RFR (M): 8149159: Clean up Unsafe In-Reply-To: <56C61A07.4010604@oracle.com> References: <56C61A07.4010604@oracle.com> Message-ID: <56C6E366.4020506@redhat.com> On 18/02/16 19:22, Mikael Vidstedt wrote: > Please review the following change which does some relatively > significant cleaning up of the Unsafe implementation. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8149159 > Webrev (hotspot): > http://cr.openjdk.java.net/~mikael/webrevs/8149159_unsafecleanup/hotspot/webrev.00/webrev/ > Webrev (jdk): > http://cr.openjdk.java.net/~mikael/webrevs/8149159_unsafecleanup/jdk/webrev.00/webrev/ That really is a nice cleanup. Unsafe really needed it. Thanks. Andrew. From paul.sandoz at oracle.com Fri Feb 19 10:00:28 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 19 Feb 2016 11:00:28 +0100 Subject: RFR (M): 8149159: Clean up Unsafe In-Reply-To: <56C61A07.4010604@oracle.com> References: <56C61A07.4010604@oracle.com> Message-ID: <00D2DF3F-0040-439E-962F-E375DAFD451C@oracle.com> Hi Mikael, Very nice cleanup. That will help immensly when creating the ?unsupported? module. +1 to a follow up nuking the single addressing accessor intrinsics. That may also clear up some confusion with have in the docs, and much can follow from unifying on/off heap access with the double-addressing mode [*]. If you are paranoid about test failures then I suggest you do another JPRT run using the core testset. Paul. [*] I may camp outside the nio developers offices :-) > On 18 Feb 2016, at 20:22, Mikael Vidstedt wrote: > > > Please review the following change which does some relatively significant cleaning up of the Unsafe implementation. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8149159 > Webrev (hotspot): http://cr.openjdk.java.net/~mikael/webrevs/8149159_unsafecleanup/hotspot/webrev.00/webrev/ > Webrev (jdk): http://cr.openjdk.java.net/~mikael/webrevs/8149159_unsafecleanup/jdk/webrev.00/webrev/ > > Summary: > > * To avoid code duplication sun.misc.Unsafe now delegates all work to jdk.internal.misc.Unsafe. This also means that the VM - and unsafe.cpp specifically - no longer needs to know or care about s.m.Unsafe. > * The s.m.Unsafe delegation methods have all been decorated with @ForceInline to minimize the risk of performance regressions, though it is highly likely that they will be inlined even without the annotations. > * The documentation has been updated to reflect that it is the responsibility of the user of Unsafe to make sure arguments are valid. > * The argument checking has, to the extent possible, been moved from unsafe.cpp up to Java to simplify the native code and allow the JIT to optimize it. > * Some of the argument checks have been relaxed. For example, the recently introduced U.copySwapMemory does not check for null pointers anymore. See docs for j.i.m.U.checkPointer for the complete reasoning behind this. Note that the Unsafe methods today, apart from U.copySwapMemory, do not perform the NULL related check(s). > * A test was added for j.i.m.U.copyMemory, based on U.copySwapMemory. Feel free to point out that I should merge them (because I should). > > Also, unsafe.cpp was cleaned up rather dramatically. Some specific highlights: > > * Unsafe_ functions are now declared static, as are the other unsafe.cpp local functions. > * Created unsafe.hpp and moved some functions used in other parts of the VM to that. Removed some "extern" function declarations (extern is bad, kittens die when extern is (over-)used). > * Remove scary looking comment about UNSAFE_LEAF not being possible to use - there's nothing special about it, it's just a JVM_LEAF. > * Used UNSAFE_LEAF for a few simple leaf methods > * Added helpful braces around UNSAFE_ENTRY/UNSAFE_END to help auto-indent > * Removed unused Unsafe_<...>##140 functions/macros > * Updated macro argument names to be consistent throughout unsafe.cpp macro definitions > * Replaced some checks with asserts - as per above the checks are now performed in j.i.m.Unsafe instead. > * Removed all the s.m.Unsafe related code > > > Testing: > > * jtreg: hotspot_jprt group, jdk/internal > * JPRT: hotspot testset > * Perf: JMH unsafe-bench.jar (no significant changes) > > I'm taking suggestions on additional things to test. > > Cheers, > Mikael > From Roger.Riggs at Oracle.com Fri Feb 19 16:36:30 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Fri, 19 Feb 2016 11:36:30 -0500 Subject: CFV: New jdk9 Reviewer: Nils Eliasson In-Reply-To: <56BCA5D1.7020202@oracle.com> References: <56BCA5D1.7020202@oracle.com> Message-ID: <56C7448E.2030508@Oracle.com> Vote: Yes On 2/11/2016 10:16 AM, Vladimir Ivanov wrote: > I hereby nominate Nils Eliasson (OpenJDK user name: neliasso to JDK > 9 Reviewer. > From Roger.Riggs at Oracle.com Fri Feb 19 16:37:40 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Fri, 19 Feb 2016 11:37:40 -0500 Subject: CFV: New jdk9 Reviewer: Claes Redestad In-Reply-To: <56BCB736.80804@oracle.com> References: <56BCB736.80804@oracle.com> Message-ID: <56C744D4.2000505@Oracle.com> Vote: Yes On 2/11/2016 11:30 AM, Vladimir Ivanov wrote: > I hereby nominate Claes Redestad (OpenJDK user name: redestad) to JDK > 9 Reviewer. > From christian.thalinger at oracle.com Fri Feb 19 18:34:22 2016 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 19 Feb 2016 08:34:22 -1000 Subject: RFR (M): 8149159: Clean up Unsafe In-Reply-To: <56C61A07.4010604@oracle.com> References: <56C61A07.4010604@oracle.com> Message-ID: <920A8C1F-2758-4DF2-A337-AFD47F5A4B35@oracle.com> ! UNSAFE_ENTRY(jobject, Unsafe_GetObject(JNIEnv *env, jobject unsafe, jobject obj, jlong offset)) { UnsafeWrapper("Unsafe_GetObject?); Could UnsafeWrapper be part of the UNSAFE_ENTRY? I mean, it?s empty anyway: #define UnsafeWrapper(arg) /*nothing, for the present*/ > On Feb 18, 2016, at 9:22 AM, Mikael Vidstedt wrote: > > > Please review the following change which does some relatively significant cleaning up of the Unsafe implementation. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8149159 > Webrev (hotspot): http://cr.openjdk.java.net/~mikael/webrevs/8149159_unsafecleanup/hotspot/webrev.00/webrev/ > Webrev (jdk): http://cr.openjdk.java.net/~mikael/webrevs/8149159_unsafecleanup/jdk/webrev.00/webrev/ > > Summary: > > * To avoid code duplication sun.misc.Unsafe now delegates all work to jdk.internal.misc.Unsafe. This also means that the VM - and unsafe.cpp specifically - no longer needs to know or care about s.m.Unsafe. > * The s.m.Unsafe delegation methods have all been decorated with @ForceInline to minimize the risk of performance regressions, though it is highly likely that they will be inlined even without the annotations. > * The documentation has been updated to reflect that it is the responsibility of the user of Unsafe to make sure arguments are valid. > * The argument checking has, to the extent possible, been moved from unsafe.cpp up to Java to simplify the native code and allow the JIT to optimize it. > * Some of the argument checks have been relaxed. For example, the recently introduced U.copySwapMemory does not check for null pointers anymore. See docs for j.i.m.U.checkPointer for the complete reasoning behind this. Note that the Unsafe methods today, apart from U.copySwapMemory, do not perform the NULL related check(s). > * A test was added for j.i.m.U.copyMemory, based on U.copySwapMemory. Feel free to point out that I should merge them (because I should). > > Also, unsafe.cpp was cleaned up rather dramatically. Some specific highlights: > > * Unsafe_ functions are now declared static, as are the other unsafe.cpp local functions. > * Created unsafe.hpp and moved some functions used in other parts of the VM to that. Removed some "extern" function declarations (extern is bad, kittens die when extern is (over-)used). > * Remove scary looking comment about UNSAFE_LEAF not being possible to use - there's nothing special about it, it's just a JVM_LEAF. > * Used UNSAFE_LEAF for a few simple leaf methods > * Added helpful braces around UNSAFE_ENTRY/UNSAFE_END to help auto-indent > * Removed unused Unsafe_<...>##140 functions/macros > * Updated macro argument names to be consistent throughout unsafe.cpp macro definitions > * Replaced some checks with asserts - as per above the checks are now performed in j.i.m.Unsafe instead. > * Removed all the s.m.Unsafe related code > > > Testing: > > * jtreg: hotspot_jprt group, jdk/internal > * JPRT: hotspot testset > * Perf: JMH unsafe-bench.jar (no significant changes) > > I'm taking suggestions on additional things to test. > > Cheers, > Mikael > From claes.redestad at oracle.com Fri Feb 19 20:05:18 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Fri, 19 Feb 2016 21:05:18 +0100 Subject: RFR (M): 8149159: Clean up Unsafe In-Reply-To: <56C61A07.4010604@oracle.com> References: <56C61A07.4010604@oracle.com> Message-ID: <56C7757E.4070806@oracle.com> Good stuff! But quite a few delegating methods in sun.misc.Unsafe did not get the @ForceInline treatment, which seems like an oversight? Thanks! /Claes On 2016-02-18 20:22, Mikael Vidstedt wrote: > > Please review the following change which does some relatively > significant cleaning up of the Unsafe implementation. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8149159 > Webrev (hotspot): > http://cr.openjdk.java.net/~mikael/webrevs/8149159_unsafecleanup/hotspot/webrev.00/webrev/ > Webrev (jdk): > http://cr.openjdk.java.net/~mikael/webrevs/8149159_unsafecleanup/jdk/webrev.00/webrev/ > > Summary: > > * To avoid code duplication sun.misc.Unsafe now delegates all work to > jdk.internal.misc.Unsafe. This also means that the VM - and unsafe.cpp > specifically - no longer needs to know or care about s.m.Unsafe. > * The s.m.Unsafe delegation methods have all been decorated with > @ForceInline to minimize the risk of performance regressions, though > it is highly likely that they will be inlined even without the > annotations. > * The documentation has been updated to reflect that it is the > responsibility of the user of Unsafe to make sure arguments are valid. > * The argument checking has, to the extent possible, been moved from > unsafe.cpp up to Java to simplify the native code and allow the JIT to > optimize it. > * Some of the argument checks have been relaxed. For example, the > recently introduced U.copySwapMemory does not check for null pointers > anymore. See docs for j.i.m.U.checkPointer for the complete reasoning > behind this. Note that the Unsafe methods today, apart from > U.copySwapMemory, do not perform the NULL related check(s). > * A test was added for j.i.m.U.copyMemory, based on U.copySwapMemory. > Feel free to point out that I should merge them (because I should). > > Also, unsafe.cpp was cleaned up rather dramatically. Some specific > highlights: > > * Unsafe_ functions are now declared static, as are the other > unsafe.cpp local functions. > * Created unsafe.hpp and moved some functions used in other parts of > the VM to that. Removed some "extern" function declarations (extern is > bad, kittens die when extern is (over-)used). > * Remove scary looking comment about UNSAFE_LEAF not being possible to > use - there's nothing special about it, it's just a JVM_LEAF. > * Used UNSAFE_LEAF for a few simple leaf methods > * Added helpful braces around UNSAFE_ENTRY/UNSAFE_END to help auto-indent > * Removed unused Unsafe_<...>##140 functions/macros > * Updated macro argument names to be consistent throughout unsafe.cpp > macro definitions > * Replaced some checks with asserts - as per above the checks are now > performed in j.i.m.Unsafe instead. > * Removed all the s.m.Unsafe related code > > > Testing: > > * jtreg: hotspot_jprt group, jdk/internal > * JPRT: hotspot testset > * Perf: JMH unsafe-bench.jar (no significant changes) > > I'm taking suggestions on additional things to test. > > Cheers, > Mikael > From michael.haupt at oracle.com Mon Feb 22 09:31:30 2016 From: michael.haupt at oracle.com (Michael Haupt) Date: Mon, 22 Feb 2016 10:31:30 +0100 Subject: RFR JDK-8149644 Integrate VarHandles In-Reply-To: <9C47EF6F-80D6-467E-A5CB-2FDD5FF6AE17@oracle.com> References: <9C47EF6F-80D6-467E-A5CB-2FDD5FF6AE17@oracle.com> Message-ID: <72838227-273B-4146-8A07-4548D31E8C00@oracle.com> Hi Paul, I've reviewed the JDK changes - looks good! Note that this is a lower-case review. Best, Michael > Am 11.02.2016 um 16:39 schrieb Paul Sandoz : > JDK: > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8149644-varhandles-integration/jdk/webrev/index.html -- Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331 200 7561 Oracle Java Platform Group | LangTools Team | Nashorn Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstra?e 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From coleen.phillimore at oracle.com Mon Feb 22 18:53:45 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 22 Feb 2016 13:53:45 -0500 Subject: CFV: New JDK 9 Committer: Rachel Protacio Message-ID: <56CB5939.6090704@oracle.com> I hereby nominate Rachel Protacio (rprotacio) to JDK 9 Committer. Rachel is a member of the Hotspot runtime team and has contributed 21 changes [3] to the OpenJDK hotspot repository. She has converted 8 Trace options to the new Unified Logging framework, fixed unified logging tests because of an overambitious testing strategy, and also fixed a significant bug in the UL framework. Votes are due by 2:00 PM EST, Monday March 7, 2016. Only current JDK 9 Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [2]. Coleen Phillimore [1] http://openjdk.java.net/census [2] http://openjdk.java.net/projects/#committer-vote [3] List of patches: http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/66a81854aa5d 8149383: Convert TraceBiasedLocking to Unified Logging http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/eda0d9992163 8148630: Convert TraceStartupTime to Unified Logging http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/1ac9a5e38143 8146137: runtime/logging/ExceptionsTest.java fails on embedded and ARM test http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/45c4d55c36f5 8146435: [TESTBUG] Logging tests are failing intermittently on windows when executed by JPRT http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/42a4b9a221cc 8144953: runtime/CommandLine/TraceExceptionsTest.java fails when exception is thrown in compiled code http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/50dd5b051754 8141564: Convert TraceItables and PrintVtables to Unified Logging http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/dda74d89ee09 8146481: Disable runtime/logging/DefaultMethodsTest.java http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/fd60a8853157 8145606: [TESTBUG] MonitorInflationTest.java should be rewritten to be more predictable http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/0c82805adfc5 8141211: Convert TraceExceptions to Unified Logging http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/a9a101b70a85 8145445: [TESTBUG] runtime/logging tests need to properly build and import libraries http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/432ae0f42a2c 8145629: Disable test/runtime/logging/MonitorInflationTest.java http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/8512cbf64495 8145153: Convert TraceMonitorInflation to Unified Logging http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/1f1e6bc1c947 8144536: Clean up Unified Logging test directory http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/fb4a19e4f7dc 8143155: Remove TraceRuntimeCalls, TraceJNICalls, and TraceJVMCalls rather than convert to UL http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/fd83b8307473 8143157: Convert TraceVMOperation to Unified Logging http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/a7ffcce47ffb 8142437: SafepointTest.java is occasionally failing in JPRT http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/766ae06f30ca 8138916: Logging write function does not allow for long enough messages http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/9c99ce707b0b 8140348: Convert TraceSafepoint to Unified Logging http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/96773453776a 8139564: Convert TraceDefaultMethods to Unified Logging http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/43a1e4ca7ee4 8138574: [TESTBUG] TestBasicLogOutput.java doesn't account for padding http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/e13d7fa76fac 8133561: linux thread id should be reported in decimal in the error reports now From coleen.phillimore at oracle.com Mon Feb 22 18:54:47 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 22 Feb 2016 13:54:47 -0500 Subject: CFV: New JDK 9 Committer: Rachel Protacio In-Reply-To: <56CB5939.6090704@oracle.com> References: <56CB5939.6090704@oracle.com> Message-ID: <56CB5977.1070005@oracle.com> Vote: yes On 2/22/16 1:53 PM, Coleen Phillimore wrote: > I hereby nominate Rachel Protacio (rprotacio) to JDK 9 Committer. > > Rachel is a member of the Hotspot runtime team and has contributed 21 > changes [3] to the OpenJDK hotspot repository. She has converted 8 > Trace options to the new Unified Logging framework, fixed unified > logging tests because of an overambitious testing strategy, and also > fixed a significant bug in the UL framework. > > Votes are due by 2:00 PM EST, Monday March 7, 2016. > > Only current JDK 9 Committers [1] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Lazy Consensus voting instructions, see [2]. > > Coleen Phillimore > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] List of patches: > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/66a81854aa5d > 8149383: Convert TraceBiasedLocking to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/eda0d9992163 > 8148630: Convert TraceStartupTime to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/1ac9a5e38143 > 8146137: runtime/logging/ExceptionsTest.java fails on embedded and ARM > test > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/45c4d55c36f5 > 8146435: [TESTBUG] Logging tests are failing intermittently on windows > when executed by JPRT > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/42a4b9a221cc > 8144953: runtime/CommandLine/TraceExceptionsTest.java fails when > exception is thrown in compiled code > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/50dd5b051754 > 8141564: Convert TraceItables and PrintVtables to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/dda74d89ee09 > 8146481: Disable runtime/logging/DefaultMethodsTest.java > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/fd60a8853157 > 8145606: [TESTBUG] MonitorInflationTest.java should be rewritten to be > more predictable > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/0c82805adfc5 > 8141211: Convert TraceExceptions to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/a9a101b70a85 > 8145445: [TESTBUG] runtime/logging tests need to properly build and > import libraries > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/432ae0f42a2c > 8145629: Disable test/runtime/logging/MonitorInflationTest.java > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/8512cbf64495 > 8145153: Convert TraceMonitorInflation to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/1f1e6bc1c947 > 8144536: Clean up Unified Logging test directory > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/fb4a19e4f7dc > 8143155: Remove TraceRuntimeCalls, TraceJNICalls, and TraceJVMCalls > rather than convert to UL > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/fd83b8307473 > 8143157: Convert TraceVMOperation to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/a7ffcce47ffb > 8142437: SafepointTest.java is occasionally failing in JPRT > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/766ae06f30ca > 8138916: Logging write function does not allow for long enough messages > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/9c99ce707b0b > 8140348: Convert TraceSafepoint to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/96773453776a > 8139564: Convert TraceDefaultMethods to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/43a1e4ca7ee4 > 8138574: [TESTBUG] TestBasicLogOutput.java doesn't account for padding > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/e13d7fa76fac > 8133561: linux thread id should be reported in decimal in the error > reports now > From jiangli.zhou at oracle.com Mon Feb 22 18:55:36 2016 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Mon, 22 Feb 2016 10:55:36 -0800 Subject: CFV: New JDK 9 Committer: Rachel Protacio In-Reply-To: <56CB5939.6090704@oracle.com> References: <56CB5939.6090704@oracle.com> Message-ID: Vote: yes Thanks, Jiangli > On Feb 22, 2016, at 10:53 AM, Coleen Phillimore wrote: > > I hereby nominate Rachel Protacio (rprotacio) to JDK 9 Committer. > > Rachel is a member of the Hotspot runtime team and has contributed 21 changes [3] to the OpenJDK hotspot repository. She has converted 8 Trace options to the new Unified Logging framework, fixed unified logging tests because of an overambitious testing strategy, and also fixed a significant bug in the UL framework. > > Votes are due by 2:00 PM EST, Monday March 7, 2016. > > Only current JDK 9 Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Coleen Phillimore > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] List of patches: > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/66a81854aa5d > 8149383: Convert TraceBiasedLocking to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/eda0d9992163 > 8148630: Convert TraceStartupTime to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/1ac9a5e38143 > 8146137: runtime/logging/ExceptionsTest.java fails on embedded and ARM test > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/45c4d55c36f5 > 8146435: [TESTBUG] Logging tests are failing intermittently on windows when executed by JPRT > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/42a4b9a221cc > 8144953: runtime/CommandLine/TraceExceptionsTest.java fails when exception is thrown in compiled code > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/50dd5b051754 > 8141564: Convert TraceItables and PrintVtables to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/dda74d89ee09 > 8146481: Disable runtime/logging/DefaultMethodsTest.java > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/fd60a8853157 > 8145606: [TESTBUG] MonitorInflationTest.java should be rewritten to be more predictable > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/0c82805adfc5 > 8141211: Convert TraceExceptions to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/a9a101b70a85 > 8145445: [TESTBUG] runtime/logging tests need to properly build and import libraries > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/432ae0f42a2c > 8145629: Disable test/runtime/logging/MonitorInflationTest.java > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/8512cbf64495 > 8145153: Convert TraceMonitorInflation to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/1f1e6bc1c947 > 8144536: Clean up Unified Logging test directory > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/fb4a19e4f7dc > 8143155: Remove TraceRuntimeCalls, TraceJNICalls, and TraceJVMCalls rather than convert to UL > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/fd83b8307473 > 8143157: Convert TraceVMOperation to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/a7ffcce47ffb > 8142437: SafepointTest.java is occasionally failing in JPRT > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/766ae06f30ca > 8138916: Logging write function does not allow for long enough messages > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/9c99ce707b0b > 8140348: Convert TraceSafepoint to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/96773453776a > 8139564: Convert TraceDefaultMethods to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/43a1e4ca7ee4 > 8138574: [TESTBUG] TestBasicLogOutput.java doesn't account for padding > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/e13d7fa76fac > 8133561: linux thread id should be reported in decimal in the error reports now > From christian.thalinger at oracle.com Mon Feb 22 18:55:52 2016 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 22 Feb 2016 08:55:52 -1000 Subject: CFV: New JDK 9 Committer: Rachel Protacio In-Reply-To: <56CB5939.6090704@oracle.com> References: <56CB5939.6090704@oracle.com> Message-ID: Vote: yes > On Feb 22, 2016, at 8:53 AM, Coleen Phillimore wrote: > > I hereby nominate Rachel Protacio (rprotacio) to JDK 9 Committer. > > Rachel is a member of the Hotspot runtime team and has contributed 21 changes [3] to the OpenJDK hotspot repository. She has converted 8 Trace options to the new Unified Logging framework, fixed unified logging tests because of an overambitious testing strategy, and also fixed a significant bug in the UL framework. > > Votes are due by 2:00 PM EST, Monday March 7, 2016. > > Only current JDK 9 Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Coleen Phillimore > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] List of patches: > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/66a81854aa5d > 8149383: Convert TraceBiasedLocking to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/eda0d9992163 > 8148630: Convert TraceStartupTime to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/1ac9a5e38143 > 8146137: runtime/logging/ExceptionsTest.java fails on embedded and ARM test > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/45c4d55c36f5 > 8146435: [TESTBUG] Logging tests are failing intermittently on windows when executed by JPRT > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/42a4b9a221cc > 8144953: runtime/CommandLine/TraceExceptionsTest.java fails when exception is thrown in compiled code > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/50dd5b051754 > 8141564: Convert TraceItables and PrintVtables to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/dda74d89ee09 > 8146481: Disable runtime/logging/DefaultMethodsTest.java > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/fd60a8853157 > 8145606: [TESTBUG] MonitorInflationTest.java should be rewritten to be more predictable > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/0c82805adfc5 > 8141211: Convert TraceExceptions to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/a9a101b70a85 > 8145445: [TESTBUG] runtime/logging tests need to properly build and import libraries > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/432ae0f42a2c > 8145629: Disable test/runtime/logging/MonitorInflationTest.java > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/8512cbf64495 > 8145153: Convert TraceMonitorInflation to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/1f1e6bc1c947 > 8144536: Clean up Unified Logging test directory > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/fb4a19e4f7dc > 8143155: Remove TraceRuntimeCalls, TraceJNICalls, and TraceJVMCalls rather than convert to UL > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/fd83b8307473 > 8143157: Convert TraceVMOperation to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/a7ffcce47ffb > 8142437: SafepointTest.java is occasionally failing in JPRT > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/766ae06f30ca > 8138916: Logging write function does not allow for long enough messages > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/9c99ce707b0b > 8140348: Convert TraceSafepoint to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/96773453776a > 8139564: Convert TraceDefaultMethods to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/43a1e4ca7ee4 > 8138574: [TESTBUG] TestBasicLogOutput.java doesn't account for padding > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/e13d7fa76fac > 8133561: linux thread id should be reported in decimal in the error reports now > From lois.foltan at oracle.com Mon Feb 22 18:59:28 2016 From: lois.foltan at oracle.com (Lois Foltan) Date: Mon, 22 Feb 2016 13:59:28 -0500 Subject: CFV: New JDK 9 Committer: Rachel Protacio In-Reply-To: <56CB5939.6090704@oracle.com> References: <56CB5939.6090704@oracle.com> Message-ID: <56CB5A90.2090507@oracle.com> Vote: yes On 2/22/2016 1:53 PM, Coleen Phillimore wrote: > I hereby nominate Rachel Protacio (rprotacio) to JDK 9 Committer. > > Rachel is a member of the Hotspot runtime team and has contributed 21 > changes [3] to the OpenJDK hotspot repository. She has converted 8 > Trace options to the new Unified Logging framework, fixed unified > logging tests because of an overambitious testing strategy, and also > fixed a significant bug in the UL framework. > > Votes are due by 2:00 PM EST, Monday March 7, 2016. > > Only current JDK 9 Committers [1] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Lazy Consensus voting instructions, see [2]. > > Coleen Phillimore > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] List of patches: > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/66a81854aa5d > 8149383: Convert TraceBiasedLocking to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/eda0d9992163 > 8148630: Convert TraceStartupTime to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/1ac9a5e38143 > 8146137: runtime/logging/ExceptionsTest.java fails on embedded and ARM > test > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/45c4d55c36f5 > 8146435: [TESTBUG] Logging tests are failing intermittently on windows > when executed by JPRT > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/42a4b9a221cc > 8144953: runtime/CommandLine/TraceExceptionsTest.java fails when > exception is thrown in compiled code > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/50dd5b051754 > 8141564: Convert TraceItables and PrintVtables to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/dda74d89ee09 > 8146481: Disable runtime/logging/DefaultMethodsTest.java > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/fd60a8853157 > 8145606: [TESTBUG] MonitorInflationTest.java should be rewritten to be > more predictable > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/0c82805adfc5 > 8141211: Convert TraceExceptions to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/a9a101b70a85 > 8145445: [TESTBUG] runtime/logging tests need to properly build and > import libraries > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/432ae0f42a2c > 8145629: Disable test/runtime/logging/MonitorInflationTest.java > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/8512cbf64495 > 8145153: Convert TraceMonitorInflation to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/1f1e6bc1c947 > 8144536: Clean up Unified Logging test directory > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/fb4a19e4f7dc > 8143155: Remove TraceRuntimeCalls, TraceJNICalls, and TraceJVMCalls > rather than convert to UL > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/fd83b8307473 > 8143157: Convert TraceVMOperation to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/a7ffcce47ffb > 8142437: SafepointTest.java is occasionally failing in JPRT > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/766ae06f30ca > 8138916: Logging write function does not allow for long enough messages > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/9c99ce707b0b > 8140348: Convert TraceSafepoint to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/96773453776a > 8139564: Convert TraceDefaultMethods to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/43a1e4ca7ee4 > 8138574: [TESTBUG] TestBasicLogOutput.java doesn't account for padding > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/e13d7fa76fac > 8133561: linux thread id should be reported in decimal in the error > reports now > From harold.seigel at oracle.com Mon Feb 22 19:00:57 2016 From: harold.seigel at oracle.com (harold seigel) Date: Mon, 22 Feb 2016 14:00:57 -0500 Subject: CFV: New JDK 9 Committer: Rachel Protacio In-Reply-To: <56CB5939.6090704@oracle.com> References: <56CB5939.6090704@oracle.com> Message-ID: <56CB5AE9.90209@oracle.com> Vote: yes Harold On 2/22/2016 1:53 PM, Coleen Phillimore wrote: > I hereby nominate Rachel Protacio (rprotacio) to JDK 9 Committer. > > Rachel is a member of the Hotspot runtime team and has contributed 21 > changes [3] to the OpenJDK hotspot repository. She has converted 8 > Trace options to the new Unified Logging framework, fixed unified > logging tests because of an overambitious testing strategy, and also > fixed a significant bug in the UL framework. > > Votes are due by 2:00 PM EST, Monday March 7, 2016. > > Only current JDK 9 Committers [1] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Lazy Consensus voting instructions, see [2]. > > Coleen Phillimore > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] List of patches: > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/66a81854aa5d > 8149383: Convert TraceBiasedLocking to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/eda0d9992163 > 8148630: Convert TraceStartupTime to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/1ac9a5e38143 > 8146137: runtime/logging/ExceptionsTest.java fails on embedded and ARM > test > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/45c4d55c36f5 > 8146435: [TESTBUG] Logging tests are failing intermittently on windows > when executed by JPRT > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/42a4b9a221cc > 8144953: runtime/CommandLine/TraceExceptionsTest.java fails when > exception is thrown in compiled code > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/50dd5b051754 > 8141564: Convert TraceItables and PrintVtables to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/dda74d89ee09 > 8146481: Disable runtime/logging/DefaultMethodsTest.java > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/fd60a8853157 > 8145606: [TESTBUG] MonitorInflationTest.java should be rewritten to be > more predictable > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/0c82805adfc5 > 8141211: Convert TraceExceptions to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/a9a101b70a85 > 8145445: [TESTBUG] runtime/logging tests need to properly build and > import libraries > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/432ae0f42a2c > 8145629: Disable test/runtime/logging/MonitorInflationTest.java > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/8512cbf64495 > 8145153: Convert TraceMonitorInflation to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/1f1e6bc1c947 > 8144536: Clean up Unified Logging test directory > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/fb4a19e4f7dc > 8143155: Remove TraceRuntimeCalls, TraceJNICalls, and TraceJVMCalls > rather than convert to UL > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/fd83b8307473 > 8143157: Convert TraceVMOperation to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/a7ffcce47ffb > 8142437: SafepointTest.java is occasionally failing in JPRT > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/766ae06f30ca > 8138916: Logging write function does not allow for long enough messages > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/9c99ce707b0b > 8140348: Convert TraceSafepoint to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/96773453776a > 8139564: Convert TraceDefaultMethods to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/43a1e4ca7ee4 > 8138574: [TESTBUG] TestBasicLogOutput.java doesn't account for padding > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/e13d7fa76fac > 8133561: linux thread id should be reported in decimal in the error > reports now > From alexander.zuev at oracle.com Mon Feb 22 19:01:37 2016 From: alexander.zuev at oracle.com (Alexander Zuev) Date: Mon, 22 Feb 2016 11:01:37 -0800 Subject: CFV: New JDK 9 Committer: Rachel Protacio In-Reply-To: <56CB5939.6090704@oracle.com> References: <56CB5939.6090704@oracle.com> Message-ID: <56CB5B11.6020906@oracle.com> Vote: yes On 22/02/16 10:53, Coleen Phillimore wrote: > I hereby nominate Rachel Protacio (rprotacio) to JDK 9 Committer. > > Rachel is a member of the Hotspot runtime team and has contributed 21 > changes [3] to the OpenJDK hotspot repository. She has converted 8 > Trace options to the new Unified Logging framework, fixed unified > logging tests because of an overambitious testing strategy, and also > fixed a significant bug in the UL framework. > > Votes are due by 2:00 PM EST, Monday March 7, 2016. > > Only current JDK 9 Committers [1] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Lazy Consensus voting instructions, see [2]. > > Coleen Phillimore > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] List of patches: > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/66a81854aa5d > 8149383: Convert TraceBiasedLocking to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/eda0d9992163 > 8148630: Convert TraceStartupTime to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/1ac9a5e38143 > 8146137: runtime/logging/ExceptionsTest.java fails on embedded and ARM > test > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/45c4d55c36f5 > 8146435: [TESTBUG] Logging tests are failing intermittently on windows > when executed by JPRT > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/42a4b9a221cc > 8144953: runtime/CommandLine/TraceExceptionsTest.java fails when > exception is thrown in compiled code > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/50dd5b051754 > 8141564: Convert TraceItables and PrintVtables to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/dda74d89ee09 > 8146481: Disable runtime/logging/DefaultMethodsTest.java > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/fd60a8853157 > 8145606: [TESTBUG] MonitorInflationTest.java should be rewritten to be > more predictable > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/0c82805adfc5 > 8141211: Convert TraceExceptions to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/a9a101b70a85 > 8145445: [TESTBUG] runtime/logging tests need to properly build and > import libraries > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/432ae0f42a2c > 8145629: Disable test/runtime/logging/MonitorInflationTest.java > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/8512cbf64495 > 8145153: Convert TraceMonitorInflation to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/1f1e6bc1c947 > 8144536: Clean up Unified Logging test directory > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/fb4a19e4f7dc > 8143155: Remove TraceRuntimeCalls, TraceJNICalls, and TraceJVMCalls > rather than convert to UL > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/fd83b8307473 > 8143157: Convert TraceVMOperation to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/a7ffcce47ffb > 8142437: SafepointTest.java is occasionally failing in JPRT > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/766ae06f30ca > 8138916: Logging write function does not allow for long enough messages > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/9c99ce707b0b > 8140348: Convert TraceSafepoint to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/96773453776a > 8139564: Convert TraceDefaultMethods to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/43a1e4ca7ee4 > 8138574: [TESTBUG] TestBasicLogOutput.java doesn't account for padding > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/e13d7fa76fac > 8133561: linux thread id should be reported in decimal in the error > reports now > From eric.caspole at oracle.com Mon Feb 22 19:01:33 2016 From: eric.caspole at oracle.com (Eric Caspole) Date: Mon, 22 Feb 2016 14:01:33 -0500 Subject: CFV: New JDK 9 Committer: Rachel Protacio In-Reply-To: <56CB5939.6090704@oracle.com> References: <56CB5939.6090704@oracle.com> Message-ID: <56CB5B0D.2040906@oracle.com> Vote: yes On 02/22/2016 01:53 PM, Coleen Phillimore wrote: > I hereby nominate Rachel Protacio (rprotacio) to JDK 9 Committer. > > Rachel is a member of the Hotspot runtime team and has contributed 21 > changes [3] to the OpenJDK hotspot repository. She has converted 8 > Trace options to the new Unified Logging framework, fixed unified > logging tests because of an overambitious testing strategy, and also > fixed a significant bug in the UL framework. > > Votes are due by 2:00 PM EST, Monday March 7, 2016. > > Only current JDK 9 Committers [1] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Lazy Consensus voting instructions, see [2]. > > Coleen Phillimore > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] List of patches: > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/66a81854aa5d > 8149383: Convert TraceBiasedLocking to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/eda0d9992163 > 8148630: Convert TraceStartupTime to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/1ac9a5e38143 > 8146137: runtime/logging/ExceptionsTest.java fails on embedded and ARM test > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/45c4d55c36f5 > 8146435: [TESTBUG] Logging tests are failing intermittently on windows > when executed by JPRT > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/42a4b9a221cc > 8144953: runtime/CommandLine/TraceExceptionsTest.java fails when > exception is thrown in compiled code > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/50dd5b051754 > 8141564: Convert TraceItables and PrintVtables to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/dda74d89ee09 > 8146481: Disable runtime/logging/DefaultMethodsTest.java > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/fd60a8853157 > 8145606: [TESTBUG] MonitorInflationTest.java should be rewritten to be > more predictable > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/0c82805adfc5 > 8141211: Convert TraceExceptions to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/a9a101b70a85 > 8145445: [TESTBUG] runtime/logging tests need to properly build and > import libraries > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/432ae0f42a2c > 8145629: Disable test/runtime/logging/MonitorInflationTest.java > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/8512cbf64495 > 8145153: Convert TraceMonitorInflation to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/1f1e6bc1c947 > 8144536: Clean up Unified Logging test directory > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/fb4a19e4f7dc > 8143155: Remove TraceRuntimeCalls, TraceJNICalls, and TraceJVMCalls > rather than convert to UL > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/fd83b8307473 > 8143157: Convert TraceVMOperation to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/a7ffcce47ffb > 8142437: SafepointTest.java is occasionally failing in JPRT > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/766ae06f30ca > 8138916: Logging write function does not allow for long enough messages > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/9c99ce707b0b > 8140348: Convert TraceSafepoint to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/96773453776a > 8139564: Convert TraceDefaultMethods to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/43a1e4ca7ee4 > 8138574: [TESTBUG] TestBasicLogOutput.java doesn't account for padding > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/e13d7fa76fac > 8133561: linux thread id should be reported in decimal in the error > reports now > From calvin.cheung at oracle.com Mon Feb 22 19:12:49 2016 From: calvin.cheung at oracle.com (Calvin Cheung) Date: Mon, 22 Feb 2016 11:12:49 -0800 Subject: CFV: New JDK 9 Committer: Rachel Protacio In-Reply-To: <56CB5939.6090704@oracle.com> References: <56CB5939.6090704@oracle.com> Message-ID: <56CB5DB1.6060504@oracle.com> Vote: yes On 2/22/16, 10:53 AM, Coleen Phillimore wrote: > I hereby nominate Rachel Protacio (rprotacio) to JDK 9 Committer. > > Rachel is a member of the Hotspot runtime team and has contributed 21 > changes [3] to the OpenJDK hotspot repository. She has converted 8 > Trace options to the new Unified Logging framework, fixed unified > logging tests because of an overambitious testing strategy, and also > fixed a significant bug in the UL framework. > > Votes are due by 2:00 PM EST, Monday March 7, 2016. > > Only current JDK 9 Committers [1] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Lazy Consensus voting instructions, see [2]. > > Coleen Phillimore > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] List of patches: > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/66a81854aa5d > 8149383: Convert TraceBiasedLocking to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/eda0d9992163 > 8148630: Convert TraceStartupTime to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/1ac9a5e38143 > 8146137: runtime/logging/ExceptionsTest.java fails on embedded and ARM > test > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/45c4d55c36f5 > 8146435: [TESTBUG] Logging tests are failing intermittently on windows > when executed by JPRT > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/42a4b9a221cc > 8144953: runtime/CommandLine/TraceExceptionsTest.java fails when > exception is thrown in compiled code > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/50dd5b051754 > 8141564: Convert TraceItables and PrintVtables to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/dda74d89ee09 > 8146481: Disable runtime/logging/DefaultMethodsTest.java > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/fd60a8853157 > 8145606: [TESTBUG] MonitorInflationTest.java should be rewritten to be > more predictable > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/0c82805adfc5 > 8141211: Convert TraceExceptions to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/a9a101b70a85 > 8145445: [TESTBUG] runtime/logging tests need to properly build and > import libraries > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/432ae0f42a2c > 8145629: Disable test/runtime/logging/MonitorInflationTest.java > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/8512cbf64495 > 8145153: Convert TraceMonitorInflation to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/1f1e6bc1c947 > 8144536: Clean up Unified Logging test directory > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/fb4a19e4f7dc > 8143155: Remove TraceRuntimeCalls, TraceJNICalls, and TraceJVMCalls > rather than convert to UL > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/fd83b8307473 > 8143157: Convert TraceVMOperation to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/a7ffcce47ffb > 8142437: SafepointTest.java is occasionally failing in JPRT > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/766ae06f30ca > 8138916: Logging write function does not allow for long enough messages > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/9c99ce707b0b > 8140348: Convert TraceSafepoint to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/96773453776a > 8139564: Convert TraceDefaultMethods to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/43a1e4ca7ee4 > 8138574: [TESTBUG] TestBasicLogOutput.java doesn't account for padding > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/e13d7fa76fac > 8133561: linux thread id should be reported in decimal in the error > reports now > From gerard.ziemski at oracle.com Mon Feb 22 19:27:24 2016 From: gerard.ziemski at oracle.com (Gerard Ziemski) Date: Mon, 22 Feb 2016 13:27:24 -0600 Subject: CFV: New JDK 9 Committer: Rachel Protacio In-Reply-To: <56CB5939.6090704@oracle.com> References: <56CB5939.6090704@oracle.com> Message-ID: Vote: yes > On Feb 22, 2016, at 12:53 PM, Coleen Phillimore wrote: > > I hereby nominate Rachel Protacio (rprotacio) to JDK 9 Committer. From paul.sandoz at oracle.com Mon Feb 22 20:09:47 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 22 Feb 2016 21:09:47 +0100 Subject: RFR JDK-8149644 Integrate VarHandles In-Reply-To: <72838227-273B-4146-8A07-4548D31E8C00@oracle.com> References: <9C47EF6F-80D6-467E-A5CB-2FDD5FF6AE17@oracle.com> <72838227-273B-4146-8A07-4548D31E8C00@oracle.com> Message-ID: <3ADCA13E-AB1E-4EE1-A7D5-7F25EBAC103F@oracle.com> > On 22 Feb 2016, at 10:31, Michael Haupt wrote: > > Hi Paul, > > I've reviewed the JDK changes - looks good! Note that this is a lower-case review. > Very much appreciated, thanks, Paul. > Best, > > Michael > >> Am 11.02.2016 um 16:39 schrieb Paul Sandoz >: >> JDK: >> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8149644-varhandles-integration/jdk/webrev/index.html From jesper.wilhelmsson at oracle.com Mon Feb 22 20:15:41 2016 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Mon, 22 Feb 2016 21:15:41 +0100 Subject: Result: New JDK 9 Committer: Dmitry Fazunenko Message-ID: <56CB6C6D.5090907@oracle.com> Voting for Dmitry Fazunenko (dfazunen) [1] is now closed. Yes: 36 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. Actually 37 persons voted 'yes' but one forgot to CC the open list and is therefore not counted. /Jesper [1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-February/003511.html From jesper.wilhelmsson at oracle.com Mon Feb 22 20:16:50 2016 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Mon, 22 Feb 2016 21:16:50 +0100 Subject: CFV: New JDK 9 Committer: Rachel Protacio In-Reply-To: <56CB5939.6090704@oracle.com> References: <56CB5939.6090704@oracle.com> Message-ID: <56CB6CB2.5050501@oracle.com> Vote: yes /Jesper Den 22/2/16 kl. 19:53, skrev Coleen Phillimore: > I hereby nominate Rachel Protacio (rprotacio) to JDK 9 Committer. > > Rachel is a member of the Hotspot runtime team and has contributed 21 changes > [3] to the OpenJDK hotspot repository. She has converted 8 Trace options to the > new Unified Logging framework, fixed unified logging tests because of an > overambitious testing strategy, and also fixed a significant bug in the UL > framework. > > Votes are due by 2:00 PM EST, Monday March 7, 2016. > > Only current JDK 9 Committers [1] are eligible to vote on this nomination. Votes > must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Coleen Phillimore > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] List of patches: > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/66a81854aa5d > 8149383: Convert TraceBiasedLocking to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/eda0d9992163 > 8148630: Convert TraceStartupTime to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/1ac9a5e38143 > 8146137: runtime/logging/ExceptionsTest.java fails on embedded and ARM test > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/45c4d55c36f5 > 8146435: [TESTBUG] Logging tests are failing intermittently on windows when > executed by JPRT > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/42a4b9a221cc > 8144953: runtime/CommandLine/TraceExceptionsTest.java fails when exception is > thrown in compiled code > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/50dd5b051754 > 8141564: Convert TraceItables and PrintVtables to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/dda74d89ee09 > 8146481: Disable runtime/logging/DefaultMethodsTest.java > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/fd60a8853157 > 8145606: [TESTBUG] MonitorInflationTest.java should be rewritten to be more > predictable > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/0c82805adfc5 > 8141211: Convert TraceExceptions to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/a9a101b70a85 > 8145445: [TESTBUG] runtime/logging tests need to properly build and import > libraries > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/432ae0f42a2c > 8145629: Disable test/runtime/logging/MonitorInflationTest.java > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/8512cbf64495 > 8145153: Convert TraceMonitorInflation to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/1f1e6bc1c947 > 8144536: Clean up Unified Logging test directory > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/fb4a19e4f7dc > 8143155: Remove TraceRuntimeCalls, TraceJNICalls, and TraceJVMCalls rather than > convert to UL > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/fd83b8307473 > 8143157: Convert TraceVMOperation to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/a7ffcce47ffb > 8142437: SafepointTest.java is occasionally failing in JPRT > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/766ae06f30ca > 8138916: Logging write function does not allow for long enough messages > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/9c99ce707b0b > 8140348: Convert TraceSafepoint to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/96773453776a > 8139564: Convert TraceDefaultMethods to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/43a1e4ca7ee4 > 8138574: [TESTBUG] TestBasicLogOutput.java doesn't account for padding > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/e13d7fa76fac > 8133561: linux thread id should be reported in decimal in the error reports now > From christian.tornqvist at oracle.com Mon Feb 22 20:34:59 2016 From: christian.tornqvist at oracle.com (Christian Tornqvist) Date: Mon, 22 Feb 2016 15:34:59 -0500 Subject: CFV: New JDK 9 Committer: Rachel Protacio In-Reply-To: <56CB5939.6090704@oracle.com> References: <56CB5939.6090704@oracle.com> Message-ID: Vote: yes > On Feb 22, 2016, at 1:53 PM, Coleen Phillimore wrote: > > I hereby nominate Rachel Protacio (rprotacio) to JDK 9 Committer. > > Rachel is a member of the Hotspot runtime team and has contributed 21 changes [3] to the OpenJDK hotspot repository. She has converted 8 Trace options to the new Unified Logging framework, fixed unified logging tests because of an overambitious testing strategy, and also fixed a significant bug in the UL framework. > > Votes are due by 2:00 PM EST, Monday March 7, 2016. > > Only current JDK 9 Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Coleen Phillimore > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] List of patches: > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/66a81854aa5d > 8149383: Convert TraceBiasedLocking to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/eda0d9992163 > 8148630: Convert TraceStartupTime to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/1ac9a5e38143 > 8146137: runtime/logging/ExceptionsTest.java fails on embedded and ARM test > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/45c4d55c36f5 > 8146435: [TESTBUG] Logging tests are failing intermittently on windows when executed by JPRT > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/42a4b9a221cc > 8144953: runtime/CommandLine/TraceExceptionsTest.java fails when exception is thrown in compiled code > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/50dd5b051754 > 8141564: Convert TraceItables and PrintVtables to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/dda74d89ee09 > 8146481: Disable runtime/logging/DefaultMethodsTest.java > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/fd60a8853157 > 8145606: [TESTBUG] MonitorInflationTest.java should be rewritten to be more predictable > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/0c82805adfc5 > 8141211: Convert TraceExceptions to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/a9a101b70a85 > 8145445: [TESTBUG] runtime/logging tests need to properly build and import libraries > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/432ae0f42a2c > 8145629: Disable test/runtime/logging/MonitorInflationTest.java > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/8512cbf64495 > 8145153: Convert TraceMonitorInflation to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/1f1e6bc1c947 > 8144536: Clean up Unified Logging test directory > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/fb4a19e4f7dc > 8143155: Remove TraceRuntimeCalls, TraceJNICalls, and TraceJVMCalls rather than convert to UL > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/fd83b8307473 > 8143157: Convert TraceVMOperation to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/a7ffcce47ffb > 8142437: SafepointTest.java is occasionally failing in JPRT > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/766ae06f30ca > 8138916: Logging write function does not allow for long enough messages > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/9c99ce707b0b > 8140348: Convert TraceSafepoint to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/96773453776a > 8139564: Convert TraceDefaultMethods to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/43a1e4ca7ee4 > 8138574: [TESTBUG] TestBasicLogOutput.java doesn't account for padding > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/e13d7fa76fac > 8133561: linux thread id should be reported in decimal in the error reports now > From serguei.spitsyn at oracle.com Mon Feb 22 20:45:48 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 22 Feb 2016 12:45:48 -0800 Subject: CFV: New JDK 9 Committer: Rachel Protacio In-Reply-To: <56CB5939.6090704@oracle.com> References: <56CB5939.6090704@oracle.com> Message-ID: <56CB737C.30406@oracle.com> Vote: yes From stuart.marks at oracle.com Mon Feb 22 22:32:27 2016 From: stuart.marks at oracle.com (Stuart Marks) Date: Mon, 22 Feb 2016 14:32:27 -0800 Subject: CFV: New jdk9 Reviewer: Claes Redestad In-Reply-To: <56BCB736.80804@oracle.com> References: <56BCB736.80804@oracle.com> Message-ID: <56CB8C7B.5070404@oracle.com> Vote: yes On 2/11/16 8:30 AM, Vladimir Ivanov wrote: > I hereby nominate Claes Redestad (OpenJDK user name: redestad) to JDK > 9 Reviewer. > > Claes is a member of the Java SE Performance team. He contributed 50 changesets > to jdk9 project [1] [2] and he is qualified to be a Reviewer. > > Among other things, Claes did numerous performance improvements in > java.lang.invoke implementation and Project Jigsaw [3]. > > Votes are due by February, 25 2016. > > Only current JDK 9 Reviewers [4] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [5]. > > Best regards, > Vladimir Ivanov > > [1] > http://hg.openjdk.java.net/jdk9/dev/jdk/search/?rev=author%28redestad%29&revcount=100 > > [2] > http://hg.openjdk.java.net/jdk9/dev/hotspot/search/?rev=author%28redestad%29&revcount=100 > > [3] http://hg.openjdk.java.net/jigsaw/jake/jdk/log?rev=author%28redestad%29 > [4] http://openjdk.java.net/census#jdk9 > [5] http://openjdk.java.net/projects#committer-vote From daniel.daugherty at oracle.com Mon Feb 22 23:38:43 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 22 Feb 2016 16:38:43 -0700 Subject: CFV: New JDK 9 Committer: Rachel Protacio In-Reply-To: <56CB5939.6090704@oracle.com> References: <56CB5939.6090704@oracle.com> Message-ID: <56CB9C03.50500@oracle.com> Vote: yes Dan On 2/22/16 11:53 AM, Coleen Phillimore wrote: > I hereby nominate Rachel Protacio (rprotacio) to JDK 9 Committer. > > Rachel is a member of the Hotspot runtime team and has contributed 21 > changes [3] to the OpenJDK hotspot repository. She has converted 8 > Trace options to the new Unified Logging framework, fixed unified > logging tests because of an overambitious testing strategy, and also > fixed a significant bug in the UL framework. > > Votes are due by 2:00 PM EST, Monday March 7, 2016. > > Only current JDK 9 Committers [1] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Lazy Consensus voting instructions, see [2]. > > Coleen Phillimore > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] List of patches: > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/66a81854aa5d > 8149383: Convert TraceBiasedLocking to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/eda0d9992163 > 8148630: Convert TraceStartupTime to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/1ac9a5e38143 > 8146137: runtime/logging/ExceptionsTest.java fails on embedded and ARM > test > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/45c4d55c36f5 > 8146435: [TESTBUG] Logging tests are failing intermittently on windows > when executed by JPRT > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/42a4b9a221cc > 8144953: runtime/CommandLine/TraceExceptionsTest.java fails when > exception is thrown in compiled code > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/50dd5b051754 > 8141564: Convert TraceItables and PrintVtables to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/dda74d89ee09 > 8146481: Disable runtime/logging/DefaultMethodsTest.java > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/fd60a8853157 > 8145606: [TESTBUG] MonitorInflationTest.java should be rewritten to be > more predictable > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/0c82805adfc5 > 8141211: Convert TraceExceptions to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/a9a101b70a85 > 8145445: [TESTBUG] runtime/logging tests need to properly build and > import libraries > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/432ae0f42a2c > 8145629: Disable test/runtime/logging/MonitorInflationTest.java > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/8512cbf64495 > 8145153: Convert TraceMonitorInflation to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/1f1e6bc1c947 > 8144536: Clean up Unified Logging test directory > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/fb4a19e4f7dc > 8143155: Remove TraceRuntimeCalls, TraceJNICalls, and TraceJVMCalls > rather than convert to UL > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/fd83b8307473 > 8143157: Convert TraceVMOperation to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/a7ffcce47ffb > 8142437: SafepointTest.java is occasionally failing in JPRT > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/766ae06f30ca > 8138916: Logging write function does not allow for long enough messages > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/9c99ce707b0b > 8140348: Convert TraceSafepoint to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/96773453776a > 8139564: Convert TraceDefaultMethods to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/43a1e4ca7ee4 > 8138574: [TESTBUG] TestBasicLogOutput.java doesn't account for padding > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/e13d7fa76fac > 8133561: linux thread id should be reported in decimal in the error > reports now > > From david.holmes at oracle.com Tue Feb 23 00:22:01 2016 From: david.holmes at oracle.com (David Holmes) Date: Tue, 23 Feb 2016 10:22:01 +1000 Subject: CFV: New JDK 9 Committer: Rachel Protacio In-Reply-To: <56CB5939.6090704@oracle.com> References: <56CB5939.6090704@oracle.com> Message-ID: <56CBA629.5080502@oracle.com> Vote: yes David On 23/02/2016 4:53 AM, Coleen Phillimore wrote: > I hereby nominate Rachel Protacio (rprotacio) to JDK 9 Committer. > > Rachel is a member of the Hotspot runtime team and has contributed 21 > changes [3] to the OpenJDK hotspot repository. She has converted 8 > Trace options to the new Unified Logging framework, fixed unified > logging tests because of an overambitious testing strategy, and also > fixed a significant bug in the UL framework. > > Votes are due by 2:00 PM EST, Monday March 7, 2016. > > Only current JDK 9 Committers [1] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Lazy Consensus voting instructions, see [2]. > > Coleen Phillimore > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] List of patches: > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/66a81854aa5d > 8149383: Convert TraceBiasedLocking to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/eda0d9992163 > 8148630: Convert TraceStartupTime to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/1ac9a5e38143 > 8146137: runtime/logging/ExceptionsTest.java fails on embedded and ARM test > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/45c4d55c36f5 > 8146435: [TESTBUG] Logging tests are failing intermittently on windows > when executed by JPRT > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/42a4b9a221cc > 8144953: runtime/CommandLine/TraceExceptionsTest.java fails when > exception is thrown in compiled code > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/50dd5b051754 > 8141564: Convert TraceItables and PrintVtables to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/dda74d89ee09 > 8146481: Disable runtime/logging/DefaultMethodsTest.java > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/fd60a8853157 > 8145606: [TESTBUG] MonitorInflationTest.java should be rewritten to be > more predictable > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/0c82805adfc5 > 8141211: Convert TraceExceptions to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/a9a101b70a85 > 8145445: [TESTBUG] runtime/logging tests need to properly build and > import libraries > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/432ae0f42a2c > 8145629: Disable test/runtime/logging/MonitorInflationTest.java > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/8512cbf64495 > 8145153: Convert TraceMonitorInflation to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/1f1e6bc1c947 > 8144536: Clean up Unified Logging test directory > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/fb4a19e4f7dc > 8143155: Remove TraceRuntimeCalls, TraceJNICalls, and TraceJVMCalls > rather than convert to UL > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/fd83b8307473 > 8143157: Convert TraceVMOperation to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/a7ffcce47ffb > 8142437: SafepointTest.java is occasionally failing in JPRT > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/766ae06f30ca > 8138916: Logging write function does not allow for long enough messages > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/9c99ce707b0b > 8140348: Convert TraceSafepoint to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/96773453776a > 8139564: Convert TraceDefaultMethods to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/43a1e4ca7ee4 > 8138574: [TESTBUG] TestBasicLogOutput.java doesn't account for padding > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/e13d7fa76fac > 8133561: linux thread id should be reported in decimal in the error > reports now > From staffan.larsen at oracle.com Tue Feb 23 00:34:43 2016 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 22 Feb 2016 16:34:43 -0800 Subject: CFV: New JDK 9 Committer: Rachel Protacio In-Reply-To: <56CB5939.6090704@oracle.com> References: <56CB5939.6090704@oracle.com> Message-ID: Vote: yes > On 22 feb. 2016, at 10:53, Coleen Phillimore wrote: > > I hereby nominate Rachel Protacio (rprotacio) to JDK 9 Committer. > > Rachel is a member of the Hotspot runtime team and has contributed 21 changes [3] to the OpenJDK hotspot repository. She has converted 8 Trace options to the new Unified Logging framework, fixed unified logging tests because of an overambitious testing strategy, and also fixed a significant bug in the UL framework. > > Votes are due by 2:00 PM EST, Monday March 7, 2016. > > Only current JDK 9 Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Coleen Phillimore > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] List of patches: > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/66a81854aa5d > 8149383: Convert TraceBiasedLocking to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/eda0d9992163 > 8148630: Convert TraceStartupTime to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/1ac9a5e38143 > 8146137: runtime/logging/ExceptionsTest.java fails on embedded and ARM test > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/45c4d55c36f5 > 8146435: [TESTBUG] Logging tests are failing intermittently on windows when executed by JPRT > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/42a4b9a221cc > 8144953: runtime/CommandLine/TraceExceptionsTest.java fails when exception is thrown in compiled code > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/50dd5b051754 > 8141564: Convert TraceItables and PrintVtables to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/dda74d89ee09 > 8146481: Disable runtime/logging/DefaultMethodsTest.java > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/fd60a8853157 > 8145606: [TESTBUG] MonitorInflationTest.java should be rewritten to be more predictable > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/0c82805adfc5 > 8141211: Convert TraceExceptions to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/a9a101b70a85 > 8145445: [TESTBUG] runtime/logging tests need to properly build and import libraries > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/432ae0f42a2c > 8145629: Disable test/runtime/logging/MonitorInflationTest.java > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/8512cbf64495 > 8145153: Convert TraceMonitorInflation to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/1f1e6bc1c947 > 8144536: Clean up Unified Logging test directory > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/fb4a19e4f7dc > 8143155: Remove TraceRuntimeCalls, TraceJNICalls, and TraceJVMCalls rather than convert to UL > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/fd83b8307473 > 8143157: Convert TraceVMOperation to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/a7ffcce47ffb > 8142437: SafepointTest.java is occasionally failing in JPRT > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/766ae06f30ca > 8138916: Logging write function does not allow for long enough messages > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/9c99ce707b0b > 8140348: Convert TraceSafepoint to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/96773453776a > 8139564: Convert TraceDefaultMethods to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/43a1e4ca7ee4 > 8138574: [TESTBUG] TestBasicLogOutput.java doesn't account for padding > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/e13d7fa76fac > 8133561: linux thread id should be reported in decimal in the error reports now > From kim.barrett at oracle.com Tue Feb 23 03:58:27 2016 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 22 Feb 2016 22:58:27 -0500 Subject: CFV: New JDK 9 Committer: Rachel Protacio In-Reply-To: <56CB5939.6090704@oracle.com> References: <56CB5939.6090704@oracle.com> Message-ID: <30BF3243-2880-4232-84FA-A4871F33740B@oracle.com> vote: yes > On Feb 22, 2016, at 1:53 PM, Coleen Phillimore wrote: > > I hereby nominate Rachel Protacio (rprotacio) to JDK 9 Committer. > > Rachel is a member of the Hotspot runtime team and has contributed 21 changes [3] to the OpenJDK hotspot repository. She has converted 8 Trace options to the new Unified Logging framework, fixed unified logging tests because of an overambitious testing strategy, and also fixed a significant bug in the UL framework. > > Votes are due by 2:00 PM EST, Monday March 7, 2016. > > Only current JDK 9 Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Coleen Phillimore From volker.simonis at gmail.com Tue Feb 23 07:45:00 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 23 Feb 2016 08:45:00 +0100 Subject: CFV: New JDK 9 Committer: Rachel Protacio In-Reply-To: <56CB5939.6090704@oracle.com> References: <56CB5939.6090704@oracle.com> Message-ID: Vote: yes On Mon, Feb 22, 2016 at 7:53 PM, Coleen Phillimore wrote: > I hereby nominate Rachel Protacio (rprotacio) to JDK 9 Committer. > > Rachel is a member of the Hotspot runtime team and has contributed 21 > changes [3] to the OpenJDK hotspot repository. She has converted 8 Trace > options to the new Unified Logging framework, fixed unified logging tests > because of an overambitious testing strategy, and also fixed a significant > bug in the UL framework. > > Votes are due by 2:00 PM EST, Monday March 7, 2016. > > Only current JDK 9 Committers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Coleen Phillimore > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] List of patches: > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/66a81854aa5d > 8149383: Convert TraceBiasedLocking to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/eda0d9992163 > 8148630: Convert TraceStartupTime to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/1ac9a5e38143 > 8146137: runtime/logging/ExceptionsTest.java fails on embedded and ARM test > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/45c4d55c36f5 > 8146435: [TESTBUG] Logging tests are failing intermittently on windows when > executed by JPRT > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/42a4b9a221cc > 8144953: runtime/CommandLine/TraceExceptionsTest.java fails when exception > is thrown in compiled code > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/50dd5b051754 > 8141564: Convert TraceItables and PrintVtables to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/dda74d89ee09 > 8146481: Disable runtime/logging/DefaultMethodsTest.java > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/fd60a8853157 > 8145606: [TESTBUG] MonitorInflationTest.java should be rewritten to be more > predictable > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/0c82805adfc5 > 8141211: Convert TraceExceptions to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/a9a101b70a85 > 8145445: [TESTBUG] runtime/logging tests need to properly build and import > libraries > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/432ae0f42a2c > 8145629: Disable test/runtime/logging/MonitorInflationTest.java > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/8512cbf64495 > 8145153: Convert TraceMonitorInflation to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/1f1e6bc1c947 > 8144536: Clean up Unified Logging test directory > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/fb4a19e4f7dc > 8143155: Remove TraceRuntimeCalls, TraceJNICalls, and TraceJVMCalls rather > than convert to UL > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/fd83b8307473 > 8143157: Convert TraceVMOperation to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/a7ffcce47ffb > 8142437: SafepointTest.java is occasionally failing in JPRT > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/766ae06f30ca > 8138916: Logging write function does not allow for long enough messages > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/9c99ce707b0b > 8140348: Convert TraceSafepoint to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/96773453776a > 8139564: Convert TraceDefaultMethods to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/43a1e4ca7ee4 > 8138574: [TESTBUG] TestBasicLogOutput.java doesn't account for padding > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/e13d7fa76fac > 8133561: linux thread id should be reported in decimal in the error reports > now > From zoltan.majo at oracle.com Tue Feb 23 07:53:14 2016 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Tue, 23 Feb 2016 08:53:14 +0100 Subject: CFV: New JDK 9 Committer: Rachel Protacio In-Reply-To: <56CB5939.6090704@oracle.com> References: <56CB5939.6090704@oracle.com> Message-ID: <56CC0FEA.4080908@oracle.com> Vote: yes. Best regards, Zoltan On 02/22/2016 07:53 PM, Coleen Phillimore wrote: > I hereby nominate Rachel Protacio (rprotacio) to JDK 9 Committer. > > Rachel is a member of the Hotspot runtime team and has contributed 21 > changes [3] to the OpenJDK hotspot repository. She has converted 8 > Trace options to the new Unified Logging framework, fixed unified > logging tests because of an overambitious testing strategy, and also > fixed a significant bug in the UL framework. > > Votes are due by 2:00 PM EST, Monday March 7, 2016. > > Only current JDK 9 Committers [1] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Lazy Consensus voting instructions, see [2]. > > Coleen Phillimore > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] List of patches: > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/66a81854aa5d > 8149383: Convert TraceBiasedLocking to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/eda0d9992163 > 8148630: Convert TraceStartupTime to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/1ac9a5e38143 > 8146137: runtime/logging/ExceptionsTest.java fails on embedded and ARM > test > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/45c4d55c36f5 > 8146435: [TESTBUG] Logging tests are failing intermittently on windows > when executed by JPRT > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/42a4b9a221cc > 8144953: runtime/CommandLine/TraceExceptionsTest.java fails when > exception is thrown in compiled code > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/50dd5b051754 > 8141564: Convert TraceItables and PrintVtables to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/dda74d89ee09 > 8146481: Disable runtime/logging/DefaultMethodsTest.java > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/fd60a8853157 > 8145606: [TESTBUG] MonitorInflationTest.java should be rewritten to be > more predictable > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/0c82805adfc5 > 8141211: Convert TraceExceptions to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/a9a101b70a85 > 8145445: [TESTBUG] runtime/logging tests need to properly build and > import libraries > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/432ae0f42a2c > 8145629: Disable test/runtime/logging/MonitorInflationTest.java > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/8512cbf64495 > 8145153: Convert TraceMonitorInflation to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/1f1e6bc1c947 > 8144536: Clean up Unified Logging test directory > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/fb4a19e4f7dc > 8143155: Remove TraceRuntimeCalls, TraceJNICalls, and TraceJVMCalls > rather than convert to UL > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/fd83b8307473 > 8143157: Convert TraceVMOperation to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/a7ffcce47ffb > 8142437: SafepointTest.java is occasionally failing in JPRT > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/766ae06f30ca > 8138916: Logging write function does not allow for long enough messages > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/9c99ce707b0b > 8140348: Convert TraceSafepoint to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/96773453776a > 8139564: Convert TraceDefaultMethods to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/43a1e4ca7ee4 > 8138574: [TESTBUG] TestBasicLogOutput.java doesn't account for padding > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/e13d7fa76fac > 8133561: linux thread id should be reported in decimal in the error > reports now > From bengt.rutisson at oracle.com Tue Feb 23 08:01:31 2016 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Tue, 23 Feb 2016 09:01:31 +0100 Subject: CFV: New JDK 9 Committer: Rachel Protacio In-Reply-To: <56CB5939.6090704@oracle.com> References: <56CB5939.6090704@oracle.com> Message-ID: <56CC11DB.5090108@oracle.com> Vote: yes Bengt On 2016-02-22 19:53, Coleen Phillimore wrote: > I hereby nominate Rachel Protacio (rprotacio) to JDK 9 Committer. > > Rachel is a member of the Hotspot runtime team and has contributed 21 > changes [3] to the OpenJDK hotspot repository. She has converted 8 > Trace options to the new Unified Logging framework, fixed unified > logging tests because of an overambitious testing strategy, and also > fixed a significant bug in the UL framework. > > Votes are due by 2:00 PM EST, Monday March 7, 2016. > > Only current JDK 9 Committers [1] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Lazy Consensus voting instructions, see [2]. > > Coleen Phillimore > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] List of patches: > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/66a81854aa5d > 8149383: Convert TraceBiasedLocking to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/eda0d9992163 > 8148630: Convert TraceStartupTime to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/1ac9a5e38143 > 8146137: runtime/logging/ExceptionsTest.java fails on embedded and ARM > test > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/45c4d55c36f5 > 8146435: [TESTBUG] Logging tests are failing intermittently on windows > when executed by JPRT > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/42a4b9a221cc > 8144953: runtime/CommandLine/TraceExceptionsTest.java fails when > exception is thrown in compiled code > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/50dd5b051754 > 8141564: Convert TraceItables and PrintVtables to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/dda74d89ee09 > 8146481: Disable runtime/logging/DefaultMethodsTest.java > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/fd60a8853157 > 8145606: [TESTBUG] MonitorInflationTest.java should be rewritten to be > more predictable > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/0c82805adfc5 > 8141211: Convert TraceExceptions to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/a9a101b70a85 > 8145445: [TESTBUG] runtime/logging tests need to properly build and > import libraries > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/432ae0f42a2c > 8145629: Disable test/runtime/logging/MonitorInflationTest.java > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/8512cbf64495 > 8145153: Convert TraceMonitorInflation to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/1f1e6bc1c947 > 8144536: Clean up Unified Logging test directory > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/fb4a19e4f7dc > 8143155: Remove TraceRuntimeCalls, TraceJNICalls, and TraceJVMCalls > rather than convert to UL > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/fd83b8307473 > 8143157: Convert TraceVMOperation to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/a7ffcce47ffb > 8142437: SafepointTest.java is occasionally failing in JPRT > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/766ae06f30ca > 8138916: Logging write function does not allow for long enough messages > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/9c99ce707b0b > 8140348: Convert TraceSafepoint to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/96773453776a > 8139564: Convert TraceDefaultMethods to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/43a1e4ca7ee4 > 8138574: [TESTBUG] TestBasicLogOutput.java doesn't account for padding > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/e13d7fa76fac > 8133561: linux thread id should be reported in decimal in the error > reports now > From tobias.hartmann at oracle.com Tue Feb 23 08:05:49 2016 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 23 Feb 2016 09:05:49 +0100 Subject: CFV: New JDK 9 Committer: Rachel Protacio In-Reply-To: <56CB5939.6090704@oracle.com> References: <56CB5939.6090704@oracle.com> Message-ID: <56CC12DD.6010300@oracle.com> Vote: yes Tobias On 22.02.2016 19:53, Coleen Phillimore wrote: > I hereby nominate Rachel Protacio (rprotacio) to JDK 9 Committer. > > Rachel is a member of the Hotspot runtime team and has contributed 21 changes [3] to the OpenJDK hotspot repository. She has converted 8 Trace options to the new Unified Logging framework, fixed unified logging tests because of an overambitious testing strategy, and also fixed a significant bug in the UL framework. > > Votes are due by 2:00 PM EST, Monday March 7, 2016. > > Only current JDK 9 Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Coleen Phillimore > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] List of patches: > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/66a81854aa5d > 8149383: Convert TraceBiasedLocking to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/eda0d9992163 > 8148630: Convert TraceStartupTime to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/1ac9a5e38143 > 8146137: runtime/logging/ExceptionsTest.java fails on embedded and ARM test > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/45c4d55c36f5 > 8146435: [TESTBUG] Logging tests are failing intermittently on windows when executed by JPRT > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/42a4b9a221cc > 8144953: runtime/CommandLine/TraceExceptionsTest.java fails when exception is thrown in compiled code > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/50dd5b051754 > 8141564: Convert TraceItables and PrintVtables to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/dda74d89ee09 > 8146481: Disable runtime/logging/DefaultMethodsTest.java > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/fd60a8853157 > 8145606: [TESTBUG] MonitorInflationTest.java should be rewritten to be more predictable > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/0c82805adfc5 > 8141211: Convert TraceExceptions to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/a9a101b70a85 > 8145445: [TESTBUG] runtime/logging tests need to properly build and import libraries > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/432ae0f42a2c > 8145629: Disable test/runtime/logging/MonitorInflationTest.java > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/8512cbf64495 > 8145153: Convert TraceMonitorInflation to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/1f1e6bc1c947 > 8144536: Clean up Unified Logging test directory > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/fb4a19e4f7dc > 8143155: Remove TraceRuntimeCalls, TraceJNICalls, and TraceJVMCalls rather than convert to UL > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/fd83b8307473 > 8143157: Convert TraceVMOperation to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/a7ffcce47ffb > 8142437: SafepointTest.java is occasionally failing in JPRT > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/766ae06f30ca > 8138916: Logging write function does not allow for long enough messages > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/9c99ce707b0b > 8140348: Convert TraceSafepoint to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/96773453776a > 8139564: Convert TraceDefaultMethods to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/43a1e4ca7ee4 > 8138574: [TESTBUG] TestBasicLogOutput.java doesn't account for padding > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/e13d7fa76fac > 8133561: linux thread id should be reported in decimal in the error reports now > From mikael.gerdin at oracle.com Tue Feb 23 08:51:52 2016 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Tue, 23 Feb 2016 09:51:52 +0100 Subject: CFV: New JDK 9 Committer: Rachel Protacio In-Reply-To: <56CB5939.6090704@oracle.com> References: <56CB5939.6090704@oracle.com> Message-ID: <56CC1DA8.5000606@oracle.com> Vote: yes /Mikael On 2016-02-22 19:53, Coleen Phillimore wrote: > I hereby nominate Rachel Protacio (rprotacio) to JDK 9 Committer. > > Rachel is a member of the Hotspot runtime team and has contributed 21 > changes [3] to the OpenJDK hotspot repository. She has converted 8 > Trace options to the new Unified Logging framework, fixed unified > logging tests because of an overambitious testing strategy, and also > fixed a significant bug in the UL framework. > > Votes are due by 2:00 PM EST, Monday March 7, 2016. > > Only current JDK 9 Committers [1] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Lazy Consensus voting instructions, see [2]. > > Coleen Phillimore > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] List of patches: > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/66a81854aa5d > 8149383: Convert TraceBiasedLocking to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/eda0d9992163 > 8148630: Convert TraceStartupTime to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/1ac9a5e38143 > 8146137: runtime/logging/ExceptionsTest.java fails on embedded and ARM test > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/45c4d55c36f5 > 8146435: [TESTBUG] Logging tests are failing intermittently on windows > when executed by JPRT > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/42a4b9a221cc > 8144953: runtime/CommandLine/TraceExceptionsTest.java fails when > exception is thrown in compiled code > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/50dd5b051754 > 8141564: Convert TraceItables and PrintVtables to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/dda74d89ee09 > 8146481: Disable runtime/logging/DefaultMethodsTest.java > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/fd60a8853157 > 8145606: [TESTBUG] MonitorInflationTest.java should be rewritten to be > more predictable > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/0c82805adfc5 > 8141211: Convert TraceExceptions to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/a9a101b70a85 > 8145445: [TESTBUG] runtime/logging tests need to properly build and > import libraries > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/432ae0f42a2c > 8145629: Disable test/runtime/logging/MonitorInflationTest.java > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/8512cbf64495 > 8145153: Convert TraceMonitorInflation to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/1f1e6bc1c947 > 8144536: Clean up Unified Logging test directory > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/fb4a19e4f7dc > 8143155: Remove TraceRuntimeCalls, TraceJNICalls, and TraceJVMCalls > rather than convert to UL > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/fd83b8307473 > 8143157: Convert TraceVMOperation to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/a7ffcce47ffb > 8142437: SafepointTest.java is occasionally failing in JPRT > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/766ae06f30ca > 8138916: Logging write function does not allow for long enough messages > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/9c99ce707b0b > 8140348: Convert TraceSafepoint to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/96773453776a > 8139564: Convert TraceDefaultMethods to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/43a1e4ca7ee4 > 8138574: [TESTBUG] TestBasicLogOutput.java doesn't account for padding > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/e13d7fa76fac > 8133561: linux thread id should be reported in decimal in the error > reports now > From thomas.schatzl at oracle.com Tue Feb 23 10:49:09 2016 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 23 Feb 2016 11:49:09 +0100 Subject: CFV: New jdk9 Reviewer: Claes Redestad In-Reply-To: <56CB8C7B.5070404@oracle.com> References: <56BCB736.80804@oracle.com> <56CB8C7B.5070404@oracle.com> Message-ID: <1456224549.2262.21.camel@oracle.com> Vote: yes Thanks, Thomas From dalibor.topic at oracle.com Tue Feb 23 13:23:02 2016 From: dalibor.topic at oracle.com (dalibor topic) Date: Tue, 23 Feb 2016 14:23:02 +0100 Subject: CFV: New JDK 9 Committer: Rachel Protacio In-Reply-To: <56CB5939.6090704@oracle.com> References: <56CB5939.6090704@oracle.com> Message-ID: <56CC5D36.30005@oracle.com> Vote: Yes. -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From volker.simonis at gmail.com Tue Feb 23 14:19:16 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 23 Feb 2016 15:19:16 +0100 Subject: RFR #2 (M) 8148146: Integrate new internal Unsafe entry points, and basic intrinsic support for VarHandles In-Reply-To: References: <56C1C2ED.10702@oracle.com> <56C1D137.5020607@redhat.com> <56C1D764.6020100@oracle.com> <56C1DD24.2060503@redhat.com> <56C394A0.2010606@redhat.com> <56C4588A.4070505@oracle.com> <56C4C6F6.8040709@oracle.com> <56C4CD2A.1000701@oracle.com> Message-ID: Hi Aleksey, sorry for the delay. Your change builds and runs fine on ppc64. Still haven't had time to look at the possible optimizations and intrinsics on ppc64 but I think that can and should be done in a follow up change. So from my side you can go ahead and push. Regards, Volker On Thu, Feb 18, 2016 at 8:47 AM, Volker Simonis wrote: > On Wed, Feb 17, 2016 at 8:42 PM, Aleksey Shipilev > wrote: >> On 02/17/2016 10:16 PM, Vladimir Kozlov wrote: >>> In general it looks good to me. >> >> Thanks Vladimir! >> >>> My main question is about implementation of new functionality on >>> other platforms. When it will be done? Yes, it works now because you >>> have guard match_rule_supported(). But we usually do implementation >>> on platforms at least as separate RFE. What is your plan? >> >> We have multiple subtasks for AArch64, SPARC and Power under VarHandles >> umbrella: >> https://bugs.openjdk.java.net/browse/JDK-8080588 >> >> Hopefully we will address them after/concurrently-with the bulk of >> VarHandles changes settle into mainline. But we need to get some basic >> code in mainline to build on. >> >> >>> SAP guys should also test it on PPC64. >> >> Volker, Goetz, I would appreciate if you can give it a spin! >> > > Sorry, I only saw this thread yesterday. I'll start now right away > with looking into it and testing it on ppc64. > > Regards, > Volker > >> >>> What test/compiler/unsafe/generate-unsafe-tests.sh is for? It is not >>> used by regression testing as far as I see. >> >> The script (re)generates the tests from the template, and is supposed to >> be run manually when test template had changed. The >> test/compiler/unsafe/ tests you see in the webrev were generated by that >> script. >> >>> And please, push it into hs-comp for nightly testing. >> >> That's was the plan, I should have said that from the beginning. >> >> Cheers, >> -Aleksey >> From aleksey.shipilev at oracle.com Tue Feb 23 14:39:17 2016 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Tue, 23 Feb 2016 17:39:17 +0300 Subject: RFR #2 (M) 8148146: Integrate new internal Unsafe entry points, and basic intrinsic support for VarHandles In-Reply-To: References: <56C1C2ED.10702@oracle.com> <56C1D137.5020607@redhat.com> <56C1D764.6020100@oracle.com> <56C1DD24.2060503@redhat.com> <56C394A0.2010606@redhat.com> <56C4588A.4070505@oracle.com> <56C4C6F6.8040709@oracle.com> <56C4CD2A.1000701@oracle.com> Message-ID: <56CC6F15.9060207@oracle.com> On 02/23/2016 05:19 PM, Volker Simonis wrote: > So from my side you can go ahead and push. Thanks Volker! Now that we have general blessings from Vladimir Kozlov and John Rose, Andrew Dinn on AArch64, and Volker Simonis on PPC64. There are also pending Unsafe cleanup changes from Mikael Vidstedt, but we negotiated that VarHandles change should go first. Therefore, I'd like to push these today: http://cr.openjdk.java.net/~shade/8148146/webrev.hs.03/ http://cr.openjdk.java.net/~shade/8148146/webrev.jdk.03/ Cheers, -Aleksey From Roger.Riggs at Oracle.com Tue Feb 23 15:05:18 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Tue, 23 Feb 2016 10:05:18 -0500 Subject: CFV: New JDK 9 Committer: Rachel Protacio In-Reply-To: <56CB5939.6090704@oracle.com> References: <56CB5939.6090704@oracle.com> Message-ID: <56CC752E.1080109@Oracle.com> Vote: Yes On 2/22/2016 1:53 PM, Coleen Phillimore wrote: > I hereby nominate Rachel Protacio (rprotacio) to JDK 9 Committer. From stefan.johansson at oracle.com Tue Feb 23 15:10:05 2016 From: stefan.johansson at oracle.com (Stefan Johansson) Date: Tue, 23 Feb 2016 16:10:05 +0100 Subject: CFV: New JDK 9 Committer: Rachel Protacio In-Reply-To: <56CB5939.6090704@oracle.com> References: <56CB5939.6090704@oracle.com> Message-ID: <56CC764D.5000403@oracle.com> Vote: yes. Stefan On 2016-02-22 19:53, Coleen Phillimore wrote: > I hereby nominate Rachel Protacio (rprotacio) to JDK 9 Committer. > > Rachel is a member of the Hotspot runtime team and has contributed 21 > changes [3] to the OpenJDK hotspot repository. She has converted 8 > Trace options to the new Unified Logging framework, fixed unified > logging tests because of an overambitious testing strategy, and also > fixed a significant bug in the UL framework. > > Votes are due by 2:00 PM EST, Monday March 7, 2016. > > Only current JDK 9 Committers [1] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Lazy Consensus voting instructions, see [2]. > > Coleen Phillimore > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] List of patches: > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/66a81854aa5d > 8149383: Convert TraceBiasedLocking to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/eda0d9992163 > 8148630: Convert TraceStartupTime to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/1ac9a5e38143 > 8146137: runtime/logging/ExceptionsTest.java fails on embedded and ARM > test > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/45c4d55c36f5 > 8146435: [TESTBUG] Logging tests are failing intermittently on windows > when executed by JPRT > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/42a4b9a221cc > 8144953: runtime/CommandLine/TraceExceptionsTest.java fails when > exception is thrown in compiled code > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/50dd5b051754 > 8141564: Convert TraceItables and PrintVtables to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/dda74d89ee09 > 8146481: Disable runtime/logging/DefaultMethodsTest.java > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/fd60a8853157 > 8145606: [TESTBUG] MonitorInflationTest.java should be rewritten to be > more predictable > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/0c82805adfc5 > 8141211: Convert TraceExceptions to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/a9a101b70a85 > 8145445: [TESTBUG] runtime/logging tests need to properly build and > import libraries > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/432ae0f42a2c > 8145629: Disable test/runtime/logging/MonitorInflationTest.java > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/8512cbf64495 > 8145153: Convert TraceMonitorInflation to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/1f1e6bc1c947 > 8144536: Clean up Unified Logging test directory > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/fb4a19e4f7dc > 8143155: Remove TraceRuntimeCalls, TraceJNICalls, and TraceJVMCalls > rather than convert to UL > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/fd83b8307473 > 8143157: Convert TraceVMOperation to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/a7ffcce47ffb > 8142437: SafepointTest.java is occasionally failing in JPRT > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/766ae06f30ca > 8138916: Logging write function does not allow for long enough messages > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/9c99ce707b0b > 8140348: Convert TraceSafepoint to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/96773453776a > 8139564: Convert TraceDefaultMethods to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/43a1e4ca7ee4 > 8138574: [TESTBUG] TestBasicLogOutput.java doesn't account for padding > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/e13d7fa76fac > 8133561: linux thread id should be reported in decimal in the error > reports now > From forax at univ-mlv.fr Tue Feb 23 20:10:42 2016 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 23 Feb 2016 21:10:42 +0100 (CET) Subject: RFR JDK-8149644 Integrate VarHandles In-Reply-To: <5ABD11CF-407C-4BAD-95A7-E267C5F1682D@oracle.com> References: <9C47EF6F-80D6-467E-A5CB-2FDD5FF6AE17@oracle.com> <56C1D973.3060802@oracle.com> <1533888573.323371.1455548322267.JavaMail.zimbra@u-pem.fr> <531723180.551702.1455576328083.JavaMail.zimbra@u-pem.fr> <5ABD11CF-407C-4BAD-95A7-E267C5F1682D@oracle.com> Message-ID: <647685396.1040286.1456258242492.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Paul Sandoz" > Cc: "jdk9-dev" , "hotspot-dev developers" > Envoy?: Mardi 16 F?vrier 2016 10:33:35 > Objet: Re: RFR JDK-8149644 Integrate VarHandles > > > > On 15 Feb 2016, at 23:45, Remi Forax wrote: > > > >>> The comment in Infer > >>> "//The return type for a polymorphic signature call" > >>> should be updated to reflect the new implementation. > >>> > >> > >> That comment should really be folded into the first if block. > >> > >> I could do that as follows: > >> > >> // The return type of the polymorphic signature is polymorphic, > >> // and is computed from the ... > >> > >> And then in the else block > >> > >> // The return type of the polymorphic signature is fixed (not > >> polymorphic) > >> > >> ? > > > > yes, good idea. > > > > Updated in place. > > > >> > >> > >>> and this change in the way to do the inference (if the return type is not > >>> Object use the declared return type) is too ad hoc for me, > >>> we will need to do the same special case for the parameter types, soon, > >>> no > >>> ? > >>> > >> > >> Do you have any use-cases in mind? > >> > >> Rather than ad-hoc i would argue instead the enhancement of > >> signature-polymorphic methods is limited to that required by the current > >> use-cases. > >> > >> IIRC I did pull on that more significantly at one point when i had > >> sub-types > >> for array handles since the index need not be polymorphic. But we dialled > >> back from that approach. > > > > as you said one use case is to be able to fix an index, but perhaps a more > > interesting case is to be able to bound the number of parameters, > > by example for compareAndSet > > boolean compareAndSet(Object expected, Object value) > > is better than > > boolean compareAndSet(Object... args); > > > > That ain?t gonna work because the shape is defined by the factory method > producing the var handle, there could be zero or more coordinate arguments > preceding zero or more explicit value arguments. We cannot declare a varargs > parameter preceding other parameters and declaring Object[] is an awkward > fit. It?s more that i would care to bite off in terms of tweaking the > definition of signature-polymorphism. ok, the actual meta-protocol used to create a varhandle doesn't allow anything other than a varargs as 'real' arguments, but it's the tail waging the dog, this meta-protocol is an implementation artifact of the current way a varhandle is created. anyway, i think it's too late to change this kind of things now, given that the spec of what a polymorphic signature is has already changed, a future release may change this definition again. > > Paul.. > R?mi From alejandro.murillo at oracle.com Wed Feb 24 03:05:32 2016 From: alejandro.murillo at oracle.com (Alejandro E Murillo) Date: Tue, 23 Feb 2016 20:05:32 -0700 Subject: jdk9-dev: HotSpot Message-ID: <56CD1DFC.4010205@oracle.com> jdk9-hs-2016-02-18 has been integrated into jdk9-dev. http://hg.openjdk.java.net/jdk9/dev/rev/4040949857df http://hg.openjdk.java.net/jdk9/dev/corba/rev/49202432b694 http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/f14a0a890704 http://hg.openjdk.java.net/jdk9/dev/jaxp/rev/95c223e6eaf0 http://hg.openjdk.java.net/jdk9/dev/jaxws/rev/fafd694e801f http://hg.openjdk.java.net/jdk9/dev/jdk/rev/a2a823780a7c http://hg.openjdk.java.net/jdk9/dev/langtools/rev/527e819dbc95 http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/8042e81b530e Component : VM Status : Go for integration Date : 22/02/2016 at 17:30 MSK Tested By : VM SQE &dmitry.fazunenko at oracle.com Bundles : 2016-02-18-232049.amurillo.jdk9-hs-2016-02-18-snapshot Testing: 158 new failures, 2643 known failures, 471755 passed. Issues and Notes: No detailed analysis. No stoppers have been detected so far. Go for integration CRs for testing: 6378256: Performance problem with System.identityHashCode in client compiler 8009538: [Event Request] Want events for tenuring distribution 8136854: G1 ConcurrentG1RefineThread::stop delays JVM shutdown for >150ms 8138922: StubCodeDesc constructor publishes partially-constructed objects on StubCodeDesc::_list 8141491: Unaligned memory access in Bits.c 8143220: Fix documentation of InitiatingHeapOccupancyPercent 8143542: C2 doesn't eliminate identical checks 8144957: Remove PICL warning message 8145700: Uninitialised variable in macroAssembler_x86.cpp:7038 8145725: Remove the WorkAroundNPTLTimedWaitHang workaround 8147379: Investigate if ConvertSleepToYield still should be false by default on Sparc 8148518: Unsafe.getCharUnaligned() loads aren't folded in case of -XX:-UseUnalignedAccesses 8148564: compiler/intrinsics/string/TestStringIntrinsics2.java times out 8148987: [Linux] Allow building on older systems without CPU_ALLOC support 8148992: VM can hang on exit if root region scanning is initiated but not executed 8148994: Replacing MH::invokeBasic with a direct call breaks LF customization 8149096: Remove unused code in methodComparator 8149123: [TESTBUG] compiler/loopopts/superword/SumRed* tests running on non-x86 platforms 8149141: Optimized build is broken 8149356: Leftover from JDK-8141044: UseNewCode usage 8149415: [AArch64] implement JVMCI CodeInstaller 8149421: Vectorized Post Loops 8149427: Remove .class files from the hotspot repo .hgignore file 8149472: NPE when executing HotSpotConstantReflectionProvider::constantEquals with null first arg 8149541: Use log_error() instead of log_info() when verification reports a problem 8149542: Missing failure reporting in HeapRegion::verify 8149543: range check CastII nodes should not be split through Phi 8149611: Add tests for Unsafe.copySwapMemory 8149648: Add number of regions to the G1HeapSummary event 8149650: Create a trace event for G1 heap region type transitions 8149689: [JVMCI] CodeInstaller::pd_patch_DataSectionReference should be able to throw exceptions 8149695: [JVMCI] add missing Checkstyle configuration file 8149697: Fix for 8145725 is broken 8149740: NPEs when executing some HotSpotConstantReflectionProvider with null args 8149797: Compilation fails with "assert(in_hash) failed: node should be in igvn hash table" 8149813: Move trusted final field handling from C2 LoadNode::Value to shared code 8149820: Move G1YoungGenSizer to g1CollectorPolicy.cpp 8149826: Concurrent misspelled in the CMS logging 8149969: [JVMCI] PrintNMethods is ignored for CompilerToVM.installCode when not called from the broker 8150075: [JVMCI] expose reserved stack machinery and Inline flag in HotSpotVMConfig -- Alejandro From dmitry.dmitriev at oracle.com Wed Feb 24 08:06:52 2016 From: dmitry.dmitriev at oracle.com (Dmitry Dmitriev) Date: Wed, 24 Feb 2016 11:06:52 +0300 Subject: CFV: New JDK 9 Committer: Rachel Protacio In-Reply-To: <56CB5939.6090704@oracle.com> References: <56CB5939.6090704@oracle.com> Message-ID: <56CD649C.4060102@oracle.com> Vote: yes Dmitry On 22.02.2016 21:53, Coleen Phillimore wrote: > I hereby nominate Rachel Protacio (rprotacio) to JDK 9 Committer. > > Rachel is a member of the Hotspot runtime team and has contributed 21 > changes [3] to the OpenJDK hotspot repository. She has converted 8 > Trace options to the new Unified Logging framework, fixed unified > logging tests because of an overambitious testing strategy, and also > fixed a significant bug in the UL framework. > > Votes are due by 2:00 PM EST, Monday March 7, 2016. > > Only current JDK 9 Committers [1] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Lazy Consensus voting instructions, see [2]. > > Coleen Phillimore > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] List of patches: > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/66a81854aa5d > 8149383: Convert TraceBiasedLocking to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/eda0d9992163 > 8148630: Convert TraceStartupTime to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/1ac9a5e38143 > 8146137: runtime/logging/ExceptionsTest.java fails on embedded and ARM > test > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/45c4d55c36f5 > 8146435: [TESTBUG] Logging tests are failing intermittently on windows > when executed by JPRT > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/42a4b9a221cc > 8144953: runtime/CommandLine/TraceExceptionsTest.java fails when > exception is thrown in compiled code > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/50dd5b051754 > 8141564: Convert TraceItables and PrintVtables to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/dda74d89ee09 > 8146481: Disable runtime/logging/DefaultMethodsTest.java > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/fd60a8853157 > 8145606: [TESTBUG] MonitorInflationTest.java should be rewritten to be > more predictable > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/0c82805adfc5 > 8141211: Convert TraceExceptions to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/a9a101b70a85 > 8145445: [TESTBUG] runtime/logging tests need to properly build and > import libraries > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/432ae0f42a2c > 8145629: Disable test/runtime/logging/MonitorInflationTest.java > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/8512cbf64495 > 8145153: Convert TraceMonitorInflation to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/1f1e6bc1c947 > 8144536: Clean up Unified Logging test directory > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/fb4a19e4f7dc > 8143155: Remove TraceRuntimeCalls, TraceJNICalls, and TraceJVMCalls > rather than convert to UL > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/fd83b8307473 > 8143157: Convert TraceVMOperation to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/a7ffcce47ffb > 8142437: SafepointTest.java is occasionally failing in JPRT > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/766ae06f30ca > 8138916: Logging write function does not allow for long enough messages > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/9c99ce707b0b > 8140348: Convert TraceSafepoint to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/96773453776a > 8139564: Convert TraceDefaultMethods to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/43a1e4ca7ee4 > 8138574: [TESTBUG] TestBasicLogOutput.java doesn't account for padding > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/e13d7fa76fac > 8133561: linux thread id should be reported in decimal in the error > reports now > From stefan.karlsson at oracle.com Wed Feb 24 08:09:09 2016 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Wed, 24 Feb 2016 09:09:09 +0100 Subject: CFV: New JDK 9 Committer: Rachel Protacio In-Reply-To: <56CB5939.6090704@oracle.com> References: <56CB5939.6090704@oracle.com> Message-ID: <56CD6525.60608@oracle.com> Vote: yes StefanK On 2016-02-22 19:53, Coleen Phillimore wrote: > I hereby nominate Rachel Protacio (rprotacio) to JDK 9 Committer. > > Rachel is a member of the Hotspot runtime team and has contributed 21 > changes [3] to the OpenJDK hotspot repository. She has converted 8 > Trace options to the new Unified Logging framework, fixed unified > logging tests because of an overambitious testing strategy, and also > fixed a significant bug in the UL framework. > > Votes are due by 2:00 PM EST, Monday March 7, 2016. > > Only current JDK 9 Committers [1] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Lazy Consensus voting instructions, see [2]. > > Coleen Phillimore > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] List of patches: > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/66a81854aa5d > 8149383: Convert TraceBiasedLocking to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/eda0d9992163 > 8148630: Convert TraceStartupTime to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/1ac9a5e38143 > 8146137: runtime/logging/ExceptionsTest.java fails on embedded and ARM > test > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/45c4d55c36f5 > 8146435: [TESTBUG] Logging tests are failing intermittently on windows > when executed by JPRT > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/42a4b9a221cc > 8144953: runtime/CommandLine/TraceExceptionsTest.java fails when > exception is thrown in compiled code > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/50dd5b051754 > 8141564: Convert TraceItables and PrintVtables to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/dda74d89ee09 > 8146481: Disable runtime/logging/DefaultMethodsTest.java > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/fd60a8853157 > 8145606: [TESTBUG] MonitorInflationTest.java should be rewritten to be > more predictable > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/0c82805adfc5 > 8141211: Convert TraceExceptions to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/a9a101b70a85 > 8145445: [TESTBUG] runtime/logging tests need to properly build and > import libraries > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/432ae0f42a2c > 8145629: Disable test/runtime/logging/MonitorInflationTest.java > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/8512cbf64495 > 8145153: Convert TraceMonitorInflation to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/1f1e6bc1c947 > 8144536: Clean up Unified Logging test directory > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/fb4a19e4f7dc > 8143155: Remove TraceRuntimeCalls, TraceJNICalls, and TraceJVMCalls > rather than convert to UL > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/fd83b8307473 > 8143157: Convert TraceVMOperation to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/a7ffcce47ffb > 8142437: SafepointTest.java is occasionally failing in JPRT > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/766ae06f30ca > 8138916: Logging write function does not allow for long enough messages > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/9c99ce707b0b > 8140348: Convert TraceSafepoint to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/96773453776a > 8139564: Convert TraceDefaultMethods to Unified Logging > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/43a1e4ca7ee4 > 8138574: [TESTBUG] TestBasicLogOutput.java doesn't account for padding > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/e13d7fa76fac > 8133561: linux thread id should be reported in decimal in the error > reports now > From vladimir.x.ivanov at oracle.com Wed Feb 24 10:32:31 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 24 Feb 2016 13:32:31 +0300 Subject: CFV: New JDK 9 Committer: Rachel Protacio In-Reply-To: <56CB5939.6090704@oracle.com> References: <56CB5939.6090704@oracle.com> Message-ID: <56CD86BF.9040608@oracle.com> Vote: yes Best regards, Vladimir Ivanov On 2/22/16 9:53 PM, Coleen Phillimore wrote: > I hereby nominate Rachel Protacio (rprotacio) to JDK 9 Committer. From sean.mullan at oracle.com Wed Feb 24 14:19:54 2016 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 24 Feb 2016 09:19:54 -0500 Subject: Result: New JDK 9 Reviewer: Anthony Scarpino Message-ID: <56CDBC0A.10104@oracle.com> Voting for Anthony Scarpino [1] is now closed. Yes: 18 Veto: 0 Abstain: 0 According to the Bylaws definition of Three-Vote Consensus, this is sufficient to approve the nomination. Sean Mullan [1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-February/003544.html From andreas.eriksson at oracle.com Wed Feb 24 14:22:15 2016 From: andreas.eriksson at oracle.com (Andreas Eriksson) Date: Wed, 24 Feb 2016 15:22:15 +0100 Subject: corrupted reposirory? In-Reply-To: <56C69460.8080302@oracle.com> References: <56C67533.7050004@gmail.com> <56C69460.8080302@oracle.com> Message-ID: <56CDBC97.4010807@oracle.com> Hi, I'm getting a lot of errors today, both when cloning and when doing 'hg in': % hg in abort: HTTP Error 500: Internal Server Error The hg web explorer is throwing python errors as well. Attached the error page I intermittently get when trying to access http://hg.openjdk.java.net/jdk9/dev/hotspot/ (gzipped because of size). Regards, Andreas On 2016-02-19 05:04, David Holmes wrote: > On 19/02/2016 11:51 AM, Alied P?rez Mart?nez wrote: >> Hi: >> I'mtrying to clone the jdk repository but I'm unable to do so. Is there >> any issue? > > Seems to be fine now. Probably just a transient error with the network. > > David > >> alied at development:~/NetBeansProjects$ hg clone >> http://hg.openjdk.java.net/jdk9/jdk9 jdk9 >> requesting all changes >> adding changesets >> adding manifests >> adding file >> changes >> transaction >> abort! >> rollback >> completed >> abort: stream ended unexpectedly (got 18609 bytes, expected 207386) >> >> >> the got bytes vary each time. >> >> Regards. >> Saludos desde la Argentina >> Alied >> From thomas.stuefe at gmail.com Wed Feb 24 14:32:44 2016 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 24 Feb 2016 15:32:44 +0100 Subject: corrupted reposirory? In-Reply-To: <56CDBC97.4010807@oracle.com> References: <56C67533.7050004@gmail.com> <56C69460.8080302@oracle.com> <56CDBC97.4010807@oracle.com> Message-ID: On Wed, Feb 24, 2016 at 3:22 PM, Andreas Eriksson < andreas.eriksson at oracle.com> wrote: > Hi, > > I'm getting a lot of errors today, both when cloning and when doing 'hg > in': > % hg in > abort: HTTP Error 500: Internal Server Error > > Same here. 4 out of 5 webrev.ksh calls fail because "hg outgoing" fails with HTTP Error 500. Regards, Thomas > The hg web explorer is throwing python errors as well. > Attached the error page I intermittently get when trying to access > http://hg.openjdk.java.net/jdk9/dev/hotspot/ (gzipped because of size). > > Regards, > Andreas > > > On 2016-02-19 05:04, David Holmes wrote: > >> On 19/02/2016 11:51 AM, Alied P?rez Mart?nez wrote: >> >>> Hi: >>> I'mtrying to clone the jdk repository but I'm unable to do so. Is there >>> any issue? >>> >> >> Seems to be fine now. Probably just a transient error with the network. >> >> David >> >> alied at development:~/NetBeansProjects$ hg clone >>> http://hg.openjdk.java.net/jdk9/jdk9 jdk9 >>> requesting all changes >>> adding changesets >>> adding manifests >>> adding file >>> changes >>> transaction >>> abort! >>> rollback >>> completed >>> abort: stream ended unexpectedly (got 18609 bytes, expected 207386) >>> >>> >>> the got bytes vary each time. >>> >>> Regards. >>> Saludos desde la Argentina >>> Alied >>> >>> > From andreas.eriksson at oracle.com Wed Feb 24 15:20:23 2016 From: andreas.eriksson at oracle.com (Andreas Eriksson) Date: Wed, 24 Feb 2016 16:20:23 +0100 Subject: corrupted reposirory? In-Reply-To: References: <56C67533.7050004@gmail.com> <56C69460.8080302@oracle.com> <56CDBC97.4010807@oracle.com> Message-ID: <56CDCA37.7080808@oracle.com> I've sent a mail to the openjdk ops list, waiting for a response. - Andreas On 2016-02-24 15:32, Thomas St?fe wrote: > > > On Wed, Feb 24, 2016 at 3:22 PM, Andreas Eriksson > > wrote: > > Hi, > > I'm getting a lot of errors today, both when cloning and when > doing 'hg in': > % hg in > abort: HTTP Error 500: Internal Server Error > > > Same here. 4 out of 5 webrev.ksh calls fail because "hg outgoing" > fails with HTTP Error 500. > > Regards, Thomas > > The hg web explorer is throwing python errors as well. > Attached the error page I intermittently get when trying to access > http://hg.openjdk.java.net/jdk9/dev/hotspot/ (gzipped because of > size). > > Regards, > Andreas > > > On 2016-02-19 05:04, David Holmes wrote: > > On 19/02/2016 11:51 AM, Alied P?rez Mart?nez wrote: > > Hi: > I'mtrying to clone the jdk repository but I'm unable to do > so. Is there > any issue? > > > Seems to be fine now. Probably just a transient error with the > network. > > David > > alied at development:~/NetBeansProjects$ hg clone > http://hg.openjdk.java.net/jdk9/jdk9 jdk9 > requesting all changes > adding changesets > adding manifests > adding file > changes > transaction > abort! > rollback > completed > abort: stream ended unexpectedly (got 18609 bytes, > expected 207386) > > > the got bytes vary each time. > > Regards. > Saludos desde la Argentina > Alied > > > From mark.reinhold at oracle.com Wed Feb 24 15:41:03 2016 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Wed, 24 Feb 2016 07:41:03 -0800 Subject: corrupted reposirory? In-Reply-To: <56CDCA37.7080808@oracle.com> References: <56C67533.7050004@gmail.com> <56C69460.8080302@oracle.com> <56CDBC97.4010807@oracle.com> <56CDCA37.7080808@oracle.com> Message-ID: <20160224074103.886324111eggemoggin.niobe.net> 2016/2/24 7:20 -0800, andreas.eriksson at oracle.com: > I've sent a mail to the openjdk ops list, waiting for a response. Problem fixed. - Mark From andreas.eriksson at oracle.com Wed Feb 24 15:49:23 2016 From: andreas.eriksson at oracle.com (Andreas Eriksson) Date: Wed, 24 Feb 2016 16:49:23 +0100 Subject: corrupted reposirory? In-Reply-To: <20160224074103.886324111eggemoggin.niobe.net> References: <56C67533.7050004@gmail.com> <56C69460.8080302@oracle.com> <56CDBC97.4010807@oracle.com> <56CDCA37.7080808@oracle.com> <20160224074103.886324111eggemoggin.niobe.net> Message-ID: <56CDD103.4010401@oracle.com> On 2016-02-24 16:41, mark.reinhold at oracle.com wrote: > 2016/2/24 7:20 -0800, andreas.eriksson at oracle.com: >> I've sent a mail to the openjdk ops list, waiting for a response. > Problem fixed. > > - Mark Perfect, thanks. - Andreas From vladimir.kozlov at oracle.com Wed Feb 24 18:14:49 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 24 Feb 2016 10:14:49 -0800 Subject: Result: New JDK 9 Reviewer: Anthony Scarpino In-Reply-To: <56CDBC0A.10104@oracle.com> References: <56CDBC0A.10104@oracle.com> Message-ID: <56CDF319.7030101@oracle.com> Vote: yes On 2/24/16 6:19 AM, Sean Mullan wrote: > Voting for Anthony Scarpino [1] is now closed. > > Yes: 18 > Veto: 0 > Abstain: 0 > > According to the Bylaws definition of Three-Vote Consensus, this is > sufficient to approve the nomination. > > Sean Mullan > > [1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-February/003544.html From lana.steuck at oracle.com Wed Feb 24 20:12:51 2016 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 24 Feb 2016 12:12:51 -0800 (PST) Subject: jdk9-b107: dev Message-ID: <201602242012.u1OKCpN7020340@sc11152554.us.oracle.com> http://hg.openjdk.java.net/jdk9/jdk9/rev/4d65eba233a8 http://hg.openjdk.java.net/jdk9/jdk9/nashorn/rev/8042e81b530e http://hg.openjdk.java.net/jdk9/jdk9/langtools/rev/7a0c34355149 http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/8701b2bb1d2e http://hg.openjdk.java.net/jdk9/jdk9/jaxws/rev/fafd694e801f http://hg.openjdk.java.net/jdk9/jdk9/jaxp/rev/781b83dadcae http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/c5146d4da417 http://hg.openjdk.java.net/jdk9/jdk9/corba/rev/49202432b694 --- All the fixes will be tested during promotion (no PIT testing at this point): List of all fixes: =================== JDK-6180449 client-libs PIT: Text in TextArea scrolls to its left one char when selecting the JDK-8022640 client-libs ServiceRegistry (used by ImageIO) lack synchronization JDK-8062946 client-libs Transparent JDialog will lose transparency upon iconify/deiconify sequ JDK-8075964 client-libs Test java/awt/Mouse/TitleBarDoubleClick/TitleBarDoubleClick.html fails JDK-8080465 client-libs The underline of the text doesn't display unless resizing the window w JDK-8139581 client-libs AWT components are not drawn after removal and addition to a container JDK-8142861 client-libs [TEST_BUG] MultiResolution image: add a manual test for two-display co JDK-8145780 client-libs [TEST] create a simple test for TIFF tag sets JDK-8147077 client-libs IllegalArgumentException thrown by api/java_awt/Component/FlipBufferSt JDK-8148127 client-libs IllegalArgumentException thrown by JCK test api/java_awt/Component/Fli JDK-8148914 client-libs BitDepth.java test fails JDK-8149151 client-libs Use local GraphicsEnvironment to get screen size in WToolkit JDK-8068686 core-libs Remove meta-index support JDK-8135108 core-libs java/util/zip/TestLocalTime.java fails intermittently with Invalid val JDK-8139927 core-libs Improve documentation for CompletableFuture composition JDK-8143089 core-libs CompletableFuture.whenComplete should use addSuppressed JDK-8144931 core-libs Assert class signatures are correct and refer to valid classes JDK-8145485 core-libs Miscellaneous changes imported from jsr166 CVS 2016-02 JDK-8147558 core-libs Add support for ES6 collections JDK-8148140 core-libs arguments are handled differently in apply for JS functions and Abstra JDK-8148346 core-libs Reduce number of packages in jdk.localedata module JDK-8148624 core-libs Test failure of ConstructInflaterOutput.java JDK-8148775 core-libs Spec for j.l.ProcessBuilder.Redirect.DISCARD need to be improved JDK-8149451 core-libs fix bytecode generation issue after 8149186 JDK-8149835 core-libs StringConcatFactory should emit classes with the same package as the h JDK-8149896 core-libs Removed unnecessary values in FloatConsts and DoubleConsts JDK-8149920 core-libs Remove intermittent key from jdk_core tests JDK-8149981 core-libs java/util/Formatter/Basic.java fails after JDK-8149896 JDK-8150014 core-libs java/lang/invoke/LFCaching/LFMultiThreadCachingTest.java fails with No JDK-8150163 core-libs JarFileSystem support for MRJARs should use the JDK specific Version A JDK-8145919 core-svc sun/management/jmxremote/bootstrap/RmiSslBootstrapTest failed with Con JDK-8147609 core-svc [TESTBUG] Correct the @build statements in the serviceability/dcmd/gc/ JDK-8149700 core-svc Remove jdk_svc test group from tier * groups JDK-8150168 core-svc jconsole AboutDialog should use the JDK specific Version API JDK-8130026 deploy When using browser certificate store, JWS should filter out expired ce JDK-8147627 deploy 64 bit only app may have problems when initially launched with 32 bit JDK-8148067 deploy [test] Need to port 2 tests from libraries WS JDK-8148266 deploy nohref jnlp files can cause multiple cache entries. JDK-8148530 deploy [test]Some cases in vmargsTest failed due to that some secure jvm args JDK-8148531 deploy [test]Test case testFailToAccessCerRevoSiteJNLP_High is unstable on so JDK-8148690 deploy Simple applet in IE11 throws NPE in Applet2Manager.getParametersString JDK-8148814 deploy [test]The value of MarkStackSize must be less than or equal to MarkSta JDK-8034047 docs JavaSound Guide "Appendix 1: Code Overview: AudioSystem.java" need upd JDK-6515172 hotspot Runtime.availableProcessors() ignores Linux taskset command JDK-8063112 hotspot Compiler diagnostic commands should have locking instead of safepoint JDK-8067333 hotspot [TESTBUG] Using same name for shared archive between test executions o JDK-8072777 hotspot java/lang/ref/ReferenceEnqueuePending.java: some references aren't que JDK-8079408 hotspot Improve class loading log (with unified logging) JDK-8132721 hotspot Add tests which check that heap counters work as expected during Humo JDK-8134963 hotspot [Newtest][TEST_BUG] New stress test for changing the coarseness level JDK-8137049 hotspot Code quality: reducing an trivial integer loop does not produce an opt JDK-8137314 hotspot vm crash from test java/security/Policy/SignedJar/SignedJarTest.java JDK-8138562 hotspot Event based tracing should cover monitor inflation JDK-8141278 hotspot New tests for PLAB testing JDK-8141421 hotspot Various test fail with OOME on win x86 JDK-8143608 hotspot Don't 64-bit align start of InstanceKlass vtable, itable, and nonstati JDK-8143897 hotspot Weblogic12medrec assert(handler_address == SharedRuntime::compute_comp JDK-8144916 hotspot Decrease PerfDataMemorySize back to 32K JDK-8145180 hotspot Add back PrintGC, PrintGCDetails and -Xloggc JDK-8145190 hotspot MinTLABSize can cause overflow problem with CMS GC JDK-8145192 hotspot 'count' variable can overflow in PSMarkSweep::invoke on 64 bit JVM JDK-8145628 hotspot hotspot metadata classes shouldn't use HeapWordSize or heap related ma JDK-8145740 hotspot Visual Studio pragmas should be guarded by #ifdef _MSC_VER JDK-8146395 hotspot Add inline qualifier in oop.hpp and fix inlining in gc files JDK-8146435 hotspot [TESTBUG] Logging tests are failing intermittently on windows when exe JDK-8146608 hotspot [JVMCI] DebugInfo Tests on DeoptimizeALot runs fails in assert(_pc == JDK-8146616 hotspot VM exit path throws fatal error: Thread holding lock at safepoint that JDK-8146793 hotspot logStream::write re-formats string JDK-8146905 hotspot cleanup ostream, staticBufferStream JDK-8146984 hotspot SIGBUS: bool Method::has_method_vptr(const void*)+0xc JDK-8146987 hotspot Improve Parallel GC Full GC by caching results of live_words_in_range( JDK-8147003 hotspot Move BubbleUpRef test into CMS directory JDK-8147087 hotspot Race when reusing PerRegionTable bitmaps may result in dropped remembe JDK-8147348 hotspot LogTagLevelExpression not properly initialized in configure_stdout JDK-8147447 hotspot [TESTBUG] serviceability/tmtools/jstack/WaitNotifyThreadTest.java test JDK-8147461 hotspot Use byte offsets for vtable start and vtable length offsets JDK-8147477 hotspot com/sun/management/HotSpotDiagnosticMXBean/CheckOrigin.java is failing JDK-8147500 hotspot The HashtableTextDump::get_num() should check for integer overflow JDK-8147510 hotspot [windows] no text locations shown for register info in hs-err file JDK-8147617 hotspot jtreg tests try to build non existing packages JDK-8147814 hotspot Move verification code out of g1collectedheap JDK-8147847 hotspot [TESTBUG] serviceability/tmtools/jstat test ported to JTREG are failin JDK-8147884 hotspot Names of GC threads should be set before the threads start JDK-8147906 hotspot G1 use of os::processor_count() JDK-8147918 hotspot Rename develop_log_is_enabled() to log_develop_is_enabled() JDK-8147940 hotspot Test gc/g1/TestG1TraceEagerReclaimHumongousObjects.java fails JDK-8148005 hotspot One byte may be corrupted by get_datetime_string() JDK-8148047 hotspot Move the vtable length field to Klass JDK-8148052 hotspot TestDefNewAllocationPendingStackTrace.java and TestG1HumongousAllocati JDK-8148053 hotspot Remove unused log tags JDK-8148104 hotspot HSDB could not terminate when launched on CLI JDK-8148141 hotspot Remove fixed level padding in UL JDK-8148165 hotspot Re-enable tests depending on AllocationStackTrace JDK-8148467 hotspot Consistent use of : in the logging JDK-8148470 hotspot Metadata print routines should not print to tty JDK-8148481 hotspot Devirtualize Klass::vtable JDK-8148507 hotspot [JVMCI] mitigate deadlocks related to JVMCI compiler under -Xbatch JDK-8148696 hotspot Race loading hsdis may cause SIGSEGV JDK-8148733 hotspot G1: Add log message to print the heap region size JDK-8148734 hotspot G1: Make G1GCPhaseTimes keep track of the start GC time JDK-8148736 hotspot Let the G1 heap transition log regions instead of bytes JDK-8148741 hotspot compiler/jvmci/code/SimpleDebugInfoTest.java fails in 'frame::sender_f JDK-8148745 hotspot [testbug] Test gc/g1/plab/TestPLABPromotion.java fails in nightly JDK-8148747 hotspot [TESTBUG] runtime/Unsafe/AllocateMemory.java fails with OOM during com JDK-8148752 hotspot Compiled StringBuilder code throws StringIndexOutOfBoundsException JDK-8148755 hotspot -XX:+HeapDumpAfterFullGC creates heap dump both before and after Full JDK-8148758 hotspot Compilation fails with "this call site should not be polymorphic" JDK-8148766 hotspot Test AvailableProcessors.java got wrong number of processors JDK-8148771 hotspot os::active_processor_count() returns garbage which causes VM to crash. JDK-8148783 hotspot aarch64: SEGV running SpecJBB2013 JDK-8148785 hotspot Update class file version to 53 for JDK-9 JDK-8148844 hotspot Update run_unit_test macro for InternalVMTests JDK-8148864 hotspot Quarantine CompilerControl tests JDK-8148944 hotspot CollectorPolicy methods for memory allocations are specific to GenColl JDK-8148945 hotspot JDK-8148481: Devirtualize Klass::vtable breaks Zero build JDK-8148948 hotspot aarch64: generate_copy_longs calls align() incorrectly JDK-8148951 hotspot Remove unused method Generation::performs_in_place_marking() JDK-8148960 hotspot Humongous mis-spelled in log output JDK-8148973 hotspot Rename g1/concurrentMark.{hpp,cpp,inline.hpp} to g1/g1ConcurrentMark.{ JDK-8148981 hotspot remove ResolvedJavaType.getClassFilePath() JDK-8149019 hotspot remove redundant modifiers JDK-8149035 hotspot Make the full_gc_dump() calls be recorded as part of the GC JDK-8149062 hotspot Remove misplaced integration of test code after 8149025 JDK-8149076 hotspot [JVMCI] missing ResourceMark in JVMCIRuntime::initialize_HotSpotJVMCIR JDK-8149080 hotspot AArch64: Recognize disjoint array copy in stub code JDK-8149099 hotspot jcmd -help mention non-existent option JDK-8149100 hotspot AArch64: "bad AD file" for LL enconding AryEq Node matching JDK-8149105 hotspot typo in jvmciCodeInstaller.cpp JDK-8149109 hotspot [TESTBUG] TestRegisterRestoring.java fails with "VM option 'SafepointA JDK-8149112 hotspot configure_stdout test depends on VM arguments JDK-8149135 hotspot [jittester] Makefile copies JitTesterDriver in incorrect directory and JDK-8149174 hotspot [TESTBUG] TestJcmdDefaults.java: ouput should contain all content of j JDK-8149184 hotspot os::is_server_class_machine() could return incorrect result if a host' JDK-8149364 hotspot Quarantine TestSelectDefaultGC.java test JDK-8149365 hotspot aarch64: memory copy does not prefetch on backwards copy JDK-8144695 infrastructure --disable-warnings-as-errors does not work for HotSpot build JDK-8149963 infrastructure build errors during API docs build JDK-8146391 install Updating Java in MAC OS X 10.11 fails with color picker pop with the f JDK-8147792 install move all msi-related files to common location JDK-8144144 other-libs ORB destroy() leaks filedescriptors after unsuccessful connection JDK-8149750 other-libs Decouple sun.misc.Signal from the base module JDK-8147772 security-libs Update KerberosTicket to describe behavior if it has been destroyed an JDK-8149411 security-libs PKCS12KeyStore cannot extract AES Secret Keys JDK-8149922 security-libs Remove intermittent key from security tests JDK-8150047 security-libs Remove SSLSession/SessionCacheSizeTests from ProblemList JDK-6469561 tools javadoc for annotation types should not display "public abstract" modi JDK-6469562 tools Use compact notation to display annotation values JDK-8149773 tools StandardDocFileFactory should be converted to use java.nio.file.Path JDK-8149842 tools javadoc incorrectly tries to get the documentation for inherited metho JDK-8149886 tools 16 windows tests broke with recent putback JDK-8149903 tools Fix other Extern. JDK-8150077 tools Due to a javac type inference issue, javadoc doesn't compile with a jd JDK-8150096 tools Cleanup synthetic JCCompilationUnit for html files JDK-8146237 xml PREFER from Features API taking precedence over catalog file From aleksey.shipilev at oracle.com Wed Feb 24 22:43:46 2016 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Thu, 25 Feb 2016 01:43:46 +0300 Subject: RFR (S) 8150465: Unsafe methods to produce uninitialized arrays Message-ID: <56CE3222.6040207@oracle.com> Hi, When instantiating arrays from Java, we have to zero the backing storage to match JLS requirements. In some cases, like with the subsequent arraycopy, compilers are able to remove zeroing. However, in a generic case where a complicated processing is done after the allocation, compilers are unable to reliably figure out the array is covered completely. JDK-8150463 is a motivational example of this: Java level String concat loses to C2's OptimizeStringConcat because C2 can skip zeroing for its own allocations. It might make sense to allow new Unsafe method that will return uninitialized arrays to trusted Java code: https://bugs.openjdk.java.net/browse/JDK-8150465 Webrevs: http://cr.openjdk.java.net/~shade/8150465/webrev.hs.01/ http://cr.openjdk.java.net/~shade/8150465/webrev.jdk.01/ It helps that we already have java.lang.reflect.Array.newArray intrinsic, so we can reuse a lot of code. The intrinsic code nukes the array allocation in the same way PhaseStringOpts::allocate_byte_array does it in OptimizeStringConcat. Alas, no such luck in C1, and so it stays untouched, falling back to normal Java allocations. Performance data shows the promising improvements: http://cr.openjdk.java.net/~shade/8150465/notes.txt Also, using this new method brings the best Java-level-only concatenation strategy to OptimizeStringConcat levels, and beyond. Testing: new test; targeted microbenchmarks; JPRT (in progress) Thanks, -Aleksey From vladimir.kozlov at oracle.com Wed Feb 24 23:21:55 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 24 Feb 2016 15:21:55 -0800 Subject: RFR (S) 8150465: Unsafe methods to produce uninitialized arrays In-Reply-To: <56CE3222.6040207@oracle.com> References: <56CE3222.6040207@oracle.com> Message-ID: <56CE3B13.3090700@oracle.com> What is your story for GC? When an array become visible and GC happens, it will expect only initialized arrays. Thanks, Vladimir On 2/24/16 2:43 PM, Aleksey Shipilev wrote: > Hi, > > When instantiating arrays from Java, we have to zero the backing storage > to match JLS requirements. In some cases, like with the subsequent > arraycopy, compilers are able to remove zeroing. However, in a generic > case where a complicated processing is done after the allocation, > compilers are unable to reliably figure out the array is covered completely. > > JDK-8150463 is a motivational example of this: Java level String concat > loses to C2's OptimizeStringConcat because C2 can skip zeroing for its > own allocations. > > It might make sense to allow new Unsafe method that will return > uninitialized arrays to trusted Java code: > https://bugs.openjdk.java.net/browse/JDK-8150465 > > Webrevs: > http://cr.openjdk.java.net/~shade/8150465/webrev.hs.01/ > http://cr.openjdk.java.net/~shade/8150465/webrev.jdk.01/ > > It helps that we already have java.lang.reflect.Array.newArray > intrinsic, so we can reuse a lot of code. The intrinsic code nukes the > array allocation in the same way PhaseStringOpts::allocate_byte_array > does it in OptimizeStringConcat. Alas, no such luck in C1, and so it > stays untouched, falling back to normal Java allocations. > > Performance data shows the promising improvements: > http://cr.openjdk.java.net/~shade/8150465/notes.txt > > Also, using this new method brings the best Java-level-only > concatenation strategy to OptimizeStringConcat levels, and beyond. > > Testing: new test; targeted microbenchmarks; JPRT (in progress) > > Thanks, > -Aleksey > From aleksey.shipilev at oracle.com Wed Feb 24 23:51:26 2016 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Thu, 25 Feb 2016 02:51:26 +0300 Subject: RFR (S) 8150465: Unsafe methods to produce uninitialized arrays In-Reply-To: <56CE3B13.3090700@oracle.com> References: <56CE3222.6040207@oracle.com> <56CE3B13.3090700@oracle.com> Message-ID: <56CE41FE.6070103@oracle.com> On 02/25/2016 02:21 AM, Vladimir Kozlov wrote: > What is your story for GC? When an array become visible and GC happens, > it will expect only initialized arrays. New method allows primitive arrays only, and its headers should be intact. This is corroborated by the new jtreg test (and benchmarks!) that allocate lots of uninitialized arrays, and obviously they get GCed. Are there specific concerns about GC seeing an uninitialized primitive array? Thanks, -Aleksey From vladimir.kozlov at oracle.com Thu Feb 25 00:20:24 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 24 Feb 2016 16:20:24 -0800 Subject: RFR (S) 8150465: Unsafe methods to produce uninitialized arrays In-Reply-To: <56CE41FE.6070103@oracle.com> References: <56CE3222.6040207@oracle.com> <56CE3B13.3090700@oracle.com> <56CE41FE.6070103@oracle.com> Message-ID: <56CE48C8.2050707@oracle.com> On 2/24/16 3:51 PM, Aleksey Shipilev wrote: > On 02/25/2016 02:21 AM, Vladimir Kozlov wrote: >> What is your story for GC? When an array become visible and GC happens, >> it will expect only initialized arrays. > > New method allows primitive arrays only, and its headers should be > intact. This is corroborated by the new jtreg test (and benchmarks!) > that allocate lots of uninitialized arrays, and obviously they get GCed. Yes, primitive arrays are fine if the header is correct. In this case changes are fine but you may need to add a check in inline_unsafe_newArray() that it is only primitive types. testIAE() should throw exception if IllegalArgumentException is not thrown. Thanks, Vladimir > > Are there specific concerns about GC seeing an uninitialized primitive > array? > > Thanks, > -Aleksey > From aleksey.shipilev at oracle.com Thu Feb 25 08:10:40 2016 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Thu, 25 Feb 2016 11:10:40 +0300 Subject: RFR (S) 8150465: Unsafe methods to produce uninitialized arrays In-Reply-To: <56CE48C8.2050707@oracle.com> References: <56CE3222.6040207@oracle.com> <56CE3B13.3090700@oracle.com> <56CE41FE.6070103@oracle.com> <56CE48C8.2050707@oracle.com> Message-ID: <56CEB700.9020603@oracle.com> On 02/25/2016 03:20 AM, Vladimir Kozlov wrote: > On 2/24/16 3:51 PM, Aleksey Shipilev wrote: >> On 02/25/2016 02:21 AM, Vladimir Kozlov wrote: >>> What is your story for GC? When an array become visible and GC happens, >>> it will expect only initialized arrays. >> >> New method allows primitive arrays only, and its headers should be >> intact. This is corroborated by the new jtreg test (and benchmarks!) >> that allocate lots of uninitialized arrays, and obviously they get GCed. > > Yes, primitive arrays are fine if the header is correct. In this case > changes are fine but you may need to add a check in > inline_unsafe_newArray() that it is only primitive types. Alas, the class argument may not be constant, and so we would need a runtime check there, which would duplicate the check we already have in Unsafe.java. I'd prefer to follow the upcoming pattern in Mikael's Unsafe cleanup with making as much checks on Java side. > testIAE() should throw exception if IllegalArgumentException is not thrown. D'uh, of course! See updates: http://cr.openjdk.java.net/~shade/8150465/webrev.jdk.01/ http://cr.openjdk.java.net/~shade/8150465/webrev.hs.02/ Cheers, -Aleksey From aph at redhat.com Thu Feb 25 09:50:22 2016 From: aph at redhat.com (Andrew Haley) Date: Thu, 25 Feb 2016 09:50:22 +0000 Subject: RFR (S) 8150465: Unsafe methods to produce uninitialized arrays In-Reply-To: <56CE3222.6040207@oracle.com> References: <56CE3222.6040207@oracle.com> Message-ID: <56CECE5E.4080105@redhat.com> This is something of a loaded gun pointed at our feet. We'll have to be extremely careful that we can prove that such arrays are never unsafely published. It's the "generic case where a complicated processing is done after the allocation" I'm worried about. The only way to guarantee safety is to prove that the array reference doesn't escape the thread until the array is fully initialized and a release barrier has been executed. I urge extreme caution. Andrew. From vladimir.x.ivanov at oracle.com Thu Feb 25 10:51:40 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Thu, 25 Feb 2016 13:51:40 +0300 Subject: Result: New jdk9 Reviewer: Tobias Hartmann Message-ID: <56CEDCBC.8030707@oracle.com> Voting for Tobias Hartmann [1] is now closed. Yes: 23 Veto: 0 Abstain: 0 According to the Bylaws definition of Three-Vote Consensus, this is sufficient to approve the nomination. Best regards, Vladimir Ivanov [1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-February/003559.html From vladimir.x.ivanov at oracle.com Thu Feb 25 10:53:04 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Thu, 25 Feb 2016 13:53:04 +0300 Subject: Result: New jdk9 Reviewer: Zoltan Majo Message-ID: <56CEDD10.9050707@oracle.com> Voting for Zoltan Majo [1] is now closed. Yes: 17 Veto: 0 Abstain: 0 According to the Bylaws definition of Three-Vote Consensus, this is sufficient to approve the nomination. Best regards, Vladimir Ivanov [1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-February/003569.html From vladimir.x.ivanov at oracle.com Thu Feb 25 10:54:17 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Thu, 25 Feb 2016 13:54:17 +0300 Subject: Result: New jdk9 Reviewer: Claes Redestad Message-ID: <56CEDD59.2020100@oracle.com> Voting for Claes Redestad [1] is now closed. Yes: 27 Veto: 0 Abstain: 0 According to the Bylaws definition of Three-Vote Consensus, this is sufficient to approve the nomination. Best regards, Vladimir Ivanov [1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-February/003585.html From vladimir.x.ivanov at oracle.com Thu Feb 25 10:55:36 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Thu, 25 Feb 2016 13:55:36 +0300 Subject: Result: New jdk9 Reviewer: Nils Eliasson Message-ID: <56CEDDA8.5020800@oracle.com> Voting for Nils Eliasson [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. Best regards, Vladimir Ivanov [1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-February/003573.html From aleksey.shipilev at oracle.com Thu Feb 25 13:44:26 2016 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Thu, 25 Feb 2016 16:44:26 +0300 Subject: RFR (S) 8150465: Unsafe methods to produce uninitialized arrays In-Reply-To: <56CECE5E.4080105@redhat.com> References: <56CE3222.6040207@oracle.com> <56CECE5E.4080105@redhat.com> Message-ID: <56CF053A.3070607@oracle.com> On 02/25/2016 12:50 PM, Andrew Haley wrote: > This is something of a loaded gun pointed at our feet. We'll have to > be extremely careful that we can prove that such arrays are never > unsafely published. It's the "generic case where a complicated > processing is done after the allocation" I'm worried about. > > The only way to guarantee safety is to prove that the array reference > doesn't escape the thread until the array is fully initialized and a > release barrier has been executed. I think the large part of the concern is the protection of object metadata. Current implementation does not eliminate the subsequent barriers after storing the metadata, and so racy publication of uninitialized array should not violate VM invariants. (Disallowing non-primitive arrays is the second part of safeguards -- no garbage oops in uninitialized arrays!) See e.g. benchmark disassembly with PrintOptoAssembly: Regular allocation: 100 B17: # B18 <- B24 top-of-loop Freq: 95429.2 100 # TLS is in R15 100 movq [R15 + #120 (8-bit)], RSI # ptr 104 PREFETCHNTA [RSI + #192 (32-bit)] 10b movq [RBX], 0x0000000000000001 # ptr 112 PREFETCHNTA [RSI + #256 (32-bit)] 119 movl [RBX + #8 (8-bit)], narrowklass: precise klass [B: 0x00007fa6b000e0e0:Constant:exact * # compressed klass ptr 120 movl [RBX + #12 (8-bit)], RDX # int 123 PREFETCHNTA [RSI + #320 (32-bit)] 12a movq RDI, RBX # spill 12d addq RDI, #16 # ptr 131 PREFETCHNTA [RSI + #384 (32-bit)] 138 shrq RCX, #3 13c addq RCX, #-2 # long 140 xorq rax, rax # ClearArray: shlq rcx,3 # Convert doublewords to bytes rep stosb # Store rax to *rdi++ while rcx-- 14a movq RBP, R11 # spill 14d movq [rsp + #0], R8 # spill 151 movq [rsp + #8], R10 # spill 156 movq [rsp + #16], R9 # spill 156 15b B18: # B36 B19 <- B26 B17 Freq: 95438.9 15b 15b MEMBAR-storestore (empty encoding) There, a StoreStore membar at the end of allocation gives you a safe semantics. For comparison, Unsafe.allocateArrayUninit allocation: 100 B17: # B18 <- B26 top-of-loop Freq: 79963.3 100 # TLS is in R15 100 movq [R15 + #120 (8-bit)], RBX # ptr 104 PREFETCHNTA [RBX + #192 (32-bit)] 10b movq [RAX], 0x0000000000000001 # ptr 112 PREFETCHNTA [RBX + #256 (32-bit)] 119 movl [RAX + #8 (8-bit)], narrowklass: precise klass [B: 0x00007f5a1c00e0e0:Constant:exact * # compressed klass ptr 120 movl [RAX + #12 (8-bit)], RDX # int 123 PREFETCHNTA [RBX + #320 (32-bit)] 12a PREFETCHNTA [RBX + #384 (32-bit)] 131 movq RBP, R8 # spill 134 movq [rsp + #0], RCX # spill 138 movq [rsp + #8], R9 # spill 13d movq [rsp + #16], R10 # spill 13d 142 B18: # B41 B19 <- B28 B17 Freq: 79971.4 142 142 MEMBAR-storestore (empty encoding) "ClearArray" parts are gone (we nuked it), but the StoreStore is still at our guard, protecting the array metadata. Of course, you will still see garbage data if after storing the array elements into the uninitialized array you would publish it racily. But the same is true for the "regular" allocations and subsequent writes. The only difference is whether you see "real" garbage, or some "synthetic" garbage like zeros. It is, of course, a caller responsibility to publish array safely in both cases, if garbage is unwanted. Aside: I really wanted to coalesce the metadata barriers with final field barriers one day, see https://bugs.openjdk.java.net/browse/JDK-8032481. Cheers, -Aleksey From aph at redhat.com Thu Feb 25 14:13:46 2016 From: aph at redhat.com (Andrew Haley) Date: Thu, 25 Feb 2016 14:13:46 +0000 Subject: RFR (S) 8150465: Unsafe methods to produce uninitialized arrays In-Reply-To: <56CF053A.3070607@oracle.com> References: <56CE3222.6040207@oracle.com> <56CECE5E.4080105@redhat.com> <56CF053A.3070607@oracle.com> Message-ID: <56CF0C1A.4040600@redhat.com> On 02/25/2016 01:44 PM, Aleksey Shipilev wrote: > Of course, you will still see garbage data if after storing the array > elements into the uninitialized array you would publish it racily. But > the same is true for the "regular" allocations and subsequent writes. > The only difference is whether you see "real" garbage, or some > "synthetic" garbage like zeros. It is, of course, a caller > responsibility to publish array safely in both cases, if garbage is > unwanted. Of course, my worry with this optimization assumes that programmers make mistakes. But you did say "complicated processing is done after the allocation." And that's where programmers make mistakes. Andrew. From aleksey.shipilev at oracle.com Thu Feb 25 14:36:19 2016 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Thu, 25 Feb 2016 17:36:19 +0300 Subject: RFR (S) 8150465: Unsafe methods to produce uninitialized arrays In-Reply-To: <56CF0C1A.4040600@redhat.com> References: <56CE3222.6040207@oracle.com> <56CECE5E.4080105@redhat.com> <56CF053A.3070607@oracle.com> <56CF0C1A.4040600@redhat.com> Message-ID: <56CF1163.4040005@oracle.com> On 02/25/2016 05:13 PM, Andrew Haley wrote: > On 02/25/2016 01:44 PM, Aleksey Shipilev wrote: >> Of course, you will still see garbage data if after storing the array >> elements into the uninitialized array you would publish it racily. But >> the same is true for the "regular" allocations and subsequent writes. >> The only difference is whether you see "real" garbage, or some >> "synthetic" garbage like zeros. It is, of course, a caller >> responsibility to publish array safely in both cases, if garbage is >> unwanted. > > Of course, my worry with this optimization assumes that programmers > make mistakes. But you did say "complicated processing is done after > the allocation." And that's where programmers make mistakes. Of course they do; at least half of the Unsafe methods is suitable for shooting oneself in a foot in creative ways. Unsafe is a sharp tool, and Unsafe callers are trusted in their madness. This is not your average Joe's use case, for sure. In other words, callers can and should provide defense in depth when they are using Unsafe. It's not the goal for Unsafe to provide those defenses, if that contradicts performance goals. If you need defenses, code in plain Java. E.g. for suggested use in StringConcatFactory [1], we say: "StringConcatFactory would probably have to provide a few more checks if using any new Unsafe API: notably the "exactness" debug check in MH_INLINE_SIZED_EXACT should probably be turned on by default -- this will check we never ever construct a String with garbage data." This single index check is much cheaper than defensively zeroing the entire array. Thanks, -Aleksey [1] https://bugs.openjdk.java.net/browse/JDK-8150463 From paul.sandoz at oracle.com Thu Feb 25 15:47:11 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 25 Feb 2016 16:47:11 +0100 Subject: RFR (S) 8150465: Unsafe methods to produce uninitialized arrays In-Reply-To: <56CF1163.4040005@oracle.com> References: <56CE3222.6040207@oracle.com> <56CECE5E.4080105@redhat.com> <56CF053A.3070607@oracle.com> <56CF0C1A.4040600@redhat.com> <56CF1163.4040005@oracle.com> Message-ID: <6D79C6DB-B770-4CAA-9338-154589441F8B@oracle.com> > On 25 Feb 2016, at 15:36, Aleksey Shipilev wrote: > > On 02/25/2016 05:13 PM, Andrew Haley wrote: >> On 02/25/2016 01:44 PM, Aleksey Shipilev wrote: >>> Of course, you will still see garbage data if after storing the array >>> elements into the uninitialized array you would publish it racily. But >>> the same is true for the "regular" allocations and subsequent writes. >>> The only difference is whether you see "real" garbage, or some >>> "synthetic" garbage like zeros. It is, of course, a caller >>> responsibility to publish array safely in both cases, if garbage is >>> unwanted. >> >> Of course, my worry with this optimization assumes that programmers >> make mistakes. But you did say "complicated processing is done after >> the allocation." And that's where programmers make mistakes. > > Of course they do; at least half of the Unsafe methods is suitable for > shooting oneself in a foot in creative ways. Unsafe is a sharp tool, and > Unsafe callers are trusted in their madness. This is not your average > Joe's use case, for sure. > FTR the contents of the memory allocated by Unsafe.allocateMemory are also uninitialized. Paul. From vladimir.kozlov at oracle.com Thu Feb 25 16:34:56 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 25 Feb 2016 08:34:56 -0800 Subject: RFR (S) 8150465: Unsafe methods to produce uninitialized arrays In-Reply-To: <56CEB700.9020603@oracle.com> References: <56CE3222.6040207@oracle.com> <56CE3B13.3090700@oracle.com> <56CE41FE.6070103@oracle.com> <56CE48C8.2050707@oracle.com> <56CEB700.9020603@oracle.com> Message-ID: <56CF2D30.6020208@oracle.com> Okay. Looks good. Thanks, Vladimir On 2/25/16 12:10 AM, Aleksey Shipilev wrote: > On 02/25/2016 03:20 AM, Vladimir Kozlov wrote: >> On 2/24/16 3:51 PM, Aleksey Shipilev wrote: >>> On 02/25/2016 02:21 AM, Vladimir Kozlov wrote: >>>> What is your story for GC? When an array become visible and GC happens, >>>> it will expect only initialized arrays. >>> >>> New method allows primitive arrays only, and its headers should be >>> intact. This is corroborated by the new jtreg test (and benchmarks!) >>> that allocate lots of uninitialized arrays, and obviously they get GCed. >> >> Yes, primitive arrays are fine if the header is correct. In this case >> changes are fine but you may need to add a check in >> inline_unsafe_newArray() that it is only primitive types. > > Alas, the class argument may not be constant, and so we would need a > runtime check there, which would duplicate the check we already have in > Unsafe.java. I'd prefer to follow the upcoming pattern in Mikael's > Unsafe cleanup with making as much checks on Java side. > >> testIAE() should throw exception if IllegalArgumentException is not thrown. > > D'uh, of course! > > See updates: > http://cr.openjdk.java.net/~shade/8150465/webrev.jdk.01/ > http://cr.openjdk.java.net/~shade/8150465/webrev.hs.02/ > > Cheers, > -Aleksey > From christian.thalinger at oracle.com Thu Feb 25 19:52:29 2016 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 25 Feb 2016 09:52:29 -1000 Subject: RFR (S) 8150465: Unsafe methods to produce uninitialized arrays In-Reply-To: <56CE3222.6040207@oracle.com> References: <56CE3222.6040207@oracle.com> Message-ID: + public Object allocateArrayUninit(Class componentType, int length) { Can we use another name like allocateUninitializedArray? > On Feb 24, 2016, at 12:43 PM, Aleksey Shipilev wrote: > > Hi, > > When instantiating arrays from Java, we have to zero the backing storage > to match JLS requirements. In some cases, like with the subsequent > arraycopy, compilers are able to remove zeroing. However, in a generic > case where a complicated processing is done after the allocation, > compilers are unable to reliably figure out the array is covered completely. > > JDK-8150463 is a motivational example of this: Java level String concat > loses to C2's OptimizeStringConcat because C2 can skip zeroing for its > own allocations. > > It might make sense to allow new Unsafe method that will return > uninitialized arrays to trusted Java code: > https://bugs.openjdk.java.net/browse/JDK-8150465 > > Webrevs: > http://cr.openjdk.java.net/~shade/8150465/webrev.hs.01/ > http://cr.openjdk.java.net/~shade/8150465/webrev.jdk.01/ > > It helps that we already have java.lang.reflect.Array.newArray > intrinsic, so we can reuse a lot of code. The intrinsic code nukes the > array allocation in the same way PhaseStringOpts::allocate_byte_array > does it in OptimizeStringConcat. Alas, no such luck in C1, and so it > stays untouched, falling back to normal Java allocations. > > Performance data shows the promising improvements: > http://cr.openjdk.java.net/~shade/8150465/notes.txt > > Also, using this new method brings the best Java-level-only > concatenation strategy to OptimizeStringConcat levels, and beyond. > > Testing: new test; targeted microbenchmarks; JPRT (in progress) > > Thanks, > -Aleksey > From aleksey.shipilev at oracle.com Thu Feb 25 20:11:51 2016 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Thu, 25 Feb 2016 23:11:51 +0300 Subject: RFR (S) 8150465: Unsafe methods to produce uninitialized arrays In-Reply-To: References: <56CE3222.6040207@oracle.com> Message-ID: <56CF6007.5060607@oracle.com> On 02/25/2016 10:52 PM, Christian Thalinger wrote: > + public Object allocateArrayUninit(Class componentType, int length) { > > Can we use another name like allocateUninitializedArray? Yes, we can: http://cr.openjdk.java.net/~shade/8150465/webrev.jdk.02/ http://cr.openjdk.java.net/~shade/8150465/webrev.hs.03/ This was search-and-replace renaming, and the test is still working fine. Haven't re-spinned JPRT for this one. Cheers, -Aleksey From aleksey.shipilev at oracle.com Thu Feb 25 20:13:05 2016 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Thu, 25 Feb 2016 23:13:05 +0300 Subject: RFR (S) 8150465: Unsafe methods to produce uninitialized arrays In-Reply-To: <56CF2D30.6020208@oracle.com> References: <56CE3222.6040207@oracle.com> <56CE3B13.3090700@oracle.com> <56CE41FE.6070103@oracle.com> <56CE48C8.2050707@oracle.com> <56CEB700.9020603@oracle.com> <56CF2D30.6020208@oracle.com> Message-ID: <56CF6051.8080201@oracle.com> On 02/25/2016 07:34 PM, Vladimir Kozlov wrote: > Okay. Looks good. Thanks for review, Vladimir! -Aleksey P.S. FTR, I renamed the method to Unsafe.allocateUninitializedArray, as per Christian's request; see my previous note. From coleen.phillimore at oracle.com Thu Feb 25 20:39:56 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 25 Feb 2016 15:39:56 -0500 Subject: CFV: New JDK 9 Committer: Chris Plummer Message-ID: <56CF669C.6080108@oracle.com> I hereby nominate Chris Plummer (cjplummer) to JDK 9 Committer. Chris is a member of the Oracle Hotspot runtime team and is a long time Java virtual machine developer. He has contributed 18 changesets to hotspot and complimentary changesets to other open repositories [3]. These changes are for test fixes, bug fixes, NMT, CDS enhancements and memory savings improvements. He is currently working to reduce memory footprint for metadata. Votes are due by 4:00 PM EST, Thursday March 10, 2016. Only current JDK 9 Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [2]. Coleen Phillimore [1] http://openjdk.java.net/census [2] http://openjdk.java.net/projects/#committer-vote [3] List of patches: http://hg.openjdk.java.net/jdk9/hs-rt/rev/d870508ede1c 8144677: jprt.properties should allow creating a user specified testset with custom build flavors and build targets http://hg.openjdk.java.net/jdk9/hs-rt/nashorn/rev/8a10da61fc61 http://hg.openjdk.java.net/jdk9/hs-rt/langtools/rev/91ea64d22fd9 http://hg.openjdk.java.net/jdk9/hs-rt/jaxp/rev/e939badf7330 http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/3923f2b31fd2 http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/40a609a54513 8141489: [TESTBUG] requiredVersion in TEST.ROOT needs to updated to 4.1 b12 http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/8a1e0568b885 http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/f81484d852ac 8140189: [TESTBUG] Get rid of "@library /../../test/lib" in jtreg tests http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/775c293c892e http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/431b1333b1c1 8129386: [TESTBUG] - com/sun/jdi/cds/*.java missing @build tag for libraries http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/86144218cf3f 8054386: Allow Java debugging when CDS is enabled http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/5791c37057ed 8081771: ProcessTool.createJavaProcessBuilder() needs new addTestVmAndJavaOptions argument http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/4a9f1b1135cb 8066507: JPRT is not capable of running jtreg tests located jdk/test http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/6d92296d52ca 6762191: Setting stack size to 16K causes segmentation fault http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/72afb83f5035 8143608: Don't 64-bit align start of InstanceKlass vtable, itable, and nonstatic_oopmap on 32-bit systems http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/01a99de9d5cb 8087153: EXCEPTION_ACCESS_VIOLATION when CDS RO section vanished on win32 http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/9fa5219f0206 8051712: regression Test7107135 crashes http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/771c83af7df8 8069111: Investigate NMT detail tracking support for 32bit ARM http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/034eb71ab7fd 8054888: Runtime: Add Diagnostic Command that prints the class hierarchy http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/a3f3bc88d1f3 8066508: JTReg tests timeout on slow devices when run using JPRT http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/351115afe32b 8043770: File leak in MemNotifyThread::start() in hotspot.src.os.linux.vm.os_linux.cpp http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/27ce97a5b0dd 6191224: (reflect) Misleading detail string in IllegalArgumentException thrown by Array.get http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/795fc0cef7c9 8046607: Code cleanup: PerfMemory::backing_store_filename() should be removed http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/5fd8e2fbafd4 8020829: JT_HS: 2 runtime NMT tests fail on platforms if NMT detail is not supported From coleen.phillimore at oracle.com Thu Feb 25 20:41:22 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 25 Feb 2016 15:41:22 -0500 Subject: CFV: New JDK 9 Committer: Chris Plummer In-Reply-To: <56CF669C.6080108@oracle.com> References: <56CF669C.6080108@oracle.com> Message-ID: <56CF66F2.5010005@oracle.com> Vote: yes On 2/25/16 3:39 PM, Coleen Phillimore wrote: > I hereby nominate Chris Plummer (cjplummer) to JDK 9 Committer. > > Chris is a member of the Oracle Hotspot runtime team and is a long > time Java virtual machine developer. He has contributed 18 changesets > to hotspot and complimentary changesets to other open repositories > [3]. These changes are for test fixes, bug fixes, NMT, CDS > enhancements and memory savings improvements. He is currently working > to reduce memory footprint for metadata. > > Votes are due by 4:00 PM EST, Thursday March 10, 2016. > > Only current JDK 9 Committers [1] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Lazy Consensus voting instructions, see [2]. > > Coleen Phillimore > > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] List of patches: > > http://hg.openjdk.java.net/jdk9/hs-rt/rev/d870508ede1c > 8144677: jprt.properties should allow creating a user specified > testset with custom build flavors and build targets > > http://hg.openjdk.java.net/jdk9/hs-rt/nashorn/rev/8a10da61fc61 > http://hg.openjdk.java.net/jdk9/hs-rt/langtools/rev/91ea64d22fd9 > http://hg.openjdk.java.net/jdk9/hs-rt/jaxp/rev/e939badf7330 > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/3923f2b31fd2 > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/40a609a54513 > 8141489: [TESTBUG] requiredVersion in TEST.ROOT needs to updated to > 4.1 b12 > > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/8a1e0568b885 > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/f81484d852ac > 8140189: [TESTBUG] Get rid of "@library /../../test/lib" in jtreg tests > > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/775c293c892e > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/431b1333b1c1 > 8129386: [TESTBUG] - com/sun/jdi/cds/*.java missing @build tag for > libraries > > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/86144218cf3f > 8054386: Allow Java debugging when CDS is enabled > > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/5791c37057ed > 8081771: ProcessTool.createJavaProcessBuilder() needs new > addTestVmAndJavaOptions argument > > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/4a9f1b1135cb > 8066507: JPRT is not capable of running jtreg tests located jdk/test > > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/6d92296d52ca > 6762191: Setting stack size to 16K causes segmentation fault > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/72afb83f5035 > 8143608: Don't 64-bit align start of InstanceKlass vtable, itable, and > nonstatic_oopmap on 32-bit systems > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/01a99de9d5cb > 8087153: EXCEPTION_ACCESS_VIOLATION when CDS RO section vanished on win32 > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/9fa5219f0206 > 8051712: regression Test7107135 crashes > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/771c83af7df8 > 8069111: Investigate NMT detail tracking support for 32bit ARM > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/034eb71ab7fd > 8054888: Runtime: Add Diagnostic Command that prints the class hierarchy > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/a3f3bc88d1f3 > 8066508: JTReg tests timeout on slow devices when run using JPRT > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/351115afe32b > 8043770: File leak in MemNotifyThread::start() in > hotspot.src.os.linux.vm.os_linux.cpp > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/27ce97a5b0dd > 6191224: (reflect) Misleading detail string in > IllegalArgumentException thrown by Array.get > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/795fc0cef7c9 > 8046607: Code cleanup: PerfMemory::backing_store_filename() should be > removed > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/5fd8e2fbafd4 > 8020829: JT_HS: 2 runtime NMT tests fail on platforms if NMT detail is > not supported > From vladimir.kozlov at oracle.com Thu Feb 25 20:45:02 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 25 Feb 2016 12:45:02 -0800 Subject: CFV: New JDK 9 Committer: Chris Plummer In-Reply-To: <56CF669C.6080108@oracle.com> References: <56CF669C.6080108@oracle.com> Message-ID: <56CF67CE.1090505@oracle.com> Vote: yes On 2/25/16 12:39 PM, Coleen Phillimore wrote: > I hereby nominate Chris Plummer (cjplummer) to JDK 9 Committer. > > Chris is a member of the Oracle Hotspot runtime team and is a long time > Java virtual machine developer. He has contributed 18 changesets to > hotspot and complimentary changesets to other open repositories [3]. > These changes are for test fixes, bug fixes, NMT, CDS enhancements and > memory savings improvements. He is currently working to reduce memory > footprint for metadata. > > Votes are due by 4:00 PM EST, Thursday March 10, 2016. > > Only current JDK 9 Committers [1] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Lazy Consensus voting instructions, see [2]. > > Coleen Phillimore > > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] List of patches: > > http://hg.openjdk.java.net/jdk9/hs-rt/rev/d870508ede1c > 8144677: jprt.properties should allow creating a user specified testset > with custom build flavors and build targets > > http://hg.openjdk.java.net/jdk9/hs-rt/nashorn/rev/8a10da61fc61 > http://hg.openjdk.java.net/jdk9/hs-rt/langtools/rev/91ea64d22fd9 > http://hg.openjdk.java.net/jdk9/hs-rt/jaxp/rev/e939badf7330 > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/3923f2b31fd2 > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/40a609a54513 > 8141489: [TESTBUG] requiredVersion in TEST.ROOT needs to updated to 4.1 b12 > > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/8a1e0568b885 > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/f81484d852ac > 8140189: [TESTBUG] Get rid of "@library /../../test/lib" in jtreg tests > > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/775c293c892e > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/431b1333b1c1 > 8129386: [TESTBUG] - com/sun/jdi/cds/*.java missing @build tag for > libraries > > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/86144218cf3f > 8054386: Allow Java debugging when CDS is enabled > > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/5791c37057ed > 8081771: ProcessTool.createJavaProcessBuilder() needs new > addTestVmAndJavaOptions argument > > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/4a9f1b1135cb > 8066507: JPRT is not capable of running jtreg tests located jdk/test > > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/6d92296d52ca > 6762191: Setting stack size to 16K causes segmentation fault > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/72afb83f5035 > 8143608: Don't 64-bit align start of InstanceKlass vtable, itable, and > nonstatic_oopmap on 32-bit systems > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/01a99de9d5cb > 8087153: EXCEPTION_ACCESS_VIOLATION when CDS RO section vanished on win32 > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/9fa5219f0206 > 8051712: regression Test7107135 crashes > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/771c83af7df8 > 8069111: Investigate NMT detail tracking support for 32bit ARM > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/034eb71ab7fd > 8054888: Runtime: Add Diagnostic Command that prints the class hierarchy > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/a3f3bc88d1f3 > 8066508: JTReg tests timeout on slow devices when run using JPRT > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/351115afe32b > 8043770: File leak in MemNotifyThread::start() in > hotspot.src.os.linux.vm.os_linux.cpp > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/27ce97a5b0dd > 6191224: (reflect) Misleading detail string in IllegalArgumentException > thrown by Array.get > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/795fc0cef7c9 > 8046607: Code cleanup: PerfMemory::backing_store_filename() should be > removed > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/5fd8e2fbafd4 > 8020829: JT_HS: 2 runtime NMT tests fail on platforms if NMT detail is > not supported > From lois.foltan at oracle.com Thu Feb 25 20:50:19 2016 From: lois.foltan at oracle.com (Lois Foltan) Date: Thu, 25 Feb 2016 15:50:19 -0500 Subject: CFV: New JDK 9 Committer: Chris Plummer In-Reply-To: <56CF669C.6080108@oracle.com> References: <56CF669C.6080108@oracle.com> Message-ID: <56CF690B.3040909@oracle.com> Vote: yes Lois On 2/25/2016 3:39 PM, Coleen Phillimore wrote: > I hereby nominate Chris Plummer (cjplummer) to JDK 9 Committer. > > Chris is a member of the Oracle Hotspot runtime team and is a long > time Java virtual machine developer. He has contributed 18 changesets > to hotspot and complimentary changesets to other open repositories > [3]. These changes are for test fixes, bug fixes, NMT, CDS > enhancements and memory savings improvements. He is currently working > to reduce memory footprint for metadata. > > Votes are due by 4:00 PM EST, Thursday March 10, 2016. > > Only current JDK 9 Committers [1] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Lazy Consensus voting instructions, see [2]. > > Coleen Phillimore > > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] List of patches: > > http://hg.openjdk.java.net/jdk9/hs-rt/rev/d870508ede1c > 8144677: jprt.properties should allow creating a user specified > testset with custom build flavors and build targets > > http://hg.openjdk.java.net/jdk9/hs-rt/nashorn/rev/8a10da61fc61 > http://hg.openjdk.java.net/jdk9/hs-rt/langtools/rev/91ea64d22fd9 > http://hg.openjdk.java.net/jdk9/hs-rt/jaxp/rev/e939badf7330 > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/3923f2b31fd2 > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/40a609a54513 > 8141489: [TESTBUG] requiredVersion in TEST.ROOT needs to updated to > 4.1 b12 > > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/8a1e0568b885 > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/f81484d852ac > 8140189: [TESTBUG] Get rid of "@library /../../test/lib" in jtreg tests > > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/775c293c892e > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/431b1333b1c1 > 8129386: [TESTBUG] - com/sun/jdi/cds/*.java missing @build tag for > libraries > > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/86144218cf3f > 8054386: Allow Java debugging when CDS is enabled > > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/5791c37057ed > 8081771: ProcessTool.createJavaProcessBuilder() needs new > addTestVmAndJavaOptions argument > > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/4a9f1b1135cb > 8066507: JPRT is not capable of running jtreg tests located jdk/test > > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/6d92296d52ca > 6762191: Setting stack size to 16K causes segmentation fault > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/72afb83f5035 > 8143608: Don't 64-bit align start of InstanceKlass vtable, itable, and > nonstatic_oopmap on 32-bit systems > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/01a99de9d5cb > 8087153: EXCEPTION_ACCESS_VIOLATION when CDS RO section vanished on win32 > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/9fa5219f0206 > 8051712: regression Test7107135 crashes > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/771c83af7df8 > 8069111: Investigate NMT detail tracking support for 32bit ARM > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/034eb71ab7fd > 8054888: Runtime: Add Diagnostic Command that prints the class hierarchy > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/a3f3bc88d1f3 > 8066508: JTReg tests timeout on slow devices when run using JPRT > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/351115afe32b > 8043770: File leak in MemNotifyThread::start() in > hotspot.src.os.linux.vm.os_linux.cpp > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/27ce97a5b0dd > 6191224: (reflect) Misleading detail string in > IllegalArgumentException thrown by Array.get > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/795fc0cef7c9 > 8046607: Code cleanup: PerfMemory::backing_store_filename() should be > removed > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/5fd8e2fbafd4 > 8020829: JT_HS: 2 runtime NMT tests fail on platforms if NMT detail is > not supported > From christian.thalinger at oracle.com Thu Feb 25 20:51:09 2016 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 25 Feb 2016 10:51:09 -1000 Subject: RFR (S) 8150465: Unsafe methods to produce uninitialized arrays In-Reply-To: <56CF6007.5060607@oracle.com> References: <56CE3222.6040207@oracle.com> <56CF6007.5060607@oracle.com> Message-ID: <3456FD3A-CBF8-46AD-9092-5DC7C6A02DD8@oracle.com> > On Feb 25, 2016, at 10:11 AM, Aleksey Shipilev wrote: > > On 02/25/2016 10:52 PM, Christian Thalinger wrote: >> + public Object allocateArrayUninit(Class componentType, int length) { >> >> Can we use another name like allocateUninitializedArray? > > Yes, we can: > http://cr.openjdk.java.net/~shade/8150465/webrev.jdk.02/ > http://cr.openjdk.java.net/~shade/8150465/webrev.hs.03/ Thanks but I wanted the change in hotspot code too. > > This was search-and-replace renaming, and the test is still working > fine. Haven't re-spinned JPRT for this one. > > Cheers, > -Aleksey > > > From christian.thalinger at oracle.com Thu Feb 25 20:51:28 2016 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 25 Feb 2016 10:51:28 -1000 Subject: CFV: New JDK 9 Committer: Chris Plummer In-Reply-To: <56CF669C.6080108@oracle.com> References: <56CF669C.6080108@oracle.com> Message-ID: <42E7588A-D0F3-4284-A130-44732E8AD881@oracle.com> Vote: yes > On Feb 25, 2016, at 10:39 AM, Coleen Phillimore wrote: > > I hereby nominate Chris Plummer (cjplummer) to JDK 9 Committer. > > Chris is a member of the Oracle Hotspot runtime team and is a long time Java virtual machine developer. He has contributed 18 changesets to hotspot and complimentary changesets to other open repositories [3]. These changes are for test fixes, bug fixes, NMT, CDS enhancements and memory savings improvements. He is currently working to reduce memory footprint for metadata. > > Votes are due by 4:00 PM EST, Thursday March 10, 2016. > > Only current JDK 9 Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Coleen Phillimore > > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] List of patches: > > http://hg.openjdk.java.net/jdk9/hs-rt/rev/d870508ede1c > 8144677: jprt.properties should allow creating a user specified testset with custom build flavors and build targets > > http://hg.openjdk.java.net/jdk9/hs-rt/nashorn/rev/8a10da61fc61 > http://hg.openjdk.java.net/jdk9/hs-rt/langtools/rev/91ea64d22fd9 > http://hg.openjdk.java.net/jdk9/hs-rt/jaxp/rev/e939badf7330 > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/3923f2b31fd2 > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/40a609a54513 > 8141489: [TESTBUG] requiredVersion in TEST.ROOT needs to updated to 4.1 b12 > > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/8a1e0568b885 > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/f81484d852ac > 8140189: [TESTBUG] Get rid of "@library /../../test/lib" in jtreg tests > > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/775c293c892e > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/431b1333b1c1 > 8129386: [TESTBUG] - com/sun/jdi/cds/*.java missing @build tag for libraries > > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/86144218cf3f > 8054386: Allow Java debugging when CDS is enabled > > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/5791c37057ed > 8081771: ProcessTool.createJavaProcessBuilder() needs new addTestVmAndJavaOptions argument > > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/4a9f1b1135cb > 8066507: JPRT is not capable of running jtreg tests located jdk/test > > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/6d92296d52ca > 6762191: Setting stack size to 16K causes segmentation fault > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/72afb83f5035 > 8143608: Don't 64-bit align start of InstanceKlass vtable, itable, and nonstatic_oopmap on 32-bit systems > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/01a99de9d5cb > 8087153: EXCEPTION_ACCESS_VIOLATION when CDS RO section vanished on win32 > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/9fa5219f0206 > 8051712: regression Test7107135 crashes > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/771c83af7df8 > 8069111: Investigate NMT detail tracking support for 32bit ARM > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/034eb71ab7fd > 8054888: Runtime: Add Diagnostic Command that prints the class hierarchy > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/a3f3bc88d1f3 > 8066508: JTReg tests timeout on slow devices when run using JPRT > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/351115afe32b > 8043770: File leak in MemNotifyThread::start() in hotspot.src.os.linux.vm.os_linux.cpp > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/27ce97a5b0dd > 6191224: (reflect) Misleading detail string in IllegalArgumentException thrown by Array.get > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/795fc0cef7c9 > 8046607: Code cleanup: PerfMemory::backing_store_filename() should be removed > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/5fd8e2fbafd4 > 8020829: JT_HS: 2 runtime NMT tests fail on platforms if NMT detail is not supported > From john.r.rose at oracle.com Thu Feb 25 20:53:17 2016 From: john.r.rose at oracle.com (John Rose) Date: Thu, 25 Feb 2016 12:53:17 -0800 Subject: CFV: New JDK 9 Committer: Chris Plummer In-Reply-To: <56CF669C.6080108@oracle.com> References: <56CF669C.6080108@oracle.com> Message-ID: <543891EC-8D63-462F-BB87-98CB6C9A928E@oracle.com> Vote: yes From Roger.Riggs at Oracle.com Thu Feb 25 20:57:41 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Thu, 25 Feb 2016 15:57:41 -0500 Subject: CFV: New JDK 9 Committer: Chris Plummer In-Reply-To: <56CF669C.6080108@oracle.com> References: <56CF669C.6080108@oracle.com> Message-ID: <56CF6AC5.3000409@Oracle.com> Vote: Yes On 2/25/2016 3:39 PM, Coleen Phillimore wrote: > I hereby nominate Chris Plummer (cjplummer) to JDK 9 Committer. > From jiangli.zhou at oracle.com Thu Feb 25 20:59:21 2016 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Thu, 25 Feb 2016 12:59:21 -0800 Subject: CFV: New JDK 9 Committer: Chris Plummer In-Reply-To: <56CF669C.6080108@oracle.com> References: <56CF669C.6080108@oracle.com> Message-ID: <98DB4D16-49BB-45C0-9ACF-3FD37734D8B1@oracle.com> Vote: yes Thanks, Jiangli > On Feb 25, 2016, at 12:39 PM, Coleen Phillimore wrote: > > I hereby nominate Chris Plummer (cjplummer) to JDK 9 Committer. > > Chris is a member of the Oracle Hotspot runtime team and is a long time Java virtual machine developer. He has contributed 18 changesets to hotspot and complimentary changesets to other open repositories [3]. These changes are for test fixes, bug fixes, NMT, CDS enhancements and memory savings improvements. He is currently working to reduce memory footprint for metadata. > > Votes are due by 4:00 PM EST, Thursday March 10, 2016. > > Only current JDK 9 Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Coleen Phillimore > > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] List of patches: > > http://hg.openjdk.java.net/jdk9/hs-rt/rev/d870508ede1c > 8144677: jprt.properties should allow creating a user specified testset with custom build flavors and build targets > > http://hg.openjdk.java.net/jdk9/hs-rt/nashorn/rev/8a10da61fc61 > http://hg.openjdk.java.net/jdk9/hs-rt/langtools/rev/91ea64d22fd9 > http://hg.openjdk.java.net/jdk9/hs-rt/jaxp/rev/e939badf7330 > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/3923f2b31fd2 > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/40a609a54513 > 8141489: [TESTBUG] requiredVersion in TEST.ROOT needs to updated to 4.1 b12 > > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/8a1e0568b885 > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/f81484d852ac > 8140189: [TESTBUG] Get rid of "@library /../../test/lib" in jtreg tests > > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/775c293c892e > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/431b1333b1c1 > 8129386: [TESTBUG] - com/sun/jdi/cds/*.java missing @build tag for libraries > > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/86144218cf3f > 8054386: Allow Java debugging when CDS is enabled > > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/5791c37057ed > 8081771: ProcessTool.createJavaProcessBuilder() needs new addTestVmAndJavaOptions argument > > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/4a9f1b1135cb > 8066507: JPRT is not capable of running jtreg tests located jdk/test > > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/6d92296d52ca > 6762191: Setting stack size to 16K causes segmentation fault > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/72afb83f5035 > 8143608: Don't 64-bit align start of InstanceKlass vtable, itable, and nonstatic_oopmap on 32-bit systems > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/01a99de9d5cb > 8087153: EXCEPTION_ACCESS_VIOLATION when CDS RO section vanished on win32 > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/9fa5219f0206 > 8051712: regression Test7107135 crashes > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/771c83af7df8 > 8069111: Investigate NMT detail tracking support for 32bit ARM > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/034eb71ab7fd > 8054888: Runtime: Add Diagnostic Command that prints the class hierarchy > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/a3f3bc88d1f3 > 8066508: JTReg tests timeout on slow devices when run using JPRT > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/351115afe32b > 8043770: File leak in MemNotifyThread::start() in hotspot.src.os.linux.vm.os_linux.cpp > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/27ce97a5b0dd > 6191224: (reflect) Misleading detail string in IllegalArgumentException thrown by Array.get > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/795fc0cef7c9 > 8046607: Code cleanup: PerfMemory::backing_store_filename() should be removed > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/5fd8e2fbafd4 > 8020829: JT_HS: 2 runtime NMT tests fail on platforms if NMT detail is not supported > From calvin.cheung at oracle.com Thu Feb 25 21:04:58 2016 From: calvin.cheung at oracle.com (Calvin Cheung) Date: Thu, 25 Feb 2016 13:04:58 -0800 Subject: CFV: New JDK 9 Committer: Chris Plummer In-Reply-To: <56CF669C.6080108@oracle.com> References: <56CF669C.6080108@oracle.com> Message-ID: <56CF6C7A.2090001@oracle.com> Vote: yes On 2/25/16, 12:39 PM, Coleen Phillimore wrote: > I hereby nominate Chris Plummer (cjplummer) to JDK 9 Committer. > > Chris is a member of the Oracle Hotspot runtime team and is a long > time Java virtual machine developer. He has contributed 18 changesets > to hotspot and complimentary changesets to other open repositories > [3]. These changes are for test fixes, bug fixes, NMT, CDS > enhancements and memory savings improvements. He is currently working > to reduce memory footprint for metadata. > > Votes are due by 4:00 PM EST, Thursday March 10, 2016. > > Only current JDK 9 Committers [1] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Lazy Consensus voting instructions, see [2]. > > Coleen Phillimore > > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] List of patches: > > http://hg.openjdk.java.net/jdk9/hs-rt/rev/d870508ede1c > 8144677: jprt.properties should allow creating a user specified > testset with custom build flavors and build targets > > http://hg.openjdk.java.net/jdk9/hs-rt/nashorn/rev/8a10da61fc61 > http://hg.openjdk.java.net/jdk9/hs-rt/langtools/rev/91ea64d22fd9 > http://hg.openjdk.java.net/jdk9/hs-rt/jaxp/rev/e939badf7330 > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/3923f2b31fd2 > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/40a609a54513 > 8141489: [TESTBUG] requiredVersion in TEST.ROOT needs to updated to > 4.1 b12 > > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/8a1e0568b885 > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/f81484d852ac > 8140189: [TESTBUG] Get rid of "@library /../../test/lib" in jtreg tests > > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/775c293c892e > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/431b1333b1c1 > 8129386: [TESTBUG] - com/sun/jdi/cds/*.java missing @build tag for > libraries > > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/86144218cf3f > 8054386: Allow Java debugging when CDS is enabled > > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/5791c37057ed > 8081771: ProcessTool.createJavaProcessBuilder() needs new > addTestVmAndJavaOptions argument > > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/4a9f1b1135cb > 8066507: JPRT is not capable of running jtreg tests located jdk/test > > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/6d92296d52ca > 6762191: Setting stack size to 16K causes segmentation fault > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/72afb83f5035 > 8143608: Don't 64-bit align start of InstanceKlass vtable, itable, and > nonstatic_oopmap on 32-bit systems > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/01a99de9d5cb > 8087153: EXCEPTION_ACCESS_VIOLATION when CDS RO section vanished on win32 > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/9fa5219f0206 > 8051712: regression Test7107135 crashes > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/771c83af7df8 > 8069111: Investigate NMT detail tracking support for 32bit ARM > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/034eb71ab7fd > 8054888: Runtime: Add Diagnostic Command that prints the class hierarchy > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/a3f3bc88d1f3 > 8066508: JTReg tests timeout on slow devices when run using JPRT > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/351115afe32b > 8043770: File leak in MemNotifyThread::start() in > hotspot.src.os.linux.vm.os_linux.cpp > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/27ce97a5b0dd > 6191224: (reflect) Misleading detail string in > IllegalArgumentException thrown by Array.get > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/795fc0cef7c9 > 8046607: Code cleanup: PerfMemory::backing_store_filename() should be > removed > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/5fd8e2fbafd4 > 8020829: JT_HS: 2 runtime NMT tests fail on platforms if NMT detail is > not supported > From Peter.B.Kessler at Oracle.COM Thu Feb 25 21:11:21 2016 From: Peter.B.Kessler at Oracle.COM (Peter B. Kessler) Date: Thu, 25 Feb 2016 13:11:21 -0800 Subject: CFV: New JDK 9 Committer: Chris Plummer In-Reply-To: <56CF669C.6080108@oracle.com> References: <56CF669C.6080108@oracle.com> Message-ID: <56CF6DF9.8000002@Oracle.COM> Vote: yes. ... peter On 02/25/16 12:39 PM, Coleen Phillimore wrote: > I hereby nominate Chris Plummer (cjplummer) to JDK 9 Committer. > > Chris is a member of the Oracle Hotspot runtime team and is a long time Java virtual machine developer. He has contributed 18 changesets to hotspot and complimentary changesets to other open repositories [3]. These changes are for test fixes, bug fixes, NMT, CDS enhancements and memory savings improvements. He is currently working to reduce memory footprint for metadata. > > Votes are due by 4:00 PM EST, Thursday March 10, 2016. > > Only current JDK 9 Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Coleen Phillimore From staffan.larsen at oracle.com Thu Feb 25 21:12:23 2016 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 25 Feb 2016 13:12:23 -0800 Subject: CFV: New JDK 9 Committer: Chris Plummer In-Reply-To: <56CF669C.6080108@oracle.com> References: <56CF669C.6080108@oracle.com> Message-ID: Vote: yes > On 25 feb. 2016, at 12:39, Coleen Phillimore wrote: > > I hereby nominate Chris Plummer (cjplummer) to JDK 9 Committer. > > Chris is a member of the Oracle Hotspot runtime team and is a long time Java virtual machine developer. He has contributed 18 changesets to hotspot and complimentary changesets to other open repositories [3]. These changes are for test fixes, bug fixes, NMT, CDS enhancements and memory savings improvements. He is currently working to reduce memory footprint for metadata. > > Votes are due by 4:00 PM EST, Thursday March 10, 2016. > > Only current JDK 9 Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Coleen Phillimore > > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] List of patches: > > http://hg.openjdk.java.net/jdk9/hs-rt/rev/d870508ede1c > 8144677: jprt.properties should allow creating a user specified testset with custom build flavors and build targets > > http://hg.openjdk.java.net/jdk9/hs-rt/nashorn/rev/8a10da61fc61 > http://hg.openjdk.java.net/jdk9/hs-rt/langtools/rev/91ea64d22fd9 > http://hg.openjdk.java.net/jdk9/hs-rt/jaxp/rev/e939badf7330 > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/3923f2b31fd2 > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/40a609a54513 > 8141489: [TESTBUG] requiredVersion in TEST.ROOT needs to updated to 4.1 b12 > > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/8a1e0568b885 > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/f81484d852ac > 8140189: [TESTBUG] Get rid of "@library /../../test/lib" in jtreg tests > > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/775c293c892e > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/431b1333b1c1 > 8129386: [TESTBUG] - com/sun/jdi/cds/*.java missing @build tag for libraries > > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/86144218cf3f > 8054386: Allow Java debugging when CDS is enabled > > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/5791c37057ed > 8081771: ProcessTool.createJavaProcessBuilder() needs new addTestVmAndJavaOptions argument > > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/4a9f1b1135cb > 8066507: JPRT is not capable of running jtreg tests located jdk/test > > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/6d92296d52ca > 6762191: Setting stack size to 16K causes segmentation fault > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/72afb83f5035 > 8143608: Don't 64-bit align start of InstanceKlass vtable, itable, and nonstatic_oopmap on 32-bit systems > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/01a99de9d5cb > 8087153: EXCEPTION_ACCESS_VIOLATION when CDS RO section vanished on win32 > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/9fa5219f0206 > 8051712: regression Test7107135 crashes > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/771c83af7df8 > 8069111: Investigate NMT detail tracking support for 32bit ARM > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/034eb71ab7fd > 8054888: Runtime: Add Diagnostic Command that prints the class hierarchy > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/a3f3bc88d1f3 > 8066508: JTReg tests timeout on slow devices when run using JPRT > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/351115afe32b > 8043770: File leak in MemNotifyThread::start() in hotspot.src.os.linux.vm.os_linux.cpp > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/27ce97a5b0dd > 6191224: (reflect) Misleading detail string in IllegalArgumentException thrown by Array.get > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/795fc0cef7c9 > 8046607: Code cleanup: PerfMemory::backing_store_filename() should be removed > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/5fd8e2fbafd4 > 8020829: JT_HS: 2 runtime NMT tests fail on platforms if NMT detail is not supported > From joseph.provino at oracle.com Thu Feb 25 21:16:22 2016 From: joseph.provino at oracle.com (Joseph Provino) Date: Thu, 25 Feb 2016 16:16:22 -0500 Subject: CFV: New JDK 9 Committer: Chris Plummer In-Reply-To: <56CF669C.6080108@oracle.com> References: <56CF669C.6080108@oracle.com> Message-ID: <56CF6F26.2080103@oracle.com> Vote: yes On 2/25/2016 3:39 PM, Coleen Phillimore wrote: > I hereby nominate Chris Plummer (cjplummer) to JDK 9 Committer. > > Chris is a member of the Oracle Hotspot runtime team and is a long > time Java virtual machine developer. He has contributed 18 changesets > to hotspot and complimentary changesets to other open repositories > [3]. These changes are for test fixes, bug fixes, NMT, CDS > enhancements and memory savings improvements. He is currently working > to reduce memory footprint for metadata. > > Votes are due by 4:00 PM EST, Thursday March 10, 2016. > > Only current JDK 9 Committers [1] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Lazy Consensus voting instructions, see [2]. > > Coleen Phillimore > > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] List of patches: > > http://hg.openjdk.java.net/jdk9/hs-rt/rev/d870508ede1c > 8144677: jprt.properties should allow creating a user specified > testset with custom build flavors and build targets > > http://hg.openjdk.java.net/jdk9/hs-rt/nashorn/rev/8a10da61fc61 > http://hg.openjdk.java.net/jdk9/hs-rt/langtools/rev/91ea64d22fd9 > http://hg.openjdk.java.net/jdk9/hs-rt/jaxp/rev/e939badf7330 > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/3923f2b31fd2 > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/40a609a54513 > 8141489: [TESTBUG] requiredVersion in TEST.ROOT needs to updated to > 4.1 b12 > > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/8a1e0568b885 > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/f81484d852ac > 8140189: [TESTBUG] Get rid of "@library /../../test/lib" in jtreg tests > > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/775c293c892e > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/431b1333b1c1 > 8129386: [TESTBUG] - com/sun/jdi/cds/*.java missing @build tag for > libraries > > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/86144218cf3f > 8054386: Allow Java debugging when CDS is enabled > > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/5791c37057ed > 8081771: ProcessTool.createJavaProcessBuilder() needs new > addTestVmAndJavaOptions argument > > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/4a9f1b1135cb > 8066507: JPRT is not capable of running jtreg tests located jdk/test > > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/6d92296d52ca > 6762191: Setting stack size to 16K causes segmentation fault > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/72afb83f5035 > 8143608: Don't 64-bit align start of InstanceKlass vtable, itable, and > nonstatic_oopmap on 32-bit systems > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/01a99de9d5cb > 8087153: EXCEPTION_ACCESS_VIOLATION when CDS RO section vanished on win32 > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/9fa5219f0206 > 8051712: regression Test7107135 crashes > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/771c83af7df8 > 8069111: Investigate NMT detail tracking support for 32bit ARM > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/034eb71ab7fd > 8054888: Runtime: Add Diagnostic Command that prints the class hierarchy > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/a3f3bc88d1f3 > 8066508: JTReg tests timeout on slow devices when run using JPRT > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/351115afe32b > 8043770: File leak in MemNotifyThread::start() in > hotspot.src.os.linux.vm.os_linux.cpp > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/27ce97a5b0dd > 6191224: (reflect) Misleading detail string in > IllegalArgumentException thrown by Array.get > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/795fc0cef7c9 > 8046607: Code cleanup: PerfMemory::backing_store_filename() should be > removed > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/5fd8e2fbafd4 > 8020829: JT_HS: 2 runtime NMT tests fail on platforms if NMT detail is > not supported > From aleksey.shipilev at oracle.com Thu Feb 25 21:18:36 2016 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Fri, 26 Feb 2016 00:18:36 +0300 Subject: RFR (S) 8150465: Unsafe methods to produce uninitialized arrays In-Reply-To: <3456FD3A-CBF8-46AD-9092-5DC7C6A02DD8@oracle.com> References: <56CE3222.6040207@oracle.com> <56CF6007.5060607@oracle.com> <3456FD3A-CBF8-46AD-9092-5DC7C6A02DD8@oracle.com> Message-ID: <56CF6FAC.8000603@oracle.com> On 02/25/2016 11:51 PM, Christian Thalinger wrote: > >> On Feb 25, 2016, at 10:11 AM, Aleksey Shipilev wrote: >> >> On 02/25/2016 10:52 PM, Christian Thalinger wrote: >>> + public Object allocateArrayUninit(Class componentType, int length) { >>> >>> Can we use another name like allocateUninitializedArray? >> >> Yes, we can: >> http://cr.openjdk.java.net/~shade/8150465/webrev.jdk.02/ >> http://cr.openjdk.java.net/~shade/8150465/webrev.hs.03/ > > Thanks but I wanted the change in hotspot code too. That wasn't made obvious. Here you go: http://cr.openjdk.java.net/~shade/8150465/webrev.jdk.02/ http://cr.openjdk.java.net/~shade/8150465/webrev.hs.04/ -Aleksey From daniel.daugherty at oracle.com Thu Feb 25 21:25:16 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 25 Feb 2016 14:25:16 -0700 Subject: CFV: New JDK 9 Committer: Chris Plummer In-Reply-To: <56CF669C.6080108@oracle.com> References: <56CF669C.6080108@oracle.com> Message-ID: <56CF713C.3020507@oracle.com> Vote: yes Dan On 2/25/16 1:39 PM, Coleen Phillimore wrote: > I hereby nominate Chris Plummer (cjplummer) to JDK 9 Committer. > > Chris is a member of the Oracle Hotspot runtime team and is a long > time Java virtual machine developer. He has contributed 18 changesets > to hotspot and complimentary changesets to other open repositories > [3]. These changes are for test fixes, bug fixes, NMT, CDS > enhancements and memory savings improvements. He is currently working > to reduce memory footprint for metadata. > > Votes are due by 4:00 PM EST, Thursday March 10, 2016. > > Only current JDK 9 Committers [1] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Lazy Consensus voting instructions, see [2]. > > Coleen Phillimore > > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] List of patches: > > http://hg.openjdk.java.net/jdk9/hs-rt/rev/d870508ede1c > 8144677: jprt.properties should allow creating a user specified > testset with custom build flavors and build targets > > http://hg.openjdk.java.net/jdk9/hs-rt/nashorn/rev/8a10da61fc61 > http://hg.openjdk.java.net/jdk9/hs-rt/langtools/rev/91ea64d22fd9 > http://hg.openjdk.java.net/jdk9/hs-rt/jaxp/rev/e939badf7330 > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/3923f2b31fd2 > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/40a609a54513 > 8141489: [TESTBUG] requiredVersion in TEST.ROOT needs to updated to > 4.1 b12 > > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/8a1e0568b885 > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/f81484d852ac > 8140189: [TESTBUG] Get rid of "@library /../../test/lib" in jtreg tests > > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/775c293c892e > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/431b1333b1c1 > 8129386: [TESTBUG] - com/sun/jdi/cds/*.java missing @build tag for > libraries > > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/86144218cf3f > 8054386: Allow Java debugging when CDS is enabled > > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/5791c37057ed > 8081771: ProcessTool.createJavaProcessBuilder() needs new > addTestVmAndJavaOptions argument > > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/4a9f1b1135cb > 8066507: JPRT is not capable of running jtreg tests located jdk/test > > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/6d92296d52ca > 6762191: Setting stack size to 16K causes segmentation fault > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/72afb83f5035 > 8143608: Don't 64-bit align start of InstanceKlass vtable, itable, and > nonstatic_oopmap on 32-bit systems > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/01a99de9d5cb > 8087153: EXCEPTION_ACCESS_VIOLATION when CDS RO section vanished on win32 > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/9fa5219f0206 > 8051712: regression Test7107135 crashes > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/771c83af7df8 > 8069111: Investigate NMT detail tracking support for 32bit ARM > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/034eb71ab7fd > 8054888: Runtime: Add Diagnostic Command that prints the class hierarchy > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/a3f3bc88d1f3 > 8066508: JTReg tests timeout on slow devices when run using JPRT > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/351115afe32b > 8043770: File leak in MemNotifyThread::start() in > hotspot.src.os.linux.vm.os_linux.cpp > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/27ce97a5b0dd > 6191224: (reflect) Misleading detail string in > IllegalArgumentException thrown by Array.get > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/795fc0cef7c9 > 8046607: Code cleanup: PerfMemory::backing_store_filename() should be > removed > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/5fd8e2fbafd4 > 8020829: JT_HS: 2 runtime NMT tests fail on platforms if NMT detail is > not supported > > From sangheon.kim at oracle.com Thu Feb 25 21:25:06 2016 From: sangheon.kim at oracle.com (sangheon) Date: Thu, 25 Feb 2016 13:25:06 -0800 Subject: CFV: New JDK 9 Committer: Chris Plummer In-Reply-To: <56CF669C.6080108@oracle.com> References: <56CF669C.6080108@oracle.com> Message-ID: <56CF7132.1020105@oracle.com> Vote: yes Thanks, Sangheon On 02/25/2016 12:39 PM, Coleen Phillimore wrote: > I hereby nominate Chris Plummer (cjplummer) to JDK 9 Committer. > > Chris is a member of the Oracle Hotspot runtime team and is a long > time Java virtual machine developer. He has contributed 18 changesets > to hotspot and complimentary changesets to other open repositories > [3]. These changes are for test fixes, bug fixes, NMT, CDS > enhancements and memory savings improvements. He is currently working > to reduce memory footprint for metadata. > > Votes are due by 4:00 PM EST, Thursday March 10, 2016. > > Only current JDK 9 Committers [1] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Lazy Consensus voting instructions, see [2]. > > Coleen Phillimore > > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] List of patches: > > http://hg.openjdk.java.net/jdk9/hs-rt/rev/d870508ede1c > 8144677: jprt.properties should allow creating a user specified > testset with custom build flavors and build targets > > http://hg.openjdk.java.net/jdk9/hs-rt/nashorn/rev/8a10da61fc61 > http://hg.openjdk.java.net/jdk9/hs-rt/langtools/rev/91ea64d22fd9 > http://hg.openjdk.java.net/jdk9/hs-rt/jaxp/rev/e939badf7330 > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/3923f2b31fd2 > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/40a609a54513 > 8141489: [TESTBUG] requiredVersion in TEST.ROOT needs to updated to > 4.1 b12 > > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/8a1e0568b885 > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/f81484d852ac > 8140189: [TESTBUG] Get rid of "@library /../../test/lib" in jtreg tests > > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/775c293c892e > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/431b1333b1c1 > 8129386: [TESTBUG] - com/sun/jdi/cds/*.java missing @build tag for > libraries > > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/86144218cf3f > 8054386: Allow Java debugging when CDS is enabled > > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/5791c37057ed > 8081771: ProcessTool.createJavaProcessBuilder() needs new > addTestVmAndJavaOptions argument > > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/4a9f1b1135cb > 8066507: JPRT is not capable of running jtreg tests located jdk/test > > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/6d92296d52ca > 6762191: Setting stack size to 16K causes segmentation fault > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/72afb83f5035 > 8143608: Don't 64-bit align start of InstanceKlass vtable, itable, and > nonstatic_oopmap on 32-bit systems > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/01a99de9d5cb > 8087153: EXCEPTION_ACCESS_VIOLATION when CDS RO section vanished on win32 > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/9fa5219f0206 > 8051712: regression Test7107135 crashes > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/771c83af7df8 > 8069111: Investigate NMT detail tracking support for 32bit ARM > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/034eb71ab7fd > 8054888: Runtime: Add Diagnostic Command that prints the class hierarchy > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/a3f3bc88d1f3 > 8066508: JTReg tests timeout on slow devices when run using JPRT > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/351115afe32b > 8043770: File leak in MemNotifyThread::start() in > hotspot.src.os.linux.vm.os_linux.cpp > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/27ce97a5b0dd > 6191224: (reflect) Misleading detail string in > IllegalArgumentException thrown by Array.get > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/795fc0cef7c9 > 8046607: Code cleanup: PerfMemory::backing_store_filename() should be > removed > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/5fd8e2fbafd4 > 8020829: JT_HS: 2 runtime NMT tests fail on platforms if NMT detail is > not supported > From david.holmes at oracle.com Thu Feb 25 21:28:14 2016 From: david.holmes at oracle.com (David Holmes) Date: Fri, 26 Feb 2016 07:28:14 +1000 Subject: CFV: New JDK 9 Committer: Chris Plummer In-Reply-To: <56CF669C.6080108@oracle.com> References: <56CF669C.6080108@oracle.com> Message-ID: <56CF71EE.9010302@oracle.com> Vote: yes David On 26/02/2016 6:39 AM, Coleen Phillimore wrote: > I hereby nominate Chris Plummer (cjplummer) to JDK 9 Committer. > > Chris is a member of the Oracle Hotspot runtime team and is a long time > Java virtual machine developer. He has contributed 18 changesets to > hotspot and complimentary changesets to other open repositories [3]. > These changes are for test fixes, bug fixes, NMT, CDS enhancements and > memory savings improvements. He is currently working to reduce memory > footprint for metadata. > > Votes are due by 4:00 PM EST, Thursday March 10, 2016. > > Only current JDK 9 Committers [1] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Lazy Consensus voting instructions, see [2]. > > Coleen Phillimore > > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] List of patches: > > http://hg.openjdk.java.net/jdk9/hs-rt/rev/d870508ede1c > 8144677: jprt.properties should allow creating a user specified testset > with custom build flavors and build targets > > http://hg.openjdk.java.net/jdk9/hs-rt/nashorn/rev/8a10da61fc61 > http://hg.openjdk.java.net/jdk9/hs-rt/langtools/rev/91ea64d22fd9 > http://hg.openjdk.java.net/jdk9/hs-rt/jaxp/rev/e939badf7330 > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/3923f2b31fd2 > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/40a609a54513 > 8141489: [TESTBUG] requiredVersion in TEST.ROOT needs to updated to 4.1 b12 > > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/8a1e0568b885 > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/f81484d852ac > 8140189: [TESTBUG] Get rid of "@library /../../test/lib" in jtreg tests > > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/775c293c892e > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/431b1333b1c1 > 8129386: [TESTBUG] - com/sun/jdi/cds/*.java missing @build tag for > libraries > > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/86144218cf3f > 8054386: Allow Java debugging when CDS is enabled > > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/5791c37057ed > 8081771: ProcessTool.createJavaProcessBuilder() needs new > addTestVmAndJavaOptions argument > > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/4a9f1b1135cb > 8066507: JPRT is not capable of running jtreg tests located jdk/test > > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/6d92296d52ca > 6762191: Setting stack size to 16K causes segmentation fault > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/72afb83f5035 > 8143608: Don't 64-bit align start of InstanceKlass vtable, itable, and > nonstatic_oopmap on 32-bit systems > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/01a99de9d5cb > 8087153: EXCEPTION_ACCESS_VIOLATION when CDS RO section vanished on win32 > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/9fa5219f0206 > 8051712: regression Test7107135 crashes > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/771c83af7df8 > 8069111: Investigate NMT detail tracking support for 32bit ARM > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/034eb71ab7fd > 8054888: Runtime: Add Diagnostic Command that prints the class hierarchy > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/a3f3bc88d1f3 > 8066508: JTReg tests timeout on slow devices when run using JPRT > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/351115afe32b > 8043770: File leak in MemNotifyThread::start() in > hotspot.src.os.linux.vm.os_linux.cpp > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/27ce97a5b0dd > 6191224: (reflect) Misleading detail string in IllegalArgumentException > thrown by Array.get > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/795fc0cef7c9 > 8046607: Code cleanup: PerfMemory::backing_store_filename() should be > removed > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/5fd8e2fbafd4 > 8020829: JT_HS: 2 runtime NMT tests fail on platforms if NMT detail is > not supported > From stefan.karlsson at oracle.com Thu Feb 25 21:35:00 2016 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Thu, 25 Feb 2016 22:35:00 +0100 Subject: CFV: New JDK 9 Committer: Chris Plummer In-Reply-To: <56CF669C.6080108@oracle.com> References: <56CF669C.6080108@oracle.com> Message-ID: <56CF7384.90601@oracle.com> Vote: yes StefanK On 2016-02-25 21:39, Coleen Phillimore wrote: > I hereby nominate Chris Plummer (cjplummer) to JDK 9 Committer. > > Chris is a member of the Oracle Hotspot runtime team and is a long > time Java virtual machine developer. He has contributed 18 changesets > to hotspot and complimentary changesets to other open repositories > [3]. These changes are for test fixes, bug fixes, NMT, CDS > enhancements and memory savings improvements. He is currently working > to reduce memory footprint for metadata. > > Votes are due by 4:00 PM EST, Thursday March 10, 2016. > > Only current JDK 9 Committers [1] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Lazy Consensus voting instructions, see [2]. > > Coleen Phillimore > > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] List of patches: > > http://hg.openjdk.java.net/jdk9/hs-rt/rev/d870508ede1c > 8144677: jprt.properties should allow creating a user specified > testset with custom build flavors and build targets > > http://hg.openjdk.java.net/jdk9/hs-rt/nashorn/rev/8a10da61fc61 > http://hg.openjdk.java.net/jdk9/hs-rt/langtools/rev/91ea64d22fd9 > http://hg.openjdk.java.net/jdk9/hs-rt/jaxp/rev/e939badf7330 > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/3923f2b31fd2 > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/40a609a54513 > 8141489: [TESTBUG] requiredVersion in TEST.ROOT needs to updated to > 4.1 b12 > > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/8a1e0568b885 > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/f81484d852ac > 8140189: [TESTBUG] Get rid of "@library /../../test/lib" in jtreg tests > > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/775c293c892e > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/431b1333b1c1 > 8129386: [TESTBUG] - com/sun/jdi/cds/*.java missing @build tag for > libraries > > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/86144218cf3f > 8054386: Allow Java debugging when CDS is enabled > > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/5791c37057ed > 8081771: ProcessTool.createJavaProcessBuilder() needs new > addTestVmAndJavaOptions argument > > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/4a9f1b1135cb > 8066507: JPRT is not capable of running jtreg tests located jdk/test > > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/6d92296d52ca > 6762191: Setting stack size to 16K causes segmentation fault > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/72afb83f5035 > 8143608: Don't 64-bit align start of InstanceKlass vtable, itable, and > nonstatic_oopmap on 32-bit systems > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/01a99de9d5cb > 8087153: EXCEPTION_ACCESS_VIOLATION when CDS RO section vanished on win32 > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/9fa5219f0206 > 8051712: regression Test7107135 crashes > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/771c83af7df8 > 8069111: Investigate NMT detail tracking support for 32bit ARM > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/034eb71ab7fd > 8054888: Runtime: Add Diagnostic Command that prints the class hierarchy > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/a3f3bc88d1f3 > 8066508: JTReg tests timeout on slow devices when run using JPRT > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/351115afe32b > 8043770: File leak in MemNotifyThread::start() in > hotspot.src.os.linux.vm.os_linux.cpp > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/27ce97a5b0dd > 6191224: (reflect) Misleading detail string in > IllegalArgumentException thrown by Array.get > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/795fc0cef7c9 > 8046607: Code cleanup: PerfMemory::backing_store_filename() should be > removed > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/5fd8e2fbafd4 > 8020829: JT_HS: 2 runtime NMT tests fail on platforms if NMT detail is > not supported > From vladimir.x.ivanov at oracle.com Thu Feb 25 22:15:34 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 26 Feb 2016 01:15:34 +0300 Subject: CFV: New JDK 9 Committer: Chris Plummer In-Reply-To: <56CF669C.6080108@oracle.com> References: <56CF669C.6080108@oracle.com> Message-ID: <56CF7D06.5050300@oracle.com> Vote: yes Best regards, Vladimir Ivanov On 2/25/16 11:39 PM, Coleen Phillimore wrote: > I hereby nominate Chris Plummer (cjplummer) to JDK 9 Committer. From james.graham at oracle.com Thu Feb 25 22:57:50 2016 From: james.graham at oracle.com (Jim Graham) Date: Thu, 25 Feb 2016 14:57:50 -0800 Subject: RFR (S) 8150465: Unsafe methods to produce uninitialized arrays In-Reply-To: <6D79C6DB-B770-4CAA-9338-154589441F8B@oracle.com> References: <56CE3222.6040207@oracle.com> <56CECE5E.4080105@redhat.com> <56CF053A.3070607@oracle.com> <56CF0C1A.4040600@redhat.com> <56CF1163.4040005@oracle.com> <6D79C6DB-B770-4CAA-9338-154589441F8B@oracle.com> Message-ID: <56CF86EE.6070704@oracle.com> Just to play devil's advocate here. It's true that from a code correctness-safety perspective Unsafe programmers can already shoot themselves in the foot with uninitialized allocations, but from the security point of view the two methods don't have the same opportunity to leak information. Unsafe.allocateMemory returns a long, which is just a long to any untrusted code since it can't use the Unsafe methods to access the data in it. The new uninitialized array allocation returns a primitive array which can be inspected by untrusted code for any stale elements that hold private information from a previous allocation - should that array ever be leaked to untrusted code... ...jim On 2/25/2016 7:47 AM, Paul Sandoz wrote: > >> On 25 Feb 2016, at 15:36, Aleksey Shipilev wrote: >> >> On 02/25/2016 05:13 PM, Andrew Haley wrote: >>> On 02/25/2016 01:44 PM, Aleksey Shipilev wrote: >>>> Of course, you will still see garbage data if after storing the array >>>> elements into the uninitialized array you would publish it racily. But >>>> the same is true for the "regular" allocations and subsequent writes. >>>> The only difference is whether you see "real" garbage, or some >>>> "synthetic" garbage like zeros. It is, of course, a caller >>>> responsibility to publish array safely in both cases, if garbage is >>>> unwanted. >>> >>> Of course, my worry with this optimization assumes that programmers >>> make mistakes. But you did say "complicated processing is done after >>> the allocation." And that's where programmers make mistakes. >> >> Of course they do; at least half of the Unsafe methods is suitable for >> shooting oneself in a foot in creative ways. Unsafe is a sharp tool, and >> Unsafe callers are trusted in their madness. This is not your average >> Joe's use case, for sure. >> > > FTR the contents of the memory allocated by Unsafe.allocateMemory are also uninitialized. > > Paul. > From dean.long at oracle.com Thu Feb 25 23:14:56 2016 From: dean.long at oracle.com (Dean Long) Date: Thu, 25 Feb 2016 15:14:56 -0800 Subject: CFV: New JDK 9 Committer: Chris Plummer In-Reply-To: <56CF669C.6080108@oracle.com> References: <56CF669C.6080108@oracle.com> Message-ID: <56CF8AF0.6070103@oracle.com> Vote: yes On 2/25/2016 12:39 PM, Coleen Phillimore wrote: > I hereby nominate Chris Plummer (cjplummer) to JDK 9 Committer. > > Chris is a member of the Oracle Hotspot runtime team and is a long > time Java virtual machine developer. He has contributed 18 changesets > to hotspot and complimentary changesets to other open repositories > [3]. These changes are for test fixes, bug fixes, NMT, CDS > enhancements and memory savings improvements. He is currently working > to reduce memory footprint for metadata. > > Votes are due by 4:00 PM EST, Thursday March 10, 2016. > > Only current JDK 9 Committers [1] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Lazy Consensus voting instructions, see [2]. > > Coleen Phillimore > > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] List of patches: > > http://hg.openjdk.java.net/jdk9/hs-rt/rev/d870508ede1c > 8144677: jprt.properties should allow creating a user specified > testset with custom build flavors and build targets > > http://hg.openjdk.java.net/jdk9/hs-rt/nashorn/rev/8a10da61fc61 > http://hg.openjdk.java.net/jdk9/hs-rt/langtools/rev/91ea64d22fd9 > http://hg.openjdk.java.net/jdk9/hs-rt/jaxp/rev/e939badf7330 > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/3923f2b31fd2 > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/40a609a54513 > 8141489: [TESTBUG] requiredVersion in TEST.ROOT needs to updated to > 4.1 b12 > > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/8a1e0568b885 > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/f81484d852ac > 8140189: [TESTBUG] Get rid of "@library /../../test/lib" in jtreg tests > > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/775c293c892e > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/431b1333b1c1 > 8129386: [TESTBUG] - com/sun/jdi/cds/*.java missing @build tag for > libraries > > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/86144218cf3f > 8054386: Allow Java debugging when CDS is enabled > > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/5791c37057ed > 8081771: ProcessTool.createJavaProcessBuilder() needs new > addTestVmAndJavaOptions argument > > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/4a9f1b1135cb > 8066507: JPRT is not capable of running jtreg tests located jdk/test > > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/6d92296d52ca > 6762191: Setting stack size to 16K causes segmentation fault > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/72afb83f5035 > 8143608: Don't 64-bit align start of InstanceKlass vtable, itable, and > nonstatic_oopmap on 32-bit systems > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/01a99de9d5cb > 8087153: EXCEPTION_ACCESS_VIOLATION when CDS RO section vanished on win32 > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/9fa5219f0206 > 8051712: regression Test7107135 crashes > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/771c83af7df8 > 8069111: Investigate NMT detail tracking support for 32bit ARM > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/034eb71ab7fd > 8054888: Runtime: Add Diagnostic Command that prints the class hierarchy > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/a3f3bc88d1f3 > 8066508: JTReg tests timeout on slow devices when run using JPRT > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/351115afe32b > 8043770: File leak in MemNotifyThread::start() in > hotspot.src.os.linux.vm.os_linux.cpp > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/27ce97a5b0dd > 6191224: (reflect) Misleading detail string in > IllegalArgumentException thrown by Array.get > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/795fc0cef7c9 > 8046607: Code cleanup: PerfMemory::backing_store_filename() should be > removed > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/5fd8e2fbafd4 > 8020829: JT_HS: 2 runtime NMT tests fail on platforms if NMT detail is > not supported > From jesper.wilhelmsson at oracle.com Thu Feb 25 23:23:12 2016 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Fri, 26 Feb 2016 00:23:12 +0100 Subject: CFV: New JDK 9 Committer: Chris Plummer In-Reply-To: <56CF669C.6080108@oracle.com> References: <56CF669C.6080108@oracle.com> Message-ID: <56CF8CE0.1000903@oracle.com> Vote: yes /Jesper Den 25/2/16 kl. 21:39, skrev Coleen Phillimore: > I hereby nominate Chris Plummer (cjplummer) to JDK 9 Committer. > > Chris is a member of the Oracle Hotspot runtime team and is a long time Java > virtual machine developer. He has contributed 18 changesets to hotspot and > complimentary changesets to other open repositories [3]. These changes are for > test fixes, bug fixes, NMT, CDS enhancements and memory savings improvements. > He is currently working to reduce memory footprint for metadata. > > Votes are due by 4:00 PM EST, Thursday March 10, 2016. > > Only current JDK 9 Committers [1] are eligible to vote on this nomination. Votes > must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Coleen Phillimore > > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] List of patches: > > http://hg.openjdk.java.net/jdk9/hs-rt/rev/d870508ede1c > 8144677: jprt.properties should allow creating a user specified testset with > custom build flavors and build targets > > http://hg.openjdk.java.net/jdk9/hs-rt/nashorn/rev/8a10da61fc61 > http://hg.openjdk.java.net/jdk9/hs-rt/langtools/rev/91ea64d22fd9 > http://hg.openjdk.java.net/jdk9/hs-rt/jaxp/rev/e939badf7330 > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/3923f2b31fd2 > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/40a609a54513 > 8141489: [TESTBUG] requiredVersion in TEST.ROOT needs to updated to 4.1 b12 > > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/8a1e0568b885 > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/f81484d852ac > 8140189: [TESTBUG] Get rid of "@library /../../test/lib" in jtreg tests > > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/775c293c892e > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/431b1333b1c1 > 8129386: [TESTBUG] - com/sun/jdi/cds/*.java missing @build tag for libraries > > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/86144218cf3f > 8054386: Allow Java debugging when CDS is enabled > > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/5791c37057ed > 8081771: ProcessTool.createJavaProcessBuilder() needs new > addTestVmAndJavaOptions argument > > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/4a9f1b1135cb > 8066507: JPRT is not capable of running jtreg tests located jdk/test > > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/6d92296d52ca > 6762191: Setting stack size to 16K causes segmentation fault > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/72afb83f5035 > 8143608: Don't 64-bit align start of InstanceKlass vtable, itable, and > nonstatic_oopmap on 32-bit systems > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/01a99de9d5cb > 8087153: EXCEPTION_ACCESS_VIOLATION when CDS RO section vanished on win32 > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/9fa5219f0206 > 8051712: regression Test7107135 crashes > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/771c83af7df8 > 8069111: Investigate NMT detail tracking support for 32bit ARM > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/034eb71ab7fd > 8054888: Runtime: Add Diagnostic Command that prints the class hierarchy > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/a3f3bc88d1f3 > 8066508: JTReg tests timeout on slow devices when run using JPRT > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/351115afe32b > 8043770: File leak in MemNotifyThread::start() in > hotspot.src.os.linux.vm.os_linux.cpp > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/27ce97a5b0dd > 6191224: (reflect) Misleading detail string in IllegalArgumentException thrown > by Array.get > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/795fc0cef7c9 > 8046607: Code cleanup: PerfMemory::backing_store_filename() should be removed > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/5fd8e2fbafd4 > 8020829: JT_HS: 2 runtime NMT tests fail on platforms if NMT detail is not > supported > From jon.masamitsu at oracle.com Thu Feb 25 23:46:40 2016 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Thu, 25 Feb 2016 15:46:40 -0800 Subject: CFV: New JDK 9 Committer: Chris Plummer In-Reply-To: <56CF669C.6080108@oracle.com> References: <56CF669C.6080108@oracle.com> Message-ID: <56CF9260.5010902@oracle.com> Vote: yes On 2/25/2016 12:39 PM, Coleen Phillimore wrote: > I hereby nominate Chris Plummer (cjplummer) to JDK 9 Committer. > > Chris is a member of the Oracle Hotspot runtime team and is a long > time Java virtual machine developer. He has contributed 18 changesets > to hotspot and complimentary changesets to other open repositories > [3]. These changes are for test fixes, bug fixes, NMT, CDS > enhancements and memory savings improvements. He is currently working > to reduce memory footprint for metadata. > > Votes are due by 4:00 PM EST, Thursday March 10, 2016. > > Only current JDK 9 Committers [1] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Lazy Consensus voting instructions, see [2]. > > Coleen Phillimore > > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] List of patches: > > http://hg.openjdk.java.net/jdk9/hs-rt/rev/d870508ede1c > 8144677: jprt.properties should allow creating a user specified > testset with custom build flavors and build targets > > http://hg.openjdk.java.net/jdk9/hs-rt/nashorn/rev/8a10da61fc61 > http://hg.openjdk.java.net/jdk9/hs-rt/langtools/rev/91ea64d22fd9 > http://hg.openjdk.java.net/jdk9/hs-rt/jaxp/rev/e939badf7330 > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/3923f2b31fd2 > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/40a609a54513 > 8141489: [TESTBUG] requiredVersion in TEST.ROOT needs to updated to > 4.1 b12 > > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/8a1e0568b885 > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/f81484d852ac > 8140189: [TESTBUG] Get rid of "@library /../../test/lib" in jtreg tests > > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/775c293c892e > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/431b1333b1c1 > 8129386: [TESTBUG] - com/sun/jdi/cds/*.java missing @build tag for > libraries > > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/86144218cf3f > 8054386: Allow Java debugging when CDS is enabled > > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/5791c37057ed > 8081771: ProcessTool.createJavaProcessBuilder() needs new > addTestVmAndJavaOptions argument > > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/4a9f1b1135cb > 8066507: JPRT is not capable of running jtreg tests located jdk/test > > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/6d92296d52ca > 6762191: Setting stack size to 16K causes segmentation fault > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/72afb83f5035 > 8143608: Don't 64-bit align start of InstanceKlass vtable, itable, and > nonstatic_oopmap on 32-bit systems > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/01a99de9d5cb > 8087153: EXCEPTION_ACCESS_VIOLATION when CDS RO section vanished on win32 > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/9fa5219f0206 > 8051712: regression Test7107135 crashes > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/771c83af7df8 > 8069111: Investigate NMT detail tracking support for 32bit ARM > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/034eb71ab7fd > 8054888: Runtime: Add Diagnostic Command that prints the class hierarchy > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/a3f3bc88d1f3 > 8066508: JTReg tests timeout on slow devices when run using JPRT > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/351115afe32b > 8043770: File leak in MemNotifyThread::start() in > hotspot.src.os.linux.vm.os_linux.cpp > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/27ce97a5b0dd > 6191224: (reflect) Misleading detail string in > IllegalArgumentException thrown by Array.get > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/795fc0cef7c9 > 8046607: Code cleanup: PerfMemory::backing_store_filename() should be > removed > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/5fd8e2fbafd4 > 8020829: JT_HS: 2 runtime NMT tests fail on platforms if NMT detail is > not supported > From serguei.spitsyn at oracle.com Fri Feb 26 02:41:15 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 25 Feb 2016 18:41:15 -0800 Subject: CFV: New JDK 9 Committer: Chris Plummer In-Reply-To: <56CF669C.6080108@oracle.com> References: <56CF669C.6080108@oracle.com> Message-ID: <56CFBB4B.70600@oracle.com> Vote: yes From aleksey.shipilev at oracle.com Fri Feb 26 07:01:39 2016 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Fri, 26 Feb 2016 10:01:39 +0300 Subject: RFR (S) 8150465: Unsafe methods to produce uninitialized arrays In-Reply-To: <56CF86EE.6070704@oracle.com> References: <56CE3222.6040207@oracle.com> <56CECE5E.4080105@redhat.com> <56CF053A.3070607@oracle.com> <56CF0C1A.4040600@redhat.com> <56CF1163.4040005@oracle.com> <6D79C6DB-B770-4CAA-9338-154589441F8B@oracle.com> <56CF86EE.6070704@oracle.com> Message-ID: <56CFF853.7020207@oracle.com> Unsafe is unsafe, no doubt about it. But if you accept the premise that Unsafe.allocateUninitializedArray is wrong because it can leak data from previous allocation if used incorrectly, then you should equally accept that compilers should not do the same automatic optimization too. Even more so, because the compiler code is much harder to audit for these mistakes; and programmers *do* make mistakes in that complicated compiler code. Notable examples in C2 are OptimizeStringConcat allocating uninitialized array for String (pretty much what we are targeting to do here), and subsequent arraycopy eliminating the array zeroing in a "tightly coupled" allocation. But, we do these optimizations already. Unsafe users *have* to provide an additional protection to avoid such leakage, pretty much how compilers *have* to guarantee safety in those situations too. Even without Unsafe.allocateUninitializedArray, I can certainly construct the buggy JDK code that will leak uninitialized memory to untrusted code: a simple mistake in offset calculation for Unsafe.getX(long,long) is enough to leak. Yet, we don't nuke the raw memory accessors from Unsafe, because they are useful, and we do understand those are sharp tools, and we should be extra careful using them. The same goes for any other Unsafe method. If you treat U.allocateUninitializedArray with the same respect you treating other tools in that toolbox, everything is fine. If you don't, then stay away from Unsafe to begin with. Unsafe is unsafe, there is no doubt about it. -Aleksey On 02/26/2016 01:57 AM, Jim Graham wrote: > Just to play devil's advocate here. > > It's true that from a code correctness-safety perspective Unsafe > programmers can already shoot themselves in the foot with uninitialized > allocations, but from the security point of view the two methods don't > have the same opportunity to leak information. > > Unsafe.allocateMemory returns a long, which is just a long to any > untrusted code since it can't use the Unsafe methods to access the data > in it. > > The new uninitialized array allocation returns a primitive array which > can be inspected by untrusted code for any stale elements that hold > private information from a previous allocation - should that array ever > be leaked to untrusted code... > > ...jim > > On 2/25/2016 7:47 AM, Paul Sandoz wrote: >> >>> On 25 Feb 2016, at 15:36, Aleksey Shipilev >>> wrote: >>> >>> On 02/25/2016 05:13 PM, Andrew Haley wrote: >>>> On 02/25/2016 01:44 PM, Aleksey Shipilev wrote: >>>>> Of course, you will still see garbage data if after storing the array >>>>> elements into the uninitialized array you would publish it racily. But >>>>> the same is true for the "regular" allocations and subsequent writes. >>>>> The only difference is whether you see "real" garbage, or some >>>>> "synthetic" garbage like zeros. It is, of course, a caller >>>>> responsibility to publish array safely in both cases, if garbage is >>>>> unwanted. >>>> >>>> Of course, my worry with this optimization assumes that programmers >>>> make mistakes. But you did say "complicated processing is done after >>>> the allocation." And that's where programmers make mistakes. >>> >>> Of course they do; at least half of the Unsafe methods is suitable for >>> shooting oneself in a foot in creative ways. Unsafe is a sharp tool, and >>> Unsafe callers are trusted in their madness. This is not your average >>> Joe's use case, for sure. >>> >> >> FTR the contents of the memory allocated by Unsafe.allocateMemory are >> also uninitialized. >> >> Paul. >> From Alan.Bateman at oracle.com Fri Feb 26 07:13:39 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 26 Feb 2016 07:13:39 +0000 Subject: CFV: New JDK 9 Committer: Chris Plummer In-Reply-To: <56CF669C.6080108@oracle.com> References: <56CF669C.6080108@oracle.com> Message-ID: <56CFFB23.4010407@oracle.com> Vote: yes From tobias.hartmann at oracle.com Fri Feb 26 07:21:22 2016 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Fri, 26 Feb 2016 08:21:22 +0100 Subject: CFV: New JDK 9 Committer: Chris Plummer In-Reply-To: <56CF669C.6080108@oracle.com> References: <56CF669C.6080108@oracle.com> Message-ID: <56CFFCF2.4080302@oracle.com> Vote: yes Best regards, Tobias On 25.02.2016 21:39, Coleen Phillimore wrote: > I hereby nominate Chris Plummer (cjplummer) to JDK 9 Committer. > > Chris is a member of the Oracle Hotspot runtime team and is a long time Java virtual machine developer. He has contributed 18 changesets to hotspot and complimentary changesets to other open repositories [3]. These changes are for test fixes, bug fixes, NMT, CDS enhancements and memory savings improvements. He is currently working to reduce memory footprint for metadata. > > Votes are due by 4:00 PM EST, Thursday March 10, 2016. > > Only current JDK 9 Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Coleen Phillimore > > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] List of patches: > > http://hg.openjdk.java.net/jdk9/hs-rt/rev/d870508ede1c > 8144677: jprt.properties should allow creating a user specified testset with custom build flavors and build targets > > http://hg.openjdk.java.net/jdk9/hs-rt/nashorn/rev/8a10da61fc61 > http://hg.openjdk.java.net/jdk9/hs-rt/langtools/rev/91ea64d22fd9 > http://hg.openjdk.java.net/jdk9/hs-rt/jaxp/rev/e939badf7330 > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/3923f2b31fd2 > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/40a609a54513 > 8141489: [TESTBUG] requiredVersion in TEST.ROOT needs to updated to 4.1 b12 > > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/8a1e0568b885 > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/f81484d852ac > 8140189: [TESTBUG] Get rid of "@library /../../test/lib" in jtreg tests > > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/775c293c892e > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/431b1333b1c1 > 8129386: [TESTBUG] - com/sun/jdi/cds/*.java missing @build tag for libraries > > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/86144218cf3f > 8054386: Allow Java debugging when CDS is enabled > > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/5791c37057ed > 8081771: ProcessTool.createJavaProcessBuilder() needs new addTestVmAndJavaOptions argument > > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/4a9f1b1135cb > 8066507: JPRT is not capable of running jtreg tests located jdk/test > > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/6d92296d52ca > 6762191: Setting stack size to 16K causes segmentation fault > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/72afb83f5035 > 8143608: Don't 64-bit align start of InstanceKlass vtable, itable, and nonstatic_oopmap on 32-bit systems > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/01a99de9d5cb > 8087153: EXCEPTION_ACCESS_VIOLATION when CDS RO section vanished on win32 > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/9fa5219f0206 > 8051712: regression Test7107135 crashes > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/771c83af7df8 > 8069111: Investigate NMT detail tracking support for 32bit ARM > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/034eb71ab7fd > 8054888: Runtime: Add Diagnostic Command that prints the class hierarchy > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/a3f3bc88d1f3 > 8066508: JTReg tests timeout on slow devices when run using JPRT > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/351115afe32b > 8043770: File leak in MemNotifyThread::start() in hotspot.src.os.linux.vm.os_linux.cpp > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/27ce97a5b0dd > 6191224: (reflect) Misleading detail string in IllegalArgumentException thrown by Array.get > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/795fc0cef7c9 > 8046607: Code cleanup: PerfMemory::backing_store_filename() should be removed > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/5fd8e2fbafd4 > 8020829: JT_HS: 2 runtime NMT tests fail on platforms if NMT detail is not supported > From volker.simonis at gmail.com Fri Feb 26 07:47:04 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 26 Feb 2016 08:47:04 +0100 Subject: CFV: New JDK 9 Committer: Chris Plummer In-Reply-To: <56CF669C.6080108@oracle.com> References: <56CF669C.6080108@oracle.com> Message-ID: Vote: yes On Thu, Feb 25, 2016 at 9:39 PM, Coleen Phillimore wrote: > I hereby nominate Chris Plummer (cjplummer) to JDK 9 Committer. > > Chris is a member of the Oracle Hotspot runtime team and is a long time Java > virtual machine developer. He has contributed 18 changesets to hotspot and > complimentary changesets to other open repositories [3]. These changes are > for test fixes, bug fixes, NMT, CDS enhancements and memory savings > improvements. He is currently working to reduce memory footprint for > metadata. > > Votes are due by 4:00 PM EST, Thursday March 10, 2016. > > Only current JDK 9 Committers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Coleen Phillimore > > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] List of patches: > > http://hg.openjdk.java.net/jdk9/hs-rt/rev/d870508ede1c > 8144677: jprt.properties should allow creating a user specified testset with > custom build flavors and build targets > > http://hg.openjdk.java.net/jdk9/hs-rt/nashorn/rev/8a10da61fc61 > http://hg.openjdk.java.net/jdk9/hs-rt/langtools/rev/91ea64d22fd9 > http://hg.openjdk.java.net/jdk9/hs-rt/jaxp/rev/e939badf7330 > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/3923f2b31fd2 > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/40a609a54513 > 8141489: [TESTBUG] requiredVersion in TEST.ROOT needs to updated to 4.1 b12 > > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/8a1e0568b885 > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/f81484d852ac > 8140189: [TESTBUG] Get rid of "@library /../../test/lib" in jtreg tests > > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/775c293c892e > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/431b1333b1c1 > 8129386: [TESTBUG] - com/sun/jdi/cds/*.java missing @build tag for libraries > > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/86144218cf3f > 8054386: Allow Java debugging when CDS is enabled > > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/5791c37057ed > 8081771: ProcessTool.createJavaProcessBuilder() needs new > addTestVmAndJavaOptions argument > > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/4a9f1b1135cb > 8066507: JPRT is not capable of running jtreg tests located jdk/test > > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/6d92296d52ca > 6762191: Setting stack size to 16K causes segmentation fault > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/72afb83f5035 > 8143608: Don't 64-bit align start of InstanceKlass vtable, itable, and > nonstatic_oopmap on 32-bit systems > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/01a99de9d5cb > 8087153: EXCEPTION_ACCESS_VIOLATION when CDS RO section vanished on win32 > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/9fa5219f0206 > 8051712: regression Test7107135 crashes > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/771c83af7df8 > 8069111: Investigate NMT detail tracking support for 32bit ARM > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/034eb71ab7fd > 8054888: Runtime: Add Diagnostic Command that prints the class hierarchy > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/a3f3bc88d1f3 > 8066508: JTReg tests timeout on slow devices when run using JPRT > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/351115afe32b > 8043770: File leak in MemNotifyThread::start() in > hotspot.src.os.linux.vm.os_linux.cpp > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/27ce97a5b0dd > 6191224: (reflect) Misleading detail string in IllegalArgumentException > thrown by Array.get > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/795fc0cef7c9 > 8046607: Code cleanup: PerfMemory::backing_store_filename() should be > removed > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/5fd8e2fbafd4 > 8020829: JT_HS: 2 runtime NMT tests fail on platforms if NMT detail is not > supported > From john.r.rose at oracle.com Fri Feb 26 08:01:22 2016 From: john.r.rose at oracle.com (John Rose) Date: Fri, 26 Feb 2016 00:01:22 -0800 Subject: RFR (S) 8150465: Unsafe methods to produce uninitialized arrays In-Reply-To: <56CEB700.9020603@oracle.com> References: <56CE3222.6040207@oracle.com> <56CE3B13.3090700@oracle.com> <56CE41FE.6070103@oracle.com> <56CE48C8.2050707@oracle.com> <56CEB700.9020603@oracle.com> Message-ID: On Feb 25, 2016, at 12:10 AM, Aleksey Shipilev wrote: > >> Yes, primitive arrays are fine if the header is correct. In this case >> changes are fine but you may need to add a check in >> inline_unsafe_newArray() that it is only primitive types. > > Alas, the class argument may not be constant, and so we would need a > runtime check there, which would duplicate the check we already have in > Unsafe.java. I'd prefer to follow the upcoming pattern in Mikael's > Unsafe cleanup with making as much checks on Java side. Yes, follow that pattern. In unsafe.cpp, you should use an assert (or guarantee) to back up the Java-level checks. The effect of the assert is to help diagnose any failure of the Java-level checks. The compiler intrinsic does not need the double-checking. Rather, it should run AFAP (as fast as possible) under the assumption that the Java-level checks have run or don't apply. On Feb 25, 2016, at 11:01 PM, Aleksey Shipilev wrote: > But if you accept the premise that Unsafe.allocateUninitializedArray is > wrong because it can leak data from previous allocation if used > incorrectly, then you should equally accept that compilers should not do > the same automatic optimization too. Even more so, because the compiler > code is much harder to audit for these mistakes; and programmers *do* > make mistakes in that complicated compiler code. Exactly right. Unsafe is the "in your face" way to do the same kind of shady stuff that (otherwise) the C runtime or the JIT IR transforms would have to do. In many cases, the necessary audits and proofs are safer and easier to accomplish when looking at Java code than when looking at C code (behind a JNI mask) or JIT IR transforms (which nobody fully understands). Unsafe is a frank admission that sometimes the barn needs sweeping, and that it might as well be swept in the daylight. We don't sit around in the living room pretending we can't smell it. About the javadoc: > * This method is suitable for special high-performance code > * that is known to overwrite the array contents right after the allocation. I suggest pounding harder on this warning: > In fact, users of this method are required to overwrite the initial (garbage) array > contents before allowing untrusted code, or code in other threads, to observe > the reference to the newly allocated array. In addition, the publication of the > array reference must be safe according to the JMM. Suggesting: Provide a second function to ensure the safe publication, and require users of aUA to call it before publication. > public Object markArrayInitialized(Object array) { /*mem-fence?*/ return array; } It can't really be enforced, but it makes a clear target for best practices. I find it very useful, when thinking about safe object allocation, to distinguish between larval and public stages. The mAI function makes it very explicit where the stage change happens. And it could map directly into the C2 IR, which represents these stages internally. ? John From jaroslav.bachorik at oracle.com Fri Feb 26 08:15:29 2016 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Fri, 26 Feb 2016 09:15:29 +0100 Subject: CFV: New JDK 9 Committer: Chris Plummer In-Reply-To: <56CF669C.6080108@oracle.com> References: <56CF669C.6080108@oracle.com> Message-ID: <56D009A1.10908@oracle.com> Vote: yes -JB- On 25.2.2016 21:39, Coleen Phillimore wrote: > I hereby nominate Chris Plummer (cjplummer) to JDK 9 Committer. > > Chris is a member of the Oracle Hotspot runtime team and is a long time > Java virtual machine developer. He has contributed 18 changesets to > hotspot and complimentary changesets to other open repositories [3]. > These changes are for test fixes, bug fixes, NMT, CDS enhancements and > memory savings improvements. He is currently working to reduce memory > footprint for metadata. > > Votes are due by 4:00 PM EST, Thursday March 10, 2016. > > Only current JDK 9 Committers [1] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Lazy Consensus voting instructions, see [2]. > > Coleen Phillimore > > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] List of patches: > > http://hg.openjdk.java.net/jdk9/hs-rt/rev/d870508ede1c > 8144677: jprt.properties should allow creating a user specified testset > with custom build flavors and build targets > > http://hg.openjdk.java.net/jdk9/hs-rt/nashorn/rev/8a10da61fc61 > http://hg.openjdk.java.net/jdk9/hs-rt/langtools/rev/91ea64d22fd9 > http://hg.openjdk.java.net/jdk9/hs-rt/jaxp/rev/e939badf7330 > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/3923f2b31fd2 > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/40a609a54513 > 8141489: [TESTBUG] requiredVersion in TEST.ROOT needs to updated to 4.1 b12 > > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/8a1e0568b885 > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/f81484d852ac > 8140189: [TESTBUG] Get rid of "@library /../../test/lib" in jtreg tests > > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/775c293c892e > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/431b1333b1c1 > 8129386: [TESTBUG] - com/sun/jdi/cds/*.java missing @build tag for > libraries > > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/86144218cf3f > 8054386: Allow Java debugging when CDS is enabled > > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/5791c37057ed > 8081771: ProcessTool.createJavaProcessBuilder() needs new > addTestVmAndJavaOptions argument > > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/4a9f1b1135cb > 8066507: JPRT is not capable of running jtreg tests located jdk/test > > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/6d92296d52ca > 6762191: Setting stack size to 16K causes segmentation fault > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/72afb83f5035 > 8143608: Don't 64-bit align start of InstanceKlass vtable, itable, and > nonstatic_oopmap on 32-bit systems > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/01a99de9d5cb > 8087153: EXCEPTION_ACCESS_VIOLATION when CDS RO section vanished on win32 > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/9fa5219f0206 > 8051712: regression Test7107135 crashes > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/771c83af7df8 > 8069111: Investigate NMT detail tracking support for 32bit ARM > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/034eb71ab7fd > 8054888: Runtime: Add Diagnostic Command that prints the class hierarchy > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/a3f3bc88d1f3 > 8066508: JTReg tests timeout on slow devices when run using JPRT > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/351115afe32b > 8043770: File leak in MemNotifyThread::start() in > hotspot.src.os.linux.vm.os_linux.cpp > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/27ce97a5b0dd > 6191224: (reflect) Misleading detail string in IllegalArgumentException > thrown by Array.get > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/795fc0cef7c9 > 8046607: Code cleanup: PerfMemory::backing_store_filename() should be > removed > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/5fd8e2fbafd4 > 8020829: JT_HS: 2 runtime NMT tests fail on platforms if NMT detail is > not supported > From mikael.gerdin at oracle.com Fri Feb 26 08:25:08 2016 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Fri, 26 Feb 2016 09:25:08 +0100 Subject: CFV: New JDK 9 Committer: Chris Plummer In-Reply-To: <56CF669C.6080108@oracle.com> References: <56CF669C.6080108@oracle.com> Message-ID: <56D00BE4.3070905@oracle.com> Vote: yes /Mikael On 2016-02-25 21:39, Coleen Phillimore wrote: > I hereby nominate Chris Plummer (cjplummer) to JDK 9 Committer. > > Chris is a member of the Oracle Hotspot runtime team and is a long time > Java virtual machine developer. He has contributed 18 changesets to > hotspot and complimentary changesets to other open repositories [3]. > These changes are for test fixes, bug fixes, NMT, CDS enhancements and > memory savings improvements. He is currently working to reduce memory > footprint for metadata. > > Votes are due by 4:00 PM EST, Thursday March 10, 2016. > > Only current JDK 9 Committers [1] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Lazy Consensus voting instructions, see [2]. > > Coleen Phillimore > > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] List of patches: > > http://hg.openjdk.java.net/jdk9/hs-rt/rev/d870508ede1c > 8144677: jprt.properties should allow creating a user specified testset > with custom build flavors and build targets > > http://hg.openjdk.java.net/jdk9/hs-rt/nashorn/rev/8a10da61fc61 > http://hg.openjdk.java.net/jdk9/hs-rt/langtools/rev/91ea64d22fd9 > http://hg.openjdk.java.net/jdk9/hs-rt/jaxp/rev/e939badf7330 > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/3923f2b31fd2 > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/40a609a54513 > 8141489: [TESTBUG] requiredVersion in TEST.ROOT needs to updated to 4.1 b12 > > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/8a1e0568b885 > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/f81484d852ac > 8140189: [TESTBUG] Get rid of "@library /../../test/lib" in jtreg tests > > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/775c293c892e > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/431b1333b1c1 > 8129386: [TESTBUG] - com/sun/jdi/cds/*.java missing @build tag for > libraries > > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/86144218cf3f > 8054386: Allow Java debugging when CDS is enabled > > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/5791c37057ed > 8081771: ProcessTool.createJavaProcessBuilder() needs new > addTestVmAndJavaOptions argument > > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/4a9f1b1135cb > 8066507: JPRT is not capable of running jtreg tests located jdk/test > > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/6d92296d52ca > 6762191: Setting stack size to 16K causes segmentation fault > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/72afb83f5035 > 8143608: Don't 64-bit align start of InstanceKlass vtable, itable, and > nonstatic_oopmap on 32-bit systems > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/01a99de9d5cb > 8087153: EXCEPTION_ACCESS_VIOLATION when CDS RO section vanished on win32 > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/9fa5219f0206 > 8051712: regression Test7107135 crashes > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/771c83af7df8 > 8069111: Investigate NMT detail tracking support for 32bit ARM > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/034eb71ab7fd > 8054888: Runtime: Add Diagnostic Command that prints the class hierarchy > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/a3f3bc88d1f3 > 8066508: JTReg tests timeout on slow devices when run using JPRT > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/351115afe32b > 8043770: File leak in MemNotifyThread::start() in > hotspot.src.os.linux.vm.os_linux.cpp > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/27ce97a5b0dd > 6191224: (reflect) Misleading detail string in IllegalArgumentException > thrown by Array.get > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/795fc0cef7c9 > 8046607: Code cleanup: PerfMemory::backing_store_filename() should be > removed > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/5fd8e2fbafd4 > 8020829: JT_HS: 2 runtime NMT tests fail on platforms if NMT detail is > not supported > From zoltan.majo at oracle.com Fri Feb 26 08:33:21 2016 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Fri, 26 Feb 2016 09:33:21 +0100 Subject: CFV: New JDK 9 Committer: Chris Plummer In-Reply-To: <56CF669C.6080108@oracle.com> References: <56CF669C.6080108@oracle.com> Message-ID: <56D00DD1.1090300@oracle.com> Vote: yes. Best regards, Zoltan On 02/25/2016 09:39 PM, Coleen Phillimore wrote: > I hereby nominate Chris Plummer (cjplummer) to JDK 9 Committer. > > Chris is a member of the Oracle Hotspot runtime team and is a long > time Java virtual machine developer. He has contributed 18 changesets > to hotspot and complimentary changesets to other open repositories > [3]. These changes are for test fixes, bug fixes, NMT, CDS > enhancements and memory savings improvements. He is currently working > to reduce memory footprint for metadata. > > Votes are due by 4:00 PM EST, Thursday March 10, 2016. > > Only current JDK 9 Committers [1] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Lazy Consensus voting instructions, see [2]. > > Coleen Phillimore > > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] List of patches: > > http://hg.openjdk.java.net/jdk9/hs-rt/rev/d870508ede1c > 8144677: jprt.properties should allow creating a user specified > testset with custom build flavors and build targets > > http://hg.openjdk.java.net/jdk9/hs-rt/nashorn/rev/8a10da61fc61 > http://hg.openjdk.java.net/jdk9/hs-rt/langtools/rev/91ea64d22fd9 > http://hg.openjdk.java.net/jdk9/hs-rt/jaxp/rev/e939badf7330 > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/3923f2b31fd2 > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/40a609a54513 > 8141489: [TESTBUG] requiredVersion in TEST.ROOT needs to updated to > 4.1 b12 > > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/8a1e0568b885 > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/f81484d852ac > 8140189: [TESTBUG] Get rid of "@library /../../test/lib" in jtreg tests > > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/775c293c892e > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/431b1333b1c1 > 8129386: [TESTBUG] - com/sun/jdi/cds/*.java missing @build tag for > libraries > > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/86144218cf3f > 8054386: Allow Java debugging when CDS is enabled > > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/5791c37057ed > 8081771: ProcessTool.createJavaProcessBuilder() needs new > addTestVmAndJavaOptions argument > > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/4a9f1b1135cb > 8066507: JPRT is not capable of running jtreg tests located jdk/test > > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/6d92296d52ca > 6762191: Setting stack size to 16K causes segmentation fault > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/72afb83f5035 > 8143608: Don't 64-bit align start of InstanceKlass vtable, itable, and > nonstatic_oopmap on 32-bit systems > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/01a99de9d5cb > 8087153: EXCEPTION_ACCESS_VIOLATION when CDS RO section vanished on win32 > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/9fa5219f0206 > 8051712: regression Test7107135 crashes > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/771c83af7df8 > 8069111: Investigate NMT detail tracking support for 32bit ARM > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/034eb71ab7fd > 8054888: Runtime: Add Diagnostic Command that prints the class hierarchy > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/a3f3bc88d1f3 > 8066508: JTReg tests timeout on slow devices when run using JPRT > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/351115afe32b > 8043770: File leak in MemNotifyThread::start() in > hotspot.src.os.linux.vm.os_linux.cpp > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/27ce97a5b0dd > 6191224: (reflect) Misleading detail string in > IllegalArgumentException thrown by Array.get > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/795fc0cef7c9 > 8046607: Code cleanup: PerfMemory::backing_store_filename() should be > removed > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/5fd8e2fbafd4 > 8020829: JT_HS: 2 runtime NMT tests fail on platforms if NMT detail is > not supported > From daniel.fuchs at oracle.com Fri Feb 26 09:26:24 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 26 Feb 2016 10:26:24 +0100 Subject: CFV: New JDK 9 Committer: Chris Plummer In-Reply-To: <56CF669C.6080108@oracle.com> References: <56CF669C.6080108@oracle.com> Message-ID: <56D01A40.5070801@oracle.com> Vote: yes -- daniel On 25/02/16 21:39, Coleen Phillimore wrote: > I hereby nominate Chris Plummer (cjplummer) to JDK 9 Committer. From igor.ignatyev at oracle.com Fri Feb 26 10:01:15 2016 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Fri, 26 Feb 2016 13:01:15 +0300 Subject: CFV: New JDK 9 Committer: Chris Plummer In-Reply-To: <56CF669C.6080108@oracle.com> References: <56CF669C.6080108@oracle.com> Message-ID: <15EA2755-6CFE-44BC-BBA5-0BF6D8F99A6B@oracle.com> Vote: yes ? Igor > On Feb 25, 2016, at 11:39 PM, Coleen Phillimore wrote: > > I hereby nominate Chris Plummer (cjplummer) to JDK 9 Committer. From james.graham at oracle.com Fri Feb 26 10:24:19 2016 From: james.graham at oracle.com (Jim Graham) Date: Fri, 26 Feb 2016 02:24:19 -0800 Subject: RFR (S) 8150465: Unsafe methods to produce uninitialized arrays In-Reply-To: <56CFF853.7020207@oracle.com> References: <56CE3222.6040207@oracle.com> <56CECE5E.4080105@redhat.com> <56CF053A.3070607@oracle.com> <56CF0C1A.4040600@redhat.com> <56CF1163.4040005@oracle.com> <6D79C6DB-B770-4CAA-9338-154589441F8B@oracle.com> <56CF86EE.6070704@oracle.com> <56CFF853.7020207@oracle.com> Message-ID: <56D027D3.9010609@oracle.com> Hi Aleksey, Agreed on all fronts that Unsafe is playing with fire. I was not objecting, I just wanted to accurately depict the similarities and differences with the existing function before we allow the faulty analogy to move that analysis off the table. "A is like B so we don't need to consider any new info" only works if all aspects of A are covered by aspects of B. As you note, we can leak uninitialized memory from Unsafe.allocateMemory as well, if we copy some of the uninitialized data out of it on behalf of an untrusted caller, but that is one level of "oops" harder than storing the reference to the unsafe primitive array in an accidentally accessible location. The potential failures of the existing method are that we dig out unwritten data and return it. It is not a failure to accidentally give them the handle, though, because the handle is useless to them. It would be a huge error to let them overwrite or otherwise change any of these handles, though, but simply returning the handle from a method does not create a leak. The potential failures of the new method are both that we might dig out unwritten data and supply that data, but also that we might accidentally give away the handle itself. It doesn't have to be "uh, oh, I forgot to initialize all of the data because my algorithm was too obscure", it can be that the programmer stored the array reference in a field that has a getter before they are finished initializing it. You can examine the initialization code in fine detail and say "Yep, that's all of the locations in the array", but if you didn't notice that there was a getter that someone could call while you were doing that work, you've leaked data. Or maybe you knew about the getter, but thought that the object was only held by trusted modules - until there's an exploit. The getter may not even exist when they write the initialization code, but someone comes along later and thinks "it would be really handy to have a getter for that array reference" and doesn't notice that it goes through part of its life span as a partially initialized array ("OMG, what's that now?!"). I also don't think that it's a good analogy that these are similar to bugs that the compiler could have. The compiler code is some of the most scrutinized code we have, with a fairly narrow and specific set of code translation operations it performs, maintained by a fairly limited group of engineers who are experts in those issues. But we have a ton of library code in many places and a huge body of engineers working on it - a few orders of magnitude more fingers that aren't trained in memory barriers and proving accessibility that can slip up ("What do you mean they can call a protected method? I thought it was protected for a reason!?"). That widens the gap of potential programmer errors that can create a data leak. It sounds like we probably accept that risk, but let's be on the table about it. All of those are programmer errors, but let's at least acknowledge the scenarios before we simply say "all programmers everywhere shouldn't do bad stuff" and rubber stamp a new feature. In the end, I'm just saying that the specific comment that we already have a mechanism that can create uninitialized memory doesn't imply that there are no new security implications to consider here. That's a logical shortcut to minimize discussion, not a valid conclusion. I'm seeing a fair amount of hand waving here and not much objective analysis of the risks. It's important to nail down the issues if for no other reason than to provide good advice on usage practices in our documentation to our internal developers... ...jim On 2/25/2016 11:01 PM, Aleksey Shipilev wrote: > Unsafe is unsafe, no doubt about it. > > But if you accept the premise that Unsafe.allocateUninitializedArray is > wrong because it can leak data from previous allocation if used > incorrectly, then you should equally accept that compilers should not do > the same automatic optimization too. Even more so, because the compiler > code is much harder to audit for these mistakes; and programmers *do* > make mistakes in that complicated compiler code. > > Notable examples in C2 are OptimizeStringConcat allocating uninitialized > array for String (pretty much what we are targeting to do here), and > subsequent arraycopy eliminating the array zeroing in a "tightly > coupled" allocation. But, we do these optimizations already. > > Unsafe users *have* to provide an additional protection to avoid such > leakage, pretty much how compilers *have* to guarantee safety in those > situations too. > > Even without Unsafe.allocateUninitializedArray, I can certainly > construct the buggy JDK code that will leak uninitialized memory to > untrusted code: a simple mistake in offset calculation for > Unsafe.getX(long,long) is enough to leak. Yet, we don't nuke the raw > memory accessors from Unsafe, because they are useful, and we do > understand those are sharp tools, and we should be extra careful using > them. > > The same goes for any other Unsafe method. If you treat > U.allocateUninitializedArray with the same respect you treating other > tools in that toolbox, everything is fine. If you don't, then stay away > from Unsafe to begin with. Unsafe is unsafe, there is no doubt about it. > > -Aleksey > > On 02/26/2016 01:57 AM, Jim Graham wrote: >> Just to play devil's advocate here. >> >> It's true that from a code correctness-safety perspective Unsafe >> programmers can already shoot themselves in the foot with uninitialized >> allocations, but from the security point of view the two methods don't >> have the same opportunity to leak information. >> >> Unsafe.allocateMemory returns a long, which is just a long to any >> untrusted code since it can't use the Unsafe methods to access the data >> in it. >> >> The new uninitialized array allocation returns a primitive array which >> can be inspected by untrusted code for any stale elements that hold >> private information from a previous allocation - should that array ever >> be leaked to untrusted code... >> >> ...jim >> >> On 2/25/2016 7:47 AM, Paul Sandoz wrote: >>> >>>> On 25 Feb 2016, at 15:36, Aleksey Shipilev >>>> wrote: >>>> >>>> On 02/25/2016 05:13 PM, Andrew Haley wrote: >>>>> On 02/25/2016 01:44 PM, Aleksey Shipilev wrote: >>>>>> Of course, you will still see garbage data if after storing the array >>>>>> elements into the uninitialized array you would publish it racily. But >>>>>> the same is true for the "regular" allocations and subsequent writes. >>>>>> The only difference is whether you see "real" garbage, or some >>>>>> "synthetic" garbage like zeros. It is, of course, a caller >>>>>> responsibility to publish array safely in both cases, if garbage is >>>>>> unwanted. >>>>> >>>>> Of course, my worry with this optimization assumes that programmers >>>>> make mistakes. But you did say "complicated processing is done after >>>>> the allocation." And that's where programmers make mistakes. >>>> >>>> Of course they do; at least half of the Unsafe methods is suitable for >>>> shooting oneself in a foot in creative ways. Unsafe is a sharp tool, and >>>> Unsafe callers are trusted in their madness. This is not your average >>>> Joe's use case, for sure. >>>> >>> >>> FTR the contents of the memory allocated by Unsafe.allocateMemory are >>> also uninitialized. >>> >>> Paul. >>> > > From dalibor.topic at oracle.com Fri Feb 26 14:12:37 2016 From: dalibor.topic at oracle.com (dalibor topic) Date: Fri, 26 Feb 2016 15:12:37 +0100 Subject: CFV: New JDK 9 Committer: Chris Plummer In-Reply-To: <56CF669C.6080108@oracle.com> References: <56CF669C.6080108@oracle.com> Message-ID: <56D05D55.9030406@oracle.com> Vote: Yes. -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From vladimir.x.ivanov at oracle.com Fri Feb 26 16:31:47 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 26 Feb 2016 19:31:47 +0300 Subject: RFR JDK-8149644 Integrate VarHandles In-Reply-To: <9C47EF6F-80D6-467E-A5CB-2FDD5FF6AE17@oracle.com> References: <9C47EF6F-80D6-467E-A5CB-2FDD5FF6AE17@oracle.com> Message-ID: <56D07DF3.6050805@oracle.com> > Hotspot: > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8149644-varhandles-integration/hotspot/webrev/index.html Looks good. > JDK: > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8149644-varhandles-integration/jdk/webrev/index.html src/java.base/share/classes/java/lang/invoke/MethodHandles.java: + public VarHandle unreflectVarHandle(Field f) throws IllegalAccessException { + MemberName getField = new MemberName(f, false); + MemberName putField = new MemberName(f, true); + return getFieldVarHandleNoSecurityManager(getField.getReferenceKind(), putField.getReferenceKind(), + f.getDeclaringClass(), getField, putField); + } unreflectField has the following check: Lookup lookup = f.isAccessible() ? IMPL_LOOKUP : this; return lookup.getDirectFieldNoSecurityManager(field.getReferenceKind(), f.getDeclaringClass(), field); } Why don't you do the same? Otherwise, looks good. Best regards, Vladimir Ivanov > > The spec/API review is proceeding here [1]. > > The patches depend on Unsafe changes [2] and ByteBuffer changes [3]. > > Recent (as of today) JPRT runs for core and hotspot tests pass without failure. Many parts of the code have been soaking in the Valhalla repo for over a year, and it?s been soaking in the sandbox for quite and many a JPRT run was performed. > > It is planned to push through hs-comp as is the case for the dependent patches, and thus minimise any delays due to integration between forests. > > > The Langtools changes are small. Tweaks were made to support updates to signature polymorphic methods and where may be located, in addition to supporting compilation of calls to MethodHandle.link*. > > > The Hotspot changes are not very large. It?s mostly a matter of augmenting checks for MethodHandle to include that for VarHandle. It?s tempting to generalise the ?invokehandle" invocation as i believe there are other use-cases where it might be useful, but i resisted temptation here. I wanted to focus on the minimal changes required. > > > The JDK changes are more substantial, but a large proportion are new tests. The source compilation approach taken is to use templates, the same approach as for code in the nio package, to generate both implementation and test source code. The implementations are generated by the build, the tests are pre-generated. I believe the tests should have good coverage but we have yet to run any code coverage tool. > > The approach to invocation of VarHandle signature polymoprhic methods is slightly different to that of MethodHandles. I wanted to ensure that linking for the common cases avoids lambda form creation, compilation and therefore class spinning. That reduces start up costs and also potential circular dependencies that might be induced in the VM boot process if VarHandles are employed early on. > > For common basic (i.e. erased ref and widened primitive) method signatures, namely all those that matter for the efficient atomic operations there are pre-generated methods that would otherwise be generated from creating and compiling invoker lambda forms. Those methods reside on the VarHandleGuards class. When the VM makes an up call to MethodHandleNatives.linkMethod to link a call site then this up-called method will first check if an appropriate pre-generated method exists on VarHandleGuards and if so it links to that, otherwise it falls back to a method on a class generated from compiling a lambda form. For testing purposes there is a system property available to switch off this optimisation when linking [*]. > > Each VarHandle instance of the same variable type produced from the same factory will share an underlying immutable instance of a VarForm that contains a set of MemberName instances, one for each implementation of a signature polymorphic method (a value of null means unsupported). The invoke methods (on VarHandleGuards or on lambda forms) will statically link to such MemberName instances using a call to MethodHandle.linkToStatic. > > There are a couple of TODOs in comments, those are all on non-critical code paths and i plan to chase them up afterwards. > > C1 does not support constant folding for @Stable arrays hence why in certain cases we have exploded stuff into fields that are operated on using if/else loops. We can simplify such code if/when C1 support is added. > > > Thanks, > Paul. > > [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-January/038150.html > [2] http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2016-January/020953.html > http://mail.openjdk.java.net/pipermail/hotspot-dev/2016-January/021514.html > [3] http://mail.openjdk.java.net/pipermail/nio-dev/2016-February/003535.html > > [*] This technique might be useful for common signatures of MH invokers to reduce associated costs of lambda form creation and compilation in the interim of something better. > From dmitry.dmitriev at oracle.com Fri Feb 26 16:49:16 2016 From: dmitry.dmitriev at oracle.com (Dmitry Dmitriev) Date: Fri, 26 Feb 2016 19:49:16 +0300 Subject: CFV: New JDK 9 Committer: Chris Plummer In-Reply-To: <56CF669C.6080108@oracle.com> References: <56CF669C.6080108@oracle.com> Message-ID: <56D0820C.3010506@oracle.com> Vote: yes Dmitry On 25.02.2016 23:39, Coleen Phillimore wrote: > I hereby nominate Chris Plummer (cjplummer) to JDK 9 Committer. > > Chris is a member of the Oracle Hotspot runtime team and is a long > time Java virtual machine developer. He has contributed 18 changesets > to hotspot and complimentary changesets to other open repositories > [3]. These changes are for test fixes, bug fixes, NMT, CDS > enhancements and memory savings improvements. He is currently working > to reduce memory footprint for metadata. > > Votes are due by 4:00 PM EST, Thursday March 10, 2016. > > Only current JDK 9 Committers [1] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Lazy Consensus voting instructions, see [2]. > > Coleen Phillimore > > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] List of patches: > > http://hg.openjdk.java.net/jdk9/hs-rt/rev/d870508ede1c > 8144677: jprt.properties should allow creating a user specified > testset with custom build flavors and build targets > > http://hg.openjdk.java.net/jdk9/hs-rt/nashorn/rev/8a10da61fc61 > http://hg.openjdk.java.net/jdk9/hs-rt/langtools/rev/91ea64d22fd9 > http://hg.openjdk.java.net/jdk9/hs-rt/jaxp/rev/e939badf7330 > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/3923f2b31fd2 > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/40a609a54513 > 8141489: [TESTBUG] requiredVersion in TEST.ROOT needs to updated to > 4.1 b12 > > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/8a1e0568b885 > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/f81484d852ac > 8140189: [TESTBUG] Get rid of "@library /../../test/lib" in jtreg tests > > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/775c293c892e > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/431b1333b1c1 > 8129386: [TESTBUG] - com/sun/jdi/cds/*.java missing @build tag for > libraries > > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/86144218cf3f > 8054386: Allow Java debugging when CDS is enabled > > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/5791c37057ed > 8081771: ProcessTool.createJavaProcessBuilder() needs new > addTestVmAndJavaOptions argument > > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/4a9f1b1135cb > 8066507: JPRT is not capable of running jtreg tests located jdk/test > > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/6d92296d52ca > 6762191: Setting stack size to 16K causes segmentation fault > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/72afb83f5035 > 8143608: Don't 64-bit align start of InstanceKlass vtable, itable, and > nonstatic_oopmap on 32-bit systems > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/01a99de9d5cb > 8087153: EXCEPTION_ACCESS_VIOLATION when CDS RO section vanished on win32 > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/9fa5219f0206 > 8051712: regression Test7107135 crashes > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/771c83af7df8 > 8069111: Investigate NMT detail tracking support for 32bit ARM > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/034eb71ab7fd > 8054888: Runtime: Add Diagnostic Command that prints the class hierarchy > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/a3f3bc88d1f3 > 8066508: JTReg tests timeout on slow devices when run using JPRT > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/351115afe32b > 8043770: File leak in MemNotifyThread::start() in > hotspot.src.os.linux.vm.os_linux.cpp > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/27ce97a5b0dd > 6191224: (reflect) Misleading detail string in > IllegalArgumentException thrown by Array.get > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/795fc0cef7c9 > 8046607: Code cleanup: PerfMemory::backing_store_filename() should be > removed > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/5fd8e2fbafd4 > 8020829: JT_HS: 2 runtime NMT tests fail on platforms if NMT detail is > not supported > From gerard.ziemski at oracle.com Fri Feb 26 17:34:59 2016 From: gerard.ziemski at oracle.com (Gerard Ziemski) Date: Fri, 26 Feb 2016 11:34:59 -0600 Subject: CFV: New JDK 9 Committer: Chris Plummer In-Reply-To: <56CF669C.6080108@oracle.com> References: <56CF669C.6080108@oracle.com> Message-ID: Vote: yes > On Feb 25, 2016, at 2:39 PM, Coleen Phillimore wrote: > > I hereby nominate Chris Plummer (cjplummer) to JDK 9 Committer. > > Chris is a member of the Oracle Hotspot runtime team and is a long time Java virtual machine developer. He has contributed 18 changesets to hotspot and complimentary changesets to other open repositories [3]. These changes are for test fixes, bug fixes, NMT, CDS enhancements and memory savings improvements. He is currently working to reduce memory footprint for metadata. > > Votes are due by 4:00 PM EST, Thursday March 10, 2016. > > Only current JDK 9 Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Coleen Phillimore From christian.thalinger at oracle.com Fri Feb 26 18:46:31 2016 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 26 Feb 2016 08:46:31 -1000 Subject: RFR (S) 8150465: Unsafe methods to produce uninitialized arrays In-Reply-To: <56CF6FAC.8000603@oracle.com> References: <56CE3222.6040207@oracle.com> <56CF6007.5060607@oracle.com> <3456FD3A-CBF8-46AD-9092-5DC7C6A02DD8@oracle.com> <56CF6FAC.8000603@oracle.com> Message-ID: <454CC9C7-E498-4F23-A210-5DA188126029@oracle.com> > On Feb 25, 2016, at 11:18 AM, Aleksey Shipilev wrote: > > On 02/25/2016 11:51 PM, Christian Thalinger wrote: >> >>> On Feb 25, 2016, at 10:11 AM, Aleksey Shipilev wrote: >>> >>> On 02/25/2016 10:52 PM, Christian Thalinger wrote: >>>> + public Object allocateArrayUninit(Class componentType, int length) { >>>> >>>> Can we use another name like allocateUninitializedArray? >>> >>> Yes, we can: >>> http://cr.openjdk.java.net/~shade/8150465/webrev.jdk.02/ >>> http://cr.openjdk.java.net/~shade/8150465/webrev.hs.03/ >> >> Thanks but I wanted the change in hotspot code too. > > That wasn't made obvious. > > Here you go: > http://cr.openjdk.java.net/~shade/8150465/webrev.jdk.02/ > http://cr.openjdk.java.net/~shade/8150465/webrev.hs.04/ Looks good. > > -Aleksey > > From aleksey.shipilev at oracle.com Fri Feb 26 18:56:04 2016 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Fri, 26 Feb 2016 21:56:04 +0300 Subject: RFR (S) 8150465: Unsafe methods to produce uninitialized arrays In-Reply-To: <56D027D3.9010609@oracle.com> References: <56CE3222.6040207@oracle.com> <56CECE5E.4080105@redhat.com> <56CF053A.3070607@oracle.com> <56CF0C1A.4040600@redhat.com> <56CF1163.4040005@oracle.com> <6D79C6DB-B770-4CAA-9338-154589441F8B@oracle.com> <56CF86EE.6070704@oracle.com> <56CFF853.7020207@oracle.com> <56D027D3.9010609@oracle.com> Message-ID: <56D09FC4.3030004@oracle.com> Hi Jim, I agree with most of your points. You are correct that comparing allocateMemory and allocateUninitializedArray is cumbersome, and I was not trying to compare these. My comment was about Unsafe at large, notably peek-and-poke methods that we already have, and can already be used to leak out data. This is to frame the discussion into "Unsafe is unsafe" mood. This is not a regular JDK method. As many other Unsafe methods, it comes with caveats, and hordes of developers are not the target audience, even most JDK developers are not the target audience. The target audience is a tiny group of core library developers who are (admittedly) well-versed in reading the labels on unsafe methods before using them. As much as I would like to have a capability-based (and also fingerprint/retina-scan-based) access control to internal APIs, current incarnation of Unsafe requires engineering discipline from users. Unsafe is "off limits" for those who do not understand low-level mechanics (memory ordering, atomicity requirements, interaction with runtime, you name it). Unsafe is a special -- perhaps, the only! -- place in JDK where the tradeoff between performance and safety is heavily tilted towards performance. Anyone from the huge body of engineers who does not understand this and uses Unsafe as just another JDK class, could use a really good talking-to, and probably lots and lots of training. On 02/26/2016 01:24 PM, Jim Graham wrote: > I'm seeing a fair amount of hand waving here and not much objective > analysis of the risks. It's important to nail down the issues if for > no other reason than to provide good advice on usage practices in > our documentation to our internal developers... Hopefully the updated Javadoc provides enough deterrent from accidental use. I'd be happy to amend this with even harsher wording, if you tell me the exact words :) Webrevs: http://cr.openjdk.java.net/~shade/8150465/webrev.jdk.03/ http://cr.openjdk.java.net/~shade/8150465/webrev.hs.04/ Thanks, -Aleksey From Paul.Sandoz at oracle.com Fri Feb 26 19:01:27 2016 From: Paul.Sandoz at oracle.com (Paul Sandoz) Date: Fri, 26 Feb 2016 20:01:27 +0100 Subject: RFR JDK-8149644 Integrate VarHandles In-Reply-To: <56D07DF3.6050805@oracle.com> References: <9C47EF6F-80D6-467E-A5CB-2FDD5FF6AE17@oracle.com> <56D07DF3.6050805@oracle.com> Message-ID: Hi Vladimir, Thanks for the reviews. > On 26 Feb 2016, at 17:31, Vladimir Ivanov wrote: > >> Hotspot: >> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8149644-varhandles-integration/hotspot/webrev/index.html > Looks good. > >> JDK: >> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8149644-varhandles-integration/jdk/webrev/index.html > src/java.base/share/classes/java/lang/invoke/MethodHandles.java: > + public VarHandle unreflectVarHandle(Field f) throws IllegalAccessException { > + MemberName getField = new MemberName(f, false); > + MemberName putField = new MemberName(f, true); > + return getFieldVarHandleNoSecurityManager(getField.getReferenceKind(), putField.getReferenceKind(), > + f.getDeclaringClass(), getField, putField); > + } > > unreflectField has the following check: > Lookup lookup = f.isAccessible() ? IMPL_LOOKUP : this; > return lookup.getDirectFieldNoSecurityManager(field.getReferenceKind(), f.getDeclaringClass(), field); > } > > Why don't you do the same? > So as not to widen the places where the reflection accessibility bit can be leveraged (calls to setAccessible), and thus not support more things that can stomp on final fields. The documentation on unreflectVarHandle states: "Access checking is performed immediately on behalf of the lookup class, regardless of value of the field's accessible flag.? (There is a typo there i need to fix, ?of value? -> ?of the value?.) There is also a comment in the following code that is not quite correct when i updated the implementation with the accessibility restriction: private VarHandle getFieldVarHandleCommon(byte getRefKind, byte putRefKind, Class refc, MemberName getField, MemberName putField, boolean checkSecurity) throws IllegalAccessException { assert getField.isStatic() == putField.isStatic(); assert getField.isGetter() && putField.isSetter(); assert MethodHandleNatives.refKindIsStatic(getRefKind) == MethodHandleNatives.refKindIsStatic(putRefKind); assert MethodHandleNatives.refKindIsGetter(getRefKind) && MethodHandleNatives.refKindIsSetter(putRefKind); checkField(getRefKind, refc, getField); if (checkSecurity) checkSecurityManager(refc, getField); if (!putField.isFinal()) { // A VarHandle will only support updates final fields if allowed // modes is TRUSTED. In such cases the following checks are // no-ops and therefore there is no need to invoke if the field // is marked final checkField(putRefKind, refc, putField); if (checkSecurity) checkSecurityManager(refc, putField); } I will update to: // A VarHandle does not support updates to final fields, any // such VarHandle to a final field will be read-only and // therefore the following write-based accessibility checks are // only required for non-final fields Paul. > Otherwise, looks good. > > Best regards, > Vladimir Ivanov From alejandro.murillo at oracle.com Fri Feb 26 19:52:31 2016 From: alejandro.murillo at oracle.com (Alejandro E Murillo) Date: Fri, 26 Feb 2016 12:52:31 -0700 Subject: CFV: New JDK 9 Committer: Chris Plummer In-Reply-To: <56CF669C.6080108@oracle.com> References: <56CF669C.6080108@oracle.com> Message-ID: <56D0ACFF.5000100@oracle.com> vote: yes On 2/25/2016 1:39 PM, Coleen Phillimore wrote: > I hereby nominate Chris Plummer (cjplummer) to JDK 9 Committer. -- Alejandro From james.graham at oracle.com Fri Feb 26 22:34:10 2016 From: james.graham at oracle.com (Jim Graham) Date: Fri, 26 Feb 2016 14:34:10 -0800 Subject: RFR (S) 8150465: Unsafe methods to produce uninitialized arrays In-Reply-To: <56D09FC4.3030004@oracle.com> References: <56CE3222.6040207@oracle.com> <56CECE5E.4080105@redhat.com> <56CF053A.3070607@oracle.com> <56CF0C1A.4040600@redhat.com> <56CF1163.4040005@oracle.com> <6D79C6DB-B770-4CAA-9338-154589441F8B@oracle.com> <56CF86EE.6070704@oracle.com> <56CFF853.7020207@oracle.com> <56D027D3.9010609@oracle.com> <56D09FC4.3030004@oracle.com> Message-ID: <56D0D2E2.6010503@oracle.com> Thanks Aleksey, As I said, I just wanted to see more objective diligence in the discussion of the risks here. With regard to documentation, I think the changes made to the javadoc include a lot of stating the obvious, which is fine, and with some tricky points mentioned as well. I think most engineers can handle "have I written to every element of the array" considerations, but one area where they may not have expertise would be in areas of how the compiler and/or processor cache mechanisms might reorder memory accesses in unexpected ways. For instance, an earlier comment showed some sort of mem-fence operation that was indicated to ensure that the data was written to the array in a thread-safe manner before any external access was allowed. (I'm guessing that the simple act of calling the method and returning the value would enforce a mem-fence in that case?) That consideration would be a good thing to describe in the javadoc. Also, perhaps recommending that the references be held in a local variable until the initialization phase is complete before storing the reference into a field (that might be part of stating the obvious, other than how it might interact with mem-fence considerations)? In the end, I'm not intending to be the voice of opposition on this, just hoping to see the discussion be a little more rounded... ...jim On 2/26/2016 10:56 AM, Aleksey Shipilev wrote: > Hi Jim, > > I agree with most of your points. > > You are correct that comparing allocateMemory and > allocateUninitializedArray is cumbersome, and I was not trying to > compare these. My comment was about Unsafe at large, notably > peek-and-poke methods that we already have, and can already be used to > leak out data. This is to frame the discussion into "Unsafe is unsafe" > mood. > > This is not a regular JDK method. As many other Unsafe methods, it comes > with caveats, and hordes of developers are not the target audience, even > most JDK developers are not the target audience. > > The target audience is a tiny group of core library developers who are > (admittedly) well-versed in reading the labels on unsafe methods before > using them. As much as I would like to have a capability-based (and also > fingerprint/retina-scan-based) access control to internal APIs, current > incarnation of Unsafe requires engineering discipline from users. > > Unsafe is "off limits" for those who do not understand low-level > mechanics (memory ordering, atomicity requirements, interaction with > runtime, you name it). Unsafe is a special -- perhaps, the only! -- > place in JDK where the tradeoff between performance and safety is > heavily tilted towards performance. > > Anyone from the huge body of engineers who does not understand this and > uses Unsafe as just another JDK class, could use a really good > talking-to, and probably lots and lots of training. > > On 02/26/2016 01:24 PM, Jim Graham wrote: >> I'm seeing a fair amount of hand waving here and not much objective >> analysis of the risks. It's important to nail down the issues if for >> no other reason than to provide good advice on usage practices in >> our documentation to our internal developers... > > Hopefully the updated Javadoc provides enough deterrent from accidental > use. I'd be happy to amend this with even harsher wording, if you tell > me the exact words :) > > Webrevs: > http://cr.openjdk.java.net/~shade/8150465/webrev.jdk.03/ > http://cr.openjdk.java.net/~shade/8150465/webrev.hs.04/ > > Thanks, > -Aleksey > > From john.r.rose at oracle.com Fri Feb 26 23:41:09 2016 From: john.r.rose at oracle.com (John Rose) Date: Fri, 26 Feb 2016 15:41:09 -0800 Subject: RFR (S) 8150465: Unsafe methods to produce uninitialized arrays In-Reply-To: <56D0D2E2.6010503@oracle.com> References: <56CE3222.6040207@oracle.com> <56CECE5E.4080105@redhat.com> <56CF053A.3070607@oracle.com> <56CF0C1A.4040600@redhat.com> <56CF1163.4040005@oracle.com> <6D79C6DB-B770-4CAA-9338-154589441F8B@oracle.com> <56CF86EE.6070704@oracle.com> <56CFF853.7020207@oracle.com> <56D027D3.9010609@oracle.com> <56D09FC4.3030004@oracle.com> <56D0D2E2.6010503@oracle.com> Message-ID: <4B0CD00B-187F-4FBE-94F0-35F6D9DF097F@oracle.com> +1 on recommending a fence op in the Java-doc. Also +1 on recommending keeping it in a local. That's overkill, but simple and safe to follow. ? John > On Feb 26, 2016, at 2:34 PM, Jim Graham wrote: > > Thanks Aleksey, > > As I said, I just wanted to see more objective diligence in the discussion of the risks here. > > With regard to documentation, I think the changes made to the javadoc include a lot of stating the obvious, which is fine, and with some tricky points mentioned as well. I think most engineers can handle "have I written to every element of the array" considerations, but one area where they may not have expertise would be in areas of how the compiler and/or processor cache mechanisms might reorder memory accesses in unexpected ways. For instance, an earlier comment showed some sort of mem-fence operation that was indicated to ensure that the data was written to the array in a thread-safe manner before any external access was allowed. (I'm guessing that the simple act of calling the method and returning the value would enforce a mem-fence in that case?) That consideration would be a good thing to describe in the javadoc. Also, perhaps recommending that the references be held in a local variable until the initialization phase is complete before storing the reference into a field (that might be part of stating the obvious, other than how it might interact with mem-fence considerations)? > > In the end, I'm not intending to be the voice of opposition on this, just hoping to see the discussion be a little more rounded... > > ...jim > >> On 2/26/2016 10:56 AM, Aleksey Shipilev wrote: >> Hi Jim, >> >> I agree with most of your points. >> >> You are correct that comparing allocateMemory and >> allocateUninitializedArray is cumbersome, and I was not trying to >> compare these. My comment was about Unsafe at large, notably >> peek-and-poke methods that we already have, and can already be used to >> leak out data. This is to frame the discussion into "Unsafe is unsafe" >> mood. >> >> This is not a regular JDK method. As many other Unsafe methods, it comes >> with caveats, and hordes of developers are not the target audience, even >> most JDK developers are not the target audience. >> >> The target audience is a tiny group of core library developers who are >> (admittedly) well-versed in reading the labels on unsafe methods before >> using them. As much as I would like to have a capability-based (and also >> fingerprint/retina-scan-based) access control to internal APIs, current >> incarnation of Unsafe requires engineering discipline from users. >> >> Unsafe is "off limits" for those who do not understand low-level >> mechanics (memory ordering, atomicity requirements, interaction with >> runtime, you name it). Unsafe is a special -- perhaps, the only! -- >> place in JDK where the tradeoff between performance and safety is >> heavily tilted towards performance. >> >> Anyone from the huge body of engineers who does not understand this and >> uses Unsafe as just another JDK class, could use a really good >> talking-to, and probably lots and lots of training. >> >>> On 02/26/2016 01:24 PM, Jim Graham wrote: >>> I'm seeing a fair amount of hand waving here and not much objective >>> analysis of the risks. It's important to nail down the issues if for >>> no other reason than to provide good advice on usage practices in >>> our documentation to our internal developers... >> >> Hopefully the updated Javadoc provides enough deterrent from accidental >> use. I'd be happy to amend this with even harsher wording, if you tell >> me the exact words :) >> >> Webrevs: >> http://cr.openjdk.java.net/~shade/8150465/webrev.jdk.03/ >> http://cr.openjdk.java.net/~shade/8150465/webrev.hs.04/ >> >> Thanks, >> -Aleksey >> >> From kim.barrett at oracle.com Sat Feb 27 00:46:29 2016 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 26 Feb 2016 19:46:29 -0500 Subject: CFV: New JDK 9 Committer: Chris Plummer In-Reply-To: <56CF669C.6080108@oracle.com> References: <56CF669C.6080108@oracle.com> Message-ID: vote: yes > On Feb 25, 2016, at 3:39 PM, Coleen Phillimore wrote: > > I hereby nominate Chris Plummer (cjplummer) to JDK 9 Committer. From aph at redhat.com Sat Feb 27 10:24:18 2016 From: aph at redhat.com (Andrew Haley) Date: Sat, 27 Feb 2016 10:24:18 +0000 Subject: RFR (S) 8150465: Unsafe methods to produce uninitialized arrays In-Reply-To: <56D0D2E2.6010503@oracle.com> References: <56CE3222.6040207@oracle.com> <56CECE5E.4080105@redhat.com> <56CF053A.3070607@oracle.com> <56CF0C1A.4040600@redhat.com> <56CF1163.4040005@oracle.com> <6D79C6DB-B770-4CAA-9338-154589441F8B@oracle.com> <56CF86EE.6070704@oracle.com> <56CFF853.7020207@oracle.com> <56D027D3.9010609@oracle.com> <56D09FC4.3030004@oracle.com> <56D0D2E2.6010503@oracle.com> Message-ID: <56D17952.5080503@redhat.com> On 26/02/16 22:34, Jim Graham wrote: > I think most engineers can handle "have I written to every element > of the array" considerations, but one area where they may not have > expertise would be in areas of how the compiler and/or processor > cache mechanisms might reorder memory accesses in unexpected ways. > For instance, an earlier comment showed some sort of mem-fence > operation that was indicated to ensure that the data was written to > the array in a thread-safe manner before any external access was > allowed. (I'm guessing that the simple act of calling the method > and returning the value would enforce a mem-fence in that case?) No, it doesn't. The Java memory model relies on dependency ordering. That is to say, if there has been a release fence between writing the array and storing a pointer to that array in a field Obj.f, then no other thread will observe the uninitialized array. This is because any reader of the data in the array must get its address via Obj.f, and all current CPUs enforce address dependency ordering. (An address dependency exists when the value returned by a read is used to compute the address of a subsequent read or write.) One other thing: it's probably not safe to use a StoreStore fence unless the contents of the array are all constants. The reasons for this are complex and I can provide a reference if required, but it's probably best simply to say "use a release fence." Andrew. From vladimir.x.ivanov at oracle.com Mon Feb 29 11:26:20 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Mon, 29 Feb 2016 14:26:20 +0300 Subject: RFR JDK-8149644 Integrate VarHandles In-Reply-To: References: <9C47EF6F-80D6-467E-A5CB-2FDD5FF6AE17@oracle.com> <56D07DF3.6050805@oracle.com> Message-ID: <56D42ADC.4000808@oracle.com> Thanks for the clarifications. JDK part looks good. Best regards, Vladimir Ivanov On 2/26/16 10:01 PM, Paul Sandoz wrote: > Hi Vladimir, > > Thanks for the reviews. > >> On 26 Feb 2016, at 17:31, Vladimir Ivanov wrote: >> >>> Hotspot: >>> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8149644-varhandles-integration/hotspot/webrev/index.html >> Looks good. >> >>> JDK: >>> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8149644-varhandles-integration/jdk/webrev/index.html >> src/java.base/share/classes/java/lang/invoke/MethodHandles.java: >> + public VarHandle unreflectVarHandle(Field f) throws IllegalAccessException { >> + MemberName getField = new MemberName(f, false); >> + MemberName putField = new MemberName(f, true); >> + return getFieldVarHandleNoSecurityManager(getField.getReferenceKind(), putField.getReferenceKind(), >> + f.getDeclaringClass(), getField, putField); >> + } >> >> unreflectField has the following check: >> Lookup lookup = f.isAccessible() ? IMPL_LOOKUP : this; >> return lookup.getDirectFieldNoSecurityManager(field.getReferenceKind(), f.getDeclaringClass(), field); >> } >> >> Why don't you do the same? >> > > So as not to widen the places where the reflection accessibility bit can be leveraged (calls to setAccessible), and thus not support more things that can stomp on final fields. > > The documentation on unreflectVarHandle states: > > "Access checking is performed immediately on behalf of the lookup class, regardless of value of the field's accessible flag.? > > (There is a typo there i need to fix, ?of value? -> ?of the value?.) > > > There is also a comment in the following code that is not quite correct when i updated the implementation with the accessibility restriction: > > private VarHandle getFieldVarHandleCommon(byte getRefKind, byte putRefKind, > Class refc, MemberName getField, MemberName putField, > boolean checkSecurity) throws IllegalAccessException { > assert getField.isStatic() == putField.isStatic(); > assert getField.isGetter() && putField.isSetter(); > assert MethodHandleNatives.refKindIsStatic(getRefKind) == MethodHandleNatives.refKindIsStatic(putRefKind); > assert MethodHandleNatives.refKindIsGetter(getRefKind) && MethodHandleNatives.refKindIsSetter(putRefKind); > > checkField(getRefKind, refc, getField); > if (checkSecurity) > checkSecurityManager(refc, getField); > > if (!putField.isFinal()) { > // A VarHandle will only support updates final fields if allowed > // modes is TRUSTED. In such cases the following checks are > // no-ops and therefore there is no need to invoke if the field > // is marked final > checkField(putRefKind, refc, putField); > if (checkSecurity) > checkSecurityManager(refc, putField); > } > > I will update to: > > // A VarHandle does not support updates to final fields, any > // such VarHandle to a final field will be read-only and > // therefore the following write-based accessibility checks are > // only required for non-final fields > > Paul. > >> Otherwise, looks good. >> >> Best regards, >> Vladimir Ivanov > From aleksey.shipilev at oracle.com Mon Feb 29 16:32:49 2016 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Mon, 29 Feb 2016 19:32:49 +0300 Subject: RFR (S) 8150465: Unsafe methods to produce uninitialized arrays In-Reply-To: <4B0CD00B-187F-4FBE-94F0-35F6D9DF097F@oracle.com> References: <56CE3222.6040207@oracle.com> <56CECE5E.4080105@redhat.com> <56CF053A.3070607@oracle.com> <56CF0C1A.4040600@redhat.com> <56CF1163.4040005@oracle.com> <6D79C6DB-B770-4CAA-9338-154589441F8B@oracle.com> <56CF86EE.6070704@oracle.com> <56CFF853.7020207@oracle.com> <56D027D3.9010609@oracle.com> <56D09FC4.3030004@oracle.com> <56D0D2E2.6010503@oracle.com> <4B0CD00B-187F-4FBE-94F0-35F6D9DF097F@oracle.com> Message-ID: <56D472B1.6020205@oracle.com> On 27.02.2016 02:41, John Rose wrote: > +1 on recommending a fence op in the Java-doc. > > Also +1 on recommending keeping it in a local. That's overkill, but simple and safe to follow. Thanks Jim, John and Andrew for chiming in. Let's see if this Javadoc variant floats: http://cr.openjdk.java.net/~shade/8150465/webrev.jdk.04/ http://cr.openjdk.java.net/~shade/8150465/webrev.hs.04/ -Aleksey From joe.darcy at oracle.com Mon Feb 29 18:25:38 2016 From: joe.darcy at oracle.com (joe darcy) Date: Mon, 29 Feb 2016 10:25:38 -0800 Subject: FYI, more concise javadoc display of annotations and annotation types in JDK 9 b107 Message-ID: <56D48D22.1030300@oracle.com> Hello, FYI, JDK 9 b107 has two annotation-related javadoc improvements which improve conciseness. First, methods in annotation types no longer display the superfluous "public abstract" modifiers. [1] Second, when a single-element annotation is present [2], the unnecessary "value=" text is elided. [3] Both changes align the javadoc output with conventions for how the corresponding source is written. For an example of these changes, compare the JDK 8 version of Repeatable http://docs.oracle.com/javase/8/docs/api/java/lang/annotation/Repeatable.html with the one from a recent JDK 9 build: http://download.java.net/java/jdk9/docs/api/java/lang/annotation/Repeatable.html Cheers, -Joe [1] JDK-6469561: javadoc for annotation types should not display "public abstract" modifiers on methods [2] https://docs.oracle.com/javase/specs/jls/se8/html/jls-9.html#jls-9.7.3 [2] JDK-6469562: Use compact notation to display annotation values From james.graham at oracle.com Mon Feb 29 19:19:14 2016 From: james.graham at oracle.com (Jim Graham) Date: Mon, 29 Feb 2016 11:19:14 -0800 Subject: RFR (S) 8150465: Unsafe methods to produce uninitialized arrays In-Reply-To: <56D472B1.6020205@oracle.com> References: <56CE3222.6040207@oracle.com> <56CECE5E.4080105@redhat.com> <56CF053A.3070607@oracle.com> <56CF0C1A.4040600@redhat.com> <56CF1163.4040005@oracle.com> <6D79C6DB-B770-4CAA-9338-154589441F8B@oracle.com> <56CF86EE.6070704@oracle.com> <56CFF853.7020207@oracle.com> <56D027D3.9010609@oracle.com> <56D09FC4.3030004@oracle.com> <56D0D2E2.6010503@oracle.com> <4B0CD00B-187F-4FBE-94F0-35F6D9DF097F@oracle.com> <56D472B1.6020205@oracle.com> Message-ID: <56D499B2.7060100@oracle.com> That looks great! Maybe I'm missing something (memory fences are not in my wheelhouse), but is storeFence() the right fence to use? I would think you would want stores before the fence to not be reordered wrt loads after the fence, but storeFence() only protects against stores after the fence (according to its doc comment). I couldn't find a storeLoadFence() method...? (and storeFence does not incorporate storeload protection) One issue I found confusing, the docs for loadFence() say that a loadloadFence is not provided and gives reasons - then 2 methods later we have loadloadFence() - it turns out that loadloadFence calls the full loadFence method, but its presence contradicts the comment in the earlier method, which is just confusing. It should probably be deprecated and mention that it is provided for convenience and actually does a full loadFence() and move the reason from the other method to the comment on the loadload method (a caller to loadFence() wouldn't likely care about that issue, but a caller to loadloadFence() would need to know it so that documentation really belongs in the latter method). Perhaps the comment was added to loadFence before the convenience loadload method was added? ...jim On 2/29/2016 8:32 AM, Aleksey Shipilev wrote: > On 27.02.2016 02:41, John Rose wrote: >> +1 on recommending a fence op in the Java-doc. >> >> Also +1 on recommending keeping it in a local. That's overkill, but simple and safe to follow. > > Thanks Jim, John and Andrew for chiming in. > > Let's see if this Javadoc variant floats: > http://cr.openjdk.java.net/~shade/8150465/webrev.jdk.04/ > http://cr.openjdk.java.net/~shade/8150465/webrev.hs.04/ > > -Aleksey > From aph at redhat.com Mon Feb 29 19:29:19 2016 From: aph at redhat.com (Andrew Haley) Date: Mon, 29 Feb 2016 19:29:19 +0000 Subject: RFR (S) 8150465: Unsafe methods to produce uninitialized arrays In-Reply-To: <56D499B2.7060100@oracle.com> References: <56CE3222.6040207@oracle.com> <56CECE5E.4080105@redhat.com> <56CF053A.3070607@oracle.com> <56CF0C1A.4040600@redhat.com> <56CF1163.4040005@oracle.com> <6D79C6DB-B770-4CAA-9338-154589441F8B@oracle.com> <56CF86EE.6070704@oracle.com> <56CFF853.7020207@oracle.com> <56D027D3.9010609@oracle.com> <56D09FC4.3030004@oracle.com> <56D0D2E2.6010503@oracle.com> <4B0CD00B-187F-4FBE-94F0-35F6D9DF097F@oracle.com> <56D472B1.6020205@oracle.com> <56D499B2.7060100@oracle.com> Message-ID: <56D49C0F.1000802@redhat.com> On 02/29/2016 07:19 PM, Jim Graham wrote: > Maybe I'm missing something (memory fences are not in my wheelhouse), Sadly, they are in mine. :-) > but is storeFence() the right fence to use? I would think you would > want stores before the fence to not be reordered wrt loads after the > fence, but storeFence() only protects against stores after the fence > (according to its doc comment). I couldn't find a storeLoadFence() > method...? (and storeFence does not incorporate storeload protection) You don't need StoreLoad (which is always a full fence AFAIK) but I think that you do need (LoadStore|StoreStore), aka release(). Andrew. From james.graham at oracle.com Mon Feb 29 20:09:09 2016 From: james.graham at oracle.com (Jim Graham) Date: Mon, 29 Feb 2016 12:09:09 -0800 Subject: RFR (S) 8150465: Unsafe methods to produce uninitialized arrays In-Reply-To: <56D49C0F.1000802@redhat.com> References: <56CE3222.6040207@oracle.com> <56CECE5E.4080105@redhat.com> <56CF053A.3070607@oracle.com> <56CF0C1A.4040600@redhat.com> <56CF1163.4040005@oracle.com> <6D79C6DB-B770-4CAA-9338-154589441F8B@oracle.com> <56CF86EE.6070704@oracle.com> <56CFF853.7020207@oracle.com> <56D027D3.9010609@oracle.com> <56D09FC4.3030004@oracle.com> <56D0D2E2.6010503@oracle.com> <4B0CD00B-187F-4FBE-94F0-35F6D9DF097F@oracle.com> <56D472B1.6020205@oracle.com> <56D499B2.7060100@oracle.com> <56D49C0F.1000802@redhat.com> Message-ID: <56D4A565.6040205@oracle.com> Which is why these docs are important, eh? ;) I think I get it now. I was worried about "loading from the array after storing to the array", but that's a red herring because the fence isn't about ordering across threads. So the distinction is actually about publishing the handle, i.e. a store operation, and the real consideration is "making sure all of the initializing stores to the array elements are flushed before the publicizing store of the array handle", so really you want store ordering... as you said... ding! I'm not sure if that is worth spelling out for those of us who don't worry about these things for a living, but adding "[or issuing a {storeFence}] just before executing the assignment that publishes the reference" might help. Looks good then! ...jim (who probably now owns enough Memory Model rope to hang himself) On 2/29/2016 11:29 AM, Andrew Haley wrote: > On 02/29/2016 07:19 PM, Jim Graham wrote: >> Maybe I'm missing something (memory fences are not in my wheelhouse), > > Sadly, they are in mine. :-) > >> but is storeFence() the right fence to use? I would think you would >> want stores before the fence to not be reordered wrt loads after the >> fence, but storeFence() only protects against stores after the fence >> (according to its doc comment). I couldn't find a storeLoadFence() >> method...? (and storeFence does not incorporate storeload protection) > > You don't need StoreLoad (which is always a full fence AFAIK) but I > think that you do need (LoadStore|StoreStore), aka release(). > > Andrew. >