April 2016 - core-libs-dev

RFR 8154556: Use java.nio.ByteOrder instead of boolean value
by Paul Sandoz 21 Apr '16

21 Apr '16

Hi Please review: http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8154556-vh-nio-byteorder/webre… <http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8154556-vh-nio-byteorder/webre…> This is a small tweak to the VarHandle API. The array and ByteBuffer related factory methods on MethodhHandles now accept a java.no.ByteOrder rather than a boolean value. Use of java.no.ByteOrder is considered more readable in code that a boolean value, for express big, little or native endianness. Paul.

2 3

Re: [9] 8149571: [launcher] create a regression test to test symlinks on Windows
by Oleg G. Barbashov 21 Apr '16

21 Apr '16

Hi, Please review the simple test of launcher started using a symlink. issue: https://bugs.openjdk.java.net/browse/JDK-8149571 webrev: http://cr.openjdk.java.net/~ogb/8149571/ Thanks, Oleg

3 5

JDK 9 RFR of JDK-8152936: java/lang/Class/GetPackageTest.java needs update to work with newer testng
by Amy Lu 21 Apr '16

21 Apr '16

To get prepared for the coming testng updating in jtreg [1], test/java/lang/Class/GetPackageTest.java needs a minor update as newer version of testng requires explicit DataProvider's name (since 6.8.10). Please review the patch. This works for both current jtreg (testng 6.8.5), and later testng 6.9.5 bug: https://bugs.openjdk.java.net/browse/JDK-8152936 webrev: http://cr.openjdk.java.net/~amlu/8152936/webrev.00/ Thanks, Amy [1]: http://mail.openjdk.java.net/pipermail/jtreg-use/2016-April/000450.html --- old/test/java/lang/Class/GetPackageTest.java 2016-04-21 13:30:41.000000000 +0800 +++ new/test/java/lang/Class/GetPackageTest.java 2016-04-21 13:30:40.000000000 +0800 @@ -1,5 +1,5 @@ /** - * Copyright (c) 2015, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2015, 2016, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -52,7 +52,7 @@ assertEquals(fooClass.getClassLoader(), loader); } - @DataProvider(name = "testclasses") + @DataProvider(name = "testClasses") public Object[][] testClasses() { return new Object[][] { // primitive type, void, array types

3 2

RFR: 8154853: java/util/TimeZone/OldIDMappingTest.sh fails after JDK-8154231
by Claes Redestad 21 Apr '16

21 Apr '16

Hi, initializing USE_OLDMAPPING after using it - deep inside load(dis) - seems like a very bad idea in hindsight. webrev: http://cr.openjdk.java.net/~redestad/8154853/webrev.01/ bug: https://bugs.openjdk.java.net/browse/JDK-8154853 Thanks! /Claes

2 2

RFR: 8154231: Simplify access to System properties from JDK code
by Claes Redestad 21 Apr '16

21 Apr '16

Hello, now that the sun.security.action package is encapsulated we can simplify internal code to get System properties. Bug: https://bugs.openjdk.java.net/browse/JDK-8154231 Webrev: http://cr.openjdk.java.net/~redestad/8154231/webrev.01/ This adds a few convenience methods to GetPropertyAction[1] and GetIntegerAction[2]. Since the code calling into this can be streamlined, this leads to a net static footprint reduction of the java.base module and a tiny startup improvement. Thanks! /Claes [1] http://cr.openjdk.java.net/~redestad/8154231/webrev.01/src/java.base/share/… [2] http://cr.openjdk.java.net/~redestad/8154231/webrev.01/src/java.base/share/…

4 8

Re: RFR: JDK-8152690: main thread does not have native thread name
by David Holmes 21 Apr '16

21 Apr '16

Hi, On 14/04/2016 1:28 AM, Yasumasa Suenaga wrote: > Hi David, > > Thanks for your comment. > > I exported new JVM function to set native thread name, and JLI uses it > in new webrev. First the launcher belongs to another team so core-libs will need to review and approve this (in particular Kumar) - now cc'd. Personally I would have used a Java upcall to Thread.setName rather than exporting JVM_SetNativeThreadName. No hotspot changes needed in that case. Thanks, David > Could you review again? > > - hotspot: > http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.02/hotspot/ > > - jdk: > http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.02/jdk/ > > > Thanks, > > Yasumasa > > > On 2016/04/13 22:00, David Holmes wrote: >> I'll answer on this original thread as well ... >> >> Hi Yasumasa, >> >> Please see my updates to the bug (sorry have been on vacation). This >> needs to be done in the launcher to be correct as we do not set the >> name of threads that attach via JNI, which includes the "main" thread. >> >> David >> >> On 31/03/2016 9:49 AM, Yasumasa Suenaga wrote: >>> Thanks Robbin, >>> >>> I'm waiting a sponsor and more reviewer :-) >>> >>> Yasumasa >>> 2016/03/31 5:58 "Robbin Ehn" <robbin.ehn(a)oracle.com>: >>> >>>> FYI: I'm not a Reviewer. >>>> >>>> /Robbin >>>> >>>> On 03/30/2016 10:55 PM, Robbin Ehn wrote: >>>> >>>>> Thanks, looks good. >>>>> >>>>> /Robbin >>>>> >>>>> On 03/30/2016 03:47 PM, Yasumasa Suenaga wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> I uploaded new webrev. >>>>>> Could you review it? >>>>>> >>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.01/ >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Yasumasa >>>>>> >>>>>> >>>>>> On 2016/03/30 19:10, Robbin Ehn wrote: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> On 03/30/2016 11:41 AM, Yasumasa Suenaga wrote: >>>>>>> >>>>>>>> Hi Robbin, >>>>>>>> >>>>>>>> 2016/03/30 18:22 "Robbin Ehn" <robbin.ehn(a)oracle.com >>>>>>>> <mailto:robbin.ehn@oracle.com>>: >>>>>>>> > >>>>>>>> > Hi Yasumasa, >>>>>>>> > >>>>>>>> > >>>>>>>> > On 03/25/2016 12:48 AM, Yasumasa Suenaga wrote: >>>>>>>> >> >>>>>>>> >> Hi Robbin, >>>>>>>> >> 2016/03/25 1:51 "Robbin Ehn" <robbin.ehn(a)oracle.com >>>>>>>> <mailto:robbin.ehn@oracle.com> >>>>>>>> >> <mailto:robbin.ehn@oracle.com >>>>>>>> <mailto:robbin.ehn@oracle.com>>>: >>>>>>>> >> >>>>>>>> >> > >>>>>>>> >> > Hi Yasumasa, >>>>>>>> >> > >>>>>>>> >> > I'm not sure why you don't set it: >>>>>>>> >> > >>>>>>>> >> > diff -r ded6ef79c770 src/share/vm/runtime/thread.cpp >>>>>>>> >> > --- a/src/share/vm/runtime/thread.cpp Thu Mar 24 >>>>>>>> 13:09:16 2016 >>>>>>>> +0000 >>>>>>>> >> > +++ b/src/share/vm/runtime/thread.cpp Thu Mar 24 >>>>>>>> 17:40:09 2016 >>>>>>>> +0100 >>>>>>>> >> > @@ -3584,6 +3584,7 @@ >>>>>>>> >> > JavaThread* main_thread = new JavaThread(); >>>>>>>> >> > main_thread->set_thread_state(_thread_in_vm); >>>>>>>> >> > main_thread->initialize_thread_current(); >>>>>>>> >> > + main_thread->set_native_thread_name("main"); >>>>>>>> >> > // must do this before set_active_handles >>>>>>>> >> > main_thread->record_stack_base_and_size(); >>>>>>>> >> > >>>>>>>> main_thread->set_active_handles(JNIHandleBlock::allocate_block()); >>>>>>>> >> > >>>>>>>> >> > here instead? Am I missing something? >>>>>>>> >> >>>>>>>> >> Native thread name is the same to thread name in Thread class. >>>>>>>> >> It is set in c'tor in Thread or setName(). >>>>>>>> >> If you create new thread in Java app, native thread name >>>>>>>> will be >>>>>>>> set at >>>>>>>> >> startup. However, main thread is already starte in VM. >>>>>>>> >> Thread name for "main" is set in create_initial_thread(). >>>>>>>> >> I think that the place of setting thrrad name should be the >>>>>>>> same. >>>>>>>> > >>>>>>>> > >>>>>>>> > Yes, I see your point. But then something like this is >>>>>>>> nicer, no? >>>>>>>> > >>>>>>>> > --- a/src/share/vm/runtime/thread.cpp Tue Mar 29 09:43:05 >>>>>>>> 2016 >>>>>>>> +0200 >>>>>>>> > +++ b/src/share/vm/runtime/thread.cpp Wed Mar 30 10:51:12 >>>>>>>> 2016 >>>>>>>> +0200 >>>>>>>> > @@ -981,6 +981,7 @@ >>>>>>>> > // Creates the initial Thread >>>>>>>> > static oop create_initial_thread(Handle thread_group, >>>>>>>> JavaThread* >>>>>>>> thread, >>>>>>>> > TRAPS) { >>>>>>>> > + static const char* initial_thread_name = "main"; >>>>>>>> > Klass* k = >>>>>>>> SystemDictionary::resolve_or_fail(vmSymbols::java_lang_Thread(), >>>>>>>> true, >>>>>>>> CHECK_NULL); >>>>>>>> > instanceKlassHandle klass (THREAD, k); >>>>>>>> > instanceHandle thread_oop = >>>>>>>> klass->allocate_instance_handle(CHECK_NULL); >>>>>>>> > @@ -988,8 +989,10 @@ >>>>>>>> > java_lang_Thread::set_thread(thread_oop(), thread); >>>>>>>> > java_lang_Thread::set_priority(thread_oop(), NormPriority); >>>>>>>> > thread->set_threadObj(thread_oop()); >>>>>>>> > - >>>>>>>> > - Handle string = java_lang_String::create_from_str("main", >>>>>>>> CHECK_NULL); >>>>>>>> > + >>>>>>>> > + thread->set_native_thread_name(initial_thread_name); >>>>>>>> > + >>>>>>>> > + Handle string = >>>>>>>> java_lang_String::create_from_str(initial_thread_name, CHECK_NULL); >>>>>>>> > >>>>>>>> > JavaValue result(T_VOID); >>>>>>>> > JavaCalls::call_special(&result, thread_oop, >>>>>>>> >>>>>>>> Okay, I will upload new webrev later. >>>>>>>> >>>>>>> >>>>>>> Thanks! >>>>>>> >>>>>>> >>>>>>>> >> > The launcher seem to name itself 'java' and naming this >>>>>>>> thread >>>>>>>> just >>>>>>>> >> > 'main' is confusing to me. >>>>>>>> >> > >>>>>>>> >> > E.g. so main thread of the process (and thus the >>>>>>>> process) is >>>>>>>> 'java' but >>>>>>>> >> > first JavaThread is 'main'. >>>>>>>> >> >>>>>>>> >> The native main thread in the process is not JavaThread. It is >>>>>>>> waiting >>>>>>>> >> for ending of Java main thread with pthread_join(). >>>>>>>> >> set_native_thread_name() is for JavaThread. So I think that >>>>>>>> we do >>>>>>>> not >>>>>>>> >> need to call it for native main thread. >>>>>>>> > >>>>>>>> > >>>>>>>> > Not sure if we can change it anyhow, since we want java and >>>>>>>> native >>>>>>>> name to be the same and java thread name might have some >>>>>>>> dependents. >>>>>>>> > >>>>>>>> > The name is visible in e.g. /proc. >>>>>>>> > >>>>>>>> > $ ps H -C java -o 'pid tid comm' | head -4 >>>>>>>> > PID TID COMMAND >>>>>>>> > 6423 6423 java >>>>>>>> > 6423 6424 main >>>>>>>> > 6423 6425 GC Thread#0 >>>>>>>> > >>>>>>>> > It would be nice with something like 'Java Main Thread'. >>>>>>>> >>>>>>>> I do not think so. >>>>>>>> Native main thread might not be a Java launcher - e.g. Apache >>>>>>>> commons-daemon, JNI application, etc. >>>>>>>> >>>>>>>> If you want to change native main thread name, I think that we >>>>>>>> have to >>>>>>>> change Java launcher code. >>>>>>>> Should I include it in new webrev? >>>>>>>> >>>>>>> >>>>>>> No >>>>>>> >>>>>>> Thanks again! >>>>>>> >>>>>>> /Robbin >>>>>>> >>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Yasumasa >>>>>>>> >>>>>>>> > Thanks >>>>>>>> > >>>>>>>> > /Robbin >>>>>>>> > >>>>>>>> > >>>>>>>> >> >>>>>>>> >> Thanks, >>>>>>>> >> >>>>>>>> >> Yasumasa >>>>>>>> >> >>>>>>>> >> > Thanks! >>>>>>>> >> > >>>>>>>> >> > /Robbin >>>>>>>> >> > >>>>>>>> >> > On 03/24/2016 03:26 PM, Yasumasa Suenaga wrote: >>>>>>>> >> > > Hi all, >>>>>>>> >> > > >>>>>>>> >> > > HotSpot for Linux will set thread name via >>>>>>>> pthread_setname_np(). >>>>>>>> >> > > However, main thread does not have it. >>>>>>>> >> > > >>>>>>>> >> > > All JavaThread have native name, and main thread is >>>>>>>> JavaThread. >>>>>>>> >> > > For consistency, main thread should have native thread >>>>>>>> name. >>>>>>>> >> > > >>>>>>>> >> > > I uploaded a webrev. Could you review it? >>>>>>>> >> > > >>>>>>>> >> > > >>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.00/ >>>>>>>> >> > > >>>>>>>> >> > > I cannot access JPRT. >>>>>>>> >> > > So I need a sponsor. >>>>>>>> >> > > >>>>>>>> >> > > >>>>>>>> >> > > Thanks, >>>>>>>> >> > > >>>>>>>> >> > > Yasumasa >>>>>>>> >> > > >>>>>>>> >> >>>>>>>> >>>>>>>>

5 35

RFR(s): 8153330: deprecate Runtime.traceInstructions & traceMethodCalls for removal
by Stuart Marks 20 Apr '16

20 Apr '16

Hi all, I missed a couple bits of cruft in the previous round of java.lang deprecations: the Runtime.traceInstructions() and traceMethodCalls() methods. Their implementations are empty. That is, they do absolutely nothing. They're only mentioned a couple times in the JDK, in CORBA (!) and in some RMI tests (!), and in a few symbol files. On grepcode.com, there are a couple uses, mainly attempting to enable these in response to some debugging flag being given. Thus, I propose these be deprecated for removal. Please review diff below. Thanks, s'marks diff -r 92280897299f src/java.base/share/classes/java/lang/Runtime.java --- a/src/java.base/share/classes/java/lang/Runtime.java Mon Apr 18 14:10:14 2016 -0700 +++ b/src/java.base/share/classes/java/lang/Runtime.java Tue Apr 19 15:04:25 2016 -0700 @@ -718,41 +718,27 @@ } /** - * Enables/Disables tracing of instructions. - * If the {@code boolean} argument is {@code true}, this - * method suggests that the Java virtual machine emit debugging - * information for each instruction in the virtual machine as it - * is executed. The format of this information, and the file or other - * output stream to which it is emitted, depends on the host environment. - * The virtual machine may ignore this request if it does not support - * this feature. The destination of the trace output is system - * dependent. - * <p> - * If the {@code boolean} argument is {@code false}, this - * method causes the virtual machine to stop performing the - * detailed instruction trace it is performing. - * - * @param on {@code true} to enable instruction tracing; - * {@code false} to disable this feature. + * Not implemented. + * + * @deprecated + * This method was intended to control instruction tracing. + * It has been superseded by JVM-specific tracing mechanisms. + * + * @param on ignored */ + @Deprecated(since="9", forRemoval=true) public void traceInstructions(boolean on) { } /** - * Enables/Disables tracing of method calls. - * If the {@code boolean} argument is {@code true}, this - * method suggests that the Java virtual machine emit debugging - * information for each method in the virtual machine as it is - * called. The format of this information, and the file or other output - * stream to which it is emitted, depends on the host environment. The - * virtual machine may ignore this request if it does not support - * this feature. - * <p> - * Calling this method with argument false suggests that the - * virtual machine cease emitting per-call debugging information. - * - * @param on {@code true} to enable instruction tracing; - * {@code false} to disable this feature. + * Not implemented. + * + * @deprecated + * This method was intended to control method call tracing. + * It has been superseded by JVM-specific tracing mechanisms. + * + * @param on ignored */ + @Deprecated(since="9", forRemoval=true) public void traceMethodCalls(boolean on) { } /**

3 2

Locks implementing Closable
by kurtymckurt 20 Apr '16

20 Apr '16

Has it been considered to have the Lock interface use AutoCloseable? That way users can lock in a try and not have to worry about a finally? -- View this message in context: http://openjdk.5641.n7.nabble.com/Locks-implementing-Closable-tp267580.html Sent from the OpenJDK Core Libraries mailing list archive at Nabble.com.

2 3

RFR: 8154387 - Parallel unordered Stream.limit() tries to collect 128 elements even if limit is less
by Tagir F. Valeev 20 Apr '16

20 Apr '16

Hello! Please review and sponsor the following patch: https://bugs.openjdk.java.net/browse/JDK-8154387 http://cr.openjdk.java.net/~tvaleev/webrev/8154387/r1/ The rationale is to speed-up the parallel processing for unordered streams with low limit value. Such problems occur when you want to perform expensive filtering and select at most x elements which pass the filter (order does not matter). Currently unordered limit operation buffers up to 128 elements for each parallel task before it checks whether limit is reached. This is actually harmful when requested limit is lower: much more elements are requested from the upstream than necessary. Here's simple JMH test which illustrates the problem: http://cr.openjdk.java.net/~tvaleev/webrev/8154387/jmh/ It extracts the requested number of probable-primes from the list of 10000 BigInteger numbers. The results with 9ea+111: Benchmark (limit) Mode Cnt Score Error Units LimitTest.parLimit 2 avgt 30 108,971 ± 0,643 us/op LimitTest.parLimit 20 avgt 30 934,176 ± 14,003 us/op LimitTest.parLimit 200 avgt 30 8772,417 ± 190,609 us/op LimitTest.parLimit 2000 avgt 30 41775,463 ± 1800,537 us/op LimitTest.parUnorderedLimit 2 avgt 30 2557,798 ± 13,161 us/op LimitTest.parUnorderedLimit 20 avgt 30 2578,283 ± 23,547 us/op LimitTest.parUnorderedLimit 200 avgt 30 4577,318 ± 40,793 us/op LimitTest.parUnorderedLimit 2000 avgt 30 12279,346 ± 523,823 us/op LimitTest.seqLimit 2 avgt 30 34,831 ± 0,190 us/op LimitTest.seqLimit 20 avgt 30 369,729 ± 1,427 us/op LimitTest.seqLimit 200 avgt 30 3690,544 ± 13,907 us/op LimitTest.seqLimit 2000 avgt 30 36681,637 ± 156,538 us/op When the limit is 2 or 20, parallel unordered version is slower than parallel ordered! Even for limit = 200 it's still slower than sequential operation. The idea of the patch is to tweak the CHUNK_SIZE using the given limit and parallelism level. I used the following formula: this.chunkSize = limit >= 0 ? (int)Math.min(CHUNK_SIZE, (skip + limit) / ForkJoinPool.getCommonPoolParallelism() + 1) : CHUNK_SIZE; This does not affect cases when limit is big or not set at all (in skip mode). However it greatly improves cases when limit is small: Benchmark (limit) Mode Cnt Score Error Units LimitTest.parLimit 2 avgt 30 109,502 ± 0,750 us/op LimitTest.parLimit 20 avgt 30 954,716 ± 39,276 us/op LimitTest.parLimit 200 avgt 30 8706,226 ± 184,330 us/op LimitTest.parLimit 2000 avgt 30 42126,346 ± 3163,444 us/op LimitTest.parUnorderedLimit 2 avgt 30 39,303 ± 0,177 us/op !!! LimitTest.parUnorderedLimit 20 avgt 30 266,107 ± 0,492 us/op !!! LimitTest.parUnorderedLimit 200 avgt 30 2547,177 ± 58,538 us/op !!! LimitTest.parUnorderedLimit 2000 avgt 30 12216,402 ± 430,574 us/op LimitTest.seqLimit 2 avgt 30 34,993 ± 0,704 us/op LimitTest.seqLimit 20 avgt 30 369,497 ± 1,754 us/op LimitTest.seqLimit 200 avgt 30 3716,059 ± 61,054 us/op LimitTest.seqLimit 2000 avgt 30 36814,356 ± 161,531 us/op Here you can see that unordered cases are significantly improved. Now they are always faster than parallel ordered and faster than sequential for limit >= 20. I did not think up how to test this patch as it does not change visible behavior, only speed. However all the existing tests pass. What do you think? With best regards, Tagir Valeev.

3 11

RFR: 8072921: -Xincgc should be removed from output
by Stefan Karlsson 20 Apr '16

20 Apr '16

Hi all, I hope this is the right list for this RFR. Please review this patch to remove the -Xincgc output from the java launcher. http://cr.openjdk.java.net/~stefank/8072921/webrev.01 https://bugs.openjdk.java.net/browse/JDK-8072921 The output can be seen by running 'java -X': $ ../build/linux-x86_64-normal-server-release/jdk/bin/java -X -Xmixed mixed mode execution (default) -Xint interpreted mode execution only -Xbootclasspath/a:<directories and zip/jar files separated by :> append to end of bootstrap class path -Xdiag show additional diagnostic messages -Xdiag:resolver show resolver diagnostic messages -Xnoclassgc disable class garbage collection -Xincgc enable incremental garbage collection The -Xincgc flag was removed with JEP 214: https://bugs.openjdk.java.net/browse/JDK-8044022 JEP 214: Remove GC Combinations Deprecated in JDK 8 I've left the locale specific launcher files untouched. Should I update them as well? Thanks, StefanK

2 2