July 2015 - core-libs-dev

Re: RFR: JDK-8114832 it.next on ArrayList throws wrong type of Exception after remove(-1)
by Fabian Lange 27 Jul '15

27 Jul '15

Hi Paul, > > I'm mildly opposed to this change - I added comments to the bug. > > > > It looks like you are not the only one. I am outnumbered :-) > > The behaviour of ArrayList.remove, and also ArrayList.removeRange, are > outliers [*]. It?s also a rather obscure difference behaviour with likely > minimal impact if changed (far less so than the change to Arrays.toList) . > There are other outliers too, add and Add all use a dedicated range check method (rangeCheckForAdd) which validates the argument > 0. Imho, the the rangeCheck method is incorrectly used in remove(int), because it says it is intended to be used immediately before the array access. I personally would vote to inline the rangeCheck methods and do the appropriate check in the former caller. as it turns out for every method a slightly different check would make most sense Fabian

1 0

RFR: 8132256: jaxp: Investigate removal of com/sun/org/apache/bcel/internal/util/ClassPath.java
by Daniel Fuchs 24 Jul '15

24 Jul '15

Hi, Please find below a patch that fixes 8132256: jaxp: Investigate removal of com/sun/org/apache/bcel/internal/util/ClassPath.java https://bugs.openjdk.java.net/browse/JDK-8132256 webrev: http://cr.openjdk.java.net/~dfuchs/webrev_8132256/webrev.00 The class com.sun.org.appache.bcel.internal.util.ClassPath does not seem to serve any useful purpose in JDK 9. - There's only one instance created, using its default empty constructor. - There's only one method called on that instance, from SyntheticRepository.java: _path.getInputStream(className); - Because _path was created using the default (and deprecated) empty constructor, and because ClassPath is loaded from the BCL (ClassPath.class.getClassLoader() == null), then _path.getInputStream(className) will always throw an IOException. Therefore - it seems that in the JDK - the use of com.sun.org.appache.bcel.internal.util.ClassPath is reduced to an elaborate means of throwing an IOException. The patch above arranges for the removal of com/sun/org/apache/bcel/internal/util/ClassPath.java best regards, -- daniel

2 1

RFR (M/L): 8131168: Refactor ProcessHandleImpl_*.c and add implememtation for AIX
by Volker Simonis 24 Jul '15

24 Jul '15

Hi, I worked on refactoring the native ProcessHandleImpl implementation to enable more code sharing and make it easier to add support for new platforms (e.g. AIX) and I think I had a pretty nice version running. But unfortunately I've just realized that the recent changes to ProcessHandleImpl (i.e. "8078099: (process) ProcessHandle should uniquely identify processes" and "8078108: (process) ProcessHandle.isAlive should be robust") have been massive so I have to start over to merge all my changes with the new version. But before doing that I just wanted to post my current changes which cleanly apply to the repo before 8078099 and ask for your opinion: http://cr.openjdk.java.net/~simonis/webrevs/2015/8131168.v1/ Here's a summary (taken from ProcesHandleImpl_unix.c) of what I've actually done (if the output appears scrambled in you mail better read it in the webrev http://cr.openjdk.java.net/~simonis/webrevs/2015/8131168.v1/src/java.base/u… ): /** * This file contains the implementation of the native ProcessHandleImpl * functions which are common to all Unix variants. * * 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 pltforms 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 this 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 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 this file 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. * * Example 1: * ---------- * The implementation of Java_java_lang_ProcessHandleImpl_00024Info_initIDs() * is the same on all platforms except on Linux where it initilizes one * additional field. So we place the implementation right into * Java_java_lang_ProcessHandleImpl_00024Info_initIDs() but add call to * os_init() at the end of the function which is empty on all platforms * except Linux where it performs the additionally initializations. * * Example 2: * ---------- * The implementation of Java_java_lang_ProcessHandleImpl_00024Info_info0 is * the same on Solaris and AIX but different on Linux and MacOSX. We therefore * simply call the two helpers os_getStatInfo() and os_getCmdlineInfo(). The * Linux and MaxOS X versions of these functions (in the corresponding files * ProcessHandleImpl_linux.c and ProcessHandleImpl_macosx.c) directly contain * the platform specific implementations while the Solaris and AIX * implementations simply call back to unix_getStatInfo() and * unix_getCmdlineInfo() which are implemented right in this file. * * The term "same implementation" is still a question of interpretation. It my * be acceptable to have a few ifdef'ed lines if that allows the sharing of a * huge function. On the other hand, if the platform specific code in a shared * function grows over a certain limit, it may be better to refactor that * functionality into corresponding, platform-specific os_ functions. */ This resulted in the new file ProcessHandleImpl_linux.c which now only contains Linux-only code which was previously in ifdefed for Linux in ProcessHandleImpl_linux.c. The advantage is that we now have only one version of: Java_java_lang_ProcessHandleImpl_00024Info_initIDs unix_fillArgArray unix_uidToUser and on version of unix_getChildren which is shared by Solaris, Linux and AIX and one version of unix_getStatInfo unix_getCmdlineInfo which are shared by Solaris and Linux. Additionally I've added the AIX port following the new schema and I've slightly improved the Solaris port to use the information from psinfo.pr_psargs for reporting at least the first 80 characters of the command line arguments. arg[0] from psinfo.pr_psargs is also used as the "command()" string in the case where "/proc/%d/path/a.out" isn't readable. This helps to report a command string for all the processes we do not own, because in that case, "/proc/%d/path/a.out" isn't readable. By the way, using args[0] as a fall-back for cmd beeing null also helps on MacOS X for processes we don't own. Finally I've also done some test improvements. I have tested all my changes on Linux/amd64, Linux/ppc64, MacOS X, Solaris and AIX. I'd be happy to forward port my changes to the newest head version if you generally agree with my approach (and give me a short time frame where you promise not to do any massive changes :) What do you think? Thank you and best regards, Volker

2 4

RFR JDK-8130914: java/util/zip/TestExtraTime.java fails with "java.lang.RuntimeException: setTime should make getLastModifiedTime return the specified instant: 3078282244456 got: 3078282244455"
by Xueming Shen 22 Jul '15

22 Jul '15

Hi, Please help review the change for JDK-8130914. issue: https://bugs.openjdk.java.net/browse/JDK-8130914 webrev: http://cr.openjdk.java.net/~sherman/8130914/ This is a "regression" triggered by https://bugs.openjdk.java.net/browse/JDK-8130914 http://cr.openjdk.java.net/~redestad/jdk9/8073497/webrev.6/ In which the change is to utilize a high 32-bit of the time value to store < 2000 ms time piece. It appears the offending timestamp (year 2067...) triggers the 32-bit "overflow" when converting java time to a 32-bit dos time. Thanks, -Sherman

4 6

Stream.generate
by Remi Forax 22 Jul '15

22 Jul '15

Hi all, hi Paul, I've found that the signature of Stream.generate doesn't to use a wildcard hence some program are rejected even if there are valid, by example: public static void main(String[] args) { Supplier<String> supplier = () -> "hello"; Stream<CharSequence> s = Stream.generate(supplier); } The fix is simple, in interface Stream, generate should be declared like this : public static<T> Stream<T> generate(Supplier<? extends T> s) and the field 's' of the InfiniteSupplyingSpliterator.OfRef should be also declared as a Supplier<? extends T>. regards, Rémi

2 4

RFR (jaxp) 8131907 : Numerous threads lock during XML processing
by huizhe wang 21 Jul '15

21 Jul '15

Please review a change that removes unnecessary class loading. http://cr.openjdk.java.net/~joehw/jdk9/8131907/webrev/ Thanks, Joe

3 4

RFR for 8068761 : Test java/nio/channels/ServerSocketChannel/AdaptServerSocket.java failed with SocketTimeoutException
by Tristan Yan 21 Jul '15

21 Jul '15

Hi Please review small fix for test java/nio/channels/ServerSocketChannel/AdaptServerSocket.java. webrev: http://cr.openjdk.java.net/~tyan/8068761/webrev/ <http://cr.openjdk.java.net/~tyan/8068761/webrev/> bug: https://bugs.openjdk.java.net/browse/JDK-8068761 <https://bugs.openjdk.java.net/browse/JDK-8068761> Thanks Tristan

2 1

[9] RFR: 8130006: java/lang/invoke/MethodHandles/CatchExceptionTest Fails
by Konstantin Shefov 21 Jul '15

21 Jul '15

Hello, Please review a test bug fix. An exception caused by code cache overflow should be re-thrown before assertion check in the test. Bug: https://bugs.openjdk.java.net/browse/JDK-8130006 Webrev: http://cr.openjdk.java.net/~kshefov/8130006/webrev.00/ -Konstantin

2 2

JDK 9 RFR of JDK-8081734 : ConcurrentHashMap/ConcurrentAssociateTest.java, times out 90% of time on sparc with 256 cpu.
by joe darcy 20 Jul '15

20 Jul '15

Hello, Please review a small change to adders JDK-8081734 : ConcurrentHashMap/ConcurrentAssociateTest.java, times out 90% of time on sparc with 256 cpu. http://cr.openjdk.java.net/~darcy/8081734.0/ Patch below. Some background, when run on large machines, 256 processors/threads, this test takes many minutes to run due to hitting some degenerate conditions. Bounding the concurrency to 32 serves the purposes of checking for the conditions the test was written for while also allowing a reasonable execution time for a single test. Thanks, -Joe --- old/test/java/util/concurrent/ConcurrentHashMap/ConcurrentAssociateTest.java 2015-07-20 14:08:23.839018642 -0700 +++ new/test/java/util/concurrent/ConcurrentHashMap/ConcurrentAssociateTest.java 2015-07-20 14:08:23.679018638 -0700 @@ -120,7 +120,8 @@ } }; - int ps = Runtime.getRuntime().availableProcessors(); + // Bound concurrency to avoid degenerate performance + int ps = Math.min(Runtime.getRuntime().availableProcessors(), 32); Stream<CompletableFuture> runners = IntStream.range(0, ps) .mapToObj(i -> sr.get()) .map(CompletableFuture::runAsync);

2 1

StackOverflowError on HashMap.hashCode() due to self reference
by Krystal Mok 20 Jul '15

20 Jul '15

Hi everyone, I'm sure somebody has seen this stack overflow before. My question is: is it expected (which should be documented to warn people not to do this), or is it considered a bug (which should be fixed)? Example: https://gist.github.com/rednaxelafx/930f8979473185cfc0a0 import java.util.*; public class HashMapStackOverflow { public static void main(String[] args) throws Exception { HashMap<String, Object> map = new HashMap<>(); map.put("self", map); System.out.println(map.hashCode()); } } $ ~/sdk/jdk1.8.0/Contents/Home/bin/java HashMapStackOverflow Exception in thread "main" java.lang.StackOverflowError at java.util.AbstractMap.hashCode(AbstractMap.java:505) at java.util.Objects.hashCode(Objects.java:98) at java.util.HashMap$Node.hashCode(HashMap.java:296) at java.util.AbstractMap.hashCode(AbstractMap.java:507) at java.util.Objects.hashCode(Objects.java:98) at java.util.HashMap$Node.hashCode(HashMap.java:296) at java.util.AbstractMap.hashCode(AbstractMap.java:507) at java.util.Objects.hashCode(Objects.java:98) at java.util.HashMap$Node.hashCode(HashMap.java:296) at java.util.AbstractMap.hashCode(AbstractMap.java:507) ... This will cause a stack overflow because HashMap.hashCode() is inherited from AbstractMap, which sums the hash code of each entry, while one of the entries is itself so it goes recursive. Thanks, Kris

4 5