May 2014 - core-libs-dev

JDK 9 RFR of fallthrough fix in ASM
by Joe Darcy 31 May '14

31 May '14

Hello, Please review this change to suppress a fall-through warning recently sync'ed into ASM: --- a/src/share/classes/jdk/internal/org/objectweb/asm/Item.java Fri May 30 13:37:35 2014 -0700 +++ b/src/share/classes/jdk/internal/org/objectweb/asm/Item.java Fri May 30 16:19:12 2014 -0700 @@ -230,6 +230,7 @@ * @param strVal3 * third part of the value of this item. */ + @SuppressWarnings("fallthrough") void set(final int type, final String strVal1, final String strVal2, final String strVal3) { this.type = type; The switch statement is switch (type) { case ClassWriter.CLASS: this.intVal = 0; // intVal of a class must be zero, see visitInnerClass case ClassWriter.UTF8: case ClassWriter.STR: case ClassWriter.MTYPE: case ClassWriter.TYPE_NORMAL: hashCode = 0x7FFFFFFF & (type + strVal1.hashCode()); return; case ClassWriter.NAME_TYPE: { hashCode = 0x7FFFFFFF & (type + strVal1.hashCode() * strVal2.hashCode()); return; } // ClassWriter.FIELD: // ClassWriter.METH: // ClassWritehr.IMETH: // ClassWriter.HANDLE_BASE + 1..9 default: hashCode = 0x7FFFFFFF & (type + strVal1.hashCode() * strVal2.hashCode() * strVal3.hashCode()); } } Thanks, -Joe

3 2

RFR 80044461: Cleanup new Boolean and single character strings
by roger riggs 30 May '14

30 May '14

A quick sanity check please for these cleanup changes to remove uses of new Boolean and using chars instead of single character strings contributed by Otávio Gonçalves de Santana. These changes update multiple classes in the jdk9-dev repo (except client packages). webrev: http://cr.openjdk.java.net/~rriggs/webrev-8044461-cleanup/ Issue: https://bugs.openjdk.java.net/browse/JDK-8044461 Thanks, Roger

3 2

Please review: 8044046: [asm] refresh internal ASM version to v5.0.3
by Kumar Srinivasan 30 May '14

30 May '14

Hello, Please review the following webrev which updates internal ASM to v5.0.3, the individual bug fixes are listed in the JBS issue for reference, https://bugs.openjdk.java.net/browse/JDK-8044046#comment-13501358 All core regression tests have been run, additionally nashorn regressions, test262parallel, octane, and all applicable JFR related tests have also been run. https://bugs.openjdk.java.net/browse/JDK-8044046 http://cr.openjdk.java.net/~ksrini/8044046/jdk9/webrev.00/ Thanks Kumar

3 2

Thread hangs reading from process output streams, even though process has terminated. (possible JDK bug?)
by Bruno Medeiros 30 May '14

30 May '14

I have some code where I start an external process (ProcessBuilder.start() ,etc.) and then I spawn two worker threads to read the stdout and stderr of the external process. I directly read the streams provided by process.getInputStream() and process.getErrorStream() , I'm not wrapping them with my own streams or anything. Rather, the worker threads are calling java.io.InputStream.read(byte[]) in a loop. I've encountered a situation, where the worker threads hang despite the process having been terminated already! ( Java HotSpot(TM) 64-Bit Server VM (build 24.51-b03, mixed mode) , Windows 7) I'm able to caught this whilst running the Java program under the debugger. I invoked process.exitValue() under the debugger to see if the JVM has indeed realized the process has terminated. It returned 0, so it seems it knows the process has terminated. Yet the streams are still blocked, in a native method: The stdout worker thread is stuck here: Daemon Thread [ExternalProcessEclipseHelper.MainWorker] (Suspended) owns: BufferedInputStream (id=145) FileInputStream.readBytes(byte[], int, int) line: not available [native method] FileInputStream.read(byte[], int, int) line: 272 BufferedInputStream.fill() line: 235 BufferedInputStream.read1(byte[], int, int) line: 275 BufferedInputStream.read(byte[], int, int) line: 334 BufferedInputStream(FilterInputStream).read(byte[]) line: 107 ExternalProcessNotifyingHelper$1(ExternalProcessHelper$ReadAllBytesTask).doRun() line: 73 The stderr worker thread is similarly stuck : Daemon Thread [ExternalProcessEclipseHelper.StdErrWorker] (Suspended) FileInputStream.readBytes(byte[], int, int) line: not available [native method] FileInputStream.read(byte[]) line: 243 ExternalProcessNotifyingHelper$2(ExternalProcessHelper$ReadAllBytesTask).doRun() line: 73 Could this be a JVM bug? I don't see that this scenario should ever be happening, unless some other part of my code somehow did some violation and messed up the JVM state. I've added a sample of the relevant code I'm using here: https://github.com/bruno-medeiros/Scratchpad/tree/jvm-processio-issue However, I haven't yet been able to replicate this bug using the isolated code from there. At the moment, I can only replicate it when I run my full application. The sample code could be simplified further, but I haven't done it yet since I couldn't replicate the bug using that. One interesting bit, is that I can only replicate it when I run the application for the first time, per computer session. That is, apparently I need to reboot my computer for the bug to manifest again! I'd like to narrow this down, but I would appreciate some help or suggestions for that. What could affect the JVM, such that subsequent invocations apparently don't cause the bug? Some code cache issue? I also wonder if the OSGi runtime could be a factor here. -- Bruno Medeiros https://twitter.com/brunodomedeiros

4 9

RFR: 8043129: JAF initialisation in SAAJ clashing with the one in javax.mail
by Miroslav Kos 29 May '14

29 May '14

Hi, this is review request for: 8043129: JAF initialisation in SAAJ clashing with the one in javax.mail JBS: https://bugs.openjdk.java.net/browse/JDK-8043129 WEBREV: http://cr.openjdk.java.net/~mkos/8043129/jaxws.00/ http://cr.openjdk.java.net/~mkos/8043129/jdk.00/ (test) This solves conflict between JAF handlers for JAX-WS and javax.mail. The issue has been introduced in the latest CPU. Thanks Miran

5 7

Boolean valueOf instead of new Boolean
by Otávio Gonçalves de Santana 29 May '14

29 May '14

The Boolean class has cache for true and false and using it, will save memory and will faster than using create new instance of boolean. Using JMH[1] with a code test[2] the result was: Benchmark Mode Samples Mean Mean error Units m.BooleanBenchmark.newInstanceBoolean thrpt 20 49801.326 369.897 ops/s m.BooleanBenchmark.newInstanceString thrpt 20 365.080 27.537 ops/s m.BooleanBenchmark.valueOfBoolean thrpt 20 764906233.316 9623009.653 ops/s m.BooleanBenchmark.valueOfString thrpt 20 371.174 28.216 ops/s The diff is on attachment or can is downloading the webdrev here: https://dl.dropboxusercontent.com/u/16109193/open_jdk/boolean_instance_of.z… [1] http://openjdk.java.net/projects/code-tools/jmh/ [2] @State(Scope.Thread) @OutputTimeUnit(TimeUnit.SECONDS) public class BooleanBenchmark { private static final int SIZE = 1_000_000; private List<String> booleanString; private boolean[] booleans; { booleans = new boolean[SIZE]; booleanString = new ArrayList<>(SIZE); for (int index = 0; index < SIZE; index++) { if (index % 2 == 0) { booleans[index] = true; booleanString.add(Boolean.TRUE.toString()); } else { booleans[index] = false; booleanString.add(Boolean.FALSE.toString()); } } } @GenerateMicroBenchmark public void valueOfBoolean() { for(boolean b: booleans) { Boolean result = b; } } @GenerateMicroBenchmark public void valueOfString() { for(String b: booleanString) { Boolean result = Boolean.valueOf(b); } } @GenerateMicroBenchmark public void newInstanceBoolean() { for(boolean b: booleans) { Boolean result = new Boolean(b); } } @GenerateMicroBenchmark public void newInstanceString() { for(String b: booleanString) { Boolean result = new Boolean(b); } } } -- Atenciosamente. Otávio Gonçalves de Santana blog: http://otaviosantana.blogspot.com.br/ twitter: http://twitter.com/otaviojava site: http://www.otaviojava.com.br (11) 98255-3513

5 7

JVM crash when I use google gperftools Non Heap profiler
by fuyou 29 May '14

29 May '14

crash log A fatal error has been detected by the Java Runtime Environment: SIGSEGV (0xb) at pc=0x00002b626db6c304, pid=15640, tid=1167100224 JRE version: Java(TM) SE Runtime Environment (7.0_55-b13) (build 1.7.0_55-b13) Java VM: Java HotSpot(TM) 64-Bit Server VM (24.55-b03 mixed mode linux-amd64 > > compressed oops) Problematic frame: C [libunwind.so.7+0xb304] _ULx86_64_get_save_loc+0x568 Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again An error report file with more information is saved as: If you would like to submit a bug report, please visit: http://bugreport.sun.com/bugreport/crash.jsp java version java version "1.7.0_55" Java(TM) SE Runtime Environment (build 1.7.0_55-b13) Java HotSpot(TM) 64-Bit Server VM (build 24.55-b03, mixed mode) google gperftools version gperftools-2.1 OS version Red Hat Enterprise Linux Server release 5.7 (Tikanga) Kernel \r on an \m reproduction step ------------------------------ 1 yum install libunwind 2 download gperftools from https://code.google.com/p/gperftools/downloads/list and configue;sudo make install 3 export LD_PRELOAD=/usr/local/lib/libtcmalloc_and_profiler.so; export HEAPPROFILE=/tmp/memory/temp how to solve it? -- ============================================= fuyou001 Best Regards

3 2

Intent to work on 8043740
by Sandipan Razzaque 28 May '14

28 May '14

Hi all, Ready to contribute another patch - I intend to try and fix the following: https://bugs.openjdk.java.net/browse/JDK-8043740 Any thoughts/objections and/or is anyone already working on it? Cheers, SR Sandipan Razzaque | www.sandipan.net

3 4

RFR: 8044059: Memory Leak in Elliptic Curve Private Key Generation
by Jeremy Manson 28 May '14

28 May '14

Just like the title says - every time you generate a new private key, you leak a little memory. Webrev here: http://cr.openjdk.java.net/~jmanson/8044059/webrev/ This is probably the wrong mailing list for this bug, but I expect someone on this list will point me in the right direction. Jeremy

3 7

[9] RFR (XXS): 8035186: j2se_jdk/jdk/test/java/lang/invoke/lambda/LogGeneratedClassesTest.java - assertion error
by Vladimir Ivanov 28 May '14

28 May '14

https://bugs.openjdk.java.net/browse/JDK-8035186 http://cr.openjdk.java.net/~vlivanov/8035186/webrev.00/ LogGeneratedClassesTest.testDumpDirNotWritable is not applicable when it is run by super user on Linux/Solaris. The test checks that it's forbidden to create files in read-only directory, but super user is allowed to do so. The fix is to skip the test in such configuration. Testing: ran the test by super user on Solaris/Linux. Best regards, Vladimir Ivanov

2 6