March 2016 - core-libs-dev

Re: RFR 8150778: Reduce Throwable.getStackTrace() calls to the JVM
by Mandy Chung 03 Mar '16

03 Mar '16

> On Mar 2, 2016, at 4:03 PM, Coleen Phillimore <coleen.phillimore(a)oracle.com> wrote: > > Freshly tested changes with jck tests, with missing checks and other changes to use the depth field, as pointed out by Aleksey. I've kept the StackTraceElement[] allocation in Java to match the new API that was approved. > > open webrev at http://cr.openjdk.java.net/~coleenp/8150778.02_hotspot/ > open webrev at http://cr.openjdk.java.net/~coleenp/8150778.02_jdk/ typo in your link: http://cr.openjdk.java.net/~coleenp/8150778.02_jck/ StackTraceElement.java 80 * @since 1.9 This is not needed. Simply take this out. Throwable.java 215 * Native code sets the depth of the backtrace for later retrieval s/Native code/VM/ since VM is setting the depth field. 896 private native void getStackTraceElements(StackTraceElement[] elements); Can you add the method description “Gets the stack trace elements." I only skimmed on the hotspot change. Looks okay to me. TestThrowable.java 43 int getDepth(Throwable t) throws Exception { 44 for (Field f : Throwable.class.getDeclaredFields()) { 45 if (f.getName().equals("depth")) { You can replace the above with Throwable.class.getDeclaredField(“depth”) Otherwise, looks okay. Mandy

2 1

RFR: 8151098: Introduce multi-slot per-thread cache for StringDecoders/Encoders
by Tony Printezis 02 Mar '16

02 Mar '16

Hi all, We discussed this change in a previous e-mail thread. Here’s a patch for your consideration: http://cr.openjdk.java.net/~tonyp/8151098/webrev.1/ I cloned the Cache class from ThreadLocalCoders and reworked it a bit. The StringDecoder and StringEncoder classes had some common fields (the Charset and the requested charset name). I moved them to a superclass (StringCoder) which made the cache easier to write (I didn’t have to create one subclass for the decoder and one for the encoder, as it is the case in ThreadLocalCoders). Feedback very welcome! Tony ----- Tony Printezis | JVM/GC Engineer / VM Team | Twitter @TonyPrintezis tprintezis(a)twitter.com

1 0

RFR [9] 8150976: JarFile and MRJAR tests should use the JDK specific Version API
by Chris Hegarty 02 Mar '16

02 Mar '16

Currently JarFile and MRJAR tests use sun.misc.Version to retrieve the major runtime version. They should be updated to use the new JDK specific Version API. Note: There is an issue, 8144062 [1], to revisit the JDK specific Version API to determine if it should be moved, or even standardized. The changes being proposed here may need to be updated, in a trivial way, in the future, but this issue is intending to break the dependency on sun.misc.Version so that 8150162 [2] can make progress. Additionally, the future refactoring will most likely be trivial. http://cr.openjdk.java.net/~chegar/8150976/ https://bugs.openjdk.java.net/browse/JDK-8150976 -Chris. [1] https://bugs.openjdk.java.net/browse/JDK-8144062 [2] https://bugs.openjdk.java.net/browse/JDK-8150162

3 2

RFR(XS): 8150953: j.l.i.MethodHandles: example section in whileLoop(...) provides example for doWhileLoop
by Michael Haupt 02 Mar '16

02 Mar '16

Dear all, please review this fix. Bug: https://bugs.openjdk.java.net/browse/JDK-8150953 Webrev: http://cr.openjdk.java.net/~mhaupt/8150953/webrev.00/ The API docs and corresponding JavaDocExampleTest test case for MethodHandles.whileLoop() wrongly used the example for MethodHandles.doWhileLoop(). Thanks, Michael -- <http://www.oracle.com/> Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331 200 7561 Oracle Java Platform Group | LangTools Team | Nashorn Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstraße 25, D-80992 München Registergericht: Amtsgericht München, HRA 95603 Komplementärin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697 Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher <http://www.oracle.com/commitment> Oracle is committed to developing practices and products that help protect the environment

2 1

RFR(M): 8150832: split T8139885 into several tests by functionality
by Michael Haupt 02 Mar '16

02 Mar '16

Dear all, please review this change. RFE: https://bugs.openjdk.java.net/browse/JDK-8150832 Webrev: http://cr.openjdk.java.net/~mhaupt/8150832/webrev.00 This is a refactoring; the monolithic test for JEP 274 was split into several tests along functionality covered. Also, data providers and other declarative annotations were introduced where it made sense. Thanks, Michael -- <http://www.oracle.com/> Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331 200 7561 Oracle Java Platform Group | LangTools Team | Nashorn Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstraße 25, D-80992 München Registergericht: Amtsgericht München, HRA 95603 Komplementärin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697 Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher <http://www.oracle.com/commitment> Oracle is committed to developing practices and products that help protect the environment

2 2

RFR (XS): 8149596: Remove java.nio.Bits copy wrapper methods
by Mikael Vidstedt 02 Mar '16

02 Mar '16

As part of JDK-8141491[1] the native methods in java.nio.Bits were removed, and the functionality is instead provided by the VM through j.i.m.Unsafe. The Bits wrapper methods are therefore redundant and can be removed. Bug: https://bugs.openjdk.java.net/browse/JDK-8149596 Webrev: http://cr.openjdk.java.net/~mikael/webrevs/8149596/webrev.00/webrev/ I've run the java/nio jtreg tests and it all passes (modulo a couple of unrelated failures). Cheers, Mikael [1] https://bugs.openjdk.java.net/browse/JDK-8141491

4 3

RFR 8148187 : Remove OS X-specific com.apple.concurrent package
by Brent Christian 02 Mar '16

02 Mar '16

Hi, A number of internal APIs were carried over into the JDK with the Apple port. Among them was com.apple.concurrent.Dispatch. Supportedness has always been murky here, but Jigsaw necessitates a firmer stance. Some of these APIs have already been removed from JDK 9 [1], some will be supplanted by new, supported APIs [2]. As already discussed in [3] and [4], com.apple.concurrent.Dispatch is no longer in use, as far as we've been able to find. com.apple.concurrent.Dispatch and its supporting code should be removed from JDK 9. It turns out this opens the door for a little module pruning as well. com.applet.concurrent makes up the bulk of the jdk.deploy.osx module. All that's left is native code for libosx, a library relied on by com.apple.eio.FileManager in the java.desktop module. By moving libosx over to java.desktop, we are able to do away with the jdk.deploy.osx module altogether. For your review is a webrev of this change: http://cr.openjdk.java.net/~bchristi/8148187/webrev.01/ JBS: https://bugs.openjdk.java.net/browse/JDK-8148187 Automated build+test runs look fine. If, in the future, there is desire for an ExecutorService backed by the native platform (as com.apple.concurrent.Dispatch does for libdispatch on OS X), such a feature could be proposed. Thanks, -Brent 1. "Remove apple script engine code in jdk repository" https://bugs.openjdk.java.net/browse/JDK-8143404 2. JEP 272 : "Platform-Specific Desktop Features" https://bugs.openjdk.java.net/browse/JDK-8048731 3. http://mail.openjdk.java.net/pipermail/macosx-port-dev/2015-May/006934.html 4. http://mail.openjdk.java.net/pipermail/macosx-port-dev/2015-September/00696…

4 3

RFR: JDK-8087104: DateFormatSymbols triggers this.clone() in the constructor
by Ramanand Patil 02 Mar '16

02 Mar '16

Hi all, Please review the fix for bug: https://bugs.openjdk.java.net/browse/JDK-8087104 Bug Description: DateFormatSymbols caches its own instance and calls this.clone() in the constructor. Because of this, any subclass implementation (which expects a field is always initialized to non-null in the constructor) will throw NPE in its overridden clone() method while using any instance variables which it assumed are initilaized in its contructor. Webrev: http://cr.openjdk.java.net/~rpatil/8087104/webrev.00/ Fix: Instead of using its own instance for caching and calling clone in DateFormatSymbols, a nested class SymbolsCacheEntry is introduced. Regards, Ramanand.

3 3

RFR: 8149330: Capacity of StringBuilder should not get close to Integer.MAX_VALUE unless necessary
by Ivan Gerasimov 01 Mar '16

01 Mar '16

Hello! When the capacity of a StringBuilder needs to be increased (either due to append() or due to explicit call to ensureCapacity()), the new capacity is calculated as "twice the old capacity, plus 2", rounded down to Integer.MAX_VALUE: http://docs.oracle.com/javase/8/docs/api/java/lang/StringBuilder.html#ensur… Because of that, StringBuilder throws OOM early, even though there may be room to grow. The proposed solution is to reserve a few bytes at the top of the range and only try to allocate them if absolutely required. The regression test is @ignored by default, as it is too greedy for memory. Would you please help review the fix? BUGURL: https://bugs.openjdk.java.net/browse/JDK-8149330 WEBREV: http://cr.openjdk.java.net/~igerasim/8149330/00/webrev/ Sincerely yours, Ivan

4 15

RFR: 8150856 - Inconsistent API documentation for @param caller in System.LoggerFinder.getLogger
by Daniel Fuchs 01 Mar '16

01 Mar '16

Hi, Please find below a trivial fix for: https://bugs.openjdk.java.net/browse/JDK-8150856 8150856: Inconsistent API documentation for @param caller in System.LoggerFinder.getLogger http://cr.openjdk.java.net/~dfuchs/webrev_8150856/webrev.00 The @param caller clause says that caller can be null, whereas the @throws clause says that NPE will be thrown. The @throws clause is correct and @param needs to be fixed. best regards, -- daniel --- old/src/java.base/share/classes/java/lang/System.java 2016-02-29 18:41:30.000000000 +0100 +++ new/src/java.base/share/classes/java/lang/System.java 2016-02-29 18:41:30.000000000 +0100 @@ -1,5 +1,5 @@ /* - * Copyright (c) 1994, 2014, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 1994, 2016, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -1419,7 +1419,6 @@ * * @param name the name of the logger. * @param caller the class for which the logger is being requested; - * can be {@code null}. * * @return a {@link Logger logger} suitable for the given caller's * use.

3 3