June 2014 - core-libs-dev

[9] RFR (M): 8037209: Improvements and cleanups to bytecode assembly for lambda forms
by Vladimir Ivanov 29 Aug '14

29 Aug '14

http://cr.openjdk.java.net/~vlivanov/8037209/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8037209 440 lines changed: 313 ins; 67 del; 60 mod This is a cleanup of JSR292 code to improve bytecode assembly code for lambda forms. 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} -D...PROFILE_LEVEL={0,1} Best regards, Vladimir Ivanov

5 24

RFR: 8047724: @since tag cleanup in jaxws
by Henry Jen 28 Jul '14

28 Jul '14

Hi, Please review a trivial webrev for jdk9/jaxws that do the same @since tag normalization as in jdk9/jdk. http://cr.openjdk.java.net/~henryjen/jdk9/8047724/0/webrev/ I am not sure if there is another mailing list thatis more appropriate for this, if so, please direct me to the right ml. Thanks. Cheers, Henry

3 4

RFR 9: 8003488 Add Process.getPid
by roger riggs 23 Jul '14

23 Jul '14

Please review and comment on this long requested addition to provide the native process id of a spawned Process. Webrev: http://cr.openjdk.java.net/~rriggs/webrev-getpid-8003488/ Issue: https://bugs.openjdk.java.net/browse/JDK-8003488 Thanks, Roger

7 21

RFR [9] 8006627: UUID to/from String performance should be improved by reducing object allocations
by Claes Redestad 21 Jul '14

21 Jul '14

Hi, please review this patch to improve UUID performance, originally proposed by Steven Schlansker, rebased to use the allocation-free methods added in https://bugs.openjdk.java.net/browse/JDK-8041972 Webrev: http://cr.openjdk.java.net/~redestad/8006627/webrev.0/ Bug: https://bugs.openjdk.java.net/browse/JDK-8006627 Thanks! /Claes

4 10

ThreadLocalRandom clinit troubles
by Martin Buchholz 18 Jul '14

18 Jul '14

ThreadLocalRandom's clinit method creates an intermediate broken state of ThreadLocalRandom and then proceeds to run some networking code to get some more machine-specific entropy in initialSeed(). This will fail if the networking code ever recursively uses a (not yet functional) ThreadLocalRandom. The clinit for InetAddress can cause arbitrary code to be run, at java.util.ServiceLoader$LazyIterator.hasNextService(ServiceLoader.java:354) at java.util.ServiceLoader$LazyIterator.hasNext(ServiceLoader.java:393) at java.util.ServiceLoader$1.hasNext(ServiceLoader.java:474) at java.net.InetAddress$3.run(InetAddress.java:923) at java.net.InetAddress$3.run(InetAddress.java:918) at java.security.AccessController.doPrivileged(Native Method) at java.net.InetAddress.createNSProvider(InetAddress.java:917) at java.net.InetAddress.<clinit>(InetAddress.java:962) if the sun.net.spi.nameservice.provider system property is defined. The current strategy of ThreadLocalRandom relying on other java code for initialization seems risky. Safer would be to have native code provide some entropy at program startup for use by ThreadLocalRandom. I don't have a clean solution for this problem (other than to rip out initialSeed()). Strictly more reliable would be to mix in the entropy from the system at the end of ThreadLocalRandom's clinit instead of the beginning, but the basic problem remains.

10 27

RFR [9] 8041972: Add improved parse/format methods for Long/Integer
by Claes Redestad 12 Jul '14

12 Jul '14

Hi, please review this patch to add offset based variants of Integer.parseInt/parseUnsignedInt, Long.parseLong/parseUnsignedLong and expose them through JavaLangAccess along with formatUnsignedInt/-Long. This is proposed to enable a number of minor optimizations, starting with https://bugs.openjdk.java.net/browse/JDK-8006627 Webrev: http://cr.openjdk.java.net/~redestad/8041972/webrev.0/ Thanks! /Claes

6 17

Character, Byte, Short valueOf instead of new instance
by Otávio Gonçalves de Santana 11 Jul '14

11 Jul '14

Reason: The Character, Byte, Short classes have cache and using it, will save memory and will faster than using create new instance. webrev: https://dl.dropboxusercontent.com/u/16109193/open_jdk/byte_short_character_… similar: https://bugs.openjdk.java.net/browse/JDK-8044461 -- Atenciosamente. Otávio Gonçalves de Santana blog: http://otaviosantana.blogspot.com.br/ twitter: http://twitter.com/otaviojava site: http://www.otaviojava.com.br (11) 98255-3513

5 10

RFR: 8044862: Fix raw and unchecked lint warnings in macosx specific code
by Henry Jen 10 Jul '14

10 Jul '14

Hi, Please review a webrev for fixing rawtypes and unchecked lint warning for macosx specific java code, this webrev is depending on JDK-8043548[1] where some of the override methods are defined, Also as the src/macosx/classes/apple/launcher/JavaAppLauncher.java to be removed from JDK-8048337, the webrev omits that file. The webrev can be found at, http://cr.openjdk.java.net/~henryjen/jdk9/8044862/0/webrev/ [1] https://bugs.openjdk.java.net/browse/JDK-8043548 Cheers, Henry

3 7

RFR: 8044656: Update JAX-WS RI integration to latest version
by Miroslav Kos 09 Jul '14

09 Jul '14

Hi, there is a bulk update of JAX-B/WS from upstream projects - webrev: http://cr.openjdk.java.net/~mkos/8044656/jaxws.00/ more details in issue desc: https://bugs.openjdk.java.net/browse/JDK-8044656 Could I ask for a review/approval? Thanks Miran

2 3

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