July 2016 - core-libs-dev

Review Request: JDK-8157464: StackWalker.getCallerClass() should not filter out non-invoker frames
by Mandy Chung 14 Sep '16

14 Sep '16

Webrev: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8157464/webrev.00/index.html StackWalker::getCallerClass() is specified to return the invoker of the MethodHandle and java.lang.reflect.Method for the method calling StackWalker::getCallerClass(). StackWalker::getCallerClass() is not used by any @CallerSensitive method. Instead one intended usage of StackWalker::getCallerClass() is to be called by library code acting as an agent that calls @CallerSensitive method on behalf of the true caller and typically it will call an appropriate method with the appropriate parameter (e.g. ResourceBundle.getBundle(String, ClassLoader). MethodHandle for @CS method behaves as if the caller is the lookup class. The actual caller class may not be the lookup class which is left as implementation details. This patch adjusts the stack walker to return the same caller as jdk.internal.reflect.Reflection::getCallerClass. Mandy

3 11

RFR: 6543126: Level.known can leak memory
by Daniel Fuchs 13 Sep '16

13 Sep '16

Hi, Please find below a fix for: 6543126: Level.known can leak memory https://bugs.openjdk.java.net/browse/JDK-6543126 webrev: http://cr.openjdk.java.net/~dfuchs/webrev_6543126/webrev.00 This is a fix for a long standing issue: Level maintains a list of know levels which has strong references to any created levels. Because the references are strong references, they prevent the garbage collection of levels, level classes, and level class loaders. This fix changes the KnownLevel class to extend WeakReference<Level> in order to only retain a weak reference to custom level instances. best regards, -- daniel

5 34

RFR: 8151901: test/tools/pack200/Pack200Test fails on verifying native unpacked JAR
by Kumar Srinivasan 03 Sep '16

03 Sep '16

Hi John, This patch contains fixes for two bugs: 8151901: test/tools/pack200/Pack200Test fails on verifying native unpacked JAR 8062335: Pack200 Java implementation differs from C version, outputs unused UTF8 for BootstrapMethods Note: The test case exhibits both of the above. With this the classes produced by java and the native implementation are congruent, though the JDK image's classes exhibit these issues, as a precaution I have extracted the minimal set of classes to reproduce the issues, into the golden jar. The webrev is at: http://cr.openjdk.java.net/~ksrini/8151901/webrev.00/ Thanks Kumar

3 5

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

Create java.util.stream.Stream from Iterator / Enumeration
by Patrick Reinhart 23 Aug '16

23 Aug '16

Hi there, I know you are busy getting the latest release ready. Still I have question according the java.util.stream.Stream's static helper methods. During my work I ran into a couple places where creating a Stream out of a Iterator or Enumeration directly would be quite handy. At the moment I have made me two methods like this on a helper class in oder to not duplicate the code: public static <T> Stream<T> iterate(Iterator<T> iterator) { Objects.requireNonNull(iterator); return StreamSupport.stream(Spliterators .spliteratorUnknownSize(iterator, Spliterator.ORDERED | Spliterator.IMMUTABLE), false); } public static <T> Stream<T> iterate(Enumeration<T> enumeration) { Objects.requireNonNull(enumeration); final Iterator<T> iterator = new Iterator<T>() { @Override public boolean hasNext() { return enumeration.hasMoreElements(); } @Override public T next() { return enumeration.nextElement(); } }; return iterate(iterator); } My question is now, if it would be worth while having something like this on the Stream itself? Cheers Patrick

3 18

RFR 8162458 Buffer view implementations use incorrect offset for Unsafe access
by Paul Sandoz 16 Aug '16

16 Aug '16

Hi, I made an embarrassing mistake in the fix for https://bugs.openjdk.java.net/browse/JDK-8151163 All Buffer implementations should leverage Unsafe unaligned accessors The offset calculation for Unsafe access was incorrect, it’s easy to get confused because for heap buffers the offset is relative to the array, and for direct buffers the address (which can update for slices/duplicates). Disturbingly all existing tests were passing both for core and hotspot when i pushed to hs. As a penance i wrote a combinatorial test for buffer views to navigate the twisty maze of heap/direct, aligned/unaligned, little/big endian for accessing binary data and views from the source buffer. Please review: http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8162458-byte-buffer-view-offse… (This may be a duplicate of [1]). Test has been verified to fail with the existing code. Focused JPRT runs pass, but i will kick off core/hotspot runs later on today. I will push to hs since that is where JDK-8151163 and it has not been integrated into jdk9/dev. Paul. [1] https://bugs.openjdk.java.net/browse/JDK-8159257 unsafe.cpp: assert(byte_offset < p_size) failed: Unsafe access: offset 32767 > object's size 16 For the test runtime/Unsafe/RangeCheck.java I can reproduce a crash in jdk9/dev which does not have JDK-8151163, and i can reproduce on jdk9/hs with this fix for JDK-8162458.

6 10

RFR: 8161379: Force inline methods calling Reflection.getCallerClass
by Claes Redestad 05 Aug '16

05 Aug '16

Hi, most @CallerSensitive methodscall Reflection.getCallerClass(), which turn out to have problematic performance characteristics when it fails to inline. Making @CallerSensitive imply @ForceInline actually works rather well across benchmarks, but didn't meet with approval from hotspot-compiler because it's a hack (unlike @ForceInline /s). Instead, here is a patch to explicitly @ForceInline those methods where it can plausibly be helping with performance: Webrev: http://cr.openjdk.java.net/~redestad/8161379/jdk.01/ Bug: https://bugs.openjdk.java.net/browse/JDK-8161379 Thanks! /Claes

3 6

RFR: 8161588: MemberName::resolveOrNull cause and hide NoSuchMethodErrors
by Claes Redestad 05 Aug '16

05 Aug '16

Hi, please review this bug fix to ensure MemberName::resolveOrNull doesn't throw exceptions when speculatively looking up members that aren't there. HS: http://cr.openjdk.java.net/~redestad/8161588/hs.01 JDK: http://cr.openjdk.java.net/~redestad/8161588/jdk.01 This avoids throwing NoSuchMethodError etc just to be ignored, avoiding a performance penalty when looking things up speculatively (which is key to possible upcoming work to generate more JLI code with jlink). There's a pre-existing issue not dealt with by this fix in that the exceptions thrown in MHN_resolve_Mem are never observed, instead the exceptions thrown from various LinkResolver methods are observed. We could clear all pending exceptions in resolve_MemberName, but this breaks tests that are very particular about which exception is thrown when and where, thus I opted to add the clear_pending boolean to allow clearing the exception conditionally instead, keeping behavior identical for MemberName::resolveOrFail Thanks! /Claes

1 1

[PATCH] JDK-8155102: Process.toString could include pid, isAlive, exitStatus
by Andrey Dyachkov 05 Aug '16

05 Aug '16

Hello, I have added toString() method in Process.java. diff --git a/src/java.base/share/classes/java/lang/Process.java b/src/java.base/share/classes/java/lang/Process.java --- a/src/java.base/share/classes/java/lang/Process.java +++ b/src/java.base/share/classes/java/lang/Process.java @@ -548,5 +548,16 @@ return toHandle().descendants(); } + @Override + public String toString() { + boolean isAlive = this.isAlive(); + return new StringBuilder(this.getClass().getSimpleName()).append("[") + .append("running=").append(isAlive).append(", ") + .append(isAlive ? "pid=" : "exitCode=") + .append(isAlive ? this.getPid() : this.exitValue()) + .append("]") + .toString(); + } + }

2 6

Review request for JDK-8145545 : Typos in Javadoc of XmlAdapter
by Abhijit Roy 05 Aug '16

05 Aug '16

Hi all, Please review a fix for Bug - https://bugs.openjdk.java.net/browse/JDK-8145545 Bug - Typos in Javadoc of XmlAdapter Webrev - http://cr.openjdk.java.net/~ntv/ababroy/8145545/webrev.00/ I have just rectified and modified those error. And moving forward it for review. Regards, Abhijit.

3 3