August 2015 - core-libs-dev

RFR [9] 8133459: replace <tt> tags (obsolete in html5) in java.nio docs
by Alexander Stepanov 12 Aug '15

12 Aug '15

Hello, Could you please review the following fix: http://cr.openjdk.java.net/~avstepan/8133459/webrev.00/index.html for https://bugs.openjdk.java.net/browse/JDK-8133459 Just a next portion of deprecated '<tt>' tags replaced (didn't touch all these multiple ' 's to avoid undesirable formatting changes). specdiff did not detect any changes in java.nio.* Regards, Alexander

2 2

Documentation nit for JDK-8023862
by Ben Horstman 12 Aug '15

12 Aug '15

According to JDK-8023862, system property "java.rmi.server.disableHttp" is true in Java 8 (i.e., proxy is disabled by default). However, the java.rmi properties page still lists the value as false: http://docs.oracle.com/javase/8/docs/technotes/guides/rmi/javarmiproperties… . I think that page should be updated to indicate the new default value of true. Regards, ~benjamin ************************ Benjamin Philip Horstman Software Lead - Rho Team MIM Software Inc.

1 0

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

RFR JDK-8039390: Unexpected behaviour of String.format with null arguments
by Xueming Shen 11 Aug '15

11 Aug '15

Hi, Please help review fix for issue: https://bugs.openjdk.java.net/browse/JDK-8039390 webrev: http://cr.openjdk.java.net/~sherman/8039390 The j.u.Formatter implementation outputs "null/Null" for all conversions if the argument is null (except 'b'/'B', in which the result is "false/FALSE"). However the API doc only explicitly specifies this behavior for 'b', 'h' and 's'. With the "Unless otherwise specified, passing a null argument to any method or constructor in this class will cause a NullPointerException to be thrown" at the bottom of the spec, it is confusing which one should be the expected behavior. The proposed change here is to add explicit wording to cover all conversions. (Will go through CCC is approved here). Thanks, Sherman

2 1

[JDK-8080741] sigsegv while heap dumping in java_lang_Class::signers(oopDesc*)+0x1b
by Bernd 11 Aug '15

11 Aug '15

Hello, very similiar to JDK-8080741 we had a crash with 8u51 on Linux. It looks like it is happening while dumping the heap in a out of memory condition. The bug talks about it is happenign on constrained heap, but it looks more like related to OutOfMemory dumps (in both cases). https://bugs.openjdk.java.net/browse/JDK-8080741 I do have a corefile and a javacore hs_err file, butcant post it publically. Do you think it is worth to reconsider opening that bug again (its closed as incomplete currently)? Let me know if you need more extracts from the log. # Java VM: Java HotSpot(TM) 64-Bit Server VM (25.51-b03 mixed mode linux-amd64 compressed oops) # Problematic frame: # V [libjvm.so+0x683c5b] java_lang_Class::signers(oopDesc*)+0x1b ... Stack: [0x00007fc56d05c000,0x00007fc56d15d000], sp=0x00007fc56d15b740, free space=1021k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0x683c5b] java_lang_Class::signers(oopDesc*)+0x1b V [libjvm.so+0x611072] DumperSupport::dump_class_and_array_classes(DumpWriter*, Klass*)+0xb2 V [libjvm.so+0x461d36] ClassLoaderDataGraph::classes_do(void (*)(Klass*))+0x36 V [libjvm.so+0x6144ce] VM_HeapDumper::doit()+0x23e V [libjvm.so+0xab5d25] VM_Operation::evaluate()+0x55 V [libjvm.so+0xab40fa] VMThread::evaluate_operation(VM_Operation*)+0xba V [libjvm.so+0xab447e] VMThread::loop()+0x1ce V [libjvm.so+0xab48f0] VMThread::run()+0x70 V [libjvm.so+0x911048] java_start(Thread*)+0x108 VM_Operation (0x00007fc52d6592a0): HeapDumper, mode: safepoint, requested by thread 0x00007fc41dbc5000 Other Threads: =>0x00007fc5a969b800 VMThread [stack: 0x00007fc56d05c000,0x00007fc56d15d000] [id=43113] Heap: garbage-first heap total 16777216K, used 16640829K [0x00000003c0000000, 0x00000003c0804000, 0x00000007c0000000) region size 8192K, 0 young (0K), 0 survivors (0K) Metaspace used 132422K, capacity 147372K, committed 150824K, reserved 1179648K class space used 15699K, capacity 20230K, committed 20888K, reserved 1048576K ... GC Heap History (10 events): Event: 56981.031 GC heap before {Heap before GC invocations=922 (full 190): garbage-first heap total 16777216K, used 16640829K [0x00000003c0000000, 0x00000003c0804000, 0x00000007c0000000) region size 8192K, 0 young (0K), 0 survivors (0K) Metaspace used 132416K, capacity 147372K, committed 150824K, reserved 1179648K class space used 15698K, capacity 20230K, committed 20888K, reserved 1048576K Event: 56981.063 GC heap after Heap after GC invocations=923 (full 190): garbage-first heap total 16777216K, used 16640829K [0x00000003c0000000, 0x00000003c0804000, 0x00000007c0000000) region size 8192K, 0 young (0K), 0 survivors (0K) Metaspace used 132416K, capacity 147372K, committed 150824K, reserved 1179648K class space used 15698K, capacity 20230K, committed 20888K, reserved 1048576K } Event: 56981.108 GC heap before {Heap before GC invocations=923 (full 190): garbage-first heap total 16777216K, used 16640829K [0x00000003c0000000, 0x00000003c0804000, 0x00000007c0000000) region size 8192K, 0 young (0K), 0 survivors (0K) Metaspace used 132420K, capacity 147372K, committed 150824K, reserved 1179648K class space used 15699K, capacity 20230K, committed 20888K, reserved 1048576K Internal exceptions (10 events): Event: 56980.917 Thread 0x00007fc55bb3f000 Exception <a 'java/lang/NoSuchMethodError': <clinit>> (0x00000007bfa969b0) thrown at [/HUDSON/workspace/8-2-build-linux-amd64/jdk8u51/3951/hotspot/src/share/vm/prims/jni.cpp, line 1598] Event: 56980.917 Thread 0x00007fc51c8af000 Exception <a 'java/lang/NoSuchMethodError': <clinit>> (0x00000007bfa39b38) thrown at [/HUDSON/workspace/8-2-build-linux-amd64/jdk8u51/3951/hotspot/src/share/vm/prims/jni.cpp, line 1598] ... OS:LSB_VERSION="core-2.0-noarch:core-3.2-noarch:core-4.0-noarch:core-2.0-x86_64:core-3.2-x86_64:core-4.0-x86_64" uname:Linux 3.0.101-0.35-default #1 SMP Wed Jul 9 11:43:04 UTC 2014 (c36987d) x86_64 libc:glibc 2.11.3 NPTL 2.11.3 rlimit: STACK 8192k, CORE infinity, NPROC 16384, NOFILE 65535, AS 122580320k load average:2.57 2.05 2.90 ... vm_info: Java HotSpot(TM) 64-Bit Server VM (25.51-b03) for linux-amd64 JRE (1.8.0_51-b16), built on Jun 8 2015 19:28:07 by "java_re" with gcc 4.3.0 20080428 (Red Hat 4.3.0-8)

1 0

RFR(XS): 8133105: Fix getFinalAttributes() on Windows to handle more special cases
by Volker Simonis 11 Aug '15

11 Aug '15

Hi, can somebody please review the following small fix contributed by matthias.baesken(a)sap.com: http://cr.openjdk.java.net/~simonis/webrevs/2015/8133105/ https://bugs.openjdk.java.net/browse/JDK-8133105 Getting file attributes on Windows via GetFileAttributesExW() can fail for some special system files. There is already code in getFinalAttributes() which handles some of these special cases by using FindFirstFileW(). However there are still cases which are not covered until now. For example on PGP WDE (Whole Disk Encryption) – encrypted machines the test java/io/File/WinSpecialFiles still fails for PGP files like C:\pgpwde01. This small change fixes the issue. Thank you and best regards, Volker

2 3

JDK 9 RFR of JDK-8133231: Mark TimeoutLockLoops.java as failing intermittently
by joe darcy 09 Aug '15

09 Aug '15

Hello, The test java/util/concurrent/locks/ReentrantLock/TimeoutLockLoops.java is failing intermittently on Linux (JDK-8029453), apparently due to the HotSpot change JDK-8130728. Until the underlying issues are addressed, I'd like to mark the test as "@key intermittent" to aid failure analysis: diff -r e1aa58e9592c test/java/util/concurrent/locks/ReentrantLock/TimeoutLockLoops.java --- a/test/java/util/concurrent/locks/ReentrantLock/TimeoutLockLoops.java Fri Aug 07 16:09:10 2015 -0700 +++ b/test/java/util/concurrent/locks/ReentrantLock/TimeoutLockLoops.java Sun Aug 09 11:30:45 2015 -0700 @@ -35,6 +35,7 @@ * @test * @bug 4486658 5031862 * @run main TimeoutLockLoops + * @key intermittent * @summary Checks for responsiveness of locks to timeouts. * Runs under the assumption that ITERS computations require more than * TIMEOUT msecs to complete, which seems to be a safe assumption for Thanks, -Joe

2 1

RFR 9: 8133022: Instant.toEpochMilli() silently overflows
by Roger Riggs 06 Aug '15

06 Aug '15

Please review a small fix and test for Instant.toEpochMilli ArithmeticOverflow. Webrev: http://cr.openjdk.java.net/~rriggs/webrev-overflow-8133022/ Issue: https://bugs.openjdk.java.net/browse/JDK-8133022 Thanks, Roger

8 11

RFR JDK-8022224: Intermittent test failures in sun/nio/cs/FindDecoderBugs.java, ,
by Xueming Shen 06 Aug '15

06 Aug '15

Hi, Would you please help review the proposed change for JDK-8022224. issue: https://bugs.openjdk.java.net/browse/JDK-8022224 webrev: http://cr.openjdk.java.net/~sherman/8022224/ The fix for this particular problem is at ln#135-#137. The rest is the clean to remove unused the code (was for the sun.nio.cs impl, which had been completely removed since jdk7). Thanks, -Sherman

3 4

RFR [9] 8133115: docs: replace <tt> tags (obsolete in html5) for java.util.logging, java.util.prefs, java.util.zip, java.util.jar
by Alexander Stepanov 06 Aug '15

06 Aug '15

Hello, Could you please review the following fix: http://cr.openjdk.java.net/~avstepan/8133115/webrev.00 for https://bugs.openjdk.java.net/browse/JDK-8133115 Just a next portion of "<tt>" tags removed. specdiffs did not detect any changes for java.util package: http://cr.openjdk.java.net/~avstepan/8133115/util.diff.00/overview-summary.… Thanks, Alexander

2 2