March 2013 - core-libs-dev

hg: jdk8/tl/jdk: 8010309: Improve PlatformLogger.isLoggable performance by direct mapping from an integer to Level
by mandy.chung＠oracle.com 03 Apr '13

03 Apr '13

Changeset: e433ed08b733 Author: mchung Date: 2013-03-28 13:14 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e433ed08b733 8010309: Improve PlatformLogger.isLoggable performance by direct mapping from an integer to Level Reviewed-by: mchung Contributed-by: peter.levart(a)gmail.com, bourges.laurent(a)gmail.com ! src/share/classes/sun/util/logging/PlatformLogger.java ! test/sun/util/logging/PlatformLoggerTest.java

5 6

RFR: JDK-8007799 Base64.getEncoder(0, byte[]) returns encoder that unexpectedly inserts line separator when using some of the encoding methods
by Mark Sheppard 02 Apr '13

02 Apr '13

Hi, please oblige and review the webrev below as a fix for the issue raised in JDK-8007799 http://cr.openjdk.java.net/~msheppar/8007799/webrev.00/ Description: "Specification for the method java.util.Base64.getEncoder(int lineLength, byte[] lineSeparator) says: Parameters: lineLength - the length of each output line (rounded down to nearest multiple of 4). If lineLength <= 0 the output will not be separated in lines However if a zero line length is specified encoding methods wrap() and encode(ByteBuffer src, ByteBuffer dst, int bytesOut) return encoded string which starts from the given line separator. " the patch adds a check for linemax > 0 whenever a line separator might be added, and adds an new test case. regards Mark

2 2

RFR JDK-8010096 : Initial java.util.Spliterator putback
by Paul Sandoz 02 Apr '13

02 Apr '13

Hi, http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8010096 Webrev: http://cr.openjdk.java.net/~psandoz/lambda/spliterator/jdk-8010096/webrev/ Spec diff: http://cr.openjdk.java.net/~psandoz/lambda/spliterator/jdk-8010096/specdiff… Relevant JavaDoc generated from lambda repo (required for viewing @apiNote, @implSpec, @implNote declarations): http://cr.openjdk.java.net/~psandoz/lambda/spliterator/jdk-8010096/api/java/ Note: some of the JavaDoc generated from the lambda repo may contain additional methods or specification that is relevant to the stream framework. -- To enable bulk operations, in parallel, on a data source it is required that such a source efficiently partition itself into smaller parts, where parts are processed concurrently, and each part is traversed sequentially. A new data interface is required that defines the contract for efficient partitioning and traversal. Collections need to implement that new data interface so the JSR-335 stream library can support bulk operations on common collection implementations, such as List/Set and arrays, in addition to other forms of data source e.g. third party collections. java.util.Spliterator, and primitive specializations of, is the key data interface that enables partitioning and traversal. JSR-335 java.util.stream.Stream instances will be constructed from spliterators. Collection is extended to define the default method spliterator(). Implementations are expected to override this method. The default implementation utilizes the collection's iterator and size to provide a spliterator implementation that permits limited parallism. Default overriding implementations are also provided for List, Set and SortedSet that support additional properties associated with those collections. Together with Spliterator some implementations are provided for creating Spliterator instances from data sources that are iterators and arrays. Note: Optimal spliterator implementations for many collection implementations in java.util and java.util.concurrent are present in the lambda repository and will duly make their way into TL after this webrev has been reviewed and pushed. -- Once this webrev is reviewed and pushed then the Stream API can follow, and then the fun really begins :-) The class com.sun.tools.jdi/EventSetImpl has been modified but is likely to change when spliterator implementations are pushed. This class cannot decide if it wants to be a List or a Set!! The compiler cannot work out if the default implementation of spliterator() for List or Set should apply. When the concrete collection implementations of spliterator arrive this class will not need to implement spliterator() and will inherit the implementation from ArrayList (implementations on classes always win over default implementations on interfaces). Unfortunately to build TL with this patch applied requires one also apply: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/fbcafacf92ef Which i suspect was lost in the wash and should have been pushed to TL a while ago. Will follow up with Robert on that one. A JPRT of TL with both patches applied did not show any abnormal test failures. Paul.

5 6

Codereview Request for 8007379: Base64.getMimeDecoder().decode() throws IAE for a non-base64 character after padding
by Xueming Shen 02 Apr '13

02 Apr '13

Hi, Please help review the fix for the following two bugs: (1) 8007379: Base64.getMimeDecoder().decode() throws IAE for a non-base64 character after padding We fixed the similar issue in 8006530, it appears there is "yet another" corner case to close here. As described in the bug report, the calculation for output buffer size for such case is incorrect when decoding in mime mode. The proposed change should fix the problem. (2) 8008925: Base64.getMimeDecoder().decode() does not ignore padding chars The change is to clarify the specification that "the padding character(s) is not required for decoding. BUT, if the padding character(s) does appear, they must be correctly encoded." http://cr.openjdk.java.net/~sherman/8007379_8008925/webrev Thanks, -Sherman

2 2

Review Request 8007035: Deprecate SecurityManager.checkMemberAccess
by Mandy Chung 02 Apr '13

02 Apr '13

Sean, John, Joe, Can you review this fix todeprecatesthe |SecurityManager.checkMemberAccess| method as proposed in http://openjdk.java.net/jeps/176? Webrev at: http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8007035/webrev.00 Specdiff: http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8007035/specdiff The |checkMemberAccess| method requires the caller’s frame to be at a stack depth of four, which is fragile and difficult to enforce. The fix deprecates the SecurityManager.checkMemberAccess method and will throw an exception unconditionally in a future release.There are several methods in java.lang.Class and the class spec of java.lang.invoke.MethodHandles.Lookup in the JDK specify to call SecurityManager.checkMemberAccess. The spec and implementation are updated to do the appropriate permission check. SecurityManager.checkMemberAccess is not final and it can be overridden by a subclass. However, we believe a SecurityManager subclass implementation that overrides the checkMemberAccess method and behaves differently than the default implementation is very rare. Thus we decide not to handle the SecurityManager subclass case that overrids the checkMemberAccess method with this fix and the compatibility risk should be low. Thanks Mandy

2 1

Review JDK-8010837 - TEST_BUG: java/io/FileInputStream/LargeFileAvailable.java fails intermittently
by Dan Xu 02 Apr '13

02 Apr '13

Hi All, In the old JVM function, os::available, it could return negative values because lseek() allows the file offset to be set beyond the end of a file. In the previous change of removing jvm functions, I wasn't aware of that and regardnegative values as invalid and return 0, which causes this test failed if it handles negative values. This fixaddressedthis problem and added a new testcase to ensure the correctbehaviour when available() encounters negative values. Webrev: http://cr.openjdk.java.net/~dxu/8010837/webrev/ Thanks, -Dan

3 4

hg: jdk8/tl/jdk: 8010846: Update the corresponding test in test/vm/verifier/TestStaticIF.java
by karen.kinnear＠oracle.com 31 Mar '13

31 Mar '13

Changeset: d254a5f9b93f Author: acorn Date: 2013-03-27 13:40 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d254a5f9b93f 8010846: Update the corresponding test in test/vm/verifier/TestStaticIF.java Summary: Remove test flag -XX:-UseSplitVerifier, not supported classfile 52 Reviewed-by: acorn, hseigel ! test/vm/verifier/TestStaticIF.java

2 1

[OpenJDK 2D-Dev] sun.java2D.pisces big memory usage (waste ?)
by Laurent Bourgès 30 Mar '13

30 Mar '13

Dear all, First I joined recently the openJDK contributors, and I plan to fix java2D pisces code in my spare time. I have a full time job on Aspro2: http://www.jmmc.fr/aspro; it is an application to prepare astronomical observations at VLTI / CHARA and is very used in our community (200 users): it provides scientific computations (observability, model images using complex numbers ...) and zoomable plots thanks to jFreeChart. Aspro2 is known to be very efficient (computation parallelization) and I am often doing profiling using netbeans profiler or visualVM. To fix huge memory usages by java2d.pisces, I started implementing an efficient ArrayCache (int[] and float[]) (in thread local to concurrency problems): - arrays in sizes between 10 and 10000 (more small arrays used than big ones) - resizing support (Arrays.copyOf) without wasting arrays - reentrance i.e. many arrays are used at the same time (java2D Pisces stroke / dash creates many segments to render) - GC / Heap friendly ie support cache eviction and avoid consuming too much memory I know object pooling is known to be not efficient with recent VM (GC is better) but I think it is counter productive to create so many int[] arrays in java2d.pisces and let the GC remove such wasted memory. Does someone have implemented such (open source) array cache (core-libs) ? Opinions are welcome (but avoid "trolls"). Moreover, sun.java2d.pisces.Helpers.widenArray() performs a lot of array resizing / copy (Arrays.copyOf) that I want to avoid mostly: // These use a hardcoded factor of 2 for increasing sizes. Perhaps this // should be provided as an argument. static float[] widenArray(float[] in, final int cursize, final int numToAdd) { if (in.length >= cursize + numToAdd) { return in; } return Arrays.copyOf(in, 2 * (cursize + numToAdd)); } static int[] widenArray(int[] in, final int cursize, final int numToAdd) { if (in.length >= cursize + numToAdd) { return in; } return Arrays.copyOf(in, 2 * (cursize + numToAdd)); } Thanks to Peter Levart, I use its microbench tool ( https://github.com/plevart/micro-bench/tree/v2) to benchmark ArrayCache operations... and J2DBench to test java2d performances What is the fastest way to clear an array (part) ie fill by 0: - public static void fill(int[] a, int fromIndex, int toIndex, int val) - public static native void arraycopy(Object src, int srcPos, Object dest, int destPos, int length); - unsafe.setMemory(array, Unsafe.ARRAY_INT_BASE_OFFSET, 512 * SIZEOF_INT, (byte) 0) Apparently, Arrays.fill is always faster (size in 10 ... 10 000) ! I suspect hotspot to optimize its code and use native functions, isn't it ??? Benchmarks results: >> JVM START: 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22] Testing arrays: int[1]... # # ZeroFill: run duration: 5 000 ms, #of logical CPUS: 4 # # Warm up: runTest[class ArrayCacheBenchmark$ZeroFill] on JVM: 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22] 1 threads, Tavg = 4,47 ns/op (σ = 0,00 ns/op) [ 4,47] runTest[class ArrayCacheBenchmark$ZeroFill] on JVM: 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22] 1 threads, Tavg = 4,40 ns/op (σ = 0,00 ns/op) [ 4,40] # Measure: runTest[class ArrayCacheBenchmark$ZeroFill] on JVM: 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22] 1 threads, Tavg = 4,43 ns/op (σ = 0,00 ns/op) [ 4,43] runTest[class ArrayCacheBenchmark$ZeroFill] on JVM: 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22] 2 threads, Tavg = 5,55 ns/op (σ = 0,16 ns/op) [ 5,40, 5,72] # # FillArraySystemCopy: run duration: 5 000 ms, #of logical CPUS: 4 # # Warm up: runTest[class ArrayCacheBenchmark$FillArraySystemCopy] on JVM: 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22] 1 threads, Tavg = 6,47 ns/op (σ = 0,00 ns/op) [ 6,47] runTest[class ArrayCacheBenchmark$FillArraySystemCopy] on JVM: 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22] 1 threads, Tavg = 6,21 ns/op (σ = 0,00 ns/op) [ 6,21] # Measure: runTest[class ArrayCacheBenchmark$FillArraySystemCopy] on JVM: 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22] 1 threads, Tavg = 6,19 ns/op (σ = 0,00 ns/op) [ 6,19] runTest[class ArrayCacheBenchmark$FillArraySystemCopy] on JVM: 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22] 2 threads, Tavg = 7,80 ns/op (σ = 0,10 ns/op) [ 7,90, 7,71] # # FillArrayUnsafe: run duration: 5 000 ms, #of logical CPUS: 4 # # Warm up: runTest[class ArrayCacheBenchmark$FillArrayUnsafe] on JVM: 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22] 1 threads, Tavg = 26,82 ns/op (σ = 0,00 ns/op) [ 26,82] runTest[class ArrayCacheBenchmark$FillArrayUnsafe] on JVM: 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22] 1 threads, Tavg = 23,48 ns/op (σ = 0,00 ns/op) [ 23,48] # Measure: runTest[class ArrayCacheBenchmark$FillArrayUnsafe] on JVM: 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22] 1 threads, Tavg = 22,42 ns/op (σ = 0,00 ns/op) [ 22,42] runTest[class ArrayCacheBenchmark$FillArrayUnsafe] on JVM: 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22] 2 threads, Tavg = 28,21 ns/op (σ = 0,88 ns/op) [ 29,11, 27,36] Testing arrays: int[100]... # # ZeroFill: run duration: 5 000 ms, #of logical CPUS: 4 # # Warm up: runTest[class ArrayCacheBenchmark$ZeroFill] on JVM: 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22] 1 threads, Tavg = 16,49 ns/op (σ = 0,00 ns/op) [ 16,49] runTest[class ArrayCacheBenchmark$ZeroFill] on JVM: 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22] 1 threads, Tavg = 15,97 ns/op (σ = 0,00 ns/op) [ 15,97] # Measure: runTest[class ArrayCacheBenchmark$ZeroFill] on JVM: 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22] 1 threads, Tavg = 16,03 ns/op (σ = 0,00 ns/op) [ 16,03] runTest[class ArrayCacheBenchmark$ZeroFill] on JVM: 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22] 2 threads, Tavg = 19,32 ns/op (σ = 0,46 ns/op) [ 18,87, 19,80] # # FillArraySystemCopy: run duration: 5 000 ms, #of logical CPUS: 4 # # Warm up: runTest[class ArrayCacheBenchmark$FillArraySystemCopy] on JVM: 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22] 1 threads, Tavg = 14,51 ns/op (σ = 0,00 ns/op) [ 14,51] runTest[class ArrayCacheBenchmark$FillArraySystemCopy] on JVM: 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22] 1 threads, Tavg = 14,17 ns/op (σ = 0,00 ns/op) [ 14,17] # Measure: runTest[class ArrayCacheBenchmark$FillArraySystemCopy] on JVM: 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22] 1 threads, Tavg = 14,09 ns/op (σ = 0,00 ns/op) [ 14,09] runTest[class ArrayCacheBenchmark$FillArraySystemCopy] on JVM: 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22] 2 threads, Tavg = 31,15 ns/op (σ = 4,04 ns/op) [ 27,65, 35,67] # # FillArrayUnsafe: run duration: 5 000 ms, #of logical CPUS: 4 # # Warm up: runTest[class ArrayCacheBenchmark$FillArrayUnsafe] on JVM: 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22] 1 threads, Tavg = 52,32 ns/op (σ = 0,00 ns/op) [ 52,32] runTest[class ArrayCacheBenchmark$FillArrayUnsafe] on JVM: 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22] 1 threads, Tavg = 52,82 ns/op (σ = 0,00 ns/op) [ 52,82] # Measure: runTest[class ArrayCacheBenchmark$FillArrayUnsafe] on JVM: 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22] 1 threads, Tavg = 52,19 ns/op (σ = 0,00 ns/op) [ 52,19] runTest[class ArrayCacheBenchmark$FillArrayUnsafe] on JVM: 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22] 2 threads, Tavg = 70,87 ns/op (σ = 0,71 ns/op) [ 70,17, 71,59] Testing arrays: int[10000]... # # ZeroFill: run duration: 5 000 ms, #of logical CPUS: 4 # # Warm up: runTest[class ArrayCacheBenchmark$ZeroFill] on JVM: 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22] 1 threads, Tavg = 1 208,64 ns/op (σ = 0,00 ns/op) [ 1 208,64] runTest[class ArrayCacheBenchmark$ZeroFill] on JVM: 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22] 1 threads, Tavg = 1 238,01 ns/op (σ = 0,00 ns/op) [ 1 238,01] # Measure: runTest[class ArrayCacheBenchmark$ZeroFill] on JVM: 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22] 1 threads, Tavg = 1 235,81 ns/op (σ = 0,00 ns/op) [ 1 235,81] runTest[class ArrayCacheBenchmark$ZeroFill] on JVM: 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22] 2 threads, Tavg = 1 325,11 ns/op (σ = 7,01 ns/op) [ 1 332,16, 1 318,14] # # FillArraySystemCopy: run duration: 5 000 ms, #of logical CPUS: 4 # # Warm up: runTest[class ArrayCacheBenchmark$FillArraySystemCopy] on JVM: 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22] 1 threads, Tavg = 1 930,93 ns/op (σ = 0,00 ns/op) [ 1 930,93] runTest[class ArrayCacheBenchmark$FillArraySystemCopy] on JVM: 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22] 1 threads, Tavg = 2 060,80 ns/op (σ = 0,00 ns/op) [ 2 060,80] # Measure: runTest[class ArrayCacheBenchmark$FillArraySystemCopy] on JVM: 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22] 1 threads, Tavg = 2 105,21 ns/op (σ = 0,00 ns/op) [ 2 105,21] runTest[class ArrayCacheBenchmark$FillArraySystemCopy] on JVM: 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22] 2 threads, Tavg = 2 160,33 ns/op (σ = 13,74 ns/op) [ 2 146,68, 2 174,15] # # FillArrayUnsafe: run duration: 5 000 ms, #of logical CPUS: 4 # # Warm up: runTest[class ArrayCacheBenchmark$FillArrayUnsafe] on JVM: 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22] 1 threads, Tavg = 3 099,50 ns/op (σ = 0,00 ns/op) [ 3 099,50] runTest[class ArrayCacheBenchmark$FillArrayUnsafe] on JVM: 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22] 1 threads, Tavg = 3 041,81 ns/op (σ = 0,00 ns/op) [ 3 041,81] # Measure: runTest[class ArrayCacheBenchmark$FillArrayUnsafe] on JVM: 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22] 1 threads, Tavg = 3 068,34 ns/op (σ = 0,00 ns/op) [ 3 068,34] runTest[class ArrayCacheBenchmark$FillArrayUnsafe] on JVM: 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22] 2 threads, Tavg = 3 296,13 ns/op (σ = 34,97 ns/op) [ 3 331,47, 3 261,53] PS: java.awt.geom.Path2D has also memory allocation issues: void needRoom(boolean needMove, int newCoords) { if (needMove && numTypes == 0) { throw new IllegalPathStateException("missing initial moveto "+ "in path definition"); } int size = pointTypes.length; if (numTypes >= size) { int grow = size; if (grow > EXPAND_MAX) { grow = EXPAND_MAX; } pointTypes = Arrays.copyOf(pointTypes, size+grow); } size = floatCoords.length; if (numCoords + newCoords > size) { int grow = size; if (grow > EXPAND_MAX * 2) { grow = EXPAND_MAX * 2; } if (grow < newCoords) { grow = newCoords; } floatCoords = Arrays.copyOf(floatCoords, size+grow); } } Best regards, Laurent

4 12

Spliterator flags as enum (was Initial java.util.Spliterator putback)
by Tim Peierls 29 Mar '13

29 Mar '13

I can't find a discussion of why Spliterator flags are ints rather than enum. The only thing coming close is this months-old update from Brian: *Sept 25, 2012 - Oct 24, 2012* > *... > **Stream flags improvements (Paul). *Added an "encounter order" flag. > Define flags with an enum. Make flags into declarative properties of Ops, > where an op can declare that they preserve, inject, or clear a given flag, > and move responsibility for flag computation into AbstractPipeline. Pass > flags to wrap{Sink,Iterator} so they can act on the current set of flags. But that was in another country, and besides, the Ops are dead. Is there anything more recent about this? I'm prepared to hear that it's for performance reasons, but there should at least be a record of the process through which this was determined. --tim

6 9

JDK-8010495: Update JAXP NetBeans project - add support for generating javadoc
by Daniel Fuchs 29 Mar '13

29 Mar '13

Hi guys, I'd like to propose a small change to jaxp/build.xml and jaxp/nbproject/project.xml - in order to allow editing JAXP sources in NetBeans, as well as generating the JAXP javadoc for previewing purposes. I actually stole the javadoc target from jdk/make/netbeans/common/shared.xml The changes are small & targeted at developers. There should be no impact on the build process. Here is the webrev: http://cr.openjdk.java.net/~dfuchs/JDK-8010495/jdk8/webrev.00/ best regards, -- daniel

2 7