From alejandro.murillo at oracle.com Tue Mar 1 02:43:25 2016 From: alejandro.murillo at oracle.com (Alejandro E Murillo) Date: Mon, 29 Feb 2016 19:43:25 -0700 Subject: jdk9-dev: HotSpot Message-ID: <56D501CD.3040602@oracle.com> jdk9-hs-2016-02-26 has been integrated into jdk9-dev. http://hg.openjdk.java.net/jdk9/dev/rev/c7be2a78c31b http://hg.openjdk.java.net/jdk9/dev/corba/rev/84f2862a25eb http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/0fe42e7d345c http://hg.openjdk.java.net/jdk9/dev/jaxp/rev/3b9fa8b14914 http://hg.openjdk.java.net/jdk9/dev/jaxws/rev/513eb2e432f6 http://hg.openjdk.java.net/jdk9/dev/jdk/rev/d6dbe934ed0f http://hg.openjdk.java.net/jdk9/dev/langtools/rev/fd18a155ad22 http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/58409eff7e3e Component : VM Status : Go for integration Date : 02/29/2015 at 20:30 MSK Tested By : VM SQE &dmitry.fazunenko at oracle.com Bundles : 2016-02-26-183622.amurillo.jdk9-hs-2016-02-26-snapshot Testing: 95 new failures, 2339 known failures, 411809 passed. Issues and Notes: No detailed analysis. No stoppers have been detected so far. Go for integration CRs for testing: 8143245: Zero build requires disabled warnings 8144578: TestOptionsWithRanges test only ever uses the default collector 8146187: Print develop and nonproduct flags by -XX:+PrintFlags* options in debug build 8146728: TestPrintGCDetailsVerbose is never run by jtreg 8146989: Introduce per-worker preserved mark stacks in ParNew 8147388: Add diagnostic commands to attach JVMTI agent. 8148219: Add decorator hostname to UL 8148630: Convert TraceStartupTime to Unified Logging 8149013: Remove unused and dead code from G1CollectorPolicy 8149383: Convert TraceBiasedLocking to Unified Logging 8149643: Remove check of counters in VirtualSpaceNode::inc_container_count 8149793: DirtyCardQueueSet::apply_closure_to_completed_buffer_helper isn't helpful 8149837: String.intern creates morre work than necessary for G1 8150067: Quarantine serviceability/tmtools/jstat/GcCapacityTest.java 8150079: MSVC prior to VS 2013 doesn't know the 'va_copy' macro 8150134: Simplify concurrent refinement thread deactivation 8150201: Restore missing -g flags to files with OPT_CFLAGS/per-file 8150232: AIX cleanup: Integrate changes of 7178026 and others 8150302: Reference processing logging prints the "from list" incorrectly 8150367: Add back information about the number of GC workers 8150379: [windows] Fix Leaks in perfMemory_windows.cpp 8150562: Quarantine LoadAgentDcmdTest.java due to JDK-8150318 8150647: Quarantine TestPLABResize.java until JDK-8150183 is fixed -- Alejandro From paul.sandoz at oracle.com Tue Mar 1 15:03:20 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 1 Mar 2016 16:03:20 +0100 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: Hi Jim, My comment was not an intent to stifle discussion (which it thankfully did not do!) or to exactly equate functionality, it was just pointing out that the unsafe approach of non-zeroing is not uncharted territory when we are all at sea with Unsafe. FWIW (you may know this already perhaps) Unsafe.allocateMemory is used in the constructor of DirectByteBuffer [*], which zeros out the contents, and is safe because it?s all carefully performed in the constructor. Paul. [*] DirectByteBuffer(int cap) { // package-private super(-1, 0, cap, cap); boolean pa = VM.isDirectMemoryPageAligned(); int ps = Bits.pageSize(); long size = Math.max(1L, (long)cap + (pa ? ps : 0)); Bits.reserveMemory(size, cap); long base = 0; try { base = unsafe.allocateMemory(size); } catch (OutOfMemoryError x) { Bits.unreserveMemory(size, cap); throw x; } unsafe.setMemory(base, size, (byte) 0); if (pa && (base % ps != 0)) { // Round up to page boundary address = base + ps - (base & (ps - 1)); } else { address = base; } cleaner = Cleaner.create(this, new Deallocator(base, size, cap)); att = null; } > On 25 Feb 2016, at 23:57, 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 mikael.vidstedt at oracle.com Tue Mar 1 16:58:10 2016 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Tue, 1 Mar 2016 08:58:10 -0800 Subject: RFR (M): 8149159: Clean up Unsafe In-Reply-To: <56C7757E.4070806@oracle.com> References: <56C61A07.4010604@oracle.com> <56C7757E.4070806@oracle.com> Message-ID: <56D5CA22.7050308@oracle.com> Thanks for all the great feedback/questions. Updated webrev(s) here: http://cr.openjdk.java.net/~mikael/webrevs/8149159_unsafecleanup/hotspot/webrev.01.incr/webrev/ http://cr.openjdk.java.net/~mikael/webrevs/8149159_unsafecleanup/jdk/webrev.01.incr/webrev/ Also, here are the changes after rebasing on top of hs-comp to include Aleksey's recent changes to Unsafe. There were some conflicts in unsafe.cpp where the new methods/functions were added, so I had to resolve that and apply the cleanup to them as well. hotspot: http://cr.openjdk.java.net/~mikael/webrevs/8149159_unsafecleanup/hotspot/webrev.01/webrev/ jdk: http://cr.openjdk.java.net/~mikael/webrevs/8149159_unsafecleanup/jdk/webrev.01/webrev/ * Changes Apart from resolving the conflicts in unsafe.cpp, this change include the following changes compared to webrev.00: Claes - you are absolutely about right about the missing annotations, I have gone through and added the ForceInline annotation to all the s.m.Unsafe methods were it was missing. Thanks for catching that! Chris - I chose to completely remove the UnsafeWrapper macro and its uses from unsafe.cpp. After all it's empty right now, and if somebody feels like adding it back it can simply be injected into the UNSAFE_ENTRY/UNSAFE_LEAF macros. * Testing I've run both -testset hotspot and -testset core on this, and FWIW it's all green. * Comments/other Stas - Wrt to the changes to the unsafe.cpp function names, I chose to rename the functions to include the suffix "0" to reflect the name change of the corresponding java (native) methods. While it's not strictly necessary it does feel just a tad clearer/more intuitive to me to have the names match. John/Paul - I filed https://bugs.openjdk.java.net/browse/JDK-8150921 to cover the migration from single (long) addressing modes for the Unsafe getters/setters to the double-register (Object + long) equivalents. Cheers, Mikael On 2016-02-19 12:05, Claes Redestad wrote: > 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 aleksey.shipilev at oracle.com Tue Mar 1 18:45:15 2016 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Tue, 1 Mar 2016 21:45:15 +0300 Subject: RFR (S) 8150465: Unsafe methods to produce uninitialized arrays In-Reply-To: <56CE3222.6040207@oracle.com> References: <56CE3222.6040207@oracle.com> Message-ID: <56D5E33B.4050606@oracle.com> On 02/25/2016 01:43 AM, Aleksey Shipilev wrote: > Webrevs: > http://cr.openjdk.java.net/~shade/8150465/webrev.hs.01/ > http://cr.openjdk.java.net/~shade/8150465/webrev.jdk.01/ For the record, after all good reviews and discussions happened in this thread, I'll be pushing these soon: http://cr.openjdk.java.net/~shade/8150465/webrev.hs.04/ http://cr.openjdk.java.net/~shade/8150465/webrev.jdk.04/ Thanks, -Aleksey From james.graham at oracle.com Tue Mar 1 23:34:29 2016 From: james.graham at oracle.com (Jim Graham) Date: Tue, 1 Mar 2016 15:34:29 -0800 Subject: RFR (S) 8150465: Unsafe methods to produce uninitialized arrays In-Reply-To: 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: <56D62705.2020506@oracle.com> Thanks Paul, That code doesn't seem to follow the recommendations in the new allocateUninit() method as far as publicizing the address field. Unless unsafe.setMemory() does a fence? ...jim On 3/1/16 7:03 AM, Paul Sandoz wrote: > Hi Jim, > > My comment was not an intent to stifle discussion (which it thankfully did not do!) or to exactly equate functionality, it was just pointing out that the unsafe approach of non-zeroing is not uncharted territory when we are all at sea with Unsafe. > > FWIW (you may know this already perhaps) Unsafe.allocateMemory is used in the constructor of DirectByteBuffer [*], which zeros out the contents, and is safe because it?s all carefully performed in the constructor. > > Paul. > > [*] > DirectByteBuffer(int cap) { // package-private > > super(-1, 0, cap, cap); > boolean pa = VM.isDirectMemoryPageAligned(); > int ps = Bits.pageSize(); > long size = Math.max(1L, (long)cap + (pa ? ps : 0)); > Bits.reserveMemory(size, cap); > > long base = 0; > try { > base = unsafe.allocateMemory(size); > } catch (OutOfMemoryError x) { > Bits.unreserveMemory(size, cap); > throw x; > } > unsafe.setMemory(base, size, (byte) 0); > if (pa && (base % ps != 0)) { > // Round up to page boundary > address = base + ps - (base & (ps - 1)); > } else { > address = base; > } > cleaner = Cleaner.create(this, new Deallocator(base, size, cap)); > att = null; > > > > > } > >> On 25 Feb 2016, at 23:57, 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 aph at redhat.com Wed Mar 2 08:45:30 2016 From: aph at redhat.com (Andrew Haley) Date: Wed, 2 Mar 2016 08:45:30 +0000 Subject: RFR (S) 8150465: Unsafe methods to produce uninitialized arrays In-Reply-To: <56D62705.2020506@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> <56D62705.2020506@oracle.com> Message-ID: <56D6A82A.2030302@redhat.com> On 01/03/16 23:34, Jim Graham wrote: > Thanks Paul, > > That code doesn't seem to follow the recommendations in the new > allocateUninit() method as far as publicizing the address field. Unless > unsafe.setMemory() does a fence? DirectByteBuffer.cleaner is final, so there is a fence at the end of DirectByteBuffer's constructor. But there is perhaps a race here because a Deallocator instance is created before the Unsafe.setMemory() becomes observable to the cleaner thread. I don't think that matters as long as the Deallocator is sane, but it's not a pattern I like much. Andrew. From erik.joelsson at oracle.com Wed Mar 2 12:27:43 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 2 Mar 2016 13:27:43 +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: <56D6DC3F.30402@oracle.com> Build part looks ok. /Erik On 2016-02-11 16: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 paul.sandoz at oracle.com Wed Mar 2 12:33:01 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 2 Mar 2016 13:33:01 +0100 Subject: RFR (M): 8149159: Clean up Unsafe In-Reply-To: <56D5CA22.7050308@oracle.com> References: <56C61A07.4010604@oracle.com> <56C7757E.4070806@oracle.com> <56D5CA22.7050308@oracle.com> Message-ID: <5BC69CC7-9933-4504-AA23-8BDCF75CEEE9@oracle.com> > On 1 Mar 2016, at 17:58, Mikael Vidstedt wrote: > > > Thanks for all the great feedback/questions. Updated webrev(s) here: > > http://cr.openjdk.java.net/~mikael/webrevs/8149159_unsafecleanup/hotspot/webrev.01.incr/webrev/ > http://cr.openjdk.java.net/~mikael/webrevs/8149159_unsafecleanup/jdk/webrev.01.incr/webrev/ > +1 > Also, here are the changes after rebasing on top of hs-comp to include Aleksey's recent changes to Unsafe. There were some conflicts in unsafe.cpp where the new methods/functions were added, so I had to resolve that and apply the cleanup to them as well. > > hotspot: http://cr.openjdk.java.net/~mikael/webrevs/8149159_unsafecleanup/hotspot/webrev.01/webrev/ > jdk: http://cr.openjdk.java.net/~mikael/webrevs/8149159_unsafecleanup/jdk/webrev.01/webrev/ > > > * Changes > > Apart from resolving the conflicts in unsafe.cpp, this change include the following changes compared to webrev.00: > > Claes - you are absolutely about right about the missing annotations, I have gone through and added the ForceInline annotation to all the s.m.Unsafe methods were it was missing. Thanks for catching that! > IMO this is a nice to have and good to be consistent to avoid any missing anything; not strictly necessary for methods that are not marked as intrinsic in the ?real? Unsafe (i assumed, perhaps incorrectly, that was the case for all such non-annotated methods). > Chris - I chose to completely remove the UnsafeWrapper macro and its uses from unsafe.cpp. After all it's empty right now, and if somebody feels like adding it back it can simply be injected into the UNSAFE_ENTRY/UNSAFE_LEAF macros. > > > * Testing > > I've run both -testset hotspot and -testset core on this, and FWIW it's all green. > > > * Comments/other > > Stas - Wrt to the changes to the unsafe.cpp function names, I chose to rename the functions to include the suffix "0" to reflect the name change of the corresponding java (native) methods. While it's not strictly necessary it does feel just a tad clearer/more intuitive to me to have the names match. > > John/Paul - I filed https://bugs.openjdk.java.net/browse/JDK-8150921 to cover the migration from single (long) addressing modes for the Unsafe getters/setters to the double-register (Object + long) equivalents. > Great! For that we might require some careful analysis of generated code to ensure the double addressing accessor with a null base value generates the same code as the current single addressing accessor. Paul. From lana.steuck at oracle.com Wed Mar 2 19:46:08 2016 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 2 Mar 2016 11:46:08 -0800 (PST) Subject: jdk9-b108: dev Message-ID: <201603021946.u22Jk8DB010358@sc11152554.us.oracle.com> http://hg.openjdk.java.net/jdk9/jdk9/rev/c7be2a78c31b http://hg.openjdk.java.net/jdk9/jdk9/nashorn/rev/58409eff7e3e http://hg.openjdk.java.net/jdk9/jdk9/langtools/rev/fd18a155ad22 http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/42794e648cfe http://hg.openjdk.java.net/jdk9/jdk9/jaxws/rev/513eb2e432f6 http://hg.openjdk.java.net/jdk9/jdk9/jaxp/rev/3b9fa8b14914 http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/934f6793f5f7 http://hg.openjdk.java.net/jdk9/jdk9/corba/rev/84f2862a25eb --- All the fixes will be tested during promotion (no PIT testing at this point): List of all fixes: =================== JDK-6432031 core-libs Add support for SO_REUSEPORT JDK-8074411 core-libs Describe "minor unit" and/or "default fraction digits" in Currency cla JDK-8087112 core-libs HTTP API and HTTP/1.1 implementation JDK-8132734 core-libs JDK 9 runtime changes to java.util.jar to support multi-release jar fi JDK-8141491 core-libs Unaligned memory access in Bits.c JDK-8143410 core-libs augment pseudo-code descriptions in MethodHandles API JDK-8148379 core-libs jdk.nashorn.api.scripting spec. adjustments, clarifications JDK-8149154 core-libs tools/pack200/Pack200Test.java failed with NullPointerException JDK-8149611 core-libs Add tests for Unsafe.copySwapMemory JDK-8150204 core-libs (fs) Enhance java/nio/file/Files/probeContentType/Basic.java debugging JDK-8150360 core-libs augment/correct MethodHandle API documentation JDK-8150434 core-libs Remove redundant "jdk_localedata" from the CLDR locale data meta info JDK-8150608 core-libs Mark BashStreams.java as intermittently failing and put to ProblemList JDK-8150814 core-libs correct package declaration in Nashorn test JDK-8150825 core-libs MethodHandles.tryFinally throws IndexOutOfBoundsException for non-conf JDK-6378256 hotspot Performance problem with System.identityHashCode in client compiler JDK-8009538 hotspot [Event Request] Want events for tenuring distribution JDK-8136854 hotspot G1 ConcurrentG1RefineThread::stop delays JVM shutdown for >150ms JDK-8138922 hotspot StubCodeDesc constructor publishes partially-constructed objects on St JDK-8143220 hotspot Fix documentation of InitiatingHeapOccupancyPercent JDK-8143542 hotspot C2 doesn't eliminate identical checks JDK-8144957 hotspot Remove PICL warning message JDK-8145725 hotspot Remove the WorkAroundNPTLTimedWaitHang workaround JDK-8147379 hotspot Investigate if ConvertSleepToYield still should be false by default on JDK-8148518 hotspot Unsafe.getCharUnaligned() loads aren't folded in case of -XX:-UseUnali JDK-8148564 hotspot compiler/intrinsics/string/TestStringIntrinsics2.java times out JDK-8148987 hotspot [Linux] Allow building on older systems without CPU_ALLOC support JDK-8148992 hotspot VM can hang on exit if root region scanning is initiated but not execu JDK-8148994 hotspot Replacing MH::invokeBasic with a direct call breaks LF customization JDK-8149096 hotspot Remove unused code in methodComparator JDK-8149123 hotspot [TESTBUG] compiler/loopopts/superword/SumRed* tests running on non-x86 JDK-8149141 hotspot Optimized build is broken JDK-8149356 hotspot Leftover from JDK-8141044: UseNewCode usage JDK-8149415 hotspot [AArch64] implement JVMCI CodeInstaller JDK-8149421 hotspot Vectorized Post Loops JDK-8149427 hotspot Remove .class files from the hotspot repo .hgignore file JDK-8149472 hotspot NPE when executing HotSpotConstantReflectionProvider::constantEquals w JDK-8149541 hotspot Use log_error() instead of log_info() when verification reports a prob JDK-8149542 hotspot Missing failure reporting in HeapRegion::verify JDK-8149543 hotspot range check CastII nodes should not be split through Phi JDK-8149648 hotspot Add number of regions to the G1HeapSummary event JDK-8149650 hotspot Create a trace event for G1 heap region type transitions JDK-8149689 hotspot [JVMCI] CodeInstaller::pd_patch_DataSectionReference should be able to JDK-8149695 hotspot [JVMCI] add missing Checkstyle configuration file JDK-8149697 hotspot Fix for 8145725 is broken JDK-8149740 hotspot NPEs when executing some HotSpotConstantReflectionProvider with null a JDK-8149797 hotspot Compilation fails with "assert(in_hash) failed: node should be in igvn JDK-8149813 hotspot Move trusted final field handling from C2 LoadNode::Value to shared co JDK-8149820 hotspot Move G1YoungGenSizer to g1CollectorPolicy.cpp JDK-8149826 hotspot Concurrent misspelled in the CMS logging JDK-8149918 hotspot CPUIDBrandString stub is generated on demand JDK-8149969 hotspot [JVMCI] PrintNMethods is ignored for CompilerToVM.installCode when not JDK-8150075 hotspot [JVMCI] expose reserved stack machinery and Inline flag in HotSpotVMCo JDK-8150197 infrastructure Integrate AIX fixes from build-infra JDK-8150203 infrastructure Incremental update from build-infra project JDK-8150257 infrastructure Remove softfloat lib support JDK-8150497 infrastructure 32 jshell tests failed on Windows 32 bit JDK-8150337 other-libs sun/misc/SunMiscSignalTest.java failed intermittently JDK-8145854 security-libs SSLContextImpl.statusResponseManager should be generated if required JDK-8149417 security-libs Use final restricted flag JDK-8131027 tools JShell API/tool: suggest imports for a class JDK-8145472 tools replace remaining java.io.File with java.nio.file.Path JDK-8147569 tools Error messages from sjavac server does not always get relayed back to JDK-8147571 tools Information about written .h files is printed on the wrong logging lev JDK-8148498 tools The sjavac client should never create a port file JDK-8149328 tools remove the dependency on java.logging from java.compiler JDK-8149600 tools javac, remove unused options, step 2 JDK-8149772 tools cleanup handling of -encoding in JavacFileManager JDK-8150427 tools Demote ToolReloadTest.java and mark as intermittently failing JDK-8150475 tools -sourcepath / crashes javac JDK-8150874 tools Disable the ComputeFQNsTest.testSuspendIndexing test JDK-8149915 xml enabling validate-annotations feature for xsd schema with annotation c JDK-8150470 xml JCK: api/xsl/conf/copy/copy19 test failure From david.dehaven at oracle.com Thu Mar 3 15:52:31 2016 From: david.dehaven at oracle.com (David DeHaven) Date: Thu, 3 Mar 2016 07:52:31 -0800 Subject: [9-dev] RfR: JDK-8132743: Move netscape.javascript package from jdk.plugin to new module Message-ID: <0DB5EFFD-B4B4-45BA-B866-1AC0DCFDBF90@oracle.com> JBS Issue: https://bugs.openjdk.java.net/browse/JDK-8132743 Code review: http://cr.openjdk.java.net/~ddehaven/8132743/webrev.0/ Summary: - Moved netscape.javascript.{JSObject,JSException} from closed source plugin to jdk - Convert package.html to package-info.java - Cleaned up Javadoc somewhat - Removed long deprecated (and unused) methods from JSException (that had been documented publicly, in case anyone is paying attention) Background: The netscape.javascript package has been used by Applets running in web browsers to gain access to the JavaScript engine running in the browser for a very long time. Originally created by Netscape, it has become the de facto standard for communication between code running in a JVM and various JavaScript engines. It has also been adopted by other components such as JavaFX that now rely on its continued existence in the Java runtime so it make sense to migrate it from the plugin to a well known location. I had to put the module in the boot modules as the plugin is currently loaded in the boot loader. This will change when Jigsaw M3 is integrated, the ultimate intention is for this to reside in the ext loader. -DrD- From mandy.chung at oracle.com Thu Mar 3 19:59:32 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 3 Mar 2016 11:59:32 -0800 Subject: [9-dev] RfR: JDK-8132743: Move netscape.javascript package from jdk.plugin to new module In-Reply-To: <0DB5EFFD-B4B4-45BA-B866-1AC0DCFDBF90@oracle.com> References: <0DB5EFFD-B4B4-45BA-B866-1AC0DCFDBF90@oracle.com> Message-ID: > On Mar 3, 2016, at 7:52 AM, David DeHaven wrote: > > > JBS Issue: > https://bugs.openjdk.java.net/browse/JDK-8132743 > > Code review: > http://cr.openjdk.java.net/~ddehaven/8132743/webrev.0/ Looks okay. There is no @since - I guess it?s okay because netscape.javascript has been shipped with plugin for long time. package-info.java "when running in an {@link java.applet.Applet Applet}? - is this true when running with JavaFX webkit? JSObject.java @throws JSException is missing in the methods Does it throw NPE if the parameter is null? Or JSException - that needs to be specified. Nit: it?d be good to wrap null with {@code null} in the javadoc. Mandy From david.dehaven at oracle.com Thu Mar 3 22:55:35 2016 From: david.dehaven at oracle.com (David DeHaven) Date: Thu, 3 Mar 2016 14:55:35 -0800 Subject: [9-dev] RfR: JDK-8132743: Move netscape.javascript package from jdk.plugin to new module In-Reply-To: References: <0DB5EFFD-B4B4-45BA-B866-1AC0DCFDBF90@oracle.com> Message-ID: <61E2A789-BFFC-401F-AA15-425A3702F5B7@oracle.com> >> JBS Issue: >> https://bugs.openjdk.java.net/browse/JDK-8132743 >> >> Code review: >> http://cr.openjdk.java.net/~ddehaven/8132743/webrev.0/ > > Looks okay. There is no @since - I guess it?s okay because netscape.javascript has been shipped with plugin for long time. I can't track down when it was first included. It pre-dates anything I've looked at so far. > package-info.java > "when running in an {@link java.applet.Applet Applet}? - is this true when running with JavaFX webkit? Yes, I believe so, assuming you have a JSObject representing the root window object. Maybe that should be reworded, I think just remove the "when running in an Applet" part. > JSObject.java > @throws JSException is missing in the methods > > Does it throw NPE if the parameter is null? Or JSException - that needs to be specified. > > Nit: it?d be good to wrap null with {@code null} in the javadoc. Ok. I can fix that. -DrD- From kevin.rushforth at oracle.com Thu Mar 3 23:57:35 2016 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 03 Mar 2016 15:57:35 -0800 Subject: [9-dev] RfR: JDK-8132743: Move netscape.javascript package from jdk.plugin to new module In-Reply-To: <61E2A789-BFFC-401F-AA15-425A3702F5B7@oracle.com> References: <0DB5EFFD-B4B4-45BA-B866-1AC0DCFDBF90@oracle.com> <61E2A789-BFFC-401F-AA15-425A3702F5B7@oracle.com> Message-ID: <56D8CF6F.3030502@oracle.com> Looks OK to me. I did a quick test build and I can see the new package in the exploded JDK, but not in the images. Maybe I did something wrong? -- Kevin David DeHaven wrote: >>> JBS Issue: >>> https://bugs.openjdk.java.net/browse/JDK-8132743 >>> >>> Code review: >>> http://cr.openjdk.java.net/~ddehaven/8132743/webrev.0/ >>> >> Looks okay. There is no @since - I guess it?s okay because netscape.javascript has been shipped with plugin for long time. >> > > I can't track down when it was first included. It pre-dates anything I've looked at so far. > > > >> package-info.java >> "when running in an {@link java.applet.Applet Applet}? - is this true when running with JavaFX webkit? >> > > Yes, I believe so, assuming you have a JSObject representing the root window object. Maybe that should be reworded, I think just remove the "when running in an Applet" part. > > > >> JSObject.java >> @throws JSException is missing in the methods >> >> Does it throw NPE if the parameter is null? Or JSException - that needs to be specified. >> >> Nit: it?d be good to wrap null with {@code null} in the javadoc. >> > > Ok. I can fix that. > > -DrD- > > From mandy.chung at oracle.com Fri Mar 4 00:16:59 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 3 Mar 2016 16:16:59 -0800 Subject: [9-dev] RfR: JDK-8132743: Move netscape.javascript package from jdk.plugin to new module In-Reply-To: <56D8CF6F.3030502@oracle.com> References: <0DB5EFFD-B4B4-45BA-B866-1AC0DCFDBF90@oracle.com> <61E2A789-BFFC-401F-AA15-425A3702F5B7@oracle.com> <56D8CF6F.3030502@oracle.com> Message-ID: <2CC76624-65B0-4CF6-9EF3-98B489DD991C@oracle.com> jdk9-dev is not the right mailing list. I bcc?ed it and add jigsaw-dev instead. > On Mar 3, 2016, at 3:57 PM, Kevin Rushforth wrote: > > Looks OK to me. I did a quick test build and I can see the new package in the exploded JDK, but not in the images. Maybe I did something wrong? > Good catch. jdk.jsobject needs to be added in MAIN_MODULES list in make/Images.gmk Mandy > -- Kevin > > > David DeHaven wrote: >>>> JBS Issue: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8132743 >>>> >>>> >>>> Code review: >>>> >>>> http://cr.openjdk.java.net/~ddehaven/8132743/webrev.0/ >>>> >>>> >>>> >>> Looks okay. There is no @since - I guess it?s okay because netscape.javascript has been shipped with plugin for long time. >>> >>> >> >> I can't track down when it was first included. It pre-dates anything I've looked at so far. >> >> >> >> >>> package-info.java >>> "when running in an {@link java.applet.Applet Applet}? - is this true when running with JavaFX webkit? >>> >>> >> >> Yes, I believe so, assuming you have a JSObject representing the root window object. Maybe that should be reworded, I think just remove the "when running in an Applet" part. >> >> >> >> >>> JSObject.java >>> @throws JSException is missing in the methods >>> >>> Does it throw NPE if the parameter is null? Or JSException - that needs to be specified. >>> >>> Nit: it?d be good to wrap null with {@code null} in the javadoc. >>> >>> >> >> Ok. I can fix that. >> >> -DrD- >> >> >> From magnus.ihse.bursie at oracle.com Sun Mar 6 21:03:15 2016 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Sun, 6 Mar 2016 22:03:15 +0100 Subject: CFV: New JDK 9 Committer: Chris Plummer In-Reply-To: <56CF669C.6080108@oracle.com> References: <56CF669C.6080108@oracle.com> Message-ID: <56DC9B13.7040109@oracle.com> Vote: yes /Magnus 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 frederic.parain at oracle.com Mon Mar 7 09:20:15 2016 From: frederic.parain at oracle.com (Frederic Parain) Date: Mon, 7 Mar 2016 10:20:15 +0100 Subject: CFV: New JDK 9 Committer: Chris Plummer In-Reply-To: <56CF669C.6080108@oracle.com> References: <56CF669C.6080108@oracle.com> Message-ID: <56DD47CF.3080708@oracle.com> Vote: yes Fred 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 > -- Frederic Parain - Oracle Grenoble Engineering Center - France Phone: +33 4 76 18 81 17 Email: Frederic.Parain at oracle.com From bertrand.delsart at oracle.com Mon Mar 7 09:26:09 2016 From: bertrand.delsart at oracle.com (Bertrand Delsart) Date: Mon, 7 Mar 2016 10:26:09 +0100 Subject: CFV: New JDK 9 Committer: Chris Plummer In-Reply-To: <56CF669C.6080108@oracle.com> References: <56CF669C.6080108@oracle.com> Message-ID: <56DD4931.2040103@oracle.com> vote: yes Bertrand. On 2/25/2016 1:39 PM, Coleen Phillimore wrote: > I hereby nominate Chris Plummer (cjplummer) to JDK 9 Committer. -- Bertrand Delsart, Grenoble Engineering Center Oracle, 180 av. de l'Europe, ZIRST de Montbonnot 38330 Montbonnot Saint Martin, FRANCE bertrand.delsart at oracle.com Phone : +33 4 76 18 81 23 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From coleen.phillimore at oracle.com Tue Mar 8 21:23:28 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 8 Mar 2016 16:23:28 -0500 Subject: Result: CFV: New JDK 9 Committer: Rachel Protacio In-Reply-To: <56CB5939.6090704@oracle.com> References: <56CB5939.6090704@oracle.com> Message-ID: <56DF42D0.2080409@oracle.com> Voting for Rachel Protacio [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. Coleen Phillimore [1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-February/003711.html From alejandro.murillo at oracle.com Wed Mar 9 03:18:18 2016 From: alejandro.murillo at oracle.com (Alejandro E Murillo) Date: Tue, 8 Mar 2016 20:18:18 -0700 Subject: jdk9-dev: HotSpot Message-ID: <56DF95FA.5000009@oracle.com> jdk9-hs-2016-03-05 has been integrated into jdk9-dev. http://hg.openjdk.java.net/jdk9/dev/rev/672174fe5bf9 http://hg.openjdk.java.net/jdk9/dev/corba/rev/b75afa17aefe http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/797e6aac6d53 http://hg.openjdk.java.net/jdk9/dev/jaxp/rev/24e247ee1fff http://hg.openjdk.java.net/jdk9/dev/jaxws/rev/4b0697e4ce89 http://hg.openjdk.java.net/jdk9/dev/jdk/rev/24661132af5c http://hg.openjdk.java.net/jdk9/dev/langtools/rev/08b48678df34 http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/70f0c3970211 Component : VM Status : Go for integration Date : 03/08/2015 at 18:00 MSK Tested By : VM SQE &dmitry.fazunenko at oracle.com Bundles : 2016-03-06-044756.amurillo.jdk9-hs-2016-03-05-snapshot Testing: 251 new failures, 2747 known failures, 469181 passed. Issues and Notes: A number of new failures were caused by JCK-7306060 which is introduced by a change in JDK JDK-8147505 so, no stopper There are still a number of failures which are not investiaget yet, but they don't look as critical, they will be analyzed later. So no stopper for the HS integration. Go for integration. CRs for testing: 7177745: JSR292: Many Callsite relinkages cause target method to always run in interpreter mode 8007986: GrowableArray should implement binary search 8058944: Unify the reporting strings for the GC debug level logging in G1 8066814: Reduce accessibility in TraceEvent 8067014: LinearScan::is_sorted significantly slows down fastdebug builds' performance 8068038: C2: large constant offsets aren't handled on SPARC 8069160: serviceability/dcmd/compiler/CompilerQueueTest.java fails due to class not found 8076463: Add logging for the preserve CM referents task 8087341: C2 doesn't optimize redundant memory operations with G1 8130425: libjvm crash due to stack overflow in executables with 32k tbss/tdata 8134119: Use new API to get cache line sizes 8134992: vm/gc/compact/Compact_InternedStrings_Strings failed due to a malloc() failure 8139651: ConcurrentG1Refine uses ints for many of its members that should be unsigned types 8140600: Convert unnecessarily malloc'd Monitors to value members 8140777: Make Adaptive IHOP logging information the same as JFR logging 8141141: Young and Old gen PLAB stats are similar in output with -XX:+PrintPLAB 8141616: Add new methods to the java Whitebox API 8141618: Change JVMCI compilerToVM constant pool tests to support CP cache 8141619: Develop new tests for JVMCI compilerToVM class' CP related methods 8143226: Minor updates to Event Based tracing 8143228: Update module exports for Java Flight Recorder 8143235: Remove libjfr mapfile 8144621: CompilerControl: inline tests timeout with Xcomp 8144732: VM_HeapDumper hits assert with bad dump_len 8145098: JNI GetVersion should return JNI_VERSION_9 8145333: -XX:+EnableJVMCI -XX:+UseJVMCICompiler -XX:-EnableJVMCI makes JVM crash 8145707: 4 Null pointer dereference defect groups in compileBroker.cpp. 8146849: Remove TraceJNIHandleAllocation rather than converting to UL 8147121: Evacuation failure allocation statistics added too late 8147442: Event-based tracing to allow for tracing Klass creation 8147978: Remove Method::_method_data for C1 8148146: Integrate new internal Unsafe entry points, and basic intrinsic support for VarHandles 8148159: [TESTBUG] TestCompilerDirectivesCompatibility tests fails on non-tiered server VMs 8148353: [linux-sparc] Crash in libawt.so on Linux SPARC 8148786: xml.tranform fails on x86-64 8148940: java/lang/ref/FinalizeOverride.java can time out due to frequent safepointing 8149036: Add tracing for thread related events at os level 8149064: TraceProtectionDomainVerification has been converted to Unified Logging. 8149655: PPC64: Implement CompactString intrinsics 8149733: AArch64: refactor array_equals/string_equals 8149741: Don't refer to stub entry points by index in external_word relocations 8149743: JVM crash after debugger hotswap with lambdas 8149789: SIGSEGV in CompileTask::print 8149907: aarch64: use load/store pair instructions in call_stub 8149916: Test case for 8149797 8150002: Check for the validity of oop before printing it in verify_remembered_set 8150038: aarch64: make use of CBZ and CBNZ when comparing narrow pointer with zero 8150045: arraycopy causes segfaults in SATB during garbage collection 8150068: Log the main G1 phases at info level 8150102: C1 should fold arraylength for constant/trusted arrays 8150103: Convert TraceClassPaths to Unified Logging 8150180: String.value contents should be trusted 8150186: Folding mismatched accesses with @Stable is incorrect 8150229: aarch64: pipeline class for several instructions is not set correctly 8150318: serviceability/dcmd/jvmti/LoadAgentDcmdTest.java - Could not find JDK_DIR/lib/x86_64/libinstrument.so 8150349: Reduce the execution time of the hotspot_compiler_3 group 8150390: Move rs length sampling data to the sampling thread 8150419: Cleanup BufferNode API 8150421: Delete experimental G1UseConcMarkReferenceProcessing 8150426: Wrong cast in metadata_at_put 8150436: Incorrect invocation mode when linkToInteface linker is eliminated 8150441: CompileTask::print_impl() is broken after JDK-8146905 8150490: Update OS detection code to recognize Windows Server 2016 8150506: Remove unused locks 8150514: C1 crashes in Canonicalizer::do_ArrayLength() after fix for JDK-8150102 8150534: C1 compilation fails with "Constant field loads are folded during parsing" 8150543: Mismatched access detection is inaccurate 8150561: [AArch64] JVMCI improvements 8150619: Improve thread based logging introduced with 8149036 8150629: Initializing all ParScanThreadStates causes significant unaccounted "Other" times 8150630: Add logging for ParScanThreadState merge phase 8150720: Cleanup code around PrintOptoStatistics 8150723: HSDB toolbar icons are missing. 8150727: [JVMCI] add LoadLoad to the implicit memory barriers on AMD64 8150738: [JVMCI] runtime/CommandLine/TraceExceptionsTest.java fails with: java.lang.RuntimeException: '' missing 8150746: runtime/logging/ItablesTest.java fails with: java.lang.RuntimeException: 'Resolving: klass: ' missing from stdout/stderr 8150822: Fix typo in JDK-8150201 8150933: System::arraycopy intrinsic doesn't mark mismatched loads 8150984: Invalid VM argument causes crash -XX:G1ConcRefinementServiceIntervalMillis=2147483648 8150986: serviceability/sa/jmap-hprof/JMapHProfLargeHeapTest.java failing because expects HPROF JAVA PROFILE 1.0.1 file format 8151017: [TESTBUG] test/compiler/c1/CanonicalizeArrayLength does not work on product builds 8151020: [TESTBUG] UnsafeGetStableArrayElement::testL_* fail intermittently 8151024: Remove TCKJapaneseChronology.java from the problem list 8151053: com/sun/jdi/StepTest.java fails in 2016-03-01 JDK9-hs-rt nightly 8151064: com/sun/jdi/RedefineAddPrivateMethod.sh fails intermittently 8151100: Test java/lang/instrument/NativeMethodPrefixAgent.java can't attempt to do CheckIntrinsics 8151130: [BACKOUT] Remove Method::_method_data for C1 8151157: Quarantine test/compiler/unsafe/UnsafeGetStableArrayElement.java -- Alejandro From bengt.rutisson at oracle.com Wed Mar 9 07:47:38 2016 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Wed, 9 Mar 2016 08:47:38 +0100 Subject: CFV: New JDK 9 Committer: Derek White Message-ID: <56DFD51A.9090908@oracle.com> I hereby nominate Derek White (drwhite) to JDK 9 Committer. Derek is a member of the Hotspot GC team and has contributed 13 changes [3] to the OpenJDK hotspot repository. Votes are due by 9:00 AM CET, Wednesday March 23, 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] http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/log?revcount=1000&rev=author%28%22drwhite%22%29+and+not+merge%28%29 From bengt.rutisson at oracle.com Wed Mar 9 07:49:16 2016 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Wed, 9 Mar 2016 08:49:16 +0100 Subject: CFV: New JDK 9 Committer: Derek White In-Reply-To: <56DFD51A.9090908@oracle.com> References: <56DFD51A.9090908@oracle.com> Message-ID: <56DFD57C.8070802@oracle.com> Corrected the signature... On 2016-03-09 08:47, Bengt Rutisson wrote: > I hereby nominate Derek White (drwhite) to JDK 9 Committer. > > Derek is a member of the Hotspot GC team and has contributed 13 > changes [3] to the OpenJDK hotspot repository. > > Votes are due by 9:00 AM CET, Wednesday March 23, 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]. > > Bengt Rutisson > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/log?revcount=1000&rev=author%28%22drwhite%22%29+and+not+merge%28%29 From bengt.rutisson at oracle.com Wed Mar 9 07:50:20 2016 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Wed, 9 Mar 2016 08:50:20 +0100 Subject: CFV: New JDK 9 Committer: Derek White In-Reply-To: <56DFD57C.8070802@oracle.com> References: <56DFD51A.9090908@oracle.com> <56DFD57C.8070802@oracle.com> Message-ID: <56DFD5BC.2090703@oracle.com> Vote: yes Bengt On 2016-03-09 08:49, Bengt Rutisson wrote: > Corrected the signature... > > On 2016-03-09 08:47, Bengt Rutisson wrote: >> I hereby nominate Derek White (drwhite) to JDK 9 Committer. >> >> Derek is a member of the Hotspot GC team and has contributed 13 >> changes [3] to the OpenJDK hotspot repository. >> >> Votes are due by 9:00 AM CET, Wednesday March 23, 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]. >> >> Bengt Rutisson >> >> [1] http://openjdk.java.net/census >> [2] http://openjdk.java.net/projects/#committer-vote >> [3] >> http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/log?revcount=1000&rev=author%28%22drwhite%22%29+and+not+merge%28%29 > From mikael.gerdin at oracle.com Wed Mar 9 07:54:27 2016 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Wed, 9 Mar 2016 08:54:27 +0100 Subject: CFV: New JDK 9 Committer: Derek White In-Reply-To: <56DFD5BC.2090703@oracle.com> References: <56DFD51A.9090908@oracle.com> <56DFD57C.8070802@oracle.com> <56DFD5BC.2090703@oracle.com> Message-ID: <56DFD6B3.3050307@oracle.com> Vote: yes /Mikael On 2016-03-09 08:50, Bengt Rutisson wrote: > > Vote: yes > > Bengt > > On 2016-03-09 08:49, Bengt Rutisson wrote: >> Corrected the signature... >> >> On 2016-03-09 08:47, Bengt Rutisson wrote: >>> I hereby nominate Derek White (drwhite) to JDK 9 Committer. >>> >>> Derek is a member of the Hotspot GC team and has contributed 13 >>> changes [3] to the OpenJDK hotspot repository. >>> >>> Votes are due by 9:00 AM CET, Wednesday March 23, 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]. >>> >>> Bengt Rutisson >>> >>> [1] http://openjdk.java.net/census >>> [2] http://openjdk.java.net/projects/#committer-vote >>> [3] >>> http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/log?revcount=1000&rev=author%28%22drwhite%22%29+and+not+merge%28%29 >>> >> > From per.liden at oracle.com Wed Mar 9 07:54:57 2016 From: per.liden at oracle.com (Per Liden) Date: Wed, 9 Mar 2016 08:54:57 +0100 Subject: CFV: New JDK 9 Committer: Derek White In-Reply-To: <56DFD57C.8070802@oracle.com> References: <56DFD51A.9090908@oracle.com> <56DFD57C.8070802@oracle.com> Message-ID: <56DFD6D1.3010003@oracle.com> Vote: yes Per On 2016-03-09 08:49, Bengt Rutisson wrote: > Corrected the signature... > > On 2016-03-09 08:47, Bengt Rutisson wrote: >> I hereby nominate Derek White (drwhite) to JDK 9 Committer. >> >> Derek is a member of the Hotspot GC team and has contributed 13 >> changes [3] to the OpenJDK hotspot repository. >> >> Votes are due by 9:00 AM CET, Wednesday March 23, 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]. >> >> Bengt Rutisson >> >> [1] http://openjdk.java.net/census >> [2] http://openjdk.java.net/projects/#committer-vote >> [3] >> http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/log?revcount=1000&rev=author%28%22drwhite%22%29+and+not+merge%28%29 >> > From staffan.larsen at oracle.com Wed Mar 9 08:00:34 2016 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 9 Mar 2016 09:00:34 +0100 Subject: CFV: New JDK 9 Committer: Derek White In-Reply-To: <56DFD57C.8070802@oracle.com> References: <56DFD51A.9090908@oracle.com> <56DFD57C.8070802@oracle.com> Message-ID: <23300F57-3611-4D14-9065-565B99090E1D@oracle.com> Vote: yes > On 9 mars 2016, at 08:49, Bengt Rutisson wrote: > > Corrected the signature... > > On 2016-03-09 08:47, Bengt Rutisson wrote: >> I hereby nominate Derek White (drwhite) to JDK 9 Committer. >> >> Derek is a member of the Hotspot GC team and has contributed 13 changes [3] to the OpenJDK hotspot repository. >> >> Votes are due by 9:00 AM CET, Wednesday March 23, 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]. >> >> Bengt Rutisson >> >> [1] http://openjdk.java.net/census >> [2] http://openjdk.java.net/projects/#committer-vote >> [3] http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/log?revcount=1000&rev=author%28%22drwhite%22%29+and+not+merge%28%29 > From david.holmes at oracle.com Wed Mar 9 08:01:36 2016 From: david.holmes at oracle.com (David Holmes) Date: Wed, 9 Mar 2016 18:01:36 +1000 Subject: CFV: New JDK 9 Committer: Derek White In-Reply-To: <56DFD51A.9090908@oracle.com> References: <56DFD51A.9090908@oracle.com> Message-ID: <56DFD860.5070902@oracle.com> Vote: yes David On 9/03/2016 5:47 PM, Bengt Rutisson wrote: > I hereby nominate Derek White (drwhite) to JDK 9 Committer. > > Derek is a member of the Hotspot GC team and has contributed 13 changes > [3] to the OpenJDK hotspot repository. > > Votes are due by 9:00 AM CET, Wednesday March 23, 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] > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/log?revcount=1000&rev=author%28%22drwhite%22%29+and+not+merge%28%29 > From vladimir.x.ivanov at oracle.com Wed Mar 9 08:04:15 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 9 Mar 2016 11:04:15 +0300 Subject: CFV: New JDK 9 Committer: Derek White In-Reply-To: <56DFD51A.9090908@oracle.com> References: <56DFD51A.9090908@oracle.com> Message-ID: <56DFD8FF.7050704@oracle.com> Vote: yes Best regards, Vladimir Ivanov On 3/9/16 10:47 AM, Bengt Rutisson wrote: > I hereby nominate Derek White (drwhite) to JDK 9 Committer. From thomas.schatzl at oracle.com Wed Mar 9 08:39:14 2016 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 09 Mar 2016 09:39:14 +0100 Subject: CFV: New JDK 9 Committer: Derek White In-Reply-To: <56DFD51A.9090908@oracle.com> References: <56DFD51A.9090908@oracle.com> Message-ID: <1457512754.2275.3.camel@oracle.com> Vote: yes Thomas From volker.simonis at gmail.com Wed Mar 9 09:39:12 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 9 Mar 2016 10:39:12 +0100 Subject: RFR (XXS): 8151497: Set REQUIRED_OS_NAME and REQUIRED_OS_VERSION on AIX Message-ID: Hi, can I please have a review and sponsor (because this change requires the recreation of generated-configure.sh) for this trivial fix: http://cr.openjdk.java.net/~simonis/webrevs/2016/8151497/ https://bugs.openjdk.java.net/browse/JDK-8151497 For some reason we've never set REQUIRED_OS_NAME and REQUIRED_OS_VERSION in platform.m4 on AIX. Until now this didn't hurt but with the upcoming integration of the jigsaw changes from the jake repository the content of these variables is used during the build for calling the jmod tool. Thank you and best regards, Volker From stefan.johansson at oracle.com Wed Mar 9 09:51:08 2016 From: stefan.johansson at oracle.com (Stefan Johansson) Date: Wed, 9 Mar 2016 10:51:08 +0100 Subject: CFV: New JDK 9 Committer: Derek White In-Reply-To: <56DFD51A.9090908@oracle.com> References: <56DFD51A.9090908@oracle.com> Message-ID: <56DFF20C.9000100@oracle.com> Vote: yes StefanJ On 2016-03-09 08:47, Bengt Rutisson wrote: > I hereby nominate Derek White (drwhite) to JDK 9 Committer. > > Derek is a member of the Hotspot GC team and has contributed 13 > changes [3] to the OpenJDK hotspot repository. > > Votes are due by 9:00 AM CET, Wednesday March 23, 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] > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/log?revcount=1000&rev=author%28%22drwhite%22%29+and+not+merge%28%29 From erik.joelsson at oracle.com Wed Mar 9 10:12:28 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 9 Mar 2016 11:12:28 +0100 Subject: RFR (XXS): 8151497: Set REQUIRED_OS_NAME and REQUIRED_OS_VERSION on AIX In-Reply-To: References: Message-ID: <56DFF70C.8030000@oracle.com> Looks good, I will push it. /Erik On 2016-03-09 10:39, Volker Simonis wrote: > Hi, > > can I please have a review and sponsor (because this change requires > the recreation of generated-configure.sh) for this trivial fix: > > http://cr.openjdk.java.net/~simonis/webrevs/2016/8151497/ > https://bugs.openjdk.java.net/browse/JDK-8151497 > > For some reason we've never set REQUIRED_OS_NAME and > REQUIRED_OS_VERSION in platform.m4 on AIX. Until now this didn't hurt > but with the upcoming integration of the jigsaw changes from the jake > repository the content of these variables is used during the build for > calling the jmod tool. > > Thank you and best regards, > Volker From volker.simonis at gmail.com Wed Mar 9 10:30:10 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 9 Mar 2016 11:30:10 +0100 Subject: RFR (XXS): 8151497: Set REQUIRED_OS_NAME and REQUIRED_OS_VERSION on AIX In-Reply-To: <56DFF70C.8030000@oracle.com> References: <56DFF70C.8030000@oracle.com> Message-ID: Great! Thanks a lot, Volker On Wed, Mar 9, 2016 at 11:12 AM, Erik Joelsson wrote: > Looks good, I will push it. > /Erik > > > On 2016-03-09 10:39, Volker Simonis wrote: >> >> Hi, >> >> can I please have a review and sponsor (because this change requires >> the recreation of generated-configure.sh) for this trivial fix: >> >> http://cr.openjdk.java.net/~simonis/webrevs/2016/8151497/ >> https://bugs.openjdk.java.net/browse/JDK-8151497 >> >> For some reason we've never set REQUIRED_OS_NAME and >> REQUIRED_OS_VERSION in platform.m4 on AIX. Until now this didn't hurt >> but with the upcoming integration of the jigsaw changes from the jake >> repository the content of these variables is used during the build for >> calling the jmod tool. >> >> Thank you and best regards, >> Volker > > From jesper.wilhelmsson at oracle.com Wed Mar 9 13:06:30 2016 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Wed, 9 Mar 2016 14:06:30 +0100 Subject: CFV: New JDK 9 Committer: Derek White In-Reply-To: <56DFD51A.9090908@oracle.com> References: <56DFD51A.9090908@oracle.com> Message-ID: <56E01FD6.1040106@oracle.com> Vote: yes /Jesper Den 9/3/16 kl. 08:47, skrev Bengt Rutisson: > I hereby nominate Derek White (drwhite) to JDK 9 Committer. > > Derek is a member of the Hotspot GC team and has contributed 13 changes [3] to > the OpenJDK hotspot repository. > > Votes are due by 9:00 AM CET, Wednesday March 23, 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] > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/log?revcount=1000&rev=author%28%22drwhite%22%29+and+not+merge%28%29 > From eric.caspole at oracle.com Wed Mar 9 14:10:12 2016 From: eric.caspole at oracle.com (Eric Caspole) Date: Wed, 9 Mar 2016 09:10:12 -0500 Subject: CFV: New JDK 9 Committer: Derek White In-Reply-To: <56DFD51A.9090908@oracle.com> References: <56DFD51A.9090908@oracle.com> Message-ID: <56E02EC4.4050007@oracle.com> Vote: Yes Eric On 3/9/2016 2:47 AM, Bengt Rutisson wrote: > I hereby nominate Derek White (drwhite) to JDK 9 Committer. > > Derek is a member of the Hotspot GC team and has contributed 13 > changes [3] to the OpenJDK hotspot repository. > > Votes are due by 9:00 AM CET, Wednesday March 23, 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] > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/log?revcount=1000&rev=author%28%22drwhite%22%29+and+not+merge%28%29 From Roger.Riggs at Oracle.com Wed Mar 9 14:34:03 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Wed, 9 Mar 2016 09:34:03 -0500 Subject: CFV: New JDK 9 Committer: Derek White In-Reply-To: <56DFD51A.9090908@oracle.com> References: <56DFD51A.9090908@oracle.com> Message-ID: <56E0345B.3040008@Oracle.com> Vote: Yes On 3/9/2016 2:47 AM, Bengt Rutisson wrote: > I hereby nominate Derek White (drwhite) to JDK 9 Committer. From joseph.provino at oracle.com Wed Mar 9 14:44:53 2016 From: joseph.provino at oracle.com (Joseph Provino) Date: Wed, 9 Mar 2016 09:44:53 -0500 Subject: CFV: New JDK 9 Committer: Derek White In-Reply-To: <56DFD51A.9090908@oracle.com> References: <56DFD51A.9090908@oracle.com> Message-ID: <56E036E5.9090901@oracle.com> Vote: yes On 3/9/2016 2:47 AM, Bengt Rutisson wrote: > I hereby nominate Derek White (drwhite) to JDK 9 Committer. > > Derek is a member of the Hotspot GC team and has contributed 13 > changes [3] to the OpenJDK hotspot repository. > > Votes are due by 9:00 AM CET, Wednesday March 23, 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] > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/log?revcount=1000&rev=author%28%22drwhite%22%29+and+not+merge%28%29 From serguei.spitsyn at oracle.com Wed Mar 9 15:18:21 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 9 Mar 2016 07:18:21 -0800 Subject: CFV: New JDK 9 Committer: Derek White In-Reply-To: <56DFD51A.9090908@oracle.com> References: <56DFD51A.9090908@oracle.com> Message-ID: <56E03EBD.4000707@oracle.com> Vote: yes From jon.masamitsu at oracle.com Wed Mar 9 15:28:22 2016 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Wed, 9 Mar 2016 07:28:22 -0800 Subject: CFV: New JDK 9 Committer: Derek White In-Reply-To: <56DFD51A.9090908@oracle.com> References: <56DFD51A.9090908@oracle.com> Message-ID: <56E04116.9040204@oracle.com> Vote: yes On 3/8/2016 11:47 PM, Bengt Rutisson wrote: > I hereby nominate Derek White (drwhite) to JDK 9 Committer. > > Derek is a member of the Hotspot GC team and has contributed 13 > changes [3] to the OpenJDK hotspot repository. > > Votes are due by 9:00 AM CET, Wednesday March 23, 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] > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/log?revcount=1000&rev=author%28%22drwhite%22%29+and+not+merge%28%29 From stefan.karlsson at oracle.com Wed Mar 9 17:44:20 2016 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Wed, 9 Mar 2016 18:44:20 +0100 Subject: CFV: New JDK 9 Committer: Derek White In-Reply-To: <56DFD51A.9090908@oracle.com> References: <56DFD51A.9090908@oracle.com> Message-ID: <56E060F4.4080009@oracle.com> Vote: yes StefanK On 2016-03-09 08:47, Bengt Rutisson wrote: > I hereby nominate Derek White (drwhite) to JDK 9 Committer. > > Derek is a member of the Hotspot GC team and has contributed 13 > changes [3] to the OpenJDK hotspot repository. > > Votes are due by 9:00 AM CET, Wednesday March 23, 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] > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/log?revcount=1000&rev=author%28%22drwhite%22%29+and+not+merge%28%29 From vladimir.kozlov at oracle.com Wed Mar 9 17:46:12 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 9 Mar 2016 09:46:12 -0800 Subject: CFV: New JDK 9 Committer: Derek White In-Reply-To: <56DFD51A.9090908@oracle.com> References: <56DFD51A.9090908@oracle.com> Message-ID: <56E06164.9000608@oracle.com> Vote: yes On 3/8/16 11:47 PM, Bengt Rutisson wrote: > I hereby nominate Derek White (drwhite) to JDK 9 Committer. > > Derek is a member of the Hotspot GC team and has contributed 13 changes > [3] to the OpenJDK hotspot repository. > > Votes are due by 9:00 AM CET, Wednesday March 23, 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] > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/log?revcount=1000&rev=author%28%22drwhite%22%29+and+not+merge%28%29 > From sangheon.kim at oracle.com Wed Mar 9 17:54:58 2016 From: sangheon.kim at oracle.com (sangheon) Date: Wed, 9 Mar 2016 09:54:58 -0800 Subject: CFV: New JDK 9 Committer: Derek White In-Reply-To: <56DFD57C.8070802@oracle.com> References: <56DFD51A.9090908@oracle.com> <56DFD57C.8070802@oracle.com> Message-ID: <56E06372.2020808@oracle.com> Vote: yes Thanks, Sangheon On 03/08/2016 11:49 PM, Bengt Rutisson wrote: > Corrected the signature... > > On 2016-03-09 08:47, Bengt Rutisson wrote: >> I hereby nominate Derek White (drwhite) to JDK 9 Committer. >> >> Derek is a member of the Hotspot GC team and has contributed 13 >> changes [3] to the OpenJDK hotspot repository. >> >> Votes are due by 9:00 AM CET, Wednesday March 23, 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]. >> >> Bengt Rutisson >> >> [1] http://openjdk.java.net/census >> [2] http://openjdk.java.net/projects/#committer-vote >> [3] >> http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/log?revcount=1000&rev=author%28%22drwhite%22%29+and+not+merge%28%29 > From Peter.B.Kessler at Oracle.COM Wed Mar 9 18:17:22 2016 From: Peter.B.Kessler at Oracle.COM (Peter B. Kessler) Date: Wed, 09 Mar 2016 10:17:22 -0800 Subject: CFV: New JDK 9 Committer: Derek White In-Reply-To: <56DFD51A.9090908@oracle.com> References: <56DFD51A.9090908@oracle.com> Message-ID: <56E068B2.3030006@Oracle.COM> Vote: yes From max.ockner at oracle.com Wed Mar 9 18:58:49 2016 From: max.ockner at oracle.com (Max Ockner) Date: Wed, 09 Mar 2016 13:58:49 -0500 Subject: Fwd: CFV: New JDK 9 Committer: Chris Plummer In-Reply-To: <2BC2C52F-4FD1-422F-AAEF-E35605E6BC1C@oracle.com> References: <56CF669C.6080108@oracle.com> <2BC2C52F-4FD1-422F-AAEF-E35605E6BC1C@oracle.com> Message-ID: <56E07269.20407@oracle.com> Vote: yes Max Ockner On 3/9/2016 1:47 PM, Karen Kinnear wrote: > > >> Begin forwarded message: >> >> *From: *Coleen Phillimore > > >> *Subject: **CFV: New JDK 9 Committer: Chris Plummer* >> *Date: *February 25, 2016 at 3:39:56 PM EST >> *To: *jdk9-dev at openjdk.java.net >> >> 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 lana.steuck at oracle.com Wed Mar 9 20:25:52 2016 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 9 Mar 2016 12:25:52 -0800 (PST) Subject: jdk9-b109: dev Message-ID: <201603092025.u29KPqYo025361@sc11152554.us.oracle.com> http://hg.openjdk.java.net/jdk9/jdk9/rev/1787bdaabb2b http://hg.openjdk.java.net/jdk9/jdk9/nashorn/rev/70f0c3970211 http://hg.openjdk.java.net/jdk9/jdk9/langtools/rev/f5991c73ed73 http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/1c7bad079890 http://hg.openjdk.java.net/jdk9/jdk9/jaxws/rev/4b0697e4ce89 http://hg.openjdk.java.net/jdk9/jdk9/jaxp/rev/24e247ee1fff http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/7e7e50ac4faf http://hg.openjdk.java.net/jdk9/jdk9/corba/rev/b75afa17aefe --- All the fixes will be tested during promotion (no PIT testing at this point): List of all fixes: =================== JDK-8150067 client-libs Quarantine GcCapacityTest.java JDK-8150998 client-libs Fix module dependences in java/lang tests JDK-6842353 core-libs Linux testcase failure java/util/WeakHashMap/GCDuringIteration.java JDK-8038330 core-libs tools/jar/JarEntryTime.java fails intermittently on checking extracted JDK-8072727 core-libs add variation of Stream.iterate() that's finite JDK-8087104 core-libs DateFormatSymbols triggers this.clone() in the constructor JDK-8147505 core-libs BaseStream.onClose() should not allow registering new handlers after s JDK-8148148 core-libs Remove pluggable CodeStore API JDK-8148609 core-libs socket impl supportedOptions() should return an immutable set JDK-8148820 core-libs Missing @since Javadoc tag in Logger.log(Level, Supplier) JDK-8149330 core-libs Capacity of StringBuilder should not get close to Integer.MAX_VALUE un JDK-8149596 core-libs Remove java.nio.Bits copy wrapper methods JDK-8150162 core-libs Move sun.misc.Version to a truly internal package JDK-8150319 core-libs [TESTBUG] ScheduledExecutorTest:testFixedDelaySequence timeout with sl JDK-8150346 core-libs java/lang/ProcessHandle/Infotest.java failed: startTime after process JDK-8150416 core-libs Miscellaneous changes imported from jsr166 CVS 2016-03 JDK-8150417 core-libs Make ThreadLocalRandom more robust against static initialization cycle JDK-8150521 core-libs SharedSecrets.getJavaNetInetAddressAccess should ensure that InetAddre JDK-8150523 core-libs improve jtreg test timeout handling, especially -timeout: JDK-8150635 core-libs j.l.i.MethodHandles.loop(...) throws IndexOutOfBoundsException JDK-8150832 core-libs split T8139885 into several tests by functionality JDK-8150856 core-libs Inconsistent API documentation for @param caller in System.LoggerFinde JDK-8150953 core-libs j.l.i.MethodHandles: 'example' section in whileLoop(...) provides exam JDK-8150957 core-libs j.l.i.MethodHandles.whileLoop(...) fails with IOOBE in the case 'init' JDK-8150976 core-libs JarFile and MRJAR tests should use the JDK specific Version API JDK-8151140 core-libs Replace use of lambda/method ref in jdk.Version constructor JDK-8151226 core-libs Mark UdpTest.java as intermittently failing JDK-8151263 core-libs Mark java/rmi test LeaseCheckInterval.java as intermittently failing JDK-8151286 core-libs Remove intermittent key from TestLocalTime.java and move back to tier1 JDK-8151339 core-libs Adding fragment to JAR URLs breaks ant JDK-8151393 core-libs Revert changes for JDK-8087104 JDK-8147610 core-svc javax/management/mxbean/MXBeanLoadingTest1.java assumes URLClassLoader JDK-8151348 core-svc quarantine compiler/codecache/jmx/PeakUsageTest.java in JDK9-dev JDK-8132743 deploy Move netscape.javascript package from jdk.plugin to new module JDK-8143245 hotspot Zero build requires disabled warnings JDK-8144578 hotspot TestOptionsWithRanges test only ever uses the default collector JDK-8146187 hotspot Print develop and nonproduct flags by -XX:+PrintFlags* options in debu JDK-8146728 hotspot TestPrintGCDetailsVerbose is never run by jtreg JDK-8146989 hotspot Introduce per-worker preserved mark stacks in ParNew JDK-8147388 hotspot Add diagnostic commands to attach JVMTI agent. JDK-8148219 hotspot Add decorator hostname to UL JDK-8148630 hotspot Convert TraceStartupTime to Unified Logging JDK-8149013 hotspot Remove unused and dead code from G1CollectorPolicy JDK-8149383 hotspot Convert TraceBiasedLocking to Unified Logging JDK-8149643 hotspot Remove check of counters in VirtualSpaceNode::inc_container_count JDK-8149793 hotspot DirtyCardQueueSet::apply_closure_to_completed_buffer_helper isn't help JDK-8149837 hotspot String.intern creates more work than necessary for G1 JDK-8150079 hotspot MSVC prior to VS 2013 doesn't know the 'va_copy' macro JDK-8150134 hotspot Simplify concurrent refinement thread deactivation JDK-8150201 hotspot Restore missing -g flags to files with OPT_CFLAGS/per-file JDK-8150232 hotspot AIX cleanup: Integrate changes of 7178026 and others JDK-8150302 hotspot Reference processing logging prints the "from list" incorrectly JDK-8150367 hotspot Add back information about the number of GC workers JDK-8150379 hotspot [windows] Fix Leaks in perfMemory_windows.cpp JDK-8150562 hotspot Quarantine LoadAgentDcmdTest.java due to JDK-8150318 JDK-8150647 hotspot Quarantine TestPLABResize.java until JDK-8150183 is fixed JDK-8151156 hotspot [TESTBUG] Integrate trivial Hotspot test changes from Jake before Jigs JDK-8151297 infrastructure Class name change for CLDRLocaleDataMetaInfo_jdk_localedata needs upda JDK-8151300 infrastructure Build shell trace functionality lost in JDK-8076060 JDK-8151302 infrastructure Attempt at silencing build log broke html32.bdtd JDK-8138653 security-libs Default key sizes for the AlgorithmParameterGenerator and KeyPairGener JDK-8151149 security-libs CipherSpi implementation of PBEWithSHA1AndDESede returns key size in JDK-8151225 security-libs Mark SpecTest.java as intermittently failing JDK-8151228 security-libs Mark TestDSAGenParameterSpec.java as intermittently failing JDK-8061320 tools Sjavac should prevent using source dir as dest dir JDK-8148930 tools Incorrect erasure of exceptions in override-equivalent dual interface JDK-8148985 tools javadoc "FRAMES" and "NO FRAMES" links not working correctly JDK-8150000 tools Javadoc omits package listing for type JDK-8150130 tools NPE building javafx docs with new doclet JDK-8150895 tools Fix bug id in test for JDK-8149842 JDK-8150941 tools Sjavac should not wait for portfile to materialize if server process i JDK-8151016 tools Migrate asserts introduced in Valhalla code generation to JDK9 dev JDK-8151018 tools javac should emit a clearer diagnostic when a <> inferred anonymous ty JDK-8151134 tools Fix bug id in test for JDK-8151018 JDK-8151141 tools Sjavac fails to fork server on Windows JDK-8150174 xml Update JAX-WS RI integration to latest version (2.3.0-SNAPSHOT) From coleen.phillimore at oracle.com Wed Mar 9 23:53:13 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 9 Mar 2016 18:53:13 -0500 Subject: CFV: New JDK 9 Committer: Derek White In-Reply-To: <56DFD51A.9090908@oracle.com> References: <56DFD51A.9090908@oracle.com> Message-ID: <56E0B769.60200@oracle.com> Vote: yes On 3/9/16 2:47 AM, Bengt Rutisson wrote: > I hereby nominate Derek White (drwhite) to JDK 9 Committer. > > Derek is a member of the Hotspot GC team and has contributed 13 > changes [3] to the OpenJDK hotspot repository. > > Votes are due by 9:00 AM CET, Wednesday March 23, 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] > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/log?revcount=1000&rev=author%28%22drwhite%22%29+and+not+merge%28%29 From karen.kinnear at oracle.com Thu Mar 10 03:18:19 2016 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Wed, 9 Mar 2016 22:18:19 -0500 Subject: CFV: New JDK 9 Committer: Derek White In-Reply-To: <56DFD57C.8070802@oracle.com> References: <56DFD51A.9090908@oracle.com> <56DFD57C.8070802@oracle.com> Message-ID: <012FF4DD-EBFC-4645-B69C-71C378D12D55@oracle.com> Vote: yes thanks, Karen > On Mar 9, 2016, at 2:49 AM, Bengt Rutisson wrote: > > Corrected the signature... > > On 2016-03-09 08:47, Bengt Rutisson wrote: >> I hereby nominate Derek White (drwhite) to JDK 9 Committer. >> >> Derek is a member of the Hotspot GC team and has contributed 13 changes [3] to the OpenJDK hotspot repository. >> >> Votes are due by 9:00 AM CET, Wednesday March 23, 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]. >> >> Bengt Rutisson >> >> [1] http://openjdk.java.net/census >> [2] http://openjdk.java.net/projects/#committer-vote >> [3] http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/log?revcount=1000&rev=author%28%22drwhite%22%29+and+not+merge%28%29 > From alejandro.murillo at oracle.com Thu Mar 10 04:16:12 2016 From: alejandro.murillo at oracle.com (Alejandro E Murillo) Date: Wed, 9 Mar 2016 21:16:12 -0700 Subject: CFV: New JDK 9 Committer: Derek White In-Reply-To: <56DFD51A.9090908@oracle.com> References: <56DFD51A.9090908@oracle.com> Message-ID: <56E0F50C.2030907@oracle.com> vote: yes On 3/9/2016 12:47 AM, Bengt Rutisson wrote: > I hereby nominate Derek White (drwhite) to JDK 9 Committer. > > -- Alejandro From erik.helin at oracle.com Thu Mar 10 10:10:08 2016 From: erik.helin at oracle.com (Erik Helin) Date: Thu, 10 Mar 2016 11:10:08 +0100 Subject: CFV: New JDK 9 Committer: Derek White In-Reply-To: <56DFD51A.9090908@oracle.com> References: <56DFD51A.9090908@oracle.com> Message-ID: <20160310101008.GE6117@ehelin.jrpg.bea.com> Vote: yes On 2016-03-09, Bengt Rutisson wrote: > I hereby nominate Derek White (drwhite) to JDK 9 Committer. > > Derek is a member of the Hotspot GC team and has contributed 13 changes [3] > to the OpenJDK hotspot repository. > > Votes are due by 9:00 AM CET, Wednesday March 23, 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] http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/log?revcount=1000&rev=author%28%22drwhite%22%29+and+not+merge%28%29 From mark.reinhold at oracle.com Thu Mar 10 21:51:54 2016 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 10 Mar 2016 13:51:54 -0800 Subject: JEPs proposed to target JDK 9 (2016/3/10) Message-ID: <20160310135154.649744865eggemoggin.niobe.net> The following JEPs have been placed into the "Proposed to Target" state by their owners after discussion and review: 200: The Modular JDK http://openjdk.java.net/jeps/200 260: Encapsulate Most Internal APIs http://openjdk.java.net/jeps/260 261: Module System http://openjdk.java.net/jeps/261 275: Modular Java Application Packaging http://openjdk.java.net/jeps/275 282: jlink: The Java Linker http://openjdk.java.net/jeps/282 284: New HotSpot Build System http://openjdk.java.net/jeps/284 285: Spin-Wait Hints http://openjdk.java.net/jeps/285 The following JEP has been placed into the "Proposed to Drop" state by its owner: 230: Microbenchmark Suite http://openjdk.java.net/jeps/230 Feedback on these proposals is more than welcome, as are reasoned objections. If no such objections are raised by 22:00 UTC next Thursday, 17 March, or if they're raised and then satisfactorily answered, then per the JEP 2.0 process proposal [1] I'll target these JEPs to JDK 9. (This information is also available on the JDK 9 Project Page [2]). - Mark [1] http://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html [2] http://openjdk.java.net/projects/jdk9/ From volker.simonis at gmail.com Fri Mar 11 09:30:35 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 11 Mar 2016 10:30:35 +0100 Subject: JEPs proposed to target JDK 9 (2016/3/10) In-Reply-To: <56e1eca1.971f620a.728f1.ffffbd65SMTPIN_ADDED_BROKEN@mx.google.com> References: <56e1eca1.971f620a.728f1.ffffbd65SMTPIN_ADDED_BROKEN@mx.google.com> Message-ID: On Thu, Mar 10, 2016 at 10:51 PM, wrote: > The following JEPs have been placed into the "Proposed to Target" > state by their owners after discussion and review: > > 200: The Modular JDK > http://openjdk.java.net/jeps/200 > > 260: Encapsulate Most Internal APIs > http://openjdk.java.net/jeps/260 > > 261: Module System > http://openjdk.java.net/jeps/261 > > 275: Modular Java Application Packaging > http://openjdk.java.net/jeps/275 > > 282: jlink: The Java Linker > http://openjdk.java.net/jeps/282 > > 284: New HotSpot Build System > http://openjdk.java.net/jeps/284 > > 285: Spin-Wait Hints > http://openjdk.java.net/jeps/285 > > The following JEP has been placed into the "Proposed to Drop" > state by its owner: > > 230: Microbenchmark Suite > http://openjdk.java.net/jeps/230 > Is there any place where I can get information on why this has been placed into "Proposed to Drop" state? Is it just a time/resources problem for jdk9 or is the plan to completely withdraw JEP 230? Regards, Volker > Feedback on these proposals is more than welcome, as are reasoned > objections. If no such objections are raised by 22:00 UTC next > Thursday, 17 March, or if they're raised and then satisfactorily > answered, then per the JEP 2.0 process proposal [1] I'll target > these JEPs to JDK 9. > > (This information is also available on the JDK 9 Project Page [2]). > > - Mark > > > [1] http://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html > [2] http://openjdk.java.net/projects/jdk9/ From coleen.phillimore at oracle.com Fri Mar 11 13:29:12 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 11 Mar 2016 08:29:12 -0500 Subject: Result: CFV: New JDK 9 Committer: Chris Plummer In-Reply-To: <56CF669C.6080108@oracle.com> References: <56CF669C.6080108@oracle.com> Message-ID: <56E2C828.8030207@oracle.com> Voting for Chris Plummer (cjplummer) [1] is now closed. Yes: 37 Veto: 0 Abstain: 0 According to the Bylaws definition of Three-Vote Consensus, this is sufficient to approve the nomination. Coleen Phillimore [1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-February/003773.html From Alan.Bateman at oracle.com Fri Mar 11 14:49:14 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 11 Mar 2016 14:49:14 +0000 Subject: Project Jigsaw integration into JDK 9 Message-ID: <56E2DAEA.60609@oracle.com> Those on jigsaw-dev will be aware [1] that we have been planning to integrate a snapshot of the changes from the jigsaw/jake forest into JDK 9. More specifically, we are proposing to stabilize a snapshot of the module system that we have been working on in Project Jigsaw and integrate it into the JDK 9 main line. Once integrated then we will continue in Project Jigsaw on the remaining areas and issues. In terms of JEPs then this integration is JEP 200 [2], JEP 260 [3], JEP 261 [4] and JEP 282 [5]. In the case of JEP 260 then JDK internal APIs will be encapsulated with the work to get us to a jdk.unsupported module ongoing. In terms of the JCP then JSR 376 is the JSR that is defining the Java Platform Module System and is what JEP 261 is implementing. The JSR is expected to submit an Early Draft Review soon. For those that have not been following the work in Project Jigsaw then the main project main page [6] has links to a lot of resources. If you only have time to read one document then make sure to read The State of the Module System [7] as that gives an informal overview of the proposal and design. If you have time to read a second document then put JEP 261 on your reading list. The Risks and Assumptions section of the JEP has the complete list of compatibility issues that we are aware of. For the integration then we are proposing to integrate during the week of March 21 for jdk-9+111. We are keeping the week of March 27 for jdk-9+112 as backup in the event of issues. The proposal is to integrate directly into jdk9/jdk9 (master) and then immediately sync up jdk9/dev with the other forests to follow. The rational for going directly into master is that this is a large change and we would like it to be the only change in the weekly build. This is our third major milestone on this project, we integrated directly in master for the previous two milestones (JEP 201 and JEP 220) too. Code review [8] is ongoing and we expect to be iterating on the changes into next week so that we get the changes into a reasonable state to bring into JDK 9. Many people are involved to ensure that we have at least some coverage in all areas and repositories. I will send an update closer to the proposed integration date once it clearer whether we can make jdk-9+111. -Alan [1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-March/006484.html [2] http://openjdk.java.net/jeps/200 [3] http://openjdk.java.net/jeps/260 [4] http://openjdk.java.net/jeps/261 [5] http://openjdk.java.net/jeps/282 [6] http://openjdk.java.net/projects/jigsaw/ [7] http://openjdk.java.net/projects/jigsaw/spec/sotms/ [8] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-March/006525.html From coleen.phillimore at oracle.com Fri Mar 11 16:27:30 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 11 Mar 2016 11:27:30 -0500 Subject: Result: CFV: New JDK 9 Committer: Chris Plummer In-Reply-To: <56E2C828.8030207@oracle.com> References: <56CF669C.6080108@oracle.com> <56E2C828.8030207@oracle.com> Message-ID: <56E2F1F1.80506@oracle.com> Voting for Chris Plummer (cjplummer) [1] is now closed. Yes: 37 Veto: 0 Abstain: 0 According to the Bylaws definition of Three-Vote Consensus, this is sufficient to approve the nomination. Coleen Phillimore [1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-February/003773.html From mikael.vidstedt at oracle.com Fri Mar 11 18:33:55 2016 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Fri, 11 Mar 2016 10:33:55 -0800 Subject: JEPs proposed to target JDK 9 (2016/3/10) In-Reply-To: References: <56e1eca1.971f620a.728f1.ffffbd65SMTPIN_ADDED_BROKEN@mx.google.com> Message-ID: <56E30F93.60505@oracle.com> On 3/11/2016 1:30 AM, Volker Simonis wrote: > On Thu, Mar 10, 2016 at 10:51 PM, wrote: >> The following JEPs have been placed into the "Proposed to Target" >> state by their owners after discussion and review: >> >> 200: The Modular JDK >> http://openjdk.java.net/jeps/200 >> >> 260: Encapsulate Most Internal APIs >> http://openjdk.java.net/jeps/260 >> >> 261: Module System >> http://openjdk.java.net/jeps/261 >> >> 275: Modular Java Application Packaging >> http://openjdk.java.net/jeps/275 >> >> 282: jlink: The Java Linker >> http://openjdk.java.net/jeps/282 >> >> 284: New HotSpot Build System >> http://openjdk.java.net/jeps/284 >> >> 285: Spin-Wait Hints >> http://openjdk.java.net/jeps/285 >> >> The following JEP has been placed into the "Proposed to Drop" >> state by its owner: >> >> 230: Microbenchmark Suite >> http://openjdk.java.net/jeps/230 >> > Is there any place where I can get information on why this has been > placed into "Proposed to Drop" state? Is it just a time/resources > problem for jdk9 or is the plan to completely withdraw JEP 230? As you guessed this is a time/resource problem. Given that the JDK 9 FC date is coming up fast we feel that it is not realistic to get the whole project finished up and pushed in time. I do think and hope that this can be picked up and targeted to an upcoming release instead, the sooner the better. Hope this helps, Mikael > > Regards, > Volker > > >> Feedback on these proposals is more than welcome, as are reasoned >> objections. If no such objections are raised by 22:00 UTC next >> Thursday, 17 March, or if they're raised and then satisfactorily >> answered, then per the JEP 2.0 process proposal [1] I'll target >> these JEPs to JDK 9. >> >> (This information is also available on the JDK 9 Project Page [2]). >> >> - Mark >> >> >> [1] http://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html >> [2] http://openjdk.java.net/projects/jdk9/ From kim.barrett at oracle.com Sun Mar 13 04:07:50 2016 From: kim.barrett at oracle.com (Kim Barrett) Date: Sat, 12 Mar 2016 23:07:50 -0500 Subject: CFV: New JDK 9 Committer: Derek White In-Reply-To: <56DFD51A.9090908@oracle.com> References: <56DFD51A.9090908@oracle.com> Message-ID: vote: yes From lana.steuck at oracle.com Mon Mar 14 16:00:08 2016 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Mon, 14 Mar 2016 09:00:08 -0700 (PDT) Subject: jdk9-b110: dev Message-ID: <201603141600.u2EG088s008990@sc11152554.us.oracle.com> http://hg.openjdk.java.net/jdk9/jdk9/rev/925be13b3740 http://hg.openjdk.java.net/jdk9/jdk9/nashorn/rev/9937077e48f1 http://hg.openjdk.java.net/jdk9/jdk9/langtools/rev/9b4c916633f8 http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/9417e1bcded6 http://hg.openjdk.java.net/jdk9/jdk9/jaxws/rev/0db939c930f3 http://hg.openjdk.java.net/jdk9/jdk9/jaxp/rev/1c1bb661d35b http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/2f5d1578b240 http://hg.openjdk.java.net/jdk9/jdk9/corba/rev/9666775734fb --- All the fixes will be tested during promotion (no PIT testing at this point): List of all fixes: =================== JDK-7126823 client-libs JInternalFrame.getNormalBounds() returns bad value after iconify/deico JDK-8020039 client-libs SynthTableHeaderUI refers to possibly null parameter in cell renderer JDK-8025001 client-libs setFocusTraversalPolicy() to ContainerOrderFocusTraversalPolicy result JDK-8038139 client-libs AudioInputStream.getFrameLength() returns wrong value for floating-poi JDK-8044788 client-libs [D3D] clip is ignored during surface->sw blit JDK-8058316 client-libs lookupDefaultPrintService returns null on Solaris 11 when default prin JDK-8081722 client-libs Provide public access to sun.awt.shell.ShellFolder methods which are r JDK-8131751 client-libs [TEST_BUG] Test javax/swing/plaf/gtk/crash/RenderBadPictureCrash.java JDK-8138749 client-libs Revisited: PrinterJob.printDialog() does not support multi-mon, always JDK-8139508 client-libs Debug option does not work in appletviewer JDK-8146321 client-libs [macosx] JInternalFrame frame icon in wrong position on Mac L&F if ico JDK-8147834 client-libs [macosx] KeyEvents for function keys F17, F18, F19 return keyCode 0 JDK-8147839 client-libs Synthetically Bolded Fonts are Stretched Vertically under rotation. JDK-8147994 client-libs [macosx] JScrollPane jitters up/down during trackpad scrolling on MacO JDK-8148886 client-libs SEGV in sun.java2d.marlin.Renderer._endRendering JDK-8149338 client-libs JVM Crash caused by Marlin renderer not handling NaN coordinates JDK-8149593 client-libs Change foo to {@code foo} in TIFF plugin classes JDK-8150233 client-libs Missing copyright headers in XSurfaceData/ExtendedKeyCodes JDK-8150258 client-libs [TEST] HiDPI: create a test for multiresolution menu item icons JDK-8150643 client-libs [TEST] add test for JDK-8150176 JDK-8043329 core-libs Wrong variable used in java.util.Collections javadoc code JDK-8138906 core-libs [TEST_BUG] Test test/script/trusted/JDK-8087292.js intermittently fail JDK-8143610 core-libs (dc) java/nio/channels/DatagramChannel/AdaptDatagramSocket.java failed JDK-8149925 core-libs We don't need jdk.internal.ref.Cleaner any more JDK-8151063 core-libs Typo in java.lang.invoke.StringConcatFactory javadoc JDK-8151065 core-libs Typo in javax.naming.CompoundName JDK-8151260 core-libs Mark URLPermission/URLTest.java and ipv6tests/TcpTest.java as intermit JDK-8151291 core-libs $EXEC yields "unknown command" on Cygwin JDK-8151299 core-libs Http client SelectorManager overwriting read and write events JDK-8151352 core-libs jdk/test/sample fails with "effective library path is outside the test JDK-8151384 core-libs Improve String.CASE_INSENSITIVE_ORDER and remove sun.misc.ASCIICaseIns JDK-8151441 core-libs Completion result in httpclient Exchange.java lost JDK-8151515 core-libs $EXEC output is truncated JDK-8151518 core-libs relax test requirements to reduce dependency on directory contents JDK-8151660 core-libs Revert NativeBuffer.java to use jdk.internal.ref.Cleaner JDK-8151100 core-svc Test java/lang/instrument/NativeMethodPrefixAgent.java can't attempt t JDK-8044212 deploy NPE in CPCallbackHandler.isAuthenticated JDK-8148866 deploy Copyright cleanup project (deploy part) JDK-8149497 deploy cannot relaunch to alternate architecture JDK-7177745 hotspot JSR292: Many Callsite relinkages cause target method to always run in JDK-8007986 hotspot GrowableArray should implement binary search JDK-8058944 hotspot Unify the reporting strings for the GC debug level logging in G1 JDK-8066814 hotspot Reduce accessibility in TraceEvent JDK-8067014 hotspot LinearScan::is_sorted significantly slows down fastdebug builds' perfo JDK-8068038 hotspot C2: large constant offsets aren't handled on SPARC JDK-8069160 hotspot serviceability/dcmd/compiler/CompilerQueueTest.java fails due to class JDK-8076463 hotspot Add logging for the preserve CM referents task JDK-8087341 hotspot C2 doesn't optimize redundant memory operations with G1 JDK-8130425 hotspot libjvm crash due to stack overflow in executables with 32k tbss/tdata JDK-8134119 hotspot Use new API to get cache line sizes JDK-8134992 hotspot vm/gc/compact/Compact_InternedStrings_Strings failed due to a malloc() JDK-8139651 hotspot ConcurrentG1Refine uses ints for many of its members that should be un JDK-8140600 hotspot Convert unnecessarily malloc'd Monitors to value members JDK-8140777 hotspot Make Adaptive IHOP logging information the same as JFR logging JDK-8141141 hotspot Young and Old gen PLAB stats are similar in output with -XX:+PrintPLAB JDK-8141616 hotspot Add new methods to the java Whitebox API JDK-8141618 hotspot Change JVMCI compilerToVM constant pool tests to support CP cache JDK-8141619 hotspot Develop new tests for JVMCI compilerToVM class' CP related methods JDK-8143226 hotspot Minor updates to Event Based tracing JDK-8143228 hotspot Update module exports for Java Flight Recorder JDK-8143235 hotspot Remove libjfr mapfile JDK-8144732 hotspot VM_HeapDumper hits assert with bad dump_len JDK-8145098 hotspot JNI GetVersion should return JNI_VERSION_9 JDK-8145333 hotspot -XX:+EnableJVMCI -XX:+UseJVMCICompiler -XX:-EnableJVMCI makes JVM cras JDK-8146849 hotspot Remove TraceJNIHandleAllocation rather than converting to UL JDK-8147121 hotspot Evacuation failure allocation statistics added too late JDK-8147442 hotspot Event-based tracing to allow for tracing Klass creation JDK-8147978 hotspot Remove Method::_method_data for C1 JDK-8148146 hotspot Integrate new internal Unsafe entry points, and basic intrinsic suppor JDK-8148159 hotspot [TESTBUG] TestCompilerDirectivesCompatibility tests fails on non-tiere JDK-8148786 hotspot xml.transform fails on x86-64 JDK-8148940 hotspot java/lang/ref/FinalizeOverride.java can time out due to frequent safep JDK-8149036 hotspot Add tracing for thread related events at os level JDK-8149064 hotspot Convert TraceProtectionDomainVerification to Unified Logging. JDK-8149655 hotspot PPC64: Implement CompactString intrinsics JDK-8149733 hotspot AArch64: refactor array_equals/string_equals JDK-8149741 hotspot Don't refer to stub entry points by index in external_word relocations JDK-8149743 hotspot JVM crash after debugger hotswap with lambdas JDK-8149789 hotspot SIGSEGV in CompileTask::print JDK-8149907 hotspot aarch64: use load/store pair instructions in call_stub JDK-8149916 hotspot Test case for 8149797 JDK-8150002 hotspot Check for the validity of oop before printing it in verify_remembered_ JDK-8150038 hotspot aarch64: Make use of CBZ and CBNZ when comparing narrow pointer with z JDK-8150045 hotspot AArch64: arraycopy causes segfaults in SATB during garbage collection JDK-8150068 hotspot Log the main G1 phases at info level JDK-8150102 hotspot C1 should fold arraylength for constant/trusted arrays JDK-8150103 hotspot Convert TraceClassPaths to Unified Logging JDK-8150180 hotspot String.value contents should be trusted JDK-8150186 hotspot Folding mismatched accesses with @Stable is incorrect JDK-8150229 hotspot aarch64: pipeline class for several instructions is not set correctly JDK-8150237 hotspot Need a jtreg regression test for JDK-8149771 JDK-8150318 hotspot serviceability/dcmd/jvmti/LoadAgentDcmdTest.java - Could not find JDK JDK-8150349 hotspot Reduce the execution time of the hotspot_compiler_3 group JDK-8150390 hotspot Move rs length sampling data to the sampling thread JDK-8150419 hotspot Cleanup BufferNode API JDK-8150421 hotspot Delete experimental G1UseConcMarkReferenceProcessing JDK-8150426 hotspot Wrong cast in metadata_at_put JDK-8150436 hotspot Incorrect invocation mode when linkToInteface linker is eliminated JDK-8150441 hotspot CompileTask::print_impl() is broken after JDK-8146905 JDK-8150490 hotspot Update OS detection code to recognize Windows Server 2016 JDK-8150506 hotspot Remove unused locks JDK-8150514 hotspot C1 crashes in Canonicalizer::do_ArrayLength() after fix for JDK-815010 JDK-8150534 hotspot C1 compilation fails with "Constant field loads are folded during pars JDK-8150543 hotspot Mismatched access detection is inaccurate JDK-8150561 hotspot [AArch64] JVMCI improvements JDK-8150619 hotspot Improve thread based logging introduced with 8149036 JDK-8150629 hotspot Initializing all ParScanThreadStates causes significant unaccounted "O JDK-8150630 hotspot Add logging for ParScanThreadState merge phase JDK-8150720 hotspot Cleanup code around PrintOptoStatistics JDK-8150727 hotspot [JVMCI] add LoadLoad to the implicit memory barriers on AMD64 JDK-8150738 hotspot [JVMCI] runtime/CommandLine/TraceExceptionsTest.java fails with: java. JDK-8150746 hotspot runtime/logging/ItablesTest.java fails with: java.lang.RuntimeExceptio JDK-8150822 hotspot Fix typo in JDK-8150201 JDK-8150933 hotspot System::arraycopy intrinsic doesn't mark mismatched loads JDK-8150984 hotspot Invalid VM argument causes crash -XX:G1ConcRefinementServiceIntervalMi JDK-8150986 hotspot serviceability/sa/jmap-hprof/JMapHProfLargeHeapTest.java failing becau JDK-8151017 hotspot [TESTBUG] test/compiler/c1/CanonicalizeArrayLength does not work on pr JDK-8151020 hotspot [TESTBUG] UnsafeGetStableArrayElement::testL_* fail intermittently JDK-8151024 hotspot Remove TCKJapaneseChronology.java from the problem list JDK-8151053 hotspot com/sun/jdi/StepTest.java fails in 2016-03-01 JDK9-hs-rt nightly JDK-8151064 hotspot com/sun/jdi/RedefineAddPrivateMethod.sh fails intermittently JDK-8151130 hotspot [BACKOUT] Remove Method::_method_data for C1 JDK-8151157 hotspot Quarantine test/compiler/unsafe/UnsafeGetStableArrayElement.java JDK-8150723 infrastructure HSDB toolbar icons are missing. JDK-8151435 infrastructure Windows devkit missing 32bit msvcdis120.dll JDK-8151497 infrastructure Set REQUIRED_OS_NAME and REQUIRED_OS_VERSION on AIX JDK-8151685 infrastructure Fix the version of required jdk in configure help text JDK-8037248 install [Installer.patch] Add checksum check to baseimage JDK-8146056 install the fix for JDK-8145094 is incomplete to *.xml JDK-8148187 other-libs Remove OS X-specific com.apple.concurrent package JDK-8132942 security-libs ServerHandshaker should not throw SSLHandshakeException when Certifica JDK-8151313 security-libs Remove ProblemList test closed/javax/crypto/CryptoPermission/CallerIde JDK-8151679 security-libs Mark SignatureOffsets.java as intermittently failing. JDK-8080069 tools JShell: Support for corralled classes JDK-8139474 tools -release 7 -verbose causes Javac exception JDK-8148316 tools jshell tool: Configurable output format JDK-8148317 tools jshell tool: unify commands into /set JDK-8149139 tools [javadoc] Modify Content to accept CharSequence JDK-8149524 tools JShell: CompletenessAnalysis fails on class Case, JDK-8150632 tools jdk.jshell.TaskFactory should use jdk.Version to check for java.specif JDK-8151223 tools String concatenation fails with implicit toString() on package-private JDK-8151516 tools test/tools/javac/TestIndyStringConcat depends on runtime JDK details JDK-8151570 tools jtreg tests leave tty in bad state JDK-8150704 xml XALAN: ERROR: 'No more DTM IDs are available' when transforming with From tadamski at redhat.com Mon Mar 14 16:33:12 2016 From: tadamski at redhat.com (Tomasz Adamski) Date: Mon, 14 Mar 2016 12:33:12 -0400 (EDT) Subject: Proposing changes to OpenJDK corba component In-Reply-To: <2139090735.28593905.1457972815781.JavaMail.zimbra@redhat.com> Message-ID: <1130784930.28595072.1457973192101.JavaMail.zimbra@redhat.com> Hello everyone, I'm part of WildFly team. We are maintaining our ORB library which is downstream of OpenJDK corba component adding changes to it when it is necessary for our project. Part of those changes are universal though and I would like to propose them to OpenJDK. Can you please tell me what the procedure is and to whom can I talk about it? Best regards, Tomek -- Tomasz Adamski Software Engineer JBoss by Red Hat From alejandro.murillo at oracle.com Mon Mar 14 22:14:02 2016 From: alejandro.murillo at oracle.com (Alejandro E Murillo) Date: Mon, 14 Mar 2016 16:14:02 -0600 Subject: jdk9-dev: HotSpot Message-ID: <56E737AA.9030400@oracle.com> jdk9-hs-2016-03-10 has been integrated into jdk9-dev. http://hg.openjdk.java.net/jdk9/dev/rev/5d868c42d888 http://hg.openjdk.java.net/jdk9/dev/corba/rev/9666775734fb http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/96638b8bfdfa http://hg.openjdk.java.net/jdk9/dev/jaxp/rev/1c1bb661d35b http://hg.openjdk.java.net/jdk9/dev/jaxws/rev/0db939c930f3 http://hg.openjdk.java.net/jdk9/dev/jdk/rev/1640de0263f7 http://hg.openjdk.java.net/jdk9/dev/langtools/rev/9b4c916633f8 http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/9937077e48f1 Component : VM Status : Go for integration Date : 03/14/2016 at 16:00 MSK Tested By : VM SQE &dmitry.fazunenko at oracle.com Bundles : 2016-03-11-000922.amurillo.jdk9-hs-2016-03-10-snapshot Testing: 180 new failures, 2068 known failures, 393580 passed. Issues and Notes: No detailed analysis. No stoppers have been detected so far. Go for integration CRs for testing: 8140721: ProfilerNumberOf*Methods flags should be diagnostic. 8146801: Allocating short arrays of non-constant size is slow 8148563: compiler/compilercontrol/jcmd/StressAddMultiThreadedTest.java timesout 8149159: Clean up Unsafe 8150082: aarch64: optimise small array copy 8150313: aarch64: optimise array copy using SIMD instructions 8150353: PPC64LE: Support RTM on linux 8150394: aarch64: add support for 8.1 LSE CAS instructions 8150465: Unsafe methods to produce uninitialized arrays 8150669: C1 intrinsic for Class.isPrimitive 8150767: Enables SHA Extensions on x86 8150839: Adjust the number of compiler threads for 32-bit platforms 8151002: Make Assembler methods vextract and vinsert match actual instructions 8151266: HotSpotResolvedJavaFieldImpl::isStable() does not work as expected 8151340: aarch64: prefetch the destination word for write prior to ldxr/stxr loops. -- Alejandro From mikael.vidstedt at oracle.com Mon Mar 14 22:47:19 2016 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Mon, 14 Mar 2016 15:47:19 -0700 Subject: RFR(S): 8151233: Unify CopySwap and CopyMemory tests Message-ID: <56E73F77.8000203@oracle.com> Please review the below change. When doing the clean up of Unsafe I cheated and made a copy of the CopySwap test (used to test U.copySwapMemory) for testing U.copyMemory. Much of the code is the same, or at least similar enough, that duplication is unfortunate. This change moves the common code to a helper file CopyCommon.java, and makes both test files use that. Bug: https://bugs.openjdk.java.net/browse/JDK-8151233 Webrev: http://cr.openjdk.java.net/~mikael/webrevs/8151233/webrev.00/webrev/ Cheers, Mikael From akashche at redhat.com Mon Mar 14 23:37:29 2016 From: akashche at redhat.com (Alex Kashchenko) Date: Mon, 14 Mar 2016 23:37:29 +0000 Subject: RFR: JDK-8133206 - Higher native memory usage caused by upgrade to zlib 1.2.8 In-Reply-To: <5641CAA7.5040200@alexkasko.com> References: <5641CAA7.5040200@alexkasko.com> Message-ID: <56E74B39.8020003@redhat.com> Hi, On 11/10/2015 10:44 AM, Alex Kashchenko wrote: > Please review the following fix to JDK-8133206: > > - bug: https://bugs.openjdk.java.net/browse/JDK-8133206 > - webrev for jdk9: > http://cr.openjdk.java.net/~akasko/jdk9/8133206/webrev.00/ > > This fix is a forward-port of the patch to jdk7u created by Nikolay > Gorshkov: > > - webrev for jdk7u: > http://cr.openjdk.java.net/~nikgor/8133206/jdk7u-dev/webrev.01/ > - jdk7u review thread with the issue details: > http://mail.openjdk.java.net/pipermail/jdk7u-dev/2015-October/010420.html > - the same thread on core-libs-dev: > http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-October/035884.html > > > Forward-port to jdk9 is almost the same as original patch (with changed > paths), one additional inflate(...) call is changed in zip_util.c . > > jdk9 with this patch passes all the regression tests from java/util/jar, > java/util/zip, tools/jar and tools/pack200. > > I created a jtreg reproducer that works with jdk7u and jdk9: > > - web link: http://cr.openjdk.java.net/~akasko/jdk9/8133206/reproducer/ > - download: > http://cr.openjdk.java.net/~akasko/jdk9/8133206/reproducer.zip > > This reproducer is Linux-only, slow (takes more than a minute) and > requires Valgrind and zlib-debuginfo (if system zlib is used). It runs > java.util.zip.Inflater under the Memcheck multiple times and parses the > output to compare the number of zlib-specific memory allocations. I am > not sure whether such reproducer should be included into the jdk > regression tests tree, so publishing it as a standalone jtreg test (not > a webrev). > > Please let me know if I need to create a new bug for jdk9 (in addition > to JDK-8133206). This is a follow-up on a positive response to this patch: http://mail.openjdk.java.net/pipermail/jdk7u-dev/2016-March/010488.html Please review and sponsor the updated change: - updated webrev: http://cr.openjdk.java.net/~akasko/jdk9/8133206/webrev.01/ - issue for jdk9: https://bugs.openjdk.java.net/browse/JDK-8151848 Change tested with java/util/zip and tools/pack200 tests and a reproducer linked above on RHEL 7.2. -- -Alex From david.holmes at oracle.com Tue Mar 15 00:26:13 2016 From: david.holmes at oracle.com (David Holmes) Date: Tue, 15 Mar 2016 10:26:13 +1000 Subject: RFR(S): 8151233: Unify CopySwap and CopyMemory tests In-Reply-To: <56E73F77.8000203@oracle.com> References: <56E73F77.8000203@oracle.com> Message-ID: <56E756A5.8090703@oracle.com> Hi Mikael, On 15/03/2016 8:47 AM, Mikael Vidstedt wrote: > > Please review the below change. > > When doing the clean up of Unsafe I cheated and made a copy of the > CopySwap test (used to test U.copySwapMemory) for testing U.copyMemory. > Much of the code is the same, or at least similar enough, that > duplication is unfortunate. This change moves the common code to a > helper file CopyCommon.java, and makes both test files use that. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8151233 > Webrev: > http://cr.openjdk.java.net/~mikael/webrevs/8151233/webrev.00/webrev/ Is it worth using CopyCommon as a base class and also sharing the UNSAFE mechanics? Otherwise the refactoring seems okay. Thanks, David > Cheers, > Mikael > From mikael.vidstedt at oracle.com Tue Mar 15 18:33:04 2016 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Tue, 15 Mar 2016 11:33:04 -0700 Subject: RFR(S): 8151233: Unify CopySwap and CopyMemory tests In-Reply-To: <56E756A5.8090703@oracle.com> References: <56E73F77.8000203@oracle.com> <56E756A5.8090703@oracle.com> Message-ID: <56E85560.10205@oracle.com> Makes sense, updated webrev: http://cr.openjdk.java.net/~mikael/webrevs/8151233/webrev.01/webrev/ Incremental: http://cr.openjdk.java.net/~mikael/webrevs/8151233/webrev.01.incr/webrev/ Cheers, Mikael On 3/14/2016 5:26 PM, David Holmes wrote: > Hi Mikael, > > On 15/03/2016 8:47 AM, Mikael Vidstedt wrote: >> >> Please review the below change. >> >> When doing the clean up of Unsafe I cheated and made a copy of the >> CopySwap test (used to test U.copySwapMemory) for testing U.copyMemory. >> Much of the code is the same, or at least similar enough, that >> duplication is unfortunate. This change moves the common code to a >> helper file CopyCommon.java, and makes both test files use that. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8151233 >> Webrev: >> http://cr.openjdk.java.net/~mikael/webrevs/8151233/webrev.00/webrev/ > > Is it worth using CopyCommon as a base class and also sharing the > UNSAFE mechanics? > > Otherwise the refactoring seems okay. > > Thanks, > David > >> Cheers, >> Mikael >> From david.holmes at oracle.com Wed Mar 16 05:36:20 2016 From: david.holmes at oracle.com (David Holmes) Date: Wed, 16 Mar 2016 15:36:20 +1000 Subject: RFR(S): 8151233: Unify CopySwap and CopyMemory tests In-Reply-To: <56E85560.10205@oracle.com> References: <56E73F77.8000203@oracle.com> <56E756A5.8090703@oracle.com> <56E85560.10205@oracle.com> Message-ID: <56E8F0D4.5020509@oracle.com> Looks good! Thanks, David On 16/03/2016 4:33 AM, Mikael Vidstedt wrote: > > Makes sense, updated webrev: > > http://cr.openjdk.java.net/~mikael/webrevs/8151233/webrev.01/webrev/ > > Incremental: > > http://cr.openjdk.java.net/~mikael/webrevs/8151233/webrev.01.incr/webrev/ > > Cheers, > Mikael > > On 3/14/2016 5:26 PM, David Holmes wrote: >> Hi Mikael, >> >> On 15/03/2016 8:47 AM, Mikael Vidstedt wrote: >>> >>> Please review the below change. >>> >>> When doing the clean up of Unsafe I cheated and made a copy of the >>> CopySwap test (used to test U.copySwapMemory) for testing U.copyMemory. >>> Much of the code is the same, or at least similar enough, that >>> duplication is unfortunate. This change moves the common code to a >>> helper file CopyCommon.java, and makes both test files use that. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8151233 >>> Webrev: >>> http://cr.openjdk.java.net/~mikael/webrevs/8151233/webrev.00/webrev/ >> >> Is it worth using CopyCommon as a base class and also sharing the >> UNSAFE mechanics? >> >> Otherwise the refactoring seems okay. >> >> Thanks, >> David >> >>> Cheers, >>> Mikael >>> > From Alan.Bateman at oracle.com Wed Mar 16 14:23:09 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 16 Mar 2016 14:23:09 +0000 Subject: Proposing changes to OpenJDK corba component In-Reply-To: <1130784930.28595072.1457973192101.JavaMail.zimbra@redhat.com> References: <1130784930.28595072.1457973192101.JavaMail.zimbra@redhat.com> Message-ID: <56E96C4D.5030403@oracle.com> On 14/03/2016 16:33, Tomasz Adamski wrote: > Hello everyone, > > I'm part of WildFly team. We are maintaining our ORB library which is downstream of OpenJDK corba component adding changes to it when it is necessary for our project. Part of those changes are universal though and I would like to propose them to OpenJDK. Can you please tell me what the procedure is and to whom can I talk about it? > The "How to contribute" page [1] is a good start. We don't have a mailing list specifically for CORBA but but core-libs-dev should be okay. There are a number of engineers from Red Hat involved in OpenJDK, maybe you know them and could get help to post the patches on cr.openjdk.java.net for the discussion/review. -Alan [1] http://openjdk.java.net/contribute/ From mark.reinhold at oracle.com Wed Mar 16 19:11:46 2016 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Wed, 16 Mar 2016 12:11:46 -0700 Subject: Result: CFV: New JDK 9 Committer: Chris Plummer In-Reply-To: <56E2F1F1.80506@oracle.com> References: <56CF669C.6080108@oracle.com> <56E2C828.8030207@oracle.com> <56E2F1F1.80506@oracle.com> Message-ID: <20160316121146.746771371eggemoggin.niobe.net> 2016/3/11 8:27 -0800, coleen.phillimore at oracle.com: > Voting for Chris Plummer (cjplummer) [1] is now closed. > > Yes: 37 > Veto: 0 > Abstain: 0 > > According to the Bylaws definition of Three-Vote Consensus, this is > sufficient to approve the nomination. So recorded. - Mark From tadamski at redhat.com Wed Mar 16 21:09:16 2016 From: tadamski at redhat.com (Tomasz Adamski) Date: Wed, 16 Mar 2016 17:09:16 -0400 (EDT) Subject: Proposing changes to OpenJDK corba component In-Reply-To: <56E96C4D.5030403@oracle.com> References: <1130784930.28595072.1457973192101.JavaMail.zimbra@redhat.com> <56E96C4D.5030403@oracle.com> Message-ID: <226045949.29254755.1458162556314.JavaMail.zimbra@redhat.com> Thanks! -- Tomasz Adamski Software Engineer JBoss by Red Hat ----- Oryginalna wiadomo?? ----- > Od: "Alan Bateman" > Do: "Tomasz Adamski" , jdk9-dev at openjdk.java.net > Wys?ane: ?roda, 16 marzec 2016 15:23:09 > Temat: Re: Proposing changes to OpenJDK corba component > > On 14/03/2016 16:33, Tomasz Adamski wrote: > > Hello everyone, > > > > I'm part of WildFly team. We are maintaining our ORB library which is > > downstream of OpenJDK corba component adding changes to it when it is > > necessary for our project. Part of those changes are universal though and > > I would like to propose them to OpenJDK. Can you please tell me what the > > procedure is and to whom can I talk about it? > > > The "How to contribute" page [1] is a good start. We don't have a > mailing list specifically for CORBA but but core-libs-dev should be > okay. There are a number of engineers from Red Hat involved in OpenJDK, > maybe you know them and could get help to post the patches on > cr.openjdk.java.net for the discussion/review. > > -Alan > > [1] http://openjdk.java.net/contribute/ > From Alan.Bateman at oracle.com Sat Mar 19 10:46:58 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 19 Mar 2016 10:46:58 +0000 Subject: Project Jigsaw integration into JDK 9 In-Reply-To: <56E2DAEA.60609@oracle.com> References: <56E2DAEA.60609@oracle.com> Message-ID: <56ED2E22.6060700@oracle.com> Just to follow-up on my previous mail about integration into JDK 9 [1]. So far so good. All the changes are in the staging forest (jigsaw/m3). The quality/test team in Oracle are testing builds from the staging forest and we'll decide next Tuesday (March 22) on whether to push to jdk9/jdk9 or not. Assuming it goes ahead then the module system will be the only change in this build. We will aim to sync up jdk9/dev as soon as jdk-9+111 has been tagged and the other team forests will follow. There will be merge conflicts to resolve in several areas but we aren't expecting too many significant issues. -Alan. [1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-March/003877.html From alejandro.murillo at oracle.com Tue Mar 22 03:27:32 2016 From: alejandro.murillo at oracle.com (Alejandro Murillo) Date: Mon, 21 Mar 2016 21:27:32 -0600 Subject: jdk9-dev: HotSpot Message-ID: <56F0BBA4.30401@oracle.com> jdk9-hs-2016-03-17 has been integrated into jdk9-dev. http://hg.openjdk.java.net/jdk9/dev/rev/15d061ef8591 http://hg.openjdk.java.net/jdk9/dev/corba/rev/c842d4efaf48 http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/c2c3ba4ed1ac http://hg.openjdk.java.net/jdk9/dev/jaxp/rev/5a94c67f40c8 http://hg.openjdk.java.net/jdk9/dev/jaxws/rev/fb63c9b3af03 http://hg.openjdk.java.net/jdk9/dev/jdk/rev/3ad0ed497418 http://hg.openjdk.java.net/jdk9/dev/langtools/rev/5bacae82131e http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/25b13597ea73 Component : VM Status : Go for integration Date : 03/21/2016 at 20:00 MSK Tested By : VM SQE &dmitry.fazunenko at oracle.com Bundles : 2016-03-17-182711.amurillo.jdk9-hs-2016-03-17-snapshot Testing: 139 new failures, 2586 known failures, 473377 passed. Issues and Notes: No detailed analysis. No stoppers have been detected so far. Go for integration CRs for testing: 6787054: Par compact - remove code that clears source_region 8066770: EnqueueMethodForCompilationTest.java fails to compile method 8073793: serviceability/dcmd/compiler/CodelistTest.java fails with ClassNotFoundException trying to load VM anonymous class 8078673: Update TEST.groups for recent GC tests 8139247: Improper locking of MethodData::_extra_data_lock 8141420: Compiler runtime entries don't hold Klass* from being GCed 8142484: Let IHOP follow the current capacity, not the maximum capacity 8143407: C1: @Stable array support 8145204: JVM can hang when ParGCArrayScanChunk=4294967296 and ParallelGC is used 8146850: Remove TraceHandleAllocation rather than converting to UL 8147456: Parsing of argument for -agentpath can write outside of allocated memory 8149557: Resource mark breaks printing to string stream 8149642: gc/g1/TestShrinkAuxiliaryData* tests fail with "GC triggered before VM initialization completed" 8149834: gc/shared/gcTimer.cpp:88 assert(_is_concurrent_phase_active) failed: A concurrent phase is not active 8149850: Remove HandleAllocationLimit and TotalHandleAllocationLimit when removing TraceHandleAllocation 8149973: Optimize object alignment check in debug builds. 8150013: ParNew: Prune nmethods scavengable list. 8150026: Add the ability to log with variable log level 8150320: C1: Illegal bci in debug info for MH::linkTo* methods 8150646: Add support for blocking compiles though whitebox API 8150804: C2 Compilation fails with assert(_base >= OopPtr && _base <= AryPtr) failed: Not a Java pointer 8150843: [windows] os::getTimesSecs() returns negative values for kernel, user times 8150850: [JVMCI] NPE when executing HotSpotConstantReflectionProvider.readStableFieldValue 8150955: RandomValidCommandsTest.java fails with UnsatisfiedLinkError: sun.hotspot.WhiteBox.registerNatives 8151101: Improve UseParallelGC parallelization of object array processing 8151470: [JVMCI] remove up-call to HotSpotJVMCICompilerConfig.selectCompiler 8151502: optimize pd_disjoint_words and pd_conjoint_words 8151664: [JVMCI] add missing test in 8151266 integration 8151795: compiler/compilercontrol/parser/DirectiveParserTest.java fails with "assert failed: 0 != 0" 8151796: compiler/whitebox/BlockingCompilation.java fails due to method not compiled 8151871: [JVMCI] missing HAS_PENDING_EXCEPTION check -- Alejandro From mark.reinhold at oracle.com Tue Mar 22 15:15:42 2016 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Tue, 22 Mar 2016 08:15:42 -0700 Subject: JEPs proposed to target JDK 9 (2016/3/10) In-Reply-To: <20160310135154.649744865eggemoggin.niobe.net> References: <20160310135154.649744865eggemoggin.niobe.net> Message-ID: <20160322081542.288705907eggemoggin.niobe.net> 2016/3/10 13:51:54 -0800, mark.reinhold at oracle.com: > The following JEPs have been placed into the "Proposed to Target" > state by their owners after discussion and review: > > 200: The Modular JDK > http://openjdk.java.net/jeps/200 > > 260: Encapsulate Most Internal APIs > http://openjdk.java.net/jeps/260 > > 261: Module System > http://openjdk.java.net/jeps/261 > > 275: Modular Java Application Packaging > http://openjdk.java.net/jeps/275 > > 282: jlink: The Java Linker > http://openjdk.java.net/jeps/282 > > 284: New HotSpot Build System > http://openjdk.java.net/jeps/284 > > 285: Spin-Wait Hints > http://openjdk.java.net/jeps/285 Hearing no objections, I've targeted these JEPs to JDK 9. > The following JEP has been placed into the "Proposed to Drop" > state by its owner: > > 230: Microbenchmark Suite > http://openjdk.java.net/jeps/230 Hearing no objections, I've dropped this JEP from JDK 9. - Mark From Alan.Bateman at oracle.com Tue Mar 22 16:51:35 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 22 Mar 2016 16:51:35 +0000 Subject: Project Jigsaw integration into JDK 9 In-Reply-To: <56ED2E22.6060700@oracle.com> References: <56E2DAEA.60609@oracle.com> <56ED2E22.6060700@oracle.com> Message-ID: <56F17817.5070901@oracle.com> Just a brief mail to say that the testing hasn't uncovered any blocker issues so we are going to proceed with integration today. This will be the only change in jdk-9+111. Chris Hegarty will sync up jdk9/dev soon after the integration. -Alan. From lana.steuck at oracle.com Tue Mar 22 20:15:52 2016 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Tue, 22 Mar 2016 13:15:52 -0700 (PDT) Subject: jdk9-b111: dev Message-ID: <201603222015.u2MKFq0R018289@sc11152554.us.oracle.com> http://hg.openjdk.java.net/jdk9/jdk9/rev/f900d5afd9c8 http://hg.openjdk.java.net/jdk9/jdk9/nashorn/rev/133ea8746b37 http://hg.openjdk.java.net/jdk9/jdk9/langtools/rev/9adfb22ff08f http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/b2a69d66dc65 http://hg.openjdk.java.net/jdk9/jdk9/jaxws/rev/4d5296e0920a http://hg.openjdk.java.net/jdk9/jdk9/jaxp/rev/27a3d65e1580 http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/c558850fac57 http://hg.openjdk.java.net/jdk9/jdk9/corba/rev/2bb92dd44275 --- All the fixes will be tested during promotion (no PIT testing at this point): List of all fixes: =================== JDK-8142968 core-libs Module System implementation From bengt.rutisson at oracle.com Wed Mar 23 13:08:37 2016 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Wed, 23 Mar 2016 14:08:37 +0100 Subject: Result: CFV: New JDK 9 Committer: Derek White In-Reply-To: <56DFD51A.9090908@oracle.com> References: <56DFD51A.9090908@oracle.com> Message-ID: <56F29555.3090807@oracle.com> Voting for Derek White (drwhite) [1] is now closed. Yes: 24 Veto: 0 Abstain: 0 According to the Bylaws definition of Three-Vote Consensus, this is sufficient to approve the nomination. Bengt Rutisson [1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-March/thread.html#3845 From alexandr.scherbatiy at oracle.com Thu Mar 24 10:27:09 2016 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Thu, 24 Mar 2016 14:27:09 +0400 Subject: CFV: New JDK 9 Committer: Rajeev Chamyal Message-ID: <56F3C0FD.7030500@oracle.com> I hereby nominate Rajeev Chamyal (rchamyal) to JDK 9 Committer. Rajeev is a member of the Java Client team. He has made several non-trivial contributions to the AWT and Swing areas which include memory leaks investigation and resolving, and HiDPI splash-screens support on Windows and Linux platforms. Here is a list of Rajeev changesets: http://hg.openjdk.java.net/jdk9/client/jdk/search/?rev=author%28%22rchamyal%22%29&revcount=200 Votes are due by April 8, 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]. Thanks, Alexandr. [1] http://openjdk.java.net/census [2] http://openjdk.java.net/projects/#committer-vote From alexander.zvegintsev at oracle.com Thu Mar 24 15:40:55 2016 From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev) Date: Thu, 24 Mar 2016 18:40:55 +0300 Subject: CFV: New JDK 9 Committer: Rajeev Chamyal In-Reply-To: <56F3C0FD.7030500@oracle.com> References: <56F3C0FD.7030500@oracle.com> Message-ID: <56F40A87.1050800@oracle.com> Vote: yes Thanks, Alexander. On 24/03/16 13:27, Alexander Scherbatiy wrote: > > I hereby nominate Rajeev Chamyal (rchamyal) to JDK 9 Committer. > > Rajeev is a member of the Java Client team. He has made several > non-trivial contributions to the AWT and Swing areas which include > memory leaks investigation and resolving, and HiDPI splash-screens > support on Windows and Linux platforms. > Here is a list of Rajeev changesets: > http://hg.openjdk.java.net/jdk9/client/jdk/search/?rev=author%28%22rchamyal%22%29&revcount=200 > > > Votes are due by April 8, 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]. > > Thanks, > Alexandr. > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote From Sergey.Bylokhov at oracle.com Thu Mar 24 16:02:43 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 24 Mar 2016 19:02:43 +0300 Subject: CFV: New JDK 9 Committer: Rajeev Chamyal In-Reply-To: <56F3C0FD.7030500@oracle.com> References: <56F3C0FD.7030500@oracle.com> Message-ID: <56F40FA3.4060003@oracle.com> Vote: yes On 24.03.16 13:27, Alexander Scherbatiy wrote: > > I hereby nominate Rajeev Chamyal (rchamyal) to JDK 9 Committer. > > Rajeev is a member of the Java Client team. He has made several > non-trivial contributions to the AWT and Swing areas which include > memory leaks investigation and resolving, and HiDPI splash-screens > support on Windows and Linux platforms. > Here is a list of Rajeev changesets: > http://hg.openjdk.java.net/jdk9/client/jdk/search/?rev=author%28%22rchamyal%22%29&revcount=200 > > > Votes are due by April 8, 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]. > > Thanks, > Alexandr. > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote -- Best regards, Sergey. From aleksey.shipilev at oracle.com Thu Mar 24 16:45:57 2016 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Thu, 24 Mar 2016 19:45:57 +0300 Subject: RFR (S) 8152698: Remove obsolete Unsafe.putOrdered{X} methods, usages, runtime and compiler support Message-ID: <56F419C5.8000408@oracle.com> (before you freak out about sun.misc.Unsafe, read fully) Hi, I would like us to sweep up Unsafe.putOrdered{X} methods in favor of new and properly-named Unsafe.put{X}Release: https://bugs.openjdk.java.net/browse/JDK-8152698 Paul had already prodded the ground for this idea, now it's time to implement it: http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-March/017413.html putRelease do exactly the same what putOrdered do barrier-wise. In fact, C2 intrinsics for putOrdered and putRelease are identical. C1 intrinsifies putOrdered into putVolatile. unsafe.cpp also fallbacks to putVolatile (actually, into a duplicate copy of it). The only thing left would be sun.misc.Unsafe.putOrdered, which we cannot yet remove. But, in the spirit of recent Unsafe cleanup, we can fallback to j.i.m.Unsafe.putRelease, relieving runtime and compilers from even knowing about putOrdered. Webrevs: http://cr.openjdk.java.net/~shade/8152698/webrev.hs.01/ http://cr.openjdk.java.net/~shade/8152698/webrev.jdk.01/ Testing: compiler/unsafe jtregs; JPRT -testset hotspot I'd like to push through hs-comp to meet other VarHandles changes. Thanks, -Aleksey From alexandr.scherbatiy at oracle.com Thu Mar 24 16:57:07 2016 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Thu, 24 Mar 2016 20:57:07 +0400 Subject: CFV: New JDK 9 Committer: Rajeev Chamyal In-Reply-To: <56F3C0FD.7030500@oracle.com> References: <56F3C0FD.7030500@oracle.com> Message-ID: <56F41C63.7090509@oracle.com> Vote: yes Thanks, Alexandr. On 24/03/16 14:27, Alexander Scherbatiy wrote: > > I hereby nominate Rajeev Chamyal (rchamyal) to JDK 9 Committer. > > Rajeev is a member of the Java Client team. He has made several > non-trivial contributions to the AWT and Swing areas which include > memory leaks investigation and resolving, and HiDPI splash-screens > support on Windows and Linux platforms. > Here is a list of Rajeev changesets: > http://hg.openjdk.java.net/jdk9/client/jdk/search/?rev=author%28%22rchamyal%22%29&revcount=200 > > > Votes are due by April 8, 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]. > > Thanks, > Alexandr. > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote From semyon.sadetsky at oracle.com Thu Mar 24 17:05:38 2016 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Thu, 24 Mar 2016 20:05:38 +0300 Subject: CFV: New JDK 9 Committer: Rajeev Chamyal In-Reply-To: <56F3C0FD.7030500@oracle.com> References: <56F3C0FD.7030500@oracle.com> Message-ID: <56F41E62.806@oracle.com> Vote: yes --Semyon On 3/24/2016 1:27 PM, Alexander Scherbatiy wrote: > > I hereby nominate Rajeev Chamyal (rchamyal) to JDK 9 Committer. > > Rajeev is a member of the Java Client team. He has made several > non-trivial contributions to the AWT and Swing areas which include > memory leaks investigation and resolving, and HiDPI splash-screens > support on Windows and Linux platforms. > Here is a list of Rajeev changesets: > http://hg.openjdk.java.net/jdk9/client/jdk/search/?rev=author%28%22rchamyal%22%29&revcount=200 > > > Votes are due by April 8, 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]. > > Thanks, > Alexandr. > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote From philip.race at oracle.com Thu Mar 24 17:06:36 2016 From: philip.race at oracle.com (Phil Race) Date: Thu, 24 Mar 2016 10:06:36 -0700 Subject: CFV: New JDK 9 Committer: Rajeev Chamyal In-Reply-To: <56F3C0FD.7030500@oracle.com> References: <56F3C0FD.7030500@oracle.com> Message-ID: <56F41E9C.6090700@oracle.com> Vote: yes From nadeesh.tv at oracle.com Thu Mar 24 17:32:15 2016 From: nadeesh.tv at oracle.com (nadeesh tv) Date: Thu, 24 Mar 2016 23:02:15 +0530 Subject: CFV: New JDK 9 Committer: Rajeev Chamyal In-Reply-To: <56F3C0FD.7030500@oracle.com> References: <56F3C0FD.7030500@oracle.com> Message-ID: <56F4249F.6030806@oracle.com> Vote : Yes Thanks, Nadeesh On 3/24/2016 3:57 PM, Alexander Scherbatiy wrote: > > I hereby nominate Rajeev Chamyal (rchamyal) to JDK 9 Committer. > > Rajeev is a member of the Java Client team. He has made several > non-trivial contributions to the AWT and Swing areas which include > memory leaks investigation and resolving, and HiDPI splash-screens > support on Windows and Linux platforms. > Here is a list of Rajeev changesets: > http://hg.openjdk.java.net/jdk9/client/jdk/search/?rev=author%28%22rchamyal%22%29&revcount=200 > > > Votes are due by April 8, 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]. > > Thanks, > Alexandr. > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote -- Thanks and Regards, Nadeesh TV From vladimir.kozlov at oracle.com Thu Mar 24 17:47:02 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 24 Mar 2016 10:47:02 -0700 Subject: RFR (S) 8152698: Remove obsolete Unsafe.putOrdered{X} methods, usages, runtime and compiler support In-Reply-To: <56F419C5.8000408@oracle.com> References: <56F419C5.8000408@oracle.com> Message-ID: <56F42816.9030709@oracle.com> I think it is good cleanup. Some Hotspot tests changes are only new empty line added - can you remove those changes? Thanks, Vladimir On 3/24/16 9:45 AM, Aleksey Shipilev wrote: > (before you freak out about sun.misc.Unsafe, read fully) > > Hi, > > I would like us to sweep up Unsafe.putOrdered{X} methods in favor of new > and properly-named Unsafe.put{X}Release: > https://bugs.openjdk.java.net/browse/JDK-8152698 > > Paul had already prodded the ground for this idea, now it's time to > implement it: > http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-March/017413.html > > putRelease do exactly the same what putOrdered do barrier-wise. In fact, > C2 intrinsics for putOrdered and putRelease are identical. C1 > intrinsifies putOrdered into putVolatile. unsafe.cpp also fallbacks to > putVolatile (actually, into a duplicate copy of it). > > The only thing left would be sun.misc.Unsafe.putOrdered, which we cannot > yet remove. But, in the spirit of recent Unsafe cleanup, we can fallback > to j.i.m.Unsafe.putRelease, relieving runtime and compilers from even > knowing about putOrdered. > > Webrevs: > http://cr.openjdk.java.net/~shade/8152698/webrev.hs.01/ > http://cr.openjdk.java.net/~shade/8152698/webrev.jdk.01/ > > Testing: compiler/unsafe jtregs; JPRT -testset hotspot > > I'd like to push through hs-comp to meet other VarHandles changes. > > Thanks, > -Aleksey > From aleksey.shipilev at oracle.com Thu Mar 24 18:09:56 2016 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Thu, 24 Mar 2016 21:09:56 +0300 Subject: RFR (S) 8152698: Remove obsolete Unsafe.putOrdered{X} methods, usages, runtime and compiler support In-Reply-To: <56F42816.9030709@oracle.com> References: <56F419C5.8000408@oracle.com> <56F42816.9030709@oracle.com> Message-ID: <56F42D74.2000909@oracle.com> On 03/24/2016 08:47 PM, Vladimir Kozlov wrote: > I think it is good cleanup. Some Hotspot tests changes are only new > empty line added - can you remove those changes? Thanks Vladimir! Those tests are automatically generated: if I remove the whitespace, it will come back on next change. So I would rather leave that alone. (I remember Paul tried to fix JDK template gen with coalescing empty lines, not sure where did that go) -Aleksey From vladimir.kozlov at oracle.com Thu Mar 24 18:16:59 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 24 Mar 2016 11:16:59 -0700 Subject: RFR (S) 8152698: Remove obsolete Unsafe.putOrdered{X} methods, usages, runtime and compiler support In-Reply-To: <56F42D74.2000909@oracle.com> References: <56F419C5.8000408@oracle.com> <56F42816.9030709@oracle.com> <56F42D74.2000909@oracle.com> Message-ID: <56F42F1B.40100@oracle.com> On 3/24/16 11:09 AM, Aleksey Shipilev wrote: > On 03/24/2016 08:47 PM, Vladimir Kozlov wrote: >> I think it is good cleanup. Some Hotspot tests changes are only new >> empty line added - can you remove those changes? > > Thanks Vladimir! > > Those tests are automatically generated: if I remove the whitespace, it > will come back on next change. So I would rather leave that alone. (I > remember Paul tried to fix JDK template gen with coalescing empty lines, > not sure where did that go) I see. Okay. Vladimir > > -Aleksey > From paul.sandoz at oracle.com Thu Mar 24 18:19:09 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 24 Mar 2016 19:19:09 +0100 Subject: RFR (S) 8152698: Remove obsolete Unsafe.putOrdered{X} methods, usages, runtime and compiler support In-Reply-To: <56F42D74.2000909@oracle.com> References: <56F419C5.8000408@oracle.com> <56F42816.9030709@oracle.com> <56F42D74.2000909@oracle.com> Message-ID: <54A91ADF-8BA8-44C8-8202-BD063B784F93@oracle.com> > On 24 Mar 2016, at 19:09, Aleksey Shipilev wrote: > > On 03/24/2016 08:47 PM, Vladimir Kozlov wrote: >> I think it is good cleanup. Some Hotspot tests changes are only new >> empty line added - can you remove those changes? > > Thanks Vladimir! > +1 to the cleanup. > Those tests are automatically generated: if I remove the whitespace, it > will come back on next change. So I would rather leave that alone. (I > remember Paul tried to fix JDK template gen with coalescing empty lines, > not sure where did that go) > I updated the template generator to support an option not to generate empty lines for stuff that was ?ifdef?ed? out, which is used in this case, but sometimes redundant newlines still leak through when the template is adjusted (i did not try too hard to avoid generating all redundant lines). In this case some of the new newlines (e.g. at the end of the file) are a bit of a mystery to me. I would just leave as is and move on :-) Paul. From derek.white at oracle.com Thu Mar 24 19:26:15 2016 From: derek.white at oracle.com (Derek White) Date: Thu, 24 Mar 2016 15:26:15 -0400 Subject: Result: CFV: New JDK 9 Committer: Derek White (Bengt Rutisson) In-Reply-To: References: Message-ID: <56F43F57.3090005@oracle.com> Thanks Bengt! Am I now just waiting for Mark to do some admin stuff? - Derek > Voting for Derek White (drwhite) [1] is now closed. > > Yes: 24 > Veto: 0 > Abstain: 0 > > According to the Bylaws definition of Three-Vote Consensus, this is > sufficient to approve the nomination. > > Bengt Rutisson > > [1] > http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-March/thread.html#3845 From prasanta.sadhukhan at oracle.com Fri Mar 25 05:39:00 2016 From: prasanta.sadhukhan at oracle.com (prasanta sadhukhan) Date: Fri, 25 Mar 2016 11:09:00 +0530 Subject: CFV: New JDK 9 Committer: Rajeev Chamyal In-Reply-To: <56F3C0FD.7030500@oracle.com> References: <56F3C0FD.7030500@oracle.com> Message-ID: <56F4CEF4.7020108@oracle.com> Vote: yes On 3/24/2016 3:57 PM, Alexander Scherbatiy wrote: > > I hereby nominate Rajeev Chamyal (rchamyal) to JDK 9 Committer. > > Rajeev is a member of the Java Client team. He has made several > non-trivial contributions to the AWT and Swing areas which include > memory leaks investigation and resolving, and HiDPI splash-screens > support on Windows and Linux platforms. > Here is a list of Rajeev changesets: > http://hg.openjdk.java.net/jdk9/client/jdk/search/?rev=author%28%22rchamyal%22%29&revcount=200 > > > Votes are due by April 8, 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]. > > Thanks, > Alexandr. > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote From mark.reinhold at oracle.com Fri Mar 25 14:42:13 2016 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Fri, 25 Mar 2016 07:42:13 -0700 Subject: JEPs proposed to target JDK 9 (2016/3/25) Message-ID: <20160325074213.602938152eggemoggin.niobe.net> The following JEPs have been placed into the "Proposed to Target" state by their owners after discussion and review: 277: Enhanced Deprecation http://openjdk.java.net/jeps/277 283: Enable GTK 3 on Linux http://openjdk.java.net/jeps/283 Feedback on these proposals is more than welcome, as are reasoned objections. If no such objections are raised by 15:00 UTC next Friday, 1 April, or if they're raised and then satisfactorily answered, then per the JEP 2.0 process proposal [1] I'll target these JEPs to JDK 9. (This information is also available on the JDK 9 Project Page [2]). - Mark [1] http://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html [2] http://openjdk.java.net/projects/jdk9/ From david.lloyd at redhat.com Fri Mar 25 14:50:02 2016 From: david.lloyd at redhat.com (David M. Lloyd) Date: Fri, 25 Mar 2016 09:50:02 -0500 Subject: JEPs proposed to target JDK 9 (2016/3/25) In-Reply-To: <20160325074213.602938152eggemoggin.niobe.net> References: <20160325074213.602938152eggemoggin.niobe.net> Message-ID: <56F5501A.1070502@redhat.com> On 03/25/2016 09:42 AM, mark.reinhold at oracle.com wrote: > The following JEPs have been placed into the "Proposed to Target" > state by their owners after discussion and review: > > 277: Enhanced Deprecation > http://openjdk.java.net/jeps/277 > > 283: Enable GTK 3 on Linux > http://openjdk.java.net/jeps/283 > > Feedback on these proposals is more than welcome, as are reasoned > objections. If no such objections are raised by 15:00 UTC next > Friday, 1 April, or if they're raised and then satisfactorily > answered, then per the JEP 2.0 process proposal [1] I'll target > these JEPs to JDK 9. > > (This information is also available on the JDK 9 Project Page [2]). "The term is not meant to imply any moral censure." made me snicker. Maybe a less extreme term than "condemned" like "forRemoval" might fit better. :) Otherwise, glad to see this come into a clean, well-defined form. -- - DML From stuart.marks at oracle.com Fri Mar 25 21:08:03 2016 From: stuart.marks at oracle.com (Stuart Marks) Date: Fri, 25 Mar 2016 14:08:03 -0700 Subject: JEPs proposed to target JDK 9 (2016/3/25) In-Reply-To: <56F5501A.1070502@redhat.com> References: <20160325074213.602938152eggemoggin.niobe.net> <56F5501A.1070502@redhat.com> Message-ID: <56F5A8B3.2060602@oracle.com> On 3/25/16 7:50 AM, David M. Lloyd wrote: >> 277: Enhanced Deprecation >> http://openjdk.java.net/jeps/277 > > "The term is not meant to imply any moral censure." made me snicker. Maybe a > less extreme term than "condemned" like "forRemoval" might fit better. :) > > Otherwise, glad to see this come into a clean, well-defined form. Thanks. That line really means something like, "The term is not meant to imply any moral censure (but if you want to feel guilty about using deprecated APIs, it's fine by me)." s'marks From neugens.limasoftware at gmail.com Sat Mar 26 12:44:34 2016 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Sat, 26 Mar 2016 13:44:34 +0100 Subject: JEPs proposed to target JDK 9 (2016/3/25) In-Reply-To: <56F5A8B3.2060602@oracle.com> References: <56F5501A.1070502@redhat.com> <56F5A8B3.2060602@oracle.com> Message-ID: On Friday, 25 March 2016, Stuart Marks wrote: > > > On 3/25/16 7:50 AM, David M. Lloyd wrote: > >> 277: Enhanced Deprecation >>> http://openjdk.java.net/jeps/277 >>> >> >> "The term is not meant to imply any moral censure." made me snicker. >> Maybe a >> less extreme term than "condemned" like "forRemoval" might fit better. :) >> >> Otherwise, glad to see this come into a clean, well-defined form. >> > > Thanks. > > That line really means something like, "The term is not meant to imply any > moral censure (but if you want to feel guilty about using deprecated APIs, > it's fine by me)." This is so good that should really be part of the official API ;) Cheers, Mario > s'marks > -- 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 stuart.marks at oracle.com Mon Mar 28 17:50:10 2016 From: stuart.marks at oracle.com (Stuart Marks) Date: Mon, 28 Mar 2016 10:50:10 -0700 Subject: JEPs proposed to target JDK 9 (2016/3/25) In-Reply-To: References: <56F5501A.1070502@redhat.com> <56F5A8B3.2060602@oracle.com> Message-ID: <56F96ED2.6040303@oracle.com> On 3/26/16 5:44 AM, Mario Torre wrote: > That line really means something like, "The term is not meant to imply any > moral censure (but if you want to feel guilty about using deprecated APIs, > it's fine by me)." > > This is so good that should really be part of the official API ;) Hm, well there is @apiNote, but fortunately (?) there is no @apiSnarkyComment. s'marks From stuart.marks at oracle.com Tue Mar 29 22:38:18 2016 From: stuart.marks at oracle.com (Stuart Marks) Date: Tue, 29 Mar 2016 15:38:18 -0700 Subject: RFR: 8145461 changes to @Deprecated annotation Message-ID: <56FB03DA.1050607@oracle.com> Hi all, Please review these changes to the @Deprecated annotation: http://cr.openjdk.java.net/~smarks/reviews/8145461/webrev.0/ This is the first of a set of changes for JEP 277, which I hope will become Targeted to JDK 9 late this week. Changes to the deprecation status of specific APIs will be in subsequent changesets, along with some deprecation tooling. Note that this is considerably simplified from previous drafts. In particular, there is no "reason" enum. See the JEP [1] for background and rationale. Thanks, s'marks [1] http://openjdk.java.net/jeps/277 From scolebourne at joda.org Tue Mar 29 22:54:29 2016 From: scolebourne at joda.org (Stephen Colebourne) Date: Tue, 29 Mar 2016 23:54:29 +0100 Subject: RFR: 8145461 changes to @Deprecated annotation In-Reply-To: <56FB03DA.1050607@oracle.com> References: <56FB03DA.1050607@oracle.com> Message-ID: I am pleased to see the simpler form of the API move forward. However, I feel that condemed() as a boolean does not provide the key piece of information necessary - the expected version of removal. I would counter-propose that condemed() be replaced by expectedDeletion(), a String with the same version semantics as since(). While occasionally, the deletion version will be wrong or need to be pushed back, in most cases it will be correct. What it does do is provides a much better sense to users as to what is going to happen. @Deprecated(since="9", expectedDeletion="11) public void myBadBadMethod() {...} Stephen On 29 March 2016 at 23:38, Stuart Marks wrote: > Hi all, > > Please review these changes to the @Deprecated annotation: > > http://cr.openjdk.java.net/~smarks/reviews/8145461/webrev.0/ > > This is the first of a set of changes for JEP 277, which I hope will become > Targeted to JDK 9 late this week. Changes to the deprecation status of > specific APIs will be in subsequent changesets, along with some deprecation > tooling. > > Note that this is considerably simplified from previous drafts. In > particular, there is no "reason" enum. See the JEP [1] for background and > rationale. > > Thanks, > > s'marks > > [1] http://openjdk.java.net/jeps/277 > From martinrb at google.com Tue Mar 29 23:39:18 2016 From: martinrb at google.com (Martin Buchholz) Date: Tue, 29 Mar 2016 16:39:18 -0700 Subject: RFR: 8145461 changes to @Deprecated annotation In-Reply-To: References: <56FB03DA.1050607@oracle.com> Message-ID: For similar work in guava, compare e.g. the clarity of http://docs.guava-libraries.googlecode.com/git/javadoc/com/google/common/io/OutputSupplier.html """Deprecated. For OutputSupplier, use ByteSink instead. For OutputSupplier, use CharSink. Implementations of OutputSupplier that don't fall into one of those categories do not benefit from any of the methods in common.io and should use a different interface. This interface is scheduled for removal in December 2015.""" (OTOH, it's already 2016 ...) On Tue, Mar 29, 2016 at 3:54 PM, Stephen Colebourne wrote: > I am pleased to see the simpler form of the API move forward. > > However, I feel that condemed() as a boolean does not provide the key > piece of information necessary - the expected version of removal. I > would counter-propose that condemed() be replaced by > expectedDeletion(), a String with the same version semantics as > since(). While occasionally, the deletion version will be wrong or > need to be pushed back, in most cases it will be correct. What it does > do is provides a much better sense to users as to what is going to > happen. > > @Deprecated(since="9", expectedDeletion="11) > public void myBadBadMethod() {...} > > Stephen > > > > On 29 March 2016 at 23:38, Stuart Marks wrote: >> Hi all, >> >> Please review these changes to the @Deprecated annotation: >> >> http://cr.openjdk.java.net/~smarks/reviews/8145461/webrev.0/ >> >> This is the first of a set of changes for JEP 277, which I hope will become >> Targeted to JDK 9 late this week. Changes to the deprecation status of >> specific APIs will be in subsequent changesets, along with some deprecation >> tooling. >> >> Note that this is considerably simplified from previous drafts. In >> particular, there is no "reason" enum. See the JEP [1] for background and >> rationale. >> >> Thanks, >> >> s'marks >> >> [1] http://openjdk.java.net/jeps/277 >> From alex.buckley at oracle.com Tue Mar 29 23:51:08 2016 From: alex.buckley at oracle.com (Alex Buckley) Date: Tue, 29 Mar 2016 16:51:08 -0700 Subject: RFR: 8145461 changes to @Deprecated annotation In-Reply-To: <56FB03DA.1050607@oracle.com> References: <56FB03DA.1050607@oracle.com> Message-ID: <56FB14EC.3090804@oracle.com> Some editorial points: - "Usage of a deprecated element may also be flagged by various analysis tools." -- recommend removing this sentence. (Vague info; passive voice; undue prominence.) If you really want to allude to third party tools, have a paragraph at the end "Analysis tools are encouraged to flag ...". - Recommend that since() precedes condemned() everywhere. Anyone who writes @Deprecated knows what since is, even if they're too busy to think about tomorrow's build let alone a version next year. I think that condemned=true without a since is passive-aggressive behavior. - "A value of {@code false} indicates that use of the annotated program element is discouraged but, at the time the annotated program element was specified, that there was no specific intent to remove it." -- by "specified", do you mean "declared" or "annotated" ? I have to think you mean "annotated", since hardly anyone declares an element and immediately writes @Deprecated. - This annotation _type_ has a ... [two occurrences] - This value indicates the version -> The value of this element indicates the version - In the @apiNote, "that element's" and "This documentation" can just use "the". - since() method decl suddenly mentions "API element" rather than "annotated element" (condemned() uses "annotated element"). Alex On 3/29/2016 3:38 PM, Stuart Marks wrote: > Hi all, > > Please review these changes to the @Deprecated annotation: > > http://cr.openjdk.java.net/~smarks/reviews/8145461/webrev.0/ > > This is the first of a set of changes for JEP 277, which I hope will > become Targeted to JDK 9 late this week. Changes to the deprecation > status of specific APIs will be in subsequent changesets, along with > some deprecation tooling. > > Note that this is considerably simplified from previous drafts. In > particular, there is no "reason" enum. See the JEP [1] for background > and rationale. > > Thanks, > > s'marks > > [1] http://openjdk.java.net/jeps/277 > From stuart.marks at oracle.com Wed Mar 30 01:44:08 2016 From: stuart.marks at oracle.com (Stuart Marks) Date: Tue, 29 Mar 2016 18:44:08 -0700 Subject: RFR: 8145461 changes to @Deprecated annotation In-Reply-To: References: <56FB03DA.1050607@oracle.com> Message-ID: <56FB2F68.9010001@oracle.com> On 3/29/16 3:54 PM, Stephen Colebourne wrote: > I am pleased to see the simpler form of the API move forward. Great! Thanks for the quick review. > However, I feel that condemed() as a boolean does not provide the key > piece of information necessary - the expected version of removal. I > would counter-propose that condemed() be replaced by > expectedDeletion(), a String with the same version semantics as > since(). While occasionally, the deletion version will be wrong or > need to be pushed back, in most cases it will be correct. What it does > do is provides a much better sense to users as to what is going to > happen. > > @Deprecated(since="9", expectedDeletion="11) > public void myBadBadMethod() {...} Yes, this came up in the discussion after the JEP was initially posted in the Autumn of last year. We considered this, and in some draft APIs there was an element called "until" with semantics similar to what you suggest. Unfortunately it didn't make the cut. It turns out there are a bunch of problems with specifying and using such a thing in practice. One issue is, how does one talk about the future? Two obvious answers are in terms of calendar dates and version numbers. Martin's reply illustrates one issue with calendar dates. Another issue with calendar dates is that, for the JDK, and many other projects, there are sustaining lines of development that overlap in time with feature-oriented lines of development. APIs would most likely be removed in the feature line, but not in a sustaining line, but you can't tell that by looking at a date. Or maybe it would be both, but you'd need more information to specify that. The more likely alternative is to specify some kind of version string, either the first version where the removal is to occur, or the last version through which the condemned API is supported. This seems sensible enough, but I don't agree with the statement that "in most cases it will be correct." Let's consider some "revisionist" history. :-) Suppose we're working on JDK 1.6, we have the annotation with an expectedDeletion element, and we have an API we need to get rid of because it's incompatible with Jigsaw. We might therefore annotate the API as follows (remember, this is in JDK 1.6): @Deprecated(since="1.6", expectedDeletion="1.7") There did end up being a 1.7 release ("Java 7") but didn't have Jigsaw in it as originally planned. [1] So we might decide to revise the annotation in 1.7 as follows: @Deprecated(since="1.6", expectedDeletion="1.8") If this thing really conflicts with Jigsaw, which clearly didn't ship in 1.8, this would be wrong again. So in 1.8 we'd revise it once again: @Deprecated(since="1.6", expectedDeletion="1.9") And now maybe this time it really will be removed. But the version number is wrong again; it's not "1.9" but instead according to JEP 223 [2] the version is now "9". The changing of the expectedDeletion value undoubtedly will cause some temporary confusion. However, the main problem is that we've now littered the historical record with a bunch of misinformation. This has the potential to cause confusion for an indefinite period of time. In addition, there is a general policy at Oracle against making any definite statements about future versions of products. So, maybe this an Oracle-specific thing about not talking about the future, and maybe it's a JDK-specific thing that things change around so much from release to release. Shouldn't there be some provision for other libraries to specify information about the expected deletion version? We considered that too. The problem is, as a matter of policy, the JDK wouldn't use it at all! For all deprecated APIs in the JDK, the expectedDeletion value would be the empty string. Now the problem is that the JDK is trying to define some attribute that it won't use itself, for external libraries to use. It might make sense if there were some clear consensus across different libraries about what could be put here, but I don't think there is. Should it be the first version where removal is expected? Or the last version there the API is guaranteed present? Or should be a date instead of a version? Now the attribute is reduced to being a string in a library-specific format specifying some information with library-specific semantics. At that point it's adding so little value that it no longer belongs in the JDK. If external libraries really want this, they can put this information in the javadoc text, or they can define their own annotations. s'marks [1] http://mreinhold.org/blog/rethinking-jdk7 [2] http://openjdk.java.net/jeps/223 From stuart.marks at oracle.com Wed Mar 30 01:49:06 2016 From: stuart.marks at oracle.com (Stuart Marks) Date: Tue, 29 Mar 2016 18:49:06 -0700 Subject: RFR: 8145461 changes to @Deprecated annotation In-Reply-To: <56FB14EC.3090804@oracle.com> References: <56FB03DA.1050607@oracle.com> <56FB14EC.3090804@oracle.com> Message-ID: <56FB3092.9040909@oracle.com> On 3/29/16 4:51 PM, Alex Buckley wrote: > Some editorial points: > > - "Usage of a deprecated element may also be flagged by various analysis tools." > -- recommend removing this sentence. (Vague info; passive voice; undue > prominence.) If you really want to allude to third party tools, have a paragraph > at the end "Analysis tools are encouraged to flag ...". Well, the tools are ones I intend to integrate later in JDK 9, but points taken. Plus, we mustn't talk about the future. :-) > - Recommend that since() precedes condemned() everywhere. Anyone who writes > @Deprecated knows what since is, even if they're too busy to think about > tomorrow's build let alone a version next year. I think that condemned=true > without a since is passive-aggressive behavior. I'll add API notes about this. > - "A value of {@code false} indicates that use of the annotated program element > is discouraged but, at the time the annotated program element was specified, > that there was no specific intent to remove it." -- by "specified", do you mean > "declared" or "annotated" ? I have to think you mean "annotated", since hardly > anyone declares an element and immediately writes @Deprecated. Yes, "annotated." Thanks, this will improve that sentence. > - This annotation _type_ has a ... [two occurrences] ok > - This value indicates the version -> The value of this element indicates the > version ok > - In the @apiNote, "that element's" and "This documentation" can just use "the". ok > - since() method decl suddenly mentions "API element" rather than "annotated > element" (condemned() uses "annotated element"). ok > Alex Thanks for the comments. s'marks > > On 3/29/2016 3:38 PM, Stuart Marks wrote: >> Hi all, >> >> Please review these changes to the @Deprecated annotation: >> >> http://cr.openjdk.java.net/~smarks/reviews/8145461/webrev.0/ >> >> This is the first of a set of changes for JEP 277, which I hope will >> become Targeted to JDK 9 late this week. Changes to the deprecation >> status of specific APIs will be in subsequent changesets, along with >> some deprecation tooling. >> >> Note that this is considerably simplified from previous drafts. In >> particular, there is no "reason" enum. See the JEP [1] for background >> and rationale. >> >> Thanks, >> >> s'marks >> >> [1] http://openjdk.java.net/jeps/277 >> From david.lloyd at redhat.com Wed Mar 30 13:03:23 2016 From: david.lloyd at redhat.com (David M. Lloyd) Date: Wed, 30 Mar 2016 08:03:23 -0500 Subject: RFR: 8145461 changes to @Deprecated annotation In-Reply-To: <56FB03DA.1050607@oracle.com> References: <56FB03DA.1050607@oracle.com> Message-ID: <56FBCE9B.8030003@redhat.com> On 03/29/2016 05:38 PM, Stuart Marks wrote: > Hi all, > > Please review these changes to the @Deprecated annotation: > > http://cr.openjdk.java.net/~smarks/reviews/8145461/webrev.0/ > > This is the first of a set of changes for JEP 277, which I hope will > become Targeted to JDK 9 late this week. Changes to the deprecation > status of specific APIs will be in subsequent changesets, along with > some deprecation tooling. > > Note that this is considerably simplified from previous drafts. In > particular, there is no "reason" enum. See the JEP [1] for background > and rationale. Great! As I said in another forum, I think "condemned" is a bit too obtuse to read, linguistically (not to mention humorously ambiguous, as you yourself pointed out). I prefer "plain langauge"; something more like "forRemoval" would be better IMO. Also I agree with Stephen about the usefulness of specifying an "until" version, but I understand the counterpoints and this could also just as easily be done by a third-party library, especially now that JavaDoc is presumably going to be much nicer (and thus hopefully more pluggable). -- - DML From scolebourne at joda.org Wed Mar 30 13:40:59 2016 From: scolebourne at joda.org (Stephen Colebourne) Date: Wed, 30 Mar 2016 14:40:59 +0100 Subject: RFR: 8145461 changes to @Deprecated annotation In-Reply-To: <56FB2F68.9010001@oracle.com> References: <56FB03DA.1050607@oracle.com> <56FB2F68.9010001@oracle.com> Message-ID: Thanks for the reply. I'm unconvinced that most of the points would be a problem in practice. Frankly, it doesn't matter if the version for removal sometimes slips, or that the syntax of the version number changes. What matters is that it is not brought forward once it is committed. However, it really sounds more like you're dancing around lawyers here rather than freely designing a feature. As David has separately mentioned, "condemed" is just too hidden a meaning for this. deletionPlanned) of plannedForDeletion() would be much clearer. Or even subjectToRemoval() which matches the Javadoc text. Stephen On 30 March 2016 at 02:44, Stuart Marks wrote: > > > On 3/29/16 3:54 PM, Stephen Colebourne wrote: >> >> I am pleased to see the simpler form of the API move forward. > > > Great! Thanks for the quick review. > >> However, I feel that condemed() as a boolean does not provide the key >> piece of information necessary - the expected version of removal. I >> would counter-propose that condemed() be replaced by >> expectedDeletion(), a String with the same version semantics as >> since(). While occasionally, the deletion version will be wrong or >> need to be pushed back, in most cases it will be correct. What it does >> do is provides a much better sense to users as to what is going to >> happen. >> >> @Deprecated(since="9", expectedDeletion="11) >> public void myBadBadMethod() {...} > > > Yes, this came up in the discussion after the JEP was initially posted in > the Autumn of last year. We considered this, and in some draft APIs there > was an element called "until" with semantics similar to what you suggest. > Unfortunately it didn't make the cut. It turns out there are a bunch of > problems with specifying and using such a thing in practice. > > One issue is, how does one talk about the future? Two obvious answers are in > terms of calendar dates and version numbers. > > Martin's reply illustrates one issue with calendar dates. > > Another issue with calendar dates is that, for the JDK, and many other > projects, there are sustaining lines of development that overlap in time > with feature-oriented lines of development. APIs would most likely be > removed in the feature line, but not in a sustaining line, but you can't > tell that by looking at a date. Or maybe it would be both, but you'd need > more information to specify that. > > The more likely alternative is to specify some kind of version string, > either the first version where the removal is to occur, or the last version > through which the condemned API is supported. This seems sensible enough, > but I don't agree with the statement that "in most cases it will be > correct." > > Let's consider some "revisionist" history. :-) > > Suppose we're working on JDK 1.6, we have the annotation with an > expectedDeletion element, and we have an API we need to get rid of because > it's incompatible with Jigsaw. We might therefore annotate the API as > follows (remember, this is in JDK 1.6): > > @Deprecated(since="1.6", expectedDeletion="1.7") > > There did end up being a 1.7 release ("Java 7") but didn't have Jigsaw in it > as originally planned. [1] So we might decide to revise the annotation in > 1.7 as follows: > > @Deprecated(since="1.6", expectedDeletion="1.8") > > If this thing really conflicts with Jigsaw, which clearly didn't ship in > 1.8, this would be wrong again. So in 1.8 we'd revise it once again: > > @Deprecated(since="1.6", expectedDeletion="1.9") > > And now maybe this time it really will be removed. But the version number is > wrong again; it's not "1.9" but instead according to JEP 223 [2] the version > is now "9". > > The changing of the expectedDeletion value undoubtedly will cause some > temporary confusion. However, the main problem is that we've now littered > the historical record with a bunch of misinformation. This has the potential > to cause confusion for an indefinite period of time. > > In addition, there is a general policy at Oracle against making any definite > statements about future versions of products. > > So, maybe this an Oracle-specific thing about not talking about the future, > and maybe it's a JDK-specific thing that things change around so much from > release to release. Shouldn't there be some provision for other libraries to > specify information about the expected deletion version? > > We considered that too. The problem is, as a matter of policy, the JDK > wouldn't use it at all! For all deprecated APIs in the JDK, the > expectedDeletion value would be the empty string. Now the problem is that > the JDK is trying to define some attribute that it won't use itself, for > external libraries to use. It might make sense if there were some clear > consensus across different libraries about what could be put here, but I > don't think there is. Should it be the first version where removal is > expected? Or the last version there the API is guaranteed present? Or should > be a date instead of a version? > > Now the attribute is reduced to being a string in a library-specific format > specifying some information with library-specific semantics. At that point > it's adding so little value that it no longer belongs in the JDK. > > If external libraries really want this, they can put this information in the > javadoc text, or they can define their own annotations. > > s'marks > > > [1] http://mreinhold.org/blog/rethinking-jdk7 > [2] http://openjdk.java.net/jeps/223 > > > From lana.steuck at oracle.com Wed Mar 30 18:50:13 2016 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 30 Mar 2016 11:50:13 -0700 (PDT) Subject: jdk9-b112: dev Message-ID: <201603301850.u2UIoDMj026822@sc11152554.us.oracle.com> http://hg.openjdk.java.net/jdk9/jdk9/rev/03543a758cd5 http://hg.openjdk.java.net/jdk9/jdk9/nashorn/rev/c261f8440c55 http://hg.openjdk.java.net/jdk9/jdk9/langtools/rev/3d4117c36559 http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/1565a0efe6f0 http://hg.openjdk.java.net/jdk9/jdk9/jaxws/rev/21274e7937ba http://hg.openjdk.java.net/jdk9/jdk9/jaxp/rev/36326537f929 http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/76582e8dc9e6 http://hg.openjdk.java.net/jdk9/jdk9/corba/rev/780d0620add3 --- All the fixes will be tested during promotion (no PIT testing at this point): List of all fixes: =================== JDK-8151750 client-libs Mark ChangingInterests.java as intermittently failing JDK-8031767 core-libs Support system or alternative implementations of zlib JDK-8032051 core-libs "ZonedDateTime" class "parse" method fails with short time zone offset JDK-8060097 core-libs sun/net/idn/TestStringPrep.java failed. JDK-8076528 core-libs LocalTime.format() throws exception when FormatStyle is LONG or FULL JDK-8085887 core-libs java.time.format.FormatStyle.LONG or FULL causes unchecked exception JDK-8131913 core-libs jdk/internal/jline/console/StripAnsiTest.java can't run in the backgro JDK-8147613 core-libs enable jjs tests on Windows JDK-8148748 core-libs ArrayList.subList().spliterator() is not late-binding JDK-8149122 core-libs Move sun.misc.URLClassPath and Resource to an internal package JDK-8149159 core-libs Clean up Unsafe JDK-8150218 core-libs Autoconversion SAM adapters sometimes don't get privileges JDK-8150463 core-libs StringConcat MH_INLINE_SIZED_EXACT should skip storage initialization JDK-8150782 core-libs findClass / accessClass throw unexpected exceptions JDK-8150840 core-libs Add an internal system property to control the default level of System JDK-8151062 core-libs unbalanced parenthesis in java.util.EnumMap.clone() Javadoc JDK-8151123 core-libs Collectors.summingDouble/averagingDouble unnecessarily call mapper twi JDK-8151233 core-libs Unify CopySwap and CopyMemory tests JDK-8151281 core-libs Module java.httpclient could use System.Logger instead of PlatformLogg JDK-8151571 core-libs InnocuousThread cannot be created during early startup JDK-8151582 core-libs (ch) test java/nio/channels/AsyncCloseAndInterrupt.java failing due to JDK-8151700 core-libs Add support for ES6 for-of JDK-8151778 core-libs TestLookup.java fails after push of JDK-8150782 JDK-8151785 core-libs Doc typo in src/../java/util/stream/PipelineHelper.java JDK-8151798 core-libs Mark java/util/TimeZone/Bug6772689.java as intermittently failing and JDK-8151809 core-libs ES6 Map/Set insertion with existing keys changes iteration order JDK-8151810 core-libs for-in iteration does not provide per-iteration scope JDK-8151811 core-libs Const declarations do not work in for..in loops JDK-8151847 core-libs rmic should support v53 classfiles JDK-8151868 core-libs Javadocs for java.time.Instant until(Temporal endExclusive, TemporalUn JDK-8151957 core-libs ObjectInputStream - Use new convenience method for immutable Map creat JDK-8152043 core-libs (fs) Remove dynamic loopup of Win32 API functions in WindowsNativeDisp JDK-8152237 core-libs Support BigInteger.TWO JDK-8152268 core-libs jjs tool makefile should use --addmods ALL-SYSTEM JDK-8152277 core-libs Move URLClassPath.pathToURLs(String) to RegistryImpl JDK-8152352 core-libs Compiling warnings in zip_util.c blocks devkit to build with --with-zl JDK-8152606 core-libs java.base no longer needs to export sun.util.logging to java.httpclien JDK-8152642 core-libs Remove sun.misc.Unsafe dependency from java.lang.reflect.Proxy JDK-8152646 core-libs disable ant octane target to avoid hudson build failure notifications JDK-8152749 core-libs Mark AdaptorCloseAndInterrupt.java as intermittently failing JDK-8152755 core-libs Problem list java/nio/file/WatchService/MayFlies.java JDK-8152161 core-svc Problem loading platform MBean server JDK-6787054 hotspot Par compact - remove code that clears source_region JDK-8066770 hotspot EnqueueMethodForCompilationTest.java fails to compile method JDK-8073793 hotspot serviceability/dcmd/compiler/CodelistTest.java fails with ClassNotFoun JDK-8078673 hotspot Update TEST.groups for recent GC tests JDK-8139247 hotspot Improper locking of MethodData::_extra_data_lock JDK-8140721 hotspot ProfilerNumberOf*Methods flags should be diagnostic JDK-8141420 hotspot Compiler runtime entries don't hold Klass* from being GCed JDK-8142484 hotspot Let IHOP follow the current capacity, not the maximum capacity JDK-8143407 hotspot C1: @Stable array support JDK-8145204 hotspot JVM can hang when ParGCArrayScanChunk=4294967296 and ParallelGC is use JDK-8146801 hotspot Allocating short arrays of non-constant size is slow JDK-8146850 hotspot Remove TraceHandleAllocation rather than converting to UL JDK-8148563 hotspot compiler/compilercontrol/jcmd/StressAddMultiThreadedTest.java timesout JDK-8149557 hotspot Resource mark breaks printing to string stream JDK-8149642 hotspot gc/g1/TestShrinkAuxiliaryData* tests fail with "GC triggered before VM JDK-8149834 hotspot gc/shared/gcTimer.cpp:88 assert(_is_concurrent_phase_active) failed: JDK-8149850 hotspot Remove HandleAllocationLimit and TotalHandleAllocationLimit when remov JDK-8149973 hotspot Optimize object alignment check in debug builds. JDK-8150013 hotspot ParNew: Prune nmethods scavengable list JDK-8150026 hotspot Add the ability to log with variable log level JDK-8150082 hotspot aarch64: optimise small array copy JDK-8150313 hotspot aarch64: optimise array copy using SIMD instructions JDK-8150320 hotspot C1: Illegal bci in debug info for MH::linkTo* methods JDK-8150353 hotspot PPC64LE: Support RTM on linux JDK-8150394 hotspot aarch64: add support for 8.1 LSE CAS instructions JDK-8150465 hotspot Unsafe methods to produce uninitialized arrays JDK-8150646 hotspot Add support for blocking compiles though whitebox API JDK-8150669 hotspot C1 intrinsic for Class.isPrimitive JDK-8150767 hotspot Enables SHA Extensions on x86 JDK-8150804 hotspot C2 Compilation fails with assert(_base >= OopPtr && _base <= AryPtr) f JDK-8150839 hotspot Adjust the number of compiler threads for 32-bit platforms JDK-8150843 hotspot [windows] os::getTimesSecs() returns negative values for kernel, user JDK-8150850 hotspot [JVMCI] NPE when executing HotSpotConstantReflectionProvider.readStabl JDK-8150955 hotspot RandomValidCommandsTest.java fails with UnsatisfiedLinkError: sun.hots JDK-8151002 hotspot Make Assembler methods vextract and vinsert match actual instructions JDK-8151101 hotspot Improve UseParallelGC parallelization of object array processing JDK-8151266 hotspot [JVMCI] HotSpotResolvedJavaFieldImpl.isStable() does not work as expec JDK-8151340 hotspot aarch64: prefetch the destination word for write prior to ldxr/stxr lo JDK-8151470 hotspot [JVMCI] remove up-call to HotSpotJVMCICompilerConfig.selectCompiler JDK-8151502 hotspot aarch64: optimize pd_disjoint_words and pd_conjoint_words JDK-8151664 hotspot [JVMCI] add missing test in 8151266 integration JDK-8151795 hotspot compiler/compilercontrol/parser/DirectiveParserTest.java fails with "a JDK-8151796 hotspot compiler/whitebox/BlockingCompilation.java fails due to method not com JDK-8151871 hotspot [JVMCI] missing HAS_PENDING_EXCEPTION check JDK-8152483 hotspot Fix a couple of tests that are being incorrectly run on C1 after jigsa JDK-8152697 hotspot JVMCI tests fail with UnsatisfiedLinkError as jdk.vm.ci not defined by JDK-8149545 infrastructure Add zlib devel package to devkit sysroot on Linux JDK-8151230 infrastructure jib config fails to download asmtools when latest link changed JDK-8151619 infrastructure genSocketOptionRegistry.exe always relinked on Windows JDK-8151726 infrastructure Introduce a JPRT testset buildinfra JDK-8151800 infrastructure Jib profile for open linux should produce compact profiles images by d JDK-8151841 infrastructure Build needs additional flags to compile with GCC 6 JDK-8152197 infrastructure Single place to specify module-specific information for images build JDK-8152209 infrastructure Non-Linux builds failing after JDK-8151841 JDK-8152545 infrastructure Use preprocessor instead of compiling a program to generate native nio JDK-8147755 other-libs ASM should create correct constant tag for invokestatic on handle poin JDK-8151858 other-libs update ASM 5.1 to accept V53.0 classfiles JDK-8152227 other-libs Remove jdk.deploy.osx module descriptor JDK-8152638 other-libs Exclude closed/javax/sound/sampled/FileWriter/WaveBigEndian.java JDK-8149017 security-libs Delayed provider selection broken in RSA client key exchange. JDK-8149169 security-libs SSLSocketInputRecord.decodeInputRecord buffer overflow JDK-8150512 security-libs Update test for jdk.security.provider.preferred security property. JDK-8151734 security-libs Mark Unreachable.java and MaxRetries.java as intermittently failing JDK-8151835 security-libs Mark SmallPrimeExponentP.java as intermittently failing JDK-8152221 security-libs Use try-with-resource in test templates JDK-8152798 security-libs Mark WeakCipherSuite.java as intermittently failing JDK-8027999 tools Poorly worded error message when attempting to assign to this JDK-8151379 tools Sjavac should not print connection attempts on info logging level JDK-8151755 tools jshell tool: properly cover resolution issues in output configuration JDK-8152048 tools change langtools tests to use ProblemList instead of @ignore JDK-8152143 tools jlink --include-locales should gracefully detect certain user error JDK-8152246 tools jshell tool: history overflow JDK-8152296 tools langtools/test/jdk/jshell/ToolReloadTest.java failing if there is no p JDK-8152411 tools Regression: inference fails to reject incompatible upper bounds JDK-8152465 tools Sjavac should not prefix server generated log messages with [server] JDK-8152503 tools tools/javac/completionDeps/DepsAndAnno.java fails after jigsaw m3 JDK-8152504 tools Problem list tools/jdeps/modules/GenModuleInfo.java until JDK-8152502 JDK-8152508 tools tools/jlink/SecurityTest.java failed intermittently JDK-8152715 tools Problem list tools/pack200/Pack200Props.java JDK-8145039 xml JAXB marshaller fails with ClassCastException on classes generated by JDK-8151154 xml IllegalArgumentException not thrown when wrong syntax value is set for From stuart.marks at oracle.com Wed Mar 30 21:51:35 2016 From: stuart.marks at oracle.com (Stuart Marks) Date: Wed, 30 Mar 2016 14:51:35 -0700 Subject: RFR: 8145461 changes to @Deprecated annotation In-Reply-To: References: <56FB03DA.1050607@oracle.com> <56FB2F68.9010001@oracle.com> Message-ID: <56FC4A67.1040507@oracle.com> On 3/30/16 6:40 AM, Stephen Colebourne wrote: > I'm unconvinced that most of the points would be a problem in > practice. Frankly, it doesn't matter if the version for removal > sometimes slips, or that the syntax of the version number changes. > What matters is that it is not brought forward once it is committed. > However, it really sounds more like you're dancing around lawyers here > rather than freely designing a feature. Regardless of the reasoning, it's quite clear that the JDK won't use any "expectedDeletion" or "until" attribute even if one were to be defined. That's not my decision. > As David has separately mentioned, "condemed" is just too hidden a > meaning for this. deletionPlanned) of plannedForDeletion() would be > much clearer. Or even subjectToRemoval() which matches the Javadoc > text. OK, point taken. I'll reply to David's email re renaming "condemned." s'marks From dify.ltd at gmail.com Thu Mar 31 08:44:17 2016 From: dify.ltd at gmail.com (Attila-Mihaly Balazs) Date: Thu, 31 Mar 2016 11:44:17 +0300 Subject: Not able to turn off G1 GC in JDK-9 preview builds? Message-ID: Hello, I'm trying to do some benchmarks and was curious what effect using / not using G1 GC had on it. However I'm unable to turn it off in the latest JDK-9 beta build (111): ~/jdk-9-111/bin/java -XX:-UseG1GC -XX:+PrintFlagsFinal -version | grep UseG1GC bool UseG1GC := true {product} java version "9-ea" Java(TM) SE Runtime Environment (build 9-ea+111) Java HotSpot(TM) 64-Bit Server VM (build 9-ea+111, mixed mode) With JDK-8 this works as expected: ~/jdk1.8.0_72/bin/java -XX:-UseG1GC -XX:+PrintFlagsFinal -version | grep UseG1GC bool UseG1GC := false {product} java version "1.8.0_72" Java(TM) SE Runtime Environment (build 1.8.0_72-b15) Java HotSpot(TM) 64-Bit Server VM (build 25.72-b15, mixed mode) Any pointers as to what my be the issue? I understand that there is a push to use G1 GC by default in Java 9, however it was my understanding that the previous GC algorithms will still be available. Thank you, Attila Balazs From thomas.schatzl at oracle.com Thu Mar 31 08:53:44 2016 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Thu, 31 Mar 2016 10:53:44 +0200 Subject: Not able to turn off G1 GC in JDK-9 preview builds? In-Reply-To: References: Message-ID: <1459414424.2264.5.camel@oracle.com> Hi, On Thu, 2016-03-31 at 11:44 +0300, Attila-Mihaly Balazs wrote: > Hello, > > I'm trying to do some benchmarks and was curious what effect using / > not using G1 GC had on it. However I'm unable to turn it off in the > latest JDK-9 beta build (111): Only trying to disable collectors and not giving an alternative will fall back to the default collector since you need a collector to run. Since G1 is the default collector in this build, it will fall back to G1. The same happens if you only specify -XX:-ParallelGC on the JDK8 command line. > ~/jdk-9-111/bin/java -XX:-UseG1GC -XX:+PrintFlagsFinal -version | > grep > UseG1GC > bool UseG1GC := > true {product} > java version "9-ea" > Java(TM) SE Runtime Environment (build 9-ea+111) > Java HotSpot(TM) 64-Bit Server VM (build 9-ea+111, mixed mode) > > With JDK-8 this works as expected: In JDK8 the default collector is parallel gc. > Any pointers as to what my be the issue? I understand that there is a > push to use G1 GC by default in Java 9, however it was my > understanding that the previous GC algorithms will still be > available. Explicitly enable a different collector, e.g. -XX:+UseParallelGC. You do not need to specify -XX:-UseGC if you want to enable a different collector. Thanks, Thomas From aph at redhat.com Thu Mar 31 08:54:10 2016 From: aph at redhat.com (Andrew Haley) Date: Thu, 31 Mar 2016 09:54:10 +0100 Subject: Not able to turn off G1 GC in JDK-9 preview builds? In-Reply-To: References: Message-ID: <56FCE5B2.9070001@redhat.com> On 31/03/16 09:44, Attila-Mihaly Balazs wrote: > Any pointers as to what my be the issue? I understand that there is a push > to use G1 GC by default in Java 9, however it was my understanding that the > previous GC algorithms will still be available. So use a different GC. The alternatives are UseG1GC UseParallelGC UseParallelOldGC UseSerialGC UseConcMarkSweepGC Andrew. From bengt.rutisson at oracle.com Thu Mar 31 09:12:34 2016 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Thu, 31 Mar 2016 11:12:34 +0200 Subject: Not able to turn off G1 GC in JDK-9 preview builds? In-Reply-To: <1459414424.2264.5.camel@oracle.com> References: <1459414424.2264.5.camel@oracle.com> Message-ID: <56FCEA02.8050901@oracle.com> Just FYI, With the fix for: Running with -XX:-UseParallelGC does not turn ParalleGC off https://bugs.openjdk.java.net/browse/JDK-8068579 That was recently pushed to JDK 9 you will get the following error message if you try to disable the default GC: Garbage collector not selected (default collector explicitly disabled) Thanks, Bengt On 2016-03-31 10:53, Thomas Schatzl wrote: > Hi, > > On Thu, 2016-03-31 at 11:44 +0300, Attila-Mihaly Balazs wrote: >> Hello, >> >> I'm trying to do some benchmarks and was curious what effect using / >> not using G1 GC had on it. However I'm unable to turn it off in the >> latest JDK-9 beta build (111): > Only trying to disable collectors and not giving an alternative will > fall back to the default collector since you need a collector to run. > Since G1 is the default collector in this build, it will fall back to > G1. > > The same happens if you only specify -XX:-ParallelGC on the JDK8 > command line. > >> ~/jdk-9-111/bin/java -XX:-UseG1GC -XX:+PrintFlagsFinal -version | >> grep >> UseG1GC >> bool UseG1GC := >> true {product} >> java version "9-ea" >> Java(TM) SE Runtime Environment (build 9-ea+111) >> Java HotSpot(TM) 64-Bit Server VM (build 9-ea+111, mixed mode) >> >> With JDK-8 this works as expected: > In JDK8 the default collector is parallel gc. > >> Any pointers as to what my be the issue? I understand that there is a >> push to use G1 GC by default in Java 9, however it was my >> understanding that the previous GC algorithms will still be >> available. > Explicitly enable a different collector, e.g. -XX:+UseParallelGC. > > You do not need to specify -XX:-UseGC if you want to enable a > different collector. > > Thanks, > Thomas > From dify.ltd at gmail.com Thu Mar 31 09:19:17 2016 From: dify.ltd at gmail.com (Attila-Mihaly Balazs) Date: Thu, 31 Mar 2016 12:19:17 +0300 Subject: Not able to turn off G1 GC in JDK-9 preview builds? In-Reply-To: <56FCEA02.8050901@oracle.com> References: <1459414424.2264.5.camel@oracle.com> <56FCEA02.8050901@oracle.com> Message-ID: Thank you all for the quick reply. And yes, disabling G1 GC *and* enabling a different GC works as expected on JDK9. Sorry for not thinking about this before posting. Cheers, Attila On Thu, Mar 31, 2016 at 12:12 PM, Bengt Rutisson wrote: > > Just FYI, > > With the fix for: > > Running with -XX:-UseParallelGC does not turn ParalleGC off > https://bugs.openjdk.java.net/browse/JDK-8068579 > > That was recently pushed to JDK 9 you will get the following error message > if you try to disable the default GC: > > Garbage collector not selected (default collector explicitly disabled) > > Thanks, > Bengt > > > On 2016-03-31 10:53, Thomas Schatzl wrote: > >> Hi, >> >> On Thu, 2016-03-31 at 11:44 +0300, Attila-Mihaly Balazs wrote: >> >>> Hello, >>> >>> I'm trying to do some benchmarks and was curious what effect using / >>> not using G1 GC had on it. However I'm unable to turn it off in the >>> latest JDK-9 beta build (111): >>> >> Only trying to disable collectors and not giving an alternative will >> fall back to the default collector since you need a collector to run. >> Since G1 is the default collector in this build, it will fall back to >> G1. >> >> The same happens if you only specify -XX:-ParallelGC on the JDK8 >> command line. >> >> ~/jdk-9-111/bin/java -XX:-UseG1GC -XX:+PrintFlagsFinal -version | >>> grep >>> UseG1GC >>> bool UseG1GC := >>> true {product} >>> java version "9-ea" >>> Java(TM) SE Runtime Environment (build 9-ea+111) >>> Java HotSpot(TM) 64-Bit Server VM (build 9-ea+111, mixed mode) >>> >>> With JDK-8 this works as expected: >>> >> In JDK8 the default collector is parallel gc. >> >> Any pointers as to what my be the issue? I understand that there is a >>> push to use G1 GC by default in Java 9, however it was my >>> understanding that the previous GC algorithms will still be >>> available. >>> >> Explicitly enable a different collector, e.g. -XX:+UseParallelGC. >> >> You do not need to specify -XX:-UseGC if you want to enable a >> different collector. >> >> Thanks, >> Thomas >> >> >