August 2016 - core-libs-dev

RFR: 8164859 Fix module dependences in java/text tests
by Alexandre (Shura) Iline 26 Aug '16

26 Aug '16

Hi. Please review this simple fix: http://cr.openjdk.java.net/~shurailine/8164859/webrev.00/ This fix is only adding @modules with either java.desktop or jdk.localedata to number of tests - no other changes. Shura

2 1

http://cr.openjdk.java.net/~redestad/8164866/webrev.01/
by Claes Redestad 26 Aug '16

26 Aug '16

Hi, JDK-8163371 forgot about the associated test. Changed it as necessary as some of the options are no longer implemented as of the latest changes: Bug: https://bugs.openjdk.java.net/browse/JDK-8164866 Webrev: http://cr.openjdk.java.net/~redestad/8164866/webrev.01/ Thanks! /Claes

3 4

RFR: 8163371: Enable tracing which JLI classes can be pre-generated
by Claes Redestad 26 Aug '16

26 Aug '16

Hi, please review this change which adds a means to trace what LFs and BMH classes we try to resolve at runtime (and whether we failed or succeeded), along with an update to the --generate-jli-classes plugin to take as it's input a file containing the output of such tracing. Bug: https://bugs.openjdk.java.net/browse/JDK-8163371 Webrev: http://cr.openjdk.java.net/~redestad/8163371/webrev.01/ I picked a random use case to test/verify the implementation in a minimal nashorn script, bin/jjs exit.js[1]. 1. On my local JDK image this loads 2359 classes. 2. On a jlink image with --generate-jli-classes=@empty to disable the default pre-generation, 2450 classes are loaded 3. On a jlink image built with the output of a tracing run[2], 2114 classes are loaded Also, inspecting the output shows that a total of 42 BoundMethodHandle$Species_* classes were pregenerated in case number 3, compared to 37 in the default case and 0 on the image with no pregeneration, meaning we avoid generating a total of 378 classes at runtime. As a follow up I plan to add tests and explore the benefits of adding a way to generate and use a relevant list of jli classes in the build (adding to the existing CDS classlist generation mechanism seems appropriate). Thanks! /Claes [1] exit.js: exit(); [2] bin/jjs -J-Djava.lang.invoke.MethodHandle.TRACE_RESOLVE=true exit.js > trace.out bin/jlink ... --generate-jli-classes=(a)trace.out

2 2

RFR 8163798: Add a versionedStream method to JarFile
by Steve Drach 26 Aug '16

26 Aug '16

Hi, Please review this changeset that adds a versionedStream method to JarFile. webrev: http://cr.openjdk.java.net/~sdrach/8163798/webrev.00/ <http://cr.openjdk.java.net/~sdrach/8163798/webrev.00/> issue: https://bugs.openjdk.java.net/browse/JDK-8163798 <https://bugs.openjdk.java.net/browse/JDK-8163798> Thanks Steve

5 4

RFR: 8164739: Remove computation of predefined interpreter forms
by Claes Redestad 25 Aug '16

25 Aug '16

Hi, LambdaForm predefines a number of forms for the benefit of the LF and NF interpreters, which doesn't appear useful at all at this point. JIRA: https://bugs.openjdk.java.net/browse/JDK-8164739 Webrev: http://cr.openjdk.java.net/~redestad/8164739/webrev.01/ Testing: all java/lang/invoke tests with various values for -Djava.lang.invoke.MethodHandle.COMPILE_THRESHOLD to run with and without LF interpretation. Removing this code improves on previous work to improve indy bootstrap to the point where the indy bootstrap happens in a few milliseconds, only loads 21 extra classes. On full program execution there's no discernible time difference between the regular and the MH variant. Thanks! /Claes

3 3

RFR: 8156500: deadlock provoked by new stress test com/sun/jdi/OomDebugTest.java
by Kim Barrett 25 Aug '16

25 Aug '16

Please review this change which moves the Reference pending list and locking from the java.lang.ref.Reference class into the VM. This includes elimination of the ReferencePendingListLocker mechanism in the VM. This fixes various fragility issues arising from having the management of this list split between Java and the VM (GC). This change addresses JDK-8156500 by eliminating the possibility of suspension while holding the lock. Because the locking is now done in the VM, we have full control over where suspension may occur. This change retains the existing interface between the reference processor and the nio.Bits package, e.g. Reference.tryHandlePending has the same signature and behavior; this change just pushes the pending list manipulation down into the VM. There are open bugs reports, enhancement requests, and discussions related to that interface; see below. This change does not attempt to address them. This change additionally addresses or renders moot https://bugs.openjdk.java.net/browse/JDK-8055232 (ref) Exceptions while processing Reference pending list and https://bugs.openjdk.java.net/browse/JDK-7103238 Ensure pending list lock is held on behalf of GC before enqueuing references on to the pending list It is also relevant for followup discussion of https://bugs.openjdk.java.net/browse/JDK-8022321 java/lang/ref/OOMEInReferenceHandler.java fails immediately and https://bugs.openjdk.java.net/browse/JDK-8149925 We don't need jdk.internal.ref.Cleaner any more - part 1 and has implications for: https://bugs.openjdk.java.net/browse/JDK-8066859 java/lang/ref/OOMEInReferenceHandler.java failed with java.lang.Exception: Reference Handler thread died In addition to the obviously relevant changes, there are a couple of changes whose presence here might seem surprising and require further explanation. - Removal of a stale comment in create_vm, noticed because it was near some code being removed as part of this change. The comment was rendered obsolete by JDK-8028275. - Moved initialization of exception classes earlier in initialize_java_lang_classes. The previous order only worked by accident, at least for OOME. During the bulk of the library initialization, OOME may be thrown, perhaps due to poorly chosen command line options. That attempts to use one of the pre-allocated OOME objects, and tries to fill in its stack trace. If the Throwable class is not yet initialized, this leads to a failed assert in the VM because Throwable.UNASSIGNED_STACK still has a null value. This initialization order issue was being masked by the old pending list implementation; the initialization of Reference ensured InterruptedException was initialized (thereby initializing its Throwable base class), and the initialization of Reference just happened to occur early enough that Throwable was initialized by the time it was needed when running certain tests. The forced initialization of InterruptedException is no longer needed by Reference, but removal of it triggered test failures (and could trigger corresponding product failures) because of this ordering issue. CR: https://bugs.openjdk.java.net/browse/JDK-8156500 Webrev: http://cr.openjdk.java.net/~kbarrett/8156500/jdk.00/ http://cr.openjdk.java.net/~kbarrett/8156500/hotspot.00/ Testing: RBT ad hoc nightly runtime & gc tests. With the proposed patch for JDK-8153711 applied, locally ran nearly 35K iterations of the OomDebugTest that is part of that patch, with no failures / deadlocks. Without this change it would typically only take on the order of 100 iterations to hit a deadlock failure. Locally ran direct byte buffer allocation test: jdk/test/java/nio/Buffer/DirectBufferAllocTest.java This change reported 3% faster allocation times, and 1/2 the standard deviation for allocation times. Locally ran failing test from JDK-8022321 and JDK-8066859 a few thousand times. jdk/test/java/lang/ref/OOMEInReferenceHandler.java No errors, but failures were noted as hard to reproduce.

6 50

RFR 8162108 Rename weakCompareAndSetVolatile to weakCompareAndSet
by Paul Sandoz 24 Aug '16

24 Aug '16

Hi Please review: http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8162108-rename-weakCompareAndS… <http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8162108-rename-weakCompareAndS…> This is a refactoring to produce a consistent naming scheme for the VarHandle Read Modify Write (RMW) methods. The unqualified methods default to volatile access. (And i hope this is the last modifying to the API signatures) This touches 166 classes that use or refer to the weak plain/volatile methods. The plan is to follow up deprecating (*not* for removal) the weakCompareAndSet methods on j.u.concurrent.atomic.* classes and add weakCompareAndSetPlain methods. Analysis via grepcode shows very little usages of the Atomic*.weakCompareAndSet methods. A further plan is to rename the Unsafe methods s/Swap/Set, add Plain qualifier etc. Paul.

2 6

j.l.invoke and the wrapping of exceptions
by Paul Sandoz 24 Aug '16

24 Aug '16

Hi, Recent discussion on the wrapping of exceptions (any Throwable) in LinkageError be it for invokedynamic and BootstrapMethodError (a spec issue) or for signature polymorphic linkage (an implementation detail AFAICT) resulted in a more detailed look at the exception handling in the j.l.invoke code. To partially fix signature polymorphic linkage i have made some small modifications [1] but i found i need to dig deeper as there are many other cases where Throwable is wrapped, specifically with the calls to MethodHandleStatic.newInternalError: /*non-public*/ static InternalError newInternalError(Throwable cause) { return new InternalError(cause); } There is also MethodHandleStatic.uncaughtException /** Propagate unchecked exceptions and errors, but wrap anything checked and throw that instead. */ /*non-public*/ static Error uncaughtException(Throwable ex) { if (ex instanceof Error) throw (Error) ex; if (ex instanceof RuntimeException) throw (RuntimeException) ex; throw newInternalError("uncaught exception", ex); } There may be cases where these are interchangeable, it’s subtle, and i would be away of replacing calls to newInternalError with uncaughtException. I propose the following: 1) change newInternalError(String message, Throwable cause) to newInternalError(String message, Exception cause) We want to be clear that the cause is an Exception, since this method will always return InternalError with a message. 2) replace newInternalError(Throwable cause) with errorOrNewInternalError(Throwable ex) /*non-public*/ static Error errorOrNewInternalError(Throwable ex) { if (ex instanceof Error) return (Error) ex; return newInternalError("uncaught exception", ex); } In all cases existing Errors will never be wrapped. 3) It’s tempting to rename uncaughtException with uncheckedOrNewInternalError. Paul. [1] diff -r 248159c6e61a src/java.base/share/classes/java/lang/invoke/LambdaForm.java --- a/src/java.base/share/classes/java/lang/invoke/LambdaForm.java Wed Aug 24 11:23:58 2016 -0700 +++ b/src/java.base/share/classes/java/lang/invoke/LambdaForm.java Wed Aug 24 15:31:29 2016 -0700 @@ -41,7 +41,6 @@ import static java.lang.invoke.LambdaForm.BasicType.*; import static java.lang.invoke.MethodHandleNatives.Constants.REF_invokeStatic; import static java.lang.invoke.MethodHandleStatics.*; -import java.util.Objects; /** * The symbolic, non-executable form of a method handle's invocation semantics. @@ -856,7 +855,7 @@ System.out.println("LambdaForm compilation failed: " + this); bge.printStackTrace(System.out); } - } catch (Error | Exception e) { + } catch (Exception e) { throw newInternalError(this.toString(), e); } } diff -r 248159c6e61a src/java.base/share/classes/java/lang/invoke/MethodHandle.java --- a/src/java.base/share/classes/java/lang/invoke/MethodHandle.java Wed Aug 24 11:23:58 2016 -0700 +++ b/src/java.base/share/classes/java/lang/invoke/MethodHandle.java Wed Aug 24 15:31:29 2016 -0700 @@ -957,7 +957,7 @@ if (!fail) return needType; // elicit an error: this.asType(needType); - throw newInternalError("should not return", null); + throw newInternalError("should not return"); } private void spreadArrayChecks(Class<?> arrayType, int arrayLength) { diff -r 248159c6e61a src/java.base/share/classes/java/lang/invoke/MethodHandleNatives.java --- a/src/java.base/share/classes/java/lang/invoke/MethodHandleNatives.java Wed Aug 24 11:23:58 2016 -0700 +++ b/src/java.base/share/classes/java/lang/invoke/MethodHandleNatives.java Wed Aug 24 15:31:29 2016 -0700 @@ -380,8 +380,11 @@ } } } catch (Throwable ex) { - if (ex instanceof LinkageError) - throw (LinkageError) ex; + // Pass through all instances of Error, thus ensuring errors such as + // ThreadDeath, StackOverflowException, OutOfMemoryException etc. + // are not wrapped + if (ex instanceof Error) + throw (Error) ex; else throw new LinkageError(ex.getMessage(), ex);

1 0

RFR: 8163353: NPE in ConcurrentHashMap.removeAll()
by Martin Buchholz 24 Aug '16

24 Aug '16

Let's get in the fix for regression 8163353 quickly: http://cr.openjdk.java.net/~martin/webrevs/openjdk9/jsr166-jdk9-integration… https://bugs.openjdk.java.net/browse/JDK-8163353

4 4

RFR:8163793: jlink has typo in copy-files plugin help text example
by Srinivas Dama 24 Aug '16

24 Aug '16

Hi, This patch fixes very small typo error. Please review http://cr.openjdk.java.net/~sdama/8163793/webrev.00/ for https://bugs.openjdk.java.net/browse/JDK-8163793 Regards, Srinivas

3 2