Re: RFR: 8197901: Crash during GC when logging level is debug

2018-02-22 Thread David Holmes
Hi Leonid, Looks fine. Please also add this bug id to @bug in test/jdk/java/lang/StackWalker/VerifyStackTrace.java Thanks, David On 23/02/2018 12:41 PM, Leonid Mesnik wrote: Hi Could you please review following fix which update implementation of Klass::external_name for anonymous classes.

RFR: 8197901: Crash during GC when logging level is debug

2018-02-22 Thread Leonid Mesnik
Hi Could you please review following fix which update implementation of Klass::external_name for anonymous classes. Previously external_name tried to add hashcode of corresponding java_mirror for InstanceKlass if it exists. However the java_mirror could be incorrect during GC. Also

Re: RFR (JDK11) 8137326: Methods for comparing CharSequence, StringBuilder, and StringBuffer

2018-02-22 Thread Joe Wang
On 2/22/18, 12:51 PM, Xueming Shen wrote: On 2/22/18, 12:04 PM, Joe Wang wrote: Hi Sherman, Thanks for reviewing the change. Taking a local copy of the count field, but the boundary check would be almost immediately done against the field itself. Are you worrying about the count field may

Re: [11] RFR JDK-8198441: Replace native Runtime::runFinalization0 method with shared secrets

2018-02-22 Thread David Holmes
Looks good. Thanks, David On 21/02/2018 3:45 AM, mandy chung wrote: Webrev:   http://cr.openjdk.java.net/~mchung/jdk11/webrevs/8198441/webrev.00 This is a small cleanup that replaces the native Runtime::runFinalization0 method with shared secrets to invoke Finalizer::runFinalization in java.

Re: RFR (JDK11) 8137326: Methods for comparing CharSequence, StringBuilder, and StringBuffer

2018-02-22 Thread Xueming Shen
On 2/22/18, 12:04 PM, Joe Wang wrote: Hi Sherman, Thanks for reviewing the change. Taking a local copy of the count field, but the boundary check would be almost immediately done against the field itself. Are you worrying about the count field may be out of sync with the byte array? I would

[JDK-6341887] Patch V2: java.util.zip: Add ByteBuffer methods to Inflater/Deflater

2018-02-22 Thread David Lloyd
This is the second version of the patch first discussed here [1] to add the ability to inflate/deflate to/from heap/direct byte buffers. The patch is attached, as well as benchmark results with the original and new code, and the benchmark source. The patch is also visible online at [2]. Some

Re: RFR (JDK11) 8137326: Methods for comparing CharSequence, StringBuilder, and StringBuffer

2018-02-22 Thread Joe Wang
Hi Sherman, Thanks for reviewing the change. Taking a local copy of the count field, but the boundary check would be almost immediately done against the field itself. Are you worrying about the count field may be out of sync with the byte array? I would think that's unlikely to happen.

Re: [11] RFR JDK-8060094: java/util/Formatter/Basic.java failed in tr locale

2018-02-22 Thread Naoto Sato
Hi Nishit, In the test case, the exception error messages may be more helpful if there is a distinction between the two (line 103 and 120) mentioning the formatter is using the default or specified locale. Naoto On 2/22/18 3:51 AM, Nishit Jain wrote: Hi, Please review the fix for

Re: [PATCH] Optimization of AbstractStringBuilder.ensureCapacityInternal()

2018-02-22 Thread Claes Redestad
Hi, interesting - do you have any numbers showing a benefit from doing this (on various sets of input)? My concerns are that count might typically be close enough to value.length to make the difference small in practice, and that there are some (fragile) JIT optimizations to try and avoid

Re: [PATCH] Optimization of AbstractStringBuilder.ensureCapacityInternal()

2018-02-22 Thread Roman Leventov
Similar optimizations are also possible in ArrayList and Vector. On 22 February 2018 at 17:51, Roman Leventov wrote: > AbstractStringBuilder.ensureCapacityInternal() doesn't need to copy the > whole underlying array, only the part until the current count. > > diff --git

Re: [11] RFR: JDK-8198385: Remove property sun.locale.formatasdefault

2018-02-22 Thread Naoto Sato
Thanks, Alan. There is no test case affected by this change, so I added "noreg" label to the jira issue. Naoto On 2/22/18 5:34 AM, Alan Bateman wrote: On 21/02/2018 21:13, naoto.s...@oracle.com wrote: Hello, Please review the fix to the following issue:

[PATCH] Optimization of AbstractStringBuilder.ensureCapacityInternal()

2018-02-22 Thread Roman Leventov
AbstractStringBuilder.ensureCapacityInternal() doesn't need to copy the whole underlying array, only the part until the current count. diff --git a/src/java.base/share/classes/java/lang/AbstractStringBuilder.java b/src/java.base/share/classes/java/lang/AbstractStringBuilder.java ---

Re: [11] RFR: JDK-8198385: Remove property sun.locale.formatasdefault

2018-02-22 Thread Alan Bateman
On 21/02/2018 21:13, naoto.s...@oracle.com wrote: Hello, Please review the fix to the following issue: https://bugs.openjdk.java.net/browse/JDK-8198385 The proposed changeset is located at: http://cr.openjdk.java.net/~naoto/8198385/webrev.00/ The property was introduced in JDK7 for the

Re: Draft JEP: To use UTF-8 as the default charset for the Java virtual machine.

2018-02-22 Thread Alan Bateman
On 21/02/2018 20:50, Uwe Schindler wrote: : Thanks for clarifying! I just wanted to mention this, because those methods are different, so you should at least think about it  These methods were deliberately specified to use UTF-8 and I don't think we should change them (changing them for a

[11] RFR JDK-8060094: java/util/Formatter/Basic.java failed in tr locale

2018-02-22 Thread Nishit Jain
Hi, Please review the fix for JDK-8060094. Bug: https://bugs.openjdk.java.net/browse/JDK-8060094 Webrev: http://cr.openjdk.java.net/~nishjain/8060094/webrev.03/ CSR: https://bugs.openjdk.java.net/browse/JDK-8197916 Cause: The Formatter APIs were not using the correct locale for upper casing

Re: RFR (XS): 8198539: Cleanup of unused imports in java/util/jar/Attributes.java (java.base) and JdpController.java (jdk.management.agent)

2018-02-22 Thread Andrew Leonard
looks good Cheers Andrew Leonard Java Runtimes Development IBM Hursley IBM United Kingdom Ltd Phone internal: 245913, external: 01962 815913 internet email: andrew_m_leon...@uk.ibm.com From: "Langer, Christoph" To: OpenJDK Dev list

Re: RFR (XS): 8198539: Cleanup of unused imports in java/util/jar/Attributes.java (java.base) and JdpController.java (jdk.management.agent)

2018-02-22 Thread Thomas Stüfe
Hi Christoph, Looks fine. .. Thomas On Feb 22, 2018 09:42, "Langer, Christoph" wrote: > Hi, > > please review a simple import cleanup fix for > java/util/jar/Attributes.java and sun/management/jdp/JdpController.java. > > Bug:

RE: Oracle Java 8u161 regression in XML Schema Factory

2018-02-22 Thread Langer, Christoph
Hi Joe, thanks for the clarification. It would be good to have a place of documentation where one could refer customers to. Thanks Christoph > -Original Message- > From: Joe Wang [mailto:huizhe.w...@oracle.com] > Sent: Mittwoch, 21. Februar 2018 21:50 > To: Langer, Christoph

RE: Oracle Java 8u161 regression in XML Schema Factory

2018-02-22 Thread Langer, Christoph
Hi Bernd, ok, your issue must be something different then. Best regards Christoph > -Original Message- > From: core-libs-dev [mailto:core-libs-dev-boun...@openjdk.java.net] On > Behalf Of Bernd Eckenfels > Sent: Mittwoch, 21. Februar 2018 20:01 > To: OpenJDK Dev list

RFR (XS): 8198539: Cleanup of unused imports in java/util/jar/Attributes.java (java.base) and JdpController.java (jdk.management.agent)

2018-02-22 Thread Langer, Christoph
Hi, please review a simple import cleanup fix for java/util/jar/Attributes.java and sun/management/jdp/JdpController.java. Bug: https://bugs.openjdk.java.net/browse/JDK-8198539 Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8198539.0/ Thanks and best regards Christoph

Re: [11] RFR: (JAXP) 8038043: Xerces Update: XInclude update

2018-02-22 Thread Joe Wang
Hi Aleksei, Thanks for taking the time to work on this! Looks good overall. XIncludeHandler: setupCurrentBaseURI method can be private. XIncludeTextReader: there's a very long line at 191. It would be good to fix it so that Sdiffs looks better the next time. As for the tests, I'm fine with