April 2016 - core-libs-dev

RFR: 8150469: unpack200 fails to compare crc correctly.
by Kumar Srinivasan 06 Apr '16

06 Apr '16

Hello John, Alex, Please review fix for https://bugs.openjdk.java.net/browse/JDK-8150469 The previous fix keeps the storage in the unpacker object which is reset, for a multi-segmented pack archive, thus the computed crc32 is lost. Now the storage is moved into the gzip container, which persists, across multiple segments, I also added the length check as specified by RFC 1952, as implemented by JDK. http://hg.openjdk.java.net/jdk9/dev/jdk/file/e4af8119eba4/src/java.base/sha… The review is at: http://cr.openjdk.java.net/~ksrini/8150469/webrev.00/ Thanks Kumar

3 2

RFR:JDK-8148849:Truncating Duration
by nadeesh tv 06 Apr '16

06 Apr '16

Hi all, Bug Id : https://bugs.openjdk.java.net/browse/JDK-8148849 Enhanced Duration by adding public Duration truncatedTo(TemporalUnit unit) Please http://cr.openjdk.java.net/~ntv/8148849/webrev.00/ -- Thanks and Regards, Nadeesh TV

3 5

RFR JDK 9 (JAXP) 8150969 : DEFER from Features API is taking precedence over defer preference in catalog file.
by huizhe wang 06 Apr '16

06 Apr '16

Hi, Fix a typo in the catalog reader where the intention was to set the defer attribute, but the prefer was set instead. The tests are from the JCK. JBS: https://bugs.openjdk.java.net/browse/JDK-8150969 webrevs: http://cr.openjdk.java.net/~joehw/jdk9/8150969/webrev/ Thanks, Joe

2 1

Re: RFR 8153123 : Streamline StackWalker code
by Coleen Phillimore 06 Apr '16

06 Apr '16

Also meant to include core-libs-dev in the email. Thanks, Coleen On 4/5/16 1:27 PM, Coleen Phillimore wrote: > > Hi, I've reviewed the hotspot changes and some of the jdk changes. > This looks really good. > > One comment about the jvm function names: > > I think FillInStackTraceElement is too close of a name to > Throwable::fill_in_stack_trace(). > > -JVM_ENTRY(void, JVM_SetMethodInfo(JNIEnv *env, jobject frame)) > +JVM_ENTRY(void, JVM_FillInStackTraceElement(JNIEnv *env, jobject > frame, jobject stack)) > JVMWrapper("JVM_SetMethodInfo"); > - Handle stackFrame(THREAD, JNIHandles::resolve(frame)); > - java_lang_StackFrameInfo::fill_methodInfo(stackFrame, THREAD); > + Handle stack_frame_info(THREAD, JNIHandles::resolve(frame)); > + Handle stack_trace_element(THREAD, JNIHandles::resolve(stack)); > + java_lang_StackFrameInfo::fill_methodInfo(stack_frame_info, > stack_trace_element, THREAD); JVM_END > > > And the function is called fill_methodInfo in the javaClasses function. > > I think the JVM and the java_lang_StackFrameInfo function names should > be closer. > > I wonder if the name JVM_ToStackFrameElement() and > java_lang_StackFrameInfo::to_stack_frame_element() would be better and > then it'd match the Java name. > > Thanks! > Coleen > > On 4/4/16 9:29 PM, Mandy Chung wrote: >>> On Apr 4, 2016, at 4:45 PM, Brent Christian >>> <brent.christian(a)oracle.com> wrote: >>> >>> Hi, >>> >>> I'd like to check in some footprint and code reduction changes to >>> the java.lang.StackWalker implementation. >>> >>> Webrev: >>> http://cr.openjdk.java.net/~bchristi/8153123/webrev.00/ >>> Bug: >>> https://bugs.openjdk.java.net/browse/JDK-8153123 >>> >> This looks good to me. >> >> One thing to mention is that this patch is a follow-up work from the >> investigation on what it takes to enable Throwable to use StackWalker >> (JDK-8141239). The current built-in VM backtrace is very compact and >> performant. We have identified and prototypes the performance >> improvements if Throwable backtrace is generated using stack walker. >> There are some performance gaps that we agree to defer JDK-8141239 to >> a future release and improve the footprint performance and GC >> throughput concerns when MemberNames are stored in the throwable >> backtrace. >> >> Mandy >> >

3 5

[9] RFR JDK-8153564: Add java/nio/Buffer/BasicByte.java to exclude list until JDK-8153563 is fixed
by Alejandro Murillo 06 Apr '16

06 Apr '16

I'd like to push the changeset below to exclude java/nio/Buffer/BasicByte.java It started failing after the hotspot snapshot was pushed to jdk9/dev tonight. https://bugs.openjdk.java.net/browse/JDK-8153563 has been filed for that failure. $ hg -R jdk9.dev/jdk tip -pv changeset: 14082:5c98c9ad8ff2 tag: tip user: amurillo date: Tue Apr 05 22:06:15 2016 -0700 files: test/ProblemList.txt description: 8153564: Add java/nio/Buffer/BasicByte.java to exclude list until JDK-8153563 is fixed Reviewed-by: tbd diff -r 04f56d4ca167 -r 5c98c9ad8ff2 test/ProblemList.txt --- a/test/ProblemList.txt Tue Apr 05 20:02:21 2016 -0700 +++ b/test/ProblemList.txt Tue Apr 05 22:06:15 2016 -0700 @@ -185,6 +185,8 @@ java/nio/charset/coders/BashStreams.java 8149712 generic-all +java/nio/Buffer/BasicByte.java 8153563 generic-all + ############################################################################ # jdk_rmi -- Alejandro

3 4

RFR:
by Kumar Srinivasan 06 Apr '16

06 Apr '16

Hi, The issue here was jimage extract was taking too long, exploding the modules onto certain slow filesystems, thus causing test timeouts. Now using jrtfs to zipfs, it takes a small fraction of that time. Please review: http://cr.openjdk.java.net/~ksrini/8152622/webrev.00/ Fix for: https://bugs.openjdk.java.net/browse/JDK-8152622 Thanks Kumar

3 8

RFR 8150829: Enhanced drop-args, identity and default constant, varargs adjustment
by shilpi.rastogi＠oracle.com 06 Apr '16

06 Apr '16

Hi All, Please review the following- https://bugs.openjdk.java.net/browse/JDK-8150829 http://cr.openjdk.java.net/~srastogi/8150829/webrev.04 Thanks, Shilpi

2 2

JDK 9 RFR of JDK-8153563: java/nio/Buffer/Basic.java and CopyDirectMemory.java are failing after JDK-8149469
by Amy Lu 06 Apr '16

06 Apr '16

With test/java/nio/Buffer/BasicByte.java change in JDK-8149469, test java/nio/Buffer/Basic.java java/nio/Buffer/CopyDirectMemory.java now requires @modules java.base/jdk.internal.misc Please review the patch. bug: https://bugs.openjdk.java.net/browse/JDK-8153563 webrev: http://cr.openjdk.java.net/~amlu/8153563/webrev.00/ Thanks, Amy --- old/test/java/nio/Buffer/Basic.java 2016-04-06 15:39:19.000000000 +0800 +++ new/test/java/nio/Buffer/Basic.java 2016-04-06 15:39:19.000000000 +0800 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2000, 2015, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2000, 2016, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -27,6 +27,7 @@ * 4526177 4463011 4660660 4661219 4663521 4782970 4804304 4938424 6231529 * 6221101 6234263 6535542 6591971 6593946 6795561 7190219 7199551 8065556 * 8149469 + * @modules java.base/jdk.internal.misc * @author Mark Reinhold */ --- old/test/java/nio/Buffer/CopyDirectMemory.java 2016-04-06 15:39:20.000000000 +0800 +++ new/test/java/nio/Buffer/CopyDirectMemory.java 2016-04-06 15:39:20.000000000 +0800 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2002, 2007, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2002, 2016, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -26,6 +26,7 @@ * @bug 4463011 * * @build Basic + * @modules java.base/jdk.internal.misc * @run main CopyDirectMemory */

2 3

Bug id : 8140747 - Data corruption when parsing XML using StAX/Xerces
by Vlad-Lucian Gînju 05 Apr '16

05 Apr '16

Hello, Encountered this bug on our server and after some investigations I was able to find the bug reported here https://bugs.openjdk.java.net/browse/JDK-8140747. It seems that you were not able to reproduce on the Java versions mentioned in the bug's description. I am able to reproduce it on JDK 7u75 constantly. Installed this Java version on several linux machines and I am able to reproduce it on every one of them using the code provided in bug's description.I hope this info can help you find the problem mentioned in the bug's description. [vlg@sec vladtmp]$ for i in $(seq 1 10); do java TestXmlReader; done; bugs bugs bugs bugs bugs bugs bugs bugs bugs bugs [vlg@sec vladtmp]$ java -version java version "1.7.0_75" Java(TM) SE Runtime Environment (build 1.7.0_75-b13) Java HotSpot(TM) 64-Bit Server VM (build 24.75-b04, mixed mode) Regards,Vlad-Lucian Gînju

2 1

RFR [9] 8153498: Update the PostVMInitHook mechanism to use an internal package in the base module
by Chris Hegarty 05 Apr '16

05 Apr '16

sun.misc.PostVMInitHook::run is called by the VM once its initialization is complete, when jdk_version_info.post_vm_init_hook_enabled bit is true. Since sun.misc will be moved out of the base module, the VM should look for the PostVMInitHook in a more suitable place, say jdk.internal.vm. http://cr.openjdk.java.net/~chegar/8153498/ -Chris.

3 2