May 2014 - core-libs-dev

Draft JEP: Efficient Stack Walking API
by Mandy Chung 09 Jul '14

09 Jul '14

Below is a draft JEP we are considering submitting for JDK 9. Mandy ---------------------------- Title: Efficient API for Stack Walking Goal ---- Define a standard API for stack walking that will be efficient and performant. Non-goal -------- It is not a goal for this API be easy to use via Reflection for example use in code that is compiled for an older JDK. Motivation ---------- There is no standard API to obtain information about the caller's class and traverse the execution stack in a performant way. Existing libraries and frameworks such as Log4j and Groovy have to resort to using the JDK internal API `sun.reflect.Reflection.getCallerClass(int depth)`. This JEP proposes to define a standard API for stack walking that will be efficient and performant and also enable the implementation up level the stack walk machinery from the VM to Java and replaces the current mechanism of `Throwable.fillInStackTrace. Description ----------- There is no standard API to traverse certain frames on the execution stack efficiently and access the Class instance of each frame. There are APIs that allow to access the stack trace information: - `Throwable.getStackTrace()` and `Thread.getStackTrace()` that returns an array of `StackTraceElement` which contains the classname and method name of a stack trace. - `SecurityManager.getClassContext()` which is a protected method such that only `SecurityManager` subclass can access the class context. These APIs require the VM to eagerly capture a snapshot of the entire stack trace and returns the information representing the entire stack. There is no other way to avoid the cost to examine all frames if the caller is only interested in the top few frames on the stack. Both `Throwable.getStackTrace()` and `Thread.getStackTrace()` methods return an array of `StackTraceElement` that contains the classname and method name of a stack frame but the `Class` instance. In fact, for applications interested in the entire stack, the specification allows VM implementation to omit some frames in the stack for performance. In other words, `Thread.getStackTrace()` may return a partial stack trace. These APIs do not satisfy the use cases that currently depend on the `getCallerClass(int depth)` method or its performance overhead is intolerable. The use cases include: - JDK caller-sensitive APIs look up its immediate caller's class which will be used to determine the behavior of the API. For example `Class.forName(String classname)` and `ResourceBundle.getBundle(String rbname)` methods use the immediate caller's class loader to load a class and a resource bundle respectively. `Class.getMethod` etc will use the immediate caller's class loader to determine the security checks to be performed. - `java.util.logging`, Log4j and Groovy runtime filter the intermediary stack frames (typically implementation-specific and reflection frames) and find the caller's class to be used by the runtime of such library or framework. - Traverse the entire stack trace or the stack trace of a `Throwbale` and obtain additional information about classes for enhanced diagnosibility in addition to the class and method name. This JEP will define a stack walk API that allows laziness, frame filtering, supports short reaches to stop at a frame matching some criteria as well as long reaches to traverse the entire stack trace. This would need the JVM to provide a flexible mechanism to traverse and materialize the specific stack frame information to be used and allow efficient lazy access to additional stack frames when required. Native JVM transitions should be minimzed. The API will define how it works when running with a security manager that allows access to a `Class` instance of any frame ensuring that the security is not compromised. An example API to walk the stack can be like: Thread.walkStack(Consumer<StackFrameInfo> action, int depthLimit) that takes a callback to be invoked for each frame traversed. A variant of the walkStack method will take a predicate for stack frame filtering. Thread.getCaller(Function<StackFrameInfo, R> function) Thread.findCaller(Predicate<StackFrameInfo> predicate, Function<StackFrameInfo, R> function) finds the caller frame with or without filtering. Testing ------- Unit tests and JCK tests for the new SE API will need to be developed. In addition, the performance of the new API for different use cases will be assessed. Impact ------ - Performance/scalability: performance measurement shall be performed using micro-benchmarks as well as real world usage of `getCallerClass` replaced with the new API. - TCK: New JCK test cases shall be developed.

4 5

[9] RFR (S): 8038261: JSR292: cache and reuse typed array accessors
by Vladimir Ivanov 08 Jul '14

08 Jul '14

http://cr.openjdk.java.net/~vlivanov/8038261/webrev.00 https://bugs.openjdk.java.net/browse/JDK-8038261 56 lines changed: 26 ins; 14 del; 16 mod Cache typed array element getters/setters and reuse them. Initially, it was part of 8037209, but I decided to integrate it separately. Contributed-by: john.r.rose(a)oracle.com Testing: jdk/java/{lang/invoke,util}, vm.mlvm.testlist, nashorn, jruby Configs: -ea -esa -Xverify:all -D...COMPILE_THRESHOLD={0,30} Best regards, Vladimir Ivanov

2 4

RFR: JDK-8042369 Remove duplicated java.time classes in build.tools.tzdb
by Xueming Shen 19 Jun '14

19 Jun '14

Hi Please help review the change for #8042369 Issue: https://bugs.openjdk.java.net/browse/JDK-8042369 Webrev: http://cr.openjdk.java.net/~sherman/8042369/webrev In jdk8 we had to duplicate dozen java.time classes in build.tools to build the timezone data for the new JSR310 timezone data compiler, which uses the new jdk8 java.time classes (these classes don't exit in the < 8 boot jdk). JDK9 has switched to use the jdk8 as the boot jdk, so most of these duplicated classes are no longer needed, with ZoneRules as the only exception. The ZoneRules is still needed to help the tzdb compiler to output the tzdb data in the serialization forms of those transitions and rules. The proposed change here is to remove those unneeded duplicated classes. I also took the opportunity to re-organize/re-wrote the "builder" classes to have a faster, simpler and and straightforward implementation, with the goal of migrating it into a second default ZoneRulesProvider later to plug it into jdk, so jdk/jre can uses the tzdb source data from the IANA directly. One of the benefits of such a provider is that the end user may just drop the latest timezone data file into the jdk/jre and go, without waiting for the latest timezone binary bits from Oracle. Here is the webrev for the idea http://cr.openjdk.java.net/~sherman/tzdbProvider/webrev/ The only disadvantage appears to be the possible "slowdown" of startup time because of the reading and compiling of the 200k tzdb source data...(we need another new "bridge" for j.u.TimeZone, if we go with this direction) Thanks! -Sherman

2 5

JDK-8041679 Replace uses of StringBuffer with StringBuilder within the JDK
by Paul Sandoz 16 Jun '14

16 Jun '14

Hi, This is a request for review of Otavio's patch replacing StringBuffer with StringBuilder within OpenJDK. (I also need to review it.) It covers many areas and i have grouped the patches into such areas to aid reviewing. When commenting please including core-libs. Jtreg tests showed no regressions, but when reviewing we need to be mindful of the context e.g. if the buffer escapes and can cross thread boundaries. This is also an experiment to see if we can review the whole thing under one bug :-) if things prove problematic and slow we can split it out. Many files are touched but there are not many changes to each file and changes are very formulaic. I have also included ASM related changes, but i suspect we may have to leave those alone since such changes will make it more difficult to pull in ASM from upstream. - Otavio, for the record can you reply to this thread posting your single ("uber") patch as textual attachment? (IIUC such attachments should now be supported by the email server). Paul. - core http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-c… - io http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-i… - management http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-m… - rmi http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-r… - security http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-s… - tools http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-t… - graphics/media http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-m… - asm http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-a…

9 23

RFR 9 and 8u: JDK-8029674: (reflect) getMethods returns default methods that are not members of the class
by Joel Borggrén-Franck 12 Jun '14

12 Jun '14

Hi, Since Java 8 the methods Class.getMethod() and Class.getMethods() can in some circumstances return methods that are not members of the class. This is due to a spec change in 8 not due to a code change. For this to happen you need to have an interface hierarchy that looks something like: interface I { void m(); } interface J extends I { void m(); } and either one of: interface K extends ***I,*** J {} class C implements ***I,*** J {} In Java 7 K.class.getMethods() would return [ I.m, J.m ]. The 7 spec is a bit vague but I have been convinced by experts that this is actually correct in 7. However this was changed in the spec for 8, now only J.m() is a member of K or C so the result should only contain [ J.m() ]. See the bug: https://bugs.openjdk.java.net/browse/JDK-8029674 for a more thorough discussion of this. The fix proposed for 8u (and 9 at first) is a partial fix that ensures that: - a concrete class does not have any abstract methods - nothing is changed unless someone introduces default methods into the interface hierarchy This is to minimise the behavioural compatibility concerns in a minor release. For 9 we might implement the full solution. (See the 9 bug: https://bugs.openjdk.java.net/browse/JDK-8029459) Basically in the fix proposed for 8u, default methods prune less specific methods from the result if they have the same discriptor. There are some complications due to preserving the old lookup order and the fact that we don’t want different results depending on the order of pairwise comparisons. Since this work and MethodArray in general is comparing descriptors bridges should not interact with this patch. Bug: https://bugs.openjdk.java.net/browse/JDK-8029674 Patch: http://cr.openjdk.java.net/~jfranck/8029674/webrev.02/ *** Testing *** I made a test with a bit over 100 cases where 40 of the tests test behaviour that shouldn’t change (IE they pass both with and without the patch). The test is a bit vast, but I have commented some of the more interesting results. *** Performance *** The time complexity of this is O(defaultMethods * methods). getMethods() is already somewhat quadratic in complexity due to removing interface methods that have a concrete implementation. Also the result is cached so this is a one time increase per Class. I have done some experiments on a patched jdk without the cache and the performance looks decent: - Loading every class in rt.jar and calling getMethods() on every Class takes 8s on my laptop both before and after the patch. Perhaps not that surprising since there aren’t that many default methods in the jdk and this is probably dominated by IO. - Calling getMethods on a Class with 16K methods, 10% which are default methods, seem to take roughly 50% longer on my laptop (2,4 instead of 1,7 seconds). I’m working on converting this benchmark to JMH, but at least I don’t think I have made the most basic benchmark errors. If this turns out to be a performance problem I have an idea for an index that will make this O(methods sharing name * methods) for an addition of a few allocations, but I don’t expect this to be necessary. Thanks in advance cheers /Joel

3 4

RFR for bug JDK-8004807: java/util/Timer/Args.java failing intermittently in HS testing
by Eric Wang 09 Jun '14

09 Jun '14

Hi, Please help to review the fix for bug https://bugs.openjdk.java.net/browse/JDK-8004807 as below: http://cr.openjdk.java.net/~ewang/JDK-8004807/webrev.00/ The root cause of the failure is if Timer.cancel() is not called in time, the recurring timer task keeps running which cause the the assertion "check(latch.getCount() > 0)" failed. The fix includes: 1. As the purpose of the assertion "check(latch.getCount() > 0)" in timer task is used to check if the unrepeatable task is executed repeatedly and this assertion is meaningless for a repeatable task. it can be replaced by other way, see the webrev. 2. The timer thread should be terminated ASAP once all tasks are finished to avoid time spent on thread switch. 3. The test should be executed in othervm mode to avoid time spent on thread switch. Thanks, Eric

4 15

RFR: 8032901: WaitForMultipleObjects() return value not handled appropriately
by Aleksej Efimov 04 Jun '14

04 Jun '14

Hi, Can I have a review for 8032901 bug [1] fix [2]. There is a possible case when 'WaitForMultipleObjects' function can return the WAIT_ABANDONED_0 [3] error value. In such case it's better to release the mutex and return error value. This will prevent other threads to be blocked on abandoned mutex. Thank you, Aleksej [1] https://bugs.openjdk.java.net/browse/JDK-8032901 [2] http://cr.openjdk.java.net/~aefimov/8032901/9/webrev.00/ [3] http://msdn.microsoft.com/en-gb/library/windows/desktop/ms687025(v=vs.85).a…

5 14

Re: [9] RFR(S): 8005873: JRuby test_respond_to.rb asserts with: MT-unsafe modification of inline cache
by John Rose 03 Jun '14

03 Jun '14

On May 16, 2014, at 4:56 AM, Tobias Hartmann <tobias.hartmann(a)oracle.com> wrote: > Is it sufficient then to use synchronized (lambdaForms) { ... } in setCachedLambdaForm(..) and a normal read in cachedLambdaForm(..)? Yes, that is how I see it. The fast path is a racy non-volatile read of a safely-published structure. (If safe publication via arrays were broken, java.lang.String would be broken. But the JMM is carefully designed to support safe publication of array elements, and through array elements.) — John

4 7

RFR: 8041602 - (prefs) Check jdk/src/windows/native/java/util/WindowsPreference.c for JNI pending exceptions
by Mark Sheppard 02 Jun '14

02 Jun '14

Hi, please oblige and review the following change http://cr.openjdk.java.net/~msheppar/8041602/webrev/ which addresses the issue https://bugs.openjdk.java.net/browse/JDK-8041602 which is a backport of https://bugs.openjdk.java.net/browse/JDK-8035340 the original changeset didn't apply cleanly and was applied manually http://hg.openjdk.java.net/jdk9/dev/jdk/rev/740ffd98e35a regression tests ran ok and finally please approve backport to jdk8u-dev regards Mark

2 2

RFR: JDK-8044343 - Check jdk/src/windows/native/java/lang/ProcessEnvironment_md.c for JNI pending exceptions
by Mark Sheppard 02 Jun '14

02 Jun '14

Hi, please oblige and review the following change http://cr.openjdk.java.net/~msheppar/8044343/webrev/ which addresses issue https://bugs.openjdk.java.net/browse/JDK-8044343 which is a backport of https://bugs.openjdk.java.net/browse/JDK-8036603 the original changeset didn't apply cleanly and was applied manually http://hg.openjdk.java.net/jdk9/dev/jdk/rev/323b64a9dede regression tests ran ok and finally please approve backport to jdk8u-dev regards Mark

2 1