November 2017 - core-libs-dev

RFR: jsr166 jdk10 integration wave 5
by Martin Buchholz 08 Nov '17

08 Nov '17

The notable thing this time around is the embarrassing number of rare races being fixed, all of which are second tries. This time for sure! There's a large number of boring changes to appease errorprone, notably http://errorprone.info/bugpattern/RandomModInteger http://errorprone.info/bugpattern/MixedArrayDimensions http://cr.openjdk.java.net/~martin/webrevs/openjdk10/jsr166-integration/ove… 8190747: ExecutorService/Invoke.java fails intermittently 8179314: CountedCompleterTest.testForkHelpQuiesce fails with expected:<21> but was:<13> 8189387: ConcurrentLinkedDeque linearizability continued ... 8189764: Miscellaneous changes imported from jsr166 CVS 2017-11

3 8

[Patch][JDK10] Use Class.getPackageName() where possible
by Christoph Dreis 08 Nov '17

08 Nov '17

Hey, I noticed two places in the codebase that could call JDK 9's new method Class.getPackageName(). Would be happy if this is sponsored in case the patch is correct. Cheers, Christoph ====== PATCH ======= diff -r 438e0c9f2f17 src/java.base/share/classes/java/io/ObjectStreamClass.java --- a/src/java.base/share/classes/java/io/ObjectStreamClass.java Mon Oct 30 17:49:33 2017 -0700 +++ b/src/java.base/share/classes/java/io/ObjectStreamClass.java Fri Nov 03 01:47:04 2017 +0100 @@ -1587,11 +1587,7 @@ * Returns package name of given class. */ private static String getPackageName(Class<?> cl) { - String s = cl.getName(); - int i = s.lastIndexOf('['); - i = (i < 0) ? 0 : i + 2; - int j = s.lastIndexOf('.'); - return (i < j) ? s.substring(i, j) : ""; + return cl.getPackageName(); } /** diff -r 438e0c9f2f17 src/java.base/share/classes/java/lang/reflect/Proxy.java --- a/src/java.base/share/classes/java/lang/reflect/Proxy.java Mon Oct 30 17:49:33 2017 -0700 +++ b/src/java.base/share/classes/java/lang/reflect/Proxy.java Fri Nov 03 01:47:04 2017 +0100 @@ -1034,11 +1034,8 @@ // do permission check if the caller is in a different runtime package // of the proxy class - int n = proxyClass.getName().lastIndexOf('.'); - String pkg = (n == -1) ? "" : proxyClass.getName().substring(0, n); - - n = caller.getName().lastIndexOf('.'); - String callerPkg = (n == -1) ? "" : caller.getName().substring(0, n); + String pkg = proxyClass.getPackageName(); + String callerPkg = caller.getPackageName(); if (pcl != ccl || !pkg.equals(callerPkg)) { sm.checkPermission(new ReflectPermission("newProxyInPackage." + pkg));

4 10

JDK10 RFR of JDK-8190258: (tz) Support tzdata2017c and 8190259: test tck.java.time.zone.TCKZoneRules is broken by tzdata2017c
by Ramanand Patil 08 Nov '17

08 Nov '17

Hi all, Please review the latest TZDATA integration (tzdata2017c) to JDK10. Bugs: https://bugs.openjdk.java.net/browse/JDK-8190258 https://bugs.openjdk.java.net/browse/JDK-8190259 Webrev: http://cr.openjdk.java.net/~rpatil/8190258+8190259/webrev.00/ All the TimeZone related tests are passed after integration. Regards, Ramanand.

3 5

[NEW BUG][JDK10] TimeUnit.timedWait(Object obj, long timeout) doc should emphasize possibility of IllegalMonitorStateException
by Christoph Dreis 08 Nov '17

08 Nov '17

Hi, I don't know if this is considered a real bug or just a lack of documentation, but I found that although the example in the documentation of TimeUnit.timedWait(Object obj, long timeout) shows the correct usage of the method, I think at least the documentation should emphasize the possibility of an IllegalMonitorStateException in case it isn't executed inside a synchronized block. The method seems to be not used inside the JDK itself after all, but people might use it. Please find a minimal reproduction and a possible documentation patch below. In case it is considered worthwhile I'd be happy if this is sponsored. Cheers, Christoph ===== MINIMAL REPRO ====== public class Main { public static void main(String[] args) { Lock lock = new ReentrantLock(); try { TimeUnit.MILLISECONDS.timedWait(lock, 1); } catch (InterruptedException e) { e.printStackTrace(); } } } ====== PATCH ========== diff -r 67aa34b019e1 src/java.base/share/classes/java/util/concurrent/TimeUnit.java --- a/src/java.base/share/classes/java/util/concurrent/TimeUnit.java Mon Nov 06 17:48:00 2017 -0800 +++ b/src/java.base/share/classes/java/util/concurrent/TimeUnit.java Tue Nov 07 23:09:24 2017 +0100 @@ -356,6 +356,8 @@ * @param timeout the maximum time to wait. If less than * or equal to zero, do not wait at all. * @throws InterruptedException if interrupted while waiting + * @throws IllegalMonitorStateException if not executed inside a + * synchronized block */ public void timedWait(Object obj, long timeout) throws InterruptedException {

2 1

RFR 8190884: java/lang/Runtime/exec/LotsOfOutput fails intermittently
by Roger Riggs 07 Nov '17

07 Nov '17

Please review a test update to run LotsOfOutput with 'othervm'; running under the default batch testing mode of agentvm may cause instability. --- old/test/jdk/java/lang/Runtime/exec/LotsOfOutput.java 2017-11-07 17:48:38.398907014 -0500 +++ new/test/jdk/java/lang/Runtime/exec/LotsOfOutput.java 2017-11-07 17:48:37.846921042 -0500 @@ -23,7 +23,8 @@ /** * @test - * @bug 4369826 8078582 + * @bug 4369826 8078582 8190884 + * @run main/othervm LotsOfOutput * @summary Process with lots of output should not crash VM * @author kladko */ Thanks, Roger

3 2

RFR: 8185925 & 8153682 (footprint reduction of java.lang.StackFrameInfo)
by Brent Christian 07 Nov '17

07 Nov '17

Hi, There are a couple opportunities to reduce the memory footprint of java.lang.StackFrameInfo (the internal implementation of java.lang.StackWalker.StackFrame): 8153682[1] : StackFrameInfo.declaringClass could be removed 8185925[2] : StackFrameInfo::walker field can be replaced with bitmap to save footprint I had a look using jol[3]. Removing only 'walker' helps only under 32- and 64-bit, but not with compressed oops. Removing both 'walker' and 'declaringClass' brings a benefit to compressed oops as well (though not for 16-byte aligned). The size change, in bytes, for each execution mode is as follows: 32-bit: 32->24 64-bit: 56->40 64/compressed oops: 32->24 64/compressed oops, 16-byte aligned: 32->32 (For reference, the jol reports for the baseline and specimen are at [4] and [5], respectively.) Please review my code change for this. The webrev is here: http://cr.openjdk.java.net/~bchristi/8185925/webrev.03/ An automated test run is in progress. Thanks! -Brent -- 1. https://bugs.openjdk.java.net/browse/JDK-8153682 2. https://bugs.openjdk.java.net/browse/JDK-8185925 3. http://openjdk.java.net/projects/code-tools/jol/ 4. http://cr.openjdk.java.net/~bchristi/8185925/StackFrameInfo.jol.baseline.txt 5. http://cr.openjdk.java.net/~bchristi/8185925/StackFrameInfo.jol.rmDeclClass…

4 9

RFR (JDK10/JAXP) 8181151: Fix lint warnings in JAXP repo: cast
by Joe Wang 07 Nov '17

07 Nov '17

Hi, This change fixes about 300 [cast] warnings in the JAXP sources. Changes are basically removing the redundant cast, a bit more than that only in one case: in XSDUniqueOrKeyTraverser at line 92, uniqueOrKey was assigned to itself when it meant to be "idc". The change didn't affect the operation since idc is a result of the get operation with uniqueOrKey's name. JAXP tests passed. JBS: https://bugs.openjdk.java.net/browse/JDK-8181151 webrevs: http://cr.openjdk.java.net/~joehw/jdk10/8181151/webrev/ Thanks, Joe

4 3

RFR 8187281 : Remove @intermittent from OnExitTest
by Roger Riggs 06 Nov '17

06 Nov '17

Please review the removal of the @intermittent keyword from OnExitTest. The failure has not occurred since it was fixed on 9/21. --- old/test/jdk/java/lang/ProcessHandle/OnExitTest.java 2017-11-06 16:45:40.762305867 -0500 +++ new/test/jdk/java/lang/ProcessHandle/OnExitTest.java 2017-11-06 16:45:40.206333294 -0500 @@ -40,7 +40,6 @@ /* * @test - * @key intermittent * @library /test/lib * @build jdk.test.lib.Utils * @run testng OnExitTest Issue: https://bugs.openjdk.java.net/browse/JDK-8187281 Thanks, Roger

2 1

RFR - 8190482: InnocuousThread creation should not require the caller to possess enableContextClassLoaderOverride
by Chris Hegarty 06 Nov '17

06 Nov '17

Currently JDK code that wants to create innocuous threads is required to do so within a privileged context that has the "enableContextClassLoaderOverride" RuntimePermission ( since the InnocuousThread class overrides setContextClassLoader ). This permissions should not be required, especially if code in de-privileged modules wants to create innocuous threads. The factory methods for creating innocuous threads should assert privileges before constructing the thread. diff --git a/src/java.base/share/classes/jdk/internal/misc/InnocuousThread.java b/src/java.base/share/classes/jdk/internal/misc/InnocuousThread.java --- a/src/java.base/share/classes/jdk/internal/misc/InnocuousThread.java +++ b/src/java.base/share/classes/jdk/internal/misc/InnocuousThread.java @@ -62,10 +62,16 @@ * set to the system class loader. */ public static Thread newThread(String name, Runnable target) { - return new InnocuousThread(INNOCUOUSTHREADGROUP, - target, - name, - ClassLoader.getSystemClassLoader()); + return AccessController.doPrivileged( + new PrivilegedAction<Thread>() { + @Override + public Thread run() { + return new InnocuousThread(INNOCUOUSTHREADGROUP, + target, + name, + ClassLoader.getSystemClassLoader()); + } + }); } /** @@ -80,8 +86,14 @@ * Returns a new InnocuousThread with null context class loader. */ public static Thread newSystemThread(String name, Runnable target) { - return new InnocuousThread(INNOCUOUSTHREADGROUP, - target, name, null); + return AccessController.doPrivileged( + new PrivilegedAction<Thread>() { + @Override + public Thread run() { + return new InnocuousThread(INNOCUOUSTHREADGROUP, + target, name, null); + } + }); } -Chris.

3 2

RFR JDK-8185582, Update Zip implementation to use Cleaner, not finalizers
by Xueming Shen 05 Nov '17

05 Nov '17

Hi, Please help review the change for JDK-8185582. issue: https://bugs.openjdk.java.net/browse/JDK-8185582 webrev: http://cr.openjdk.java.net/~sherman/8185582/webrev/ csr: https://bugs.openjdk.java.net/browse/JDK-8187485 The proposed change here is to replace the finalize() cleanup mechanism with the newly introduced java.lang.ref.Cleaner for java.util.zip package (Deflater, Inflater, ZipFile and ZipFile.ZipFileInputStrean/ZipFileInflaterInputStream). Since it's an "incompatible" change, both behavioral and source incompatibility, to remove the public finalize() from these classes, a corresponding CSR is also created and need review as well. Thanks, Sherman

8 51