July 2015 - core-libs-dev

RFR 8073056: Repeating annotations throws java.security.AccessControlException with a SecurityManager
by Joel Borggrén-Franck 24 Aug '15

24 Aug '15

Hi, Here is a fix for an issue with repeating annotations when a security manager is set. Fix is to use the Proxy invocation handler to unwrap the array containing the repeating annotations. In theory it might be possible to have instances of Annotations that are not implemented using Proxies, so the old code which is independent of implementation is kept as a fall-back, but the user or these theoretical annotations will have to configure the security policy accordingly. http://cr.openjdk.java.net/~jfranck/8073056/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8073056 cheers /Joel

5 25

RFR - 8027634: Support @argfiles for java command-line tool
by Henry Jen 23 Aug '15

23 Aug '15

Hi, Please review proposed patch for JDK-8027634[1]. This patch is to enable java support command line argument file like javac does. The implementation use the same syntax rule, which is implemented in CommandLine.java[3] with java.io.StreamTokenizer. Some early comment is that we probably don’t need such complexity to support same syntax, also require to quote whole token is a little inconvenient. For example, must be -cp “c:\\foo bar\\lib;c:\\lib” instead of -cp c:\”foo bar”\lib;c:\lib. I am debating if such compatibility is necessary useful, after all, easy and intuitive is more important, and with simpler rule, the implementation will be cleaner as well. Anyhow, with the patch out, at least developer can build idk and have something to test with to see if this can fulfill their use cases. Also, for tools other than java that use launcher, it’s possible to use -J@argfile to pass arguments. For example, if want to pass -J options to javac, it’s now possible to do so with javac -J@argfile, and put -J options in the argfile. If the consensus is that such syntax compatibility is not important, we will go ahead remove the escaping support(except probably enable escape for quote itself) in quote, and maybe add support of quote within a token. CCing build-dev for build changes, jdk9-dev for wider audience for tools. Cheers, Henry [1] https://bugs.openjdk.java.net/browse/JDK-8027634 [2] http://docs.oracle.com/javase/7/docs/technotes/tools/windows/javac.html#com… [3] http://hg.openjdk.java.net/jdk9/jdk9/langtools/file/03e083639ee9/src/jdk.co…

5 25

Custom spliterator for Collections.nCopies(n, obj).stream()
by Tagir F. Valeev 22 Aug '15

22 Aug '15

Hello! Current implementation of Collections.nCopies().stream() is as follows: http://hg.openjdk.java.net/jdk9/dev/jdk/file/f160dec9a350/src/java.base/sha… public Stream<E> stream() { return IntStream.range(0, n).mapToObj(i -> element); } @Override public Stream<E> parallelStream() { return IntStream.range(0, n).parallel().mapToObj(i -> element); } The problem is that it adds a lambda expression to the RangeIntSpliterator type profile which can be polluted by some other code and vice versa: using nCopies().stream() may pollute the type profile for other code making it slower. Another thing which is missing in current implementation is unordered mode. This collection is unordered by nature, its stream is similar to Stream.generate(), so to my opinion it should be unordered which may improve the parallel reduction in some cases. This can be improved by introducing the custom spliterator class which is quite simple: https://gist.github.com/amaembo/62f3efee9923b1468e86 On pre-polluted type profile with simple mapping and reduction using custom spliterator is about 25-30% faster in both parallel and sequential cases as benchmarking shows (performed on 4-core cpu). What do you think? With best regards, Tagir Valeev.

2 5

[9] RFR: 8060717: [TESTBUG] Improve test coverage of MethodHandles.explicitCastArguments()
by Konstantin Shefov 14 Aug '15

14 Aug '15

Hello, Please review a test improvement. Covered more cases for MethodHandles.explicitCastArguments(). Bug: https://bugs.openjdk.java.net/browse/JDK-8060717 Webrev: http://cr.openjdk.java.net/~kshefov/8060717/webrev.00/ -Konstantin

3 9

Fwd: Re: RFR (M/L): 8131168: Refactor ProcessHandleImpl_*.c and add implememtation for AIX
by Roger Riggs 14 Aug '15

14 Aug '15

Hi Volker, Thanks for the refactoring and the AIX implementation. We still need a tie-breaker with respect to the issue of truncated/incomplete argument and executable values. On 7/24/2015 9:30 AM, Volker Simonis wrote: > Hi, > > so here comes the new webrev which cleanly applies to the current > jdk9-dev/jdk repo: > > http://cr.openjdk.java.net/~simonis/webrevs/2015/8131168.v2/ Comments: os_getParentPid() - the function name doesn't reflect the additional values returned. The time units on the starttime and cputime need should appear in the function header without having to refer to the declaration. os_getParentPid() - Within this function can the code that accesses the sysctl info be kept together. Perhaps move the rusage if/block before the if (sysctl) {...} Or just move the start time extraction to just before the return pid.. ProcessHandleImpl_unix.c: 138 and 140 - The macros should not include the trailing semicolon ";" (causes a unreachable compilation warning on Solaris 10) ProcessHandlmpl_unix.c: 401: extra semicolon ";;" (causes a warning about declarations after statements on Solaris 10). 691: Typo: Solris 730: separeted ProcessHandleImpl_unix:c: 358 - Info_info0 - it appears that the psinfo file is read twice. Once by unix_getUid and again by unix_getCmdLineInfo One aspect of the original code was to avoid opening and reading /proc files more than once/necessary. ProcessHandleImpl_unix.c: 691-700 - There is no point in doing a file lookup that is known to fail. This should be #ifdef/#ifndef'd to apply only to the appropriate OS. !! ProcessHandleImpl_unix: 709-738: I still disagree with returning truncated or incomplete values for the executable or arguments. Can anyone be a tie-breaker (with a good rational and suggestion for how an application can use the data). InfoTest.java: 139: Is this the best that can be done for checking the times on AIX? InfoTest.java:285 - mentions /proc/pid/status ; should that be /proc/pid/psinfo? ProcessHandleImpl_linux.c: 63: getUID and getCmdlineInfo both format the /proc file name and do a lookup of the file. The original version avoided doing the lookup twice in the same native call. Perhaps there is a refactoring that puts the extraction of the UID in with getting the command line. This might address the repeated reading of psinfo in ProcessHandleImpl_unix:358 as well. ProcessHandleImpl_unix.h is a new file and only needs a 2015 copyright date. Somewhere the unixs for the start and cputimes needs to be documented at the declaration. That is first pass on comments. Thanks, Roger > The good thing beforehand - although I added the AIX-port and a big > 50-line comment the new version is still 60 lines shorter :) > 10 files changed, 829 insertions(+), 999 deletions(-) > > The main idea behind the new code layout is as follows (see the > comment in ProcessHandleImpl_unix.c for more details): > > The currently supported Unix variants are Solaris, Linux, MaxOS X > and AIX. The various similarities and differences between these > systems make it hard to find a clear boundary between platform > specific and shared code. > > In order to ease code sharing between the platforms while still > keeping the code as clean as possible (i.e. free of preprocessor > macros) we use the following source code layout (remember that > ProcessHandleImpl_unix.c will be compiled on EVERY Unix platform > while ProcessHandleImpl_<os>.c will be only compiled on the > specific OS): > > - all the JNI wrappers for the ProcessHandleImpl functions go > into ProcessHandleImpl_unix.c file > > - if their implementation is common on ALL the supported Unix > platforms it goes right into the JNI wrappers > > - if the whole function or substantial parts of it are platform > dependent, the implementation goes into os_<function_name> > functions in ProcessHandleImpl_<os>.c > > - if at least two platforms implement an os_<function_name> > function in the same way, this implementation is factored out > into unix_<function_name>, placed into > ProcessHandleImpl_unix.c and called from the corresponding > os_<function_name> function. > > - For convenience, all the os_ and unix_ functions are declared > in ProcessHandleImpl_unix.h which is included into every > ProcessHandleImpl_<os>.c file. > > So ProcessHandleImpl_unix.c only contains code which is shared by at > least two platforms. Code which is specific to one single platform > goes into the corresponding ProcessHandleImpl_<os>.c file (and this > changes adds ProcessHandleImpl_aix.c for AIX-specific code and > ProcessHandleImpl_linux.c for Linux-specific code which was in > ProcessHandleImpl_unix.c previously). > > I tried to unify similar functions (e.g. > Java_java_lang_ProcessHandleImpl_00024Info_initIDs, > Java_java_lang_ProcessHandleImpl_isAlive0 or fillArgArray) into a > single instance in ProcessHandleImpl_unix.c. > > I renamed and unified getStatInfo() into > os_getParentPid()/unix_getParentPid() with three implemantions for > MacOSX, Linux and Solaris/AIX. > > I've factored out Java_java_lang_ProcessHandleImpl_getProcessPids0() > into os_getChildren()/unix_getChildren() with two implemantions - one > for MacOSX and one for Linux/Solaris/AIX. > > I've tested the new implementation on MacOSX, Linux (x86_64 and ppc64) > , Solaris 10/11 (x86_64 and Sparc) and AIX. > > The final point, which was already mentioned in the first review is > the fact that we can not easily get accurate information fort he > command line and arguments on AIX. I'd prefer to stay with the current > solution which gives "best effort" answers for these attributes but if > everybody’s opinion is that such information is useless I can also > omit it altogether. I haven’t looked at the other platforms which we > have to support (e.g. HPUX, AS/400) but the situation may be similar > there. > > Regards, > Volker >

3 17

RFR: 8132306: java/lang/ref/ReferenceEnqueue.java fails with "RuntimeException: Error: poll() returned null; expected ref object"
by Kim Barrett 11 Aug '15

11 Aug '15

Please review this fix of a race condition in j.l.r.Reference/ReferenceQueue. See comments in the bug report for a description of the race. The race is being fixed by reordering a pair of volatile assignments. CR: https://bugs.openjdk.java.net/browse/JDK-8132306 Webrev: http://cr.openjdk.java.net/~kbarrett/8132306/webrev.00/ Testing: jprt with default and hotspot testsets Locally tested race in original code by insertion of sleep in enqueue and verifying ReferenceEnqueue regression test fails consistently as described in the bug report. Locally tested fixed code by insertion of sleeps at various points and verifying ReferenceEnqueue regression test still passes.

6 27

Review request: JDK-8080108: [TEST_BUG] ERROR: No IPv6 address returned from platform
by Alexander Fomin 05 Aug '15

05 Aug '15

Hello, Please review the test bug fix https://bugs.openjdk.java.net/browse/JDK-8080108 See webrev here http://cr.openjdk.java.net/~kshefov/8080108/webrev.00/ The original test (com/sun/jndi/dns/IPv6NameserverPlatformParsingTest.java @bug 6991580) fails automatically if /etc/resolv.conf file doesn't contain IPv6 nameserver entries. It's needed to edit /etc/resolv.conf manually before the test run, so this is a manual regression test. The test is intended to be run on non-Windows systems. Fix: - provided standard test machinery for regression manual tests with instructions for a user; - the test excluded for Windows. Tested on Linux and Windows(to make sure it's excluded). Thanks, Alexander

2 4

RFR(s): 8132800: clarify stream package documentation regarding sequential vs parallel modes
by Stuart Marks 05 Aug '15

05 Aug '15

Hi all, The sequential() and parallel() methods on a stream set the execution mode for the entire pipeline. Unfortunately this isn't particularly clear from the documentation. This has been a recurring question. Please review this change to the java.util.stream package documentation to help clarify this point. I've also added a couple anchor tags that were missing from various sections. This is intended to be a purely editorial change, not a specification change. Bug: https://bugs.openjdk.java.net/browse/JDK-8132800 Webrev: http://cr.openjdk.java.net/~smarks/reviews/8132800/webrev.0/ Thanks, s'marks

3 8

RFR: JDK-8062849 -- Optimize EnumMap.equals
by Steve Drach 03 Aug '15

03 Aug '15

Please review the following simple fix for the issue reported in https://bugs.openjdk.java.net/browse/JDK-8062849 <https://bugs.openjdk.java.net/browse/JDK-8062849>. ----------------- # HG changeset patch # User sdrach # Date 1437777193 25200 # Fri Jul 24 15:33:13 2015 -0700 # Node ID e57b1569a65ec4dc8c749dedd3345abe5d493054 # Parent 4dd09cb5f7c2a2a23a9958ea7a602dd74d5709b2 8062849: Optimize EnumMap.equals Summary: In the equals method, if the two EnumMaps are a different size return false since they can't be equal. Reviewed-by: brent.christian(a)oracle.com, paul.sandoz(a)oracle.com Contributed-by: steve.drach(a)oracle.com diff --git a/src/java.base/share/classes/java/util/EnumMap.java b/src/java.base/share/classes/java/util/EnumMap.java --- a/src/java.base/share/classes/java/util/EnumMap.java +++ b/src/java.base/share/classes/java/util/EnumMap.java @@ -681,8 +681,11 @@ } private boolean equals(EnumMap<?,?> em) { + if (size != em.size) + return false; + if (em.keyType != keyType) - return size == 0 && em.size == 0; + return size == 0; // Key types match, compare each value for (int i = 0; i < keyUniverse.length; i++) {

4 3

Replacement for sun.misc.Unsafe.allocateInstance(Class<?>) ?
by Jörg Schaible 02 Aug '15

02 Aug '15

Hello guys, there's a lot of talk about making sun.misc.Unsafe unaccessible in JDK 9 ... however, there seems no replacement for the allocateInstance method. XStream is relying heavily on this functionality and without it the library will no longer be able to deserialize a lot of objects from XML. What are the long-term options? Cheers, jörg

5 5