Re: RFR (JDK11/java.xml) 8199792: Wrong license header in XMLLimitAnalyzer.java

Hi Joe, Looks fine Roger On 3/20/18 1:57 PM, Joe Wang wrote: Hi, Please help review a quick fix for a license header. Note that I didn't change the copyright year since there's no code change, and also I'd like to maintain the same copyright year as the other classes that were added togeth

Re: RFR 8199843 : Optimize Integer/Long.highestOneBit()

Hi Ivan, On Mar 20, 2018, at 10:24 AM, Ivan Gerasimov wrote: > With non-zero values the new function performs 11-13% worse. > I guess it's acceptable? If we are mostly concerned about the intrinsified cases then I would think that this would be acceptable. Brian

Re: RFR (JDK11/java.xml) 8199792: Wrong license header in XMLLimitAnalyzer.java

Thanks! On 3/20/2018 11:00 AM, Lance Andersen wrote: +1 On Mar 20, 2018, at 1:57 PM, Joe Wang > wrote: Hi, Please help review a quick fix for a license header. Note that I didn't change the copyright year since there's no code change, and also I'd like to main

Re: [11] RFR JDK-8196399, JDK-8199672: Formatting a decimal using locale-specific grouping..., ClassCastException is thrown...

Looks good to me. Naoto On 3/20/18 10:37 AM, Nishit Jain wrote: Hi, Please review the fix for JDK-8196399 & JDK-8199672 Bug: https://bugs.openjdk.java.net/browse/JDK-8196399 https://bugs.openjdk.java.net/browse/JDK-8199672 Webrev: http://cr.openjdk.java.net/~nishjain/8196399_8199672/webrev.01

Re: RFR (JDK11/java.xml) 8199792: Wrong license header in XMLLimitAnalyzer.java

+1 > On Mar 20, 2018, at 1:57 PM, Joe Wang wrote: > > Hi, > > Please help review a quick fix for a license header. Note that I didn't > change the copyright year since there's no code change, and also I'd like to > maintain the same copyright year as the other classes that were added > togeth

RFR (JDK11/java.xml) 8199792: Wrong license header in XMLLimitAnalyzer.java

Hi, Please help review a quick fix for a license header. Note that I didn't change the copyright year since there's no code change, and also I'd like to maintain the same copyright year as the other classes that were added together with this class. JBS: https://bugs.openjdk.java.net/browse/J

Re: RFR 8199773 (bf) XXXBuffer:compareTo method is not working as expected

> On Mar 20, 2018, at 10:24 AM, Alan Bateman wrote: > > > > On 20/03/2018 17:12, Paul Sandoz wrote: >> Hi, >> >> Please review this simple fix for a silly mistake when calculating the >> result of comparing two buffers: >> >> >> http://cr.openjdk.java.net/~psandoz/jdk/JDK-8199773-buffer

[11] RFR JDK-8196399, JDK-8199672: Formatting a decimal using locale-specific grouping..., ClassCastException is thrown...

Hi, Please review the fix for JDK-8196399 & JDK-8199672 Bug: https://bugs.openjdk.java.net/browse/JDK-8196399 https://bugs.openjdk.java.net/browse/JDK-8199672 Webrev: http://cr.openjdk.java.net/~nishjain/8196399_8199672/webrev.01/ Issue: 8196399: Locales such as hy_AM do not use grouping, but s

Re: RFR 8199773 (bf) XXXBuffer:compareTo method is not working as expected

On 20/03/2018 17:12, Paul Sandoz wrote: Hi, Please review this simple fix for a silly mistake when calculating the result of comparing two buffers: http://cr.openjdk.java.net/~psandoz/jdk/JDK-8199773-buffer-compare-value/webrev/

Re: RFR 8199843 : Optimize Integer/Long.highestOneBit()

Hi Claes! On 3/20/18 2:46 AM, Claes Redestad wrote: Hi, On 2018-03-20 09:58, Ivan Gerasimov wrote: Hello! The hightestOneBit function doesn't have an intrinsic and is currently implemented with a dozen of instructions. Alternatively, it could be implemented as MIN_VALUE >>> numberOfLeading

Re: RFR 8199843 : Optimize Integer/Long.highestOneBit()

Hi Peter! On 3/20/18 6:05 AM, Peter Levart wrote: Hi Ivan, What about branch-less variant? public static int highestOneBit(int i) { return i & (MIN_VALUE >>> numberOfLeadingZeros(i)); } Nice variant! I tried to run it, but the numbers are non-distinguishable for non-zero arguments. A

RFR 8199773 (bf) XXXBuffer:compareTo method is not working as expected

Hi, Please review this simple fix for a silly mistake when calculating the result of comparing two buffers: http://cr.openjdk.java.net/~psandoz/jdk/JDK-8199773-buffer-compare-value/webrev/ Paul.

Re: RFR: 8199862: Examine ProxyBuilder::referencedTypes startup cost

On 3/20/18 6:00 AM, Claes Redestad wrote: Hi, by desugaring Stream+lambda usage in Proxy$ProxyBuilder::referencedTypes - and carefully avoiding cloning of parameter and exception type arrays - we can significantly reduce the startup overhead of doing annotation processing in a set of typica

Re: RFR: 8199865: Avoid initializing ShortCache in ProxyGenerator

Looks fine.  Nice small perf gain. Mandy On 3/20/18 7:47 AM, Claes Redestad wrote: Hi, by using Map instead of Map (preserving shortness of values) we can avoid having ProxyGenerator depend on Short$ShortCache, which is a small startup and footprint win (since Integer$IntegerCache is 100% l

Re: RFR 8181594: Efficient and constant-time modular arithmetic

I have no other comments. Thanks, Xuelei On 3/20/2018 7:50 AM, Adam Petcher wrote: Latest webrev: http://cr.openjdk.java.net/~apetcher/8181594/webrev.02/ Comments inline below. In addition, I also changed the name of IntegerModuloP_Base to IntegerModuloP, and IntegerModuloP to ImmutableInteg

Re: RFR 8181594: Efficient and constant-time modular arithmetic

Latest webrev: http://cr.openjdk.java.net/~apetcher/8181594/webrev.02/ Comments inline below. In addition, I also changed the name of IntegerModuloP_Base to IntegerModuloP, and IntegerModuloP to ImmutableIntegerModuloP. On 3/11/2018 12:04 PM, Xuelei Fan wrote: On 2/26/2018 10:39 AM, Adam Pe

RFR: 8199865: Avoid initializing ShortCache in ProxyGenerator

Hi, by using Map instead of Map (preserving shortness of values) we can avoid having ProxyGenerator depend on Short$ShortCache, which is a small startup and footprint win (since Integer$IntegerCache is 100% likely to have already been initialized): http://cr.openjdk.java.net/~redestad/819986

Re: Raw String Literal Library Support

Summary. A. Line support. - Supporting a mix of line terminators `\n|\r\n|\r` is already a well established pattern in language parsers, in the JDK (ex. see java.nio.file.FileChannelLinesSpliterator) and RegEx (ex. see `\R`). The performance difference between checking one vs the three is neg

Re: RFR 8199843 : Optimize Integer/Long.highestOneBit()

Hi Ivan, What about branch-less variant? public static int highestOneBit(int i) {     return i & (MIN_VALUE >>> numberOfLeadingZeros(i)); } Would it be any better for call sites that vary 0 and non-0 argument? Regards, Peter On 03/20/2018 09:58 AM, Ivan Gerasimov wrote: Hello! The hightestO

RFR: 8199862: Examine ProxyBuilder::referencedTypes startup cost

Hi, by desugaring Stream+lambda usage in Proxy$ProxyBuilder::referencedTypes - and carefully avoiding cloning of parameter and exception type arrays - we can significantly reduce the startup overhead of doing annotation processing in a set of typical applications. Webrev: http://cr.openjdk.j

Re: RFR 8199843 : Optimize Integer/Long.highestOneBit()

Hi, On 2018-03-20 09:58, Ivan Gerasimov wrote: Hello! The hightestOneBit function doesn't have an intrinsic and is currently implemented with a dozen of instructions. Alternatively, it could be implemented as MIN_VALUE >>> numberOfLeadingZeros(i), which works for all integers but zero. The fo

RFR 8199843 : Optimize Integer/Long.highestOneBit()

Hello! The hightestOneBit function doesn't have an intrinsic and is currently implemented with a dozen of instructions. Alternatively, it could be implemented as MIN_VALUE >>> numberOfLeadingZeros(i), which works for all integers but zero. The former function gets intrisified by hotspot, which