Re: JDK 9 RFR of 4477961: java.lang.Math.toDegrees(double) could be optimized

Hi Brian, On 09/23/2014 02:34 AM, Brian Burkhalter wrote: > I created an alternate webrev using compile-time constants per your > suggestion: > > http://cr.openjdk.java.net/~bpb/4477961/webrev.01/ > Ah, sorry for confusing language about "co

Re: Urgent [9] RFR (S) : JDK-8039915 NumberFormat.format() does not consider required no. of fraction digits properly

Hello, I've looked over the proposed changeset as well. I don't see a problem with the code, but I'm not (yet) convinced it is right. For future work, I think be clearer to combine the CEILING and FLOOR cases to share a loop with a condition test based on CEILING/FLOOR lie. In the test, aga

java.time.Clock$TickClock wrong javadoc

Hi core-libs-dev, Quick note that it seems that the Javadoc for Clock$TickClock has copypasta from Clock$OffsetClock. Not a huge deal for a non-public class but probably worth fixing. http://hg.openjdk.java.net/jdk9/client/jdk/file/5edbebb72540/src/java.base/share/classes/java/time/Clock.java

Re: JDK 9 RFR of 4477961: java.lang.Math.toDegrees(double) could be optimized

Hi Mike, Thanks for the review. For the sake of completeness I tested converting 89.0 * Double.MIN_VALUE to radians and Double.MAX_VALUE / 89.0 to degrees. The old version gives 0.0 and Double.POSITIVE_INFINITY, respectively, whereas the webrev.01 version gives the respective results 1.0E-323

Re: JDK 9 RFR of 4477961: java.lang.Math.toDegrees(double) could be optimized

Looks fine to me! Mike On Sep 22 2014, at 15:34 , Brian Burkhalter wrote: > Hi Aleksey, > > On Sep 22, 2014, at 2:43 PM, Aleksey Shipilev > wrote: > >> Hm, and this compiler transformation works in strictfp context? I hope >> compilers do the constant folding in strictfp/fdlibm mode… > > Y

Re: JDK 9 RFR of 4477961: java.lang.Math.toDegrees(double) could be optimized

Hi Aleksey, On Sep 22, 2014, at 2:43 PM, Aleksey Shipilev wrote: > Hm, and this compiler transformation works in strictfp context? I hope > compilers do the constant folding in strictfp/fdlibm mode… Yes. > I would probably just go and declare the private compile-time constants. > This is safe

Re: RFR: 8058887: (fmt) Improve java/util/Formatter test coverage of group separators and width

Fair enough! I removed the Spp changes and and regenerated the test files using the original script: http://cr.openjdk.java.net/~redestad/8058887/webrev.04/ Thanks! /Claes On 2014-09-22 23:00, Xueming Shen wrote: It was on purpose to keep those blank lines when I wrote the Spp to replace the

Re: JDK 9 RFR of 4477961: java.lang.Math.toDegrees(double) could be optimized

Hi Mike, It’s definitely worth mentioning and something which should be taken into consideration when considering the change. Thanks, Brian On Sep 22, 2014, at 2:48 PM, Mike Duigou wrote: > I thought it was worth mentioning because I had had to deal with the > underflow issue in the mapping

Re: JDK 9 RFR of 4477961: java.lang.Math.toDegrees(double) could be optimized

Hi Aleksey, On Sep 22, 2014, at 2:43 PM, Aleksey Shipilev wrote: > I would probably just go and declare the private compile-time constants. > This is safer, since: a) you are not at the mercy of optimizing compiler > anymore (have you tried the benchmark with C1?); b) the initializing > express

Re: JDK 9 RFR of 4477961: java.lang.Math.toDegrees(double) could be optimized

Hi Brian; I thought it was worth mentioning because I had had to deal with the underflow issue in the mapping software for the Audi/Stanford autonomous. For various reasons that system ends up with many very-tiny-but-non-zero quantities in it's mapping and heading component and I initially had

Re: RFR [8058875]: CharsetEncoder.maxBytesPerChar() should return 4 for UTF-8

Much of the documentation (especially the early stuff when supplementary characters were rarer/nonexistent) doesn't distinguish between "character (codepoint)" and "char" clearly enough. Fixing that in all the docs would be a fine thing to do. On Mon, Sep 22, 2014 at 2:34 PM, Mark Thomas wrote:

Re: JDK 9 RFR of 4477961: java.lang.Math.toDegrees(double) could be optimized

Hi Brian, Looks OK. On 09/23/2014 01:10 AM, Brian Burkhalter wrote: > Summary: Change constructs like “a * B / C” and “u / V * W” to “x * > (Y / Z)” where lower case denotes a variable and upper case a > constant. This forces the constant value (Y / Z) to be evaluated only > once per VM instance,

Re: RFR [8058875]: CharsetEncoder.maxBytesPerChar() should return 4 for UTF-8

On 22/09/2014 22:46, Xueming Shen wrote: > On 09/22/2014 01:14 PM, Ivan Gerasimov wrote: >> Hello! >> >> The UTF-8 encoding allows characters that are 4 bytes long. >> However, CharsetEncoder.maxBytesPerChar() currently returns 3.0, which >> is not always enough. >> >> Would you please review the s

Re: JDK 9 RFR of 4477961: java.lang.Math.toDegrees(double) could be optimized

Indeed these considerations made me a little nervous about the change. For the edge cases which would have previously overflowed or underflowed this does not seem like a problem, i.e., to obtain a valid result where one would not have done before. For the cases in between however I suppose that

Re: RFR [8058875]: CharsetEncoder.maxBytesPerChar() should return 4 for UTF-8

On 22/09/2014 22:23, Martin Buchholz wrote: > I think you are mistaken. It's maxBytesPerChar, not maxBytesPerCodepoint! You are going to have to explain that some more. The Javadoc for CharsetEncoder.maxBytesPerChar() is explicit: Returns the maximum number of bytes that will be produced for each

Re: RFR [8058875]: CharsetEncoder.maxBytesPerChar() should return 4 for UTF-8

On 09/22/2014 01:14 PM, Ivan Gerasimov wrote: Hello! The UTF-8 encoding allows characters that are 4 bytes long. However, CharsetEncoder.maxBytesPerChar() currently returns 3.0, which is not always enough. Would you please review the simple fix for this issue? BUGURL: https://bugs.openjdk.jav

Re: JDK 9 RFR of 4477961: java.lang.Math.toDegrees(double) could be optimized

Looks fine. I think it is always important note when a change may result in different results for some inputs. I will reiterate for the record what's mentioned in the bug: > However, one caveat is that this may affect the results of some calculations. > For example, some range of numbers that u

Re: RFR [8058875]: CharsetEncoder.maxBytesPerChar() should return 4 for UTF-8

I think you are mistaken. It's maxBytesPerChar, not maxBytesPerCodepoint! changeset: 3116:b44704ce8a08 user:sherman date:2010-11-19 12:58 -0800 6957230: CharsetEncoder.maxBytesPerChar() reports 4 for UTF-8; should be 3 Summary: changged utf-8's CharsetEncoder.maxBytesPerChar to

JDK 9 RFR of 4477961: java.lang.Math.toDegrees(double) could be optimized

Hello, Another relatively small numerics fix: Issue: https://bugs.openjdk.java.net/browse/JDK-4477961 Webrev: http://cr.openjdk.java.net/~bpb/4477961/webrev.00/ Summary: Change constructs like “a * B / C” and “u / V * W” to “x * (Y / Z)” where lower case denotes a variable and upper case a con

Re: RFR: 8058887: (fmt) Improve java/util/Formatter test coverage of group separators and width

On 09/22/2014 02:00 PM, Xueming Shen wrote: It was on purpose to keep those blank lines when I wrote the Spp to replace the original script. it serves the purpose of preserving the line number the generated source code (identical to the ln# of the same code line in template file). This is con

Re: RFR: 8058887: (fmt) Improve java/util/Formatter test coverage of group separators and width

It was on purpose to keep those blank lines when I wrote the Spp to replace the original script. it serves the purpose of preserving the line number the generated source code (identical to the ln# of the same code line in template file). This is convenient/import when debugging those generated

Re: RFR (XXS): 8058887: TEST_BUG: java/util/Formatter/genBasic.sh points to old location of Spp.java

On 09/22/2014 07:35 AM, Claes Redestad wrote: Hi, can I have a review and sponsor for this trivial fix to make the jtreg test generator script jdk/test/java/util/Formatter/genBasic.sh work in the new build system? bug: https://bugs.openjdk.java.net/browse/JDK-8058887 webrev: http://cr.openjdk

RFR [8058875]: CharsetEncoder.maxBytesPerChar() should return 4 for UTF-8

Hello! The UTF-8 encoding allows characters that are 4 bytes long. However, CharsetEncoder.maxBytesPerChar() currently returns 3.0, which is not always enough. Would you please review the simple fix for this issue? BUGURL: https://bugs.openjdk.java.net/browse/JDK-8058875 WEBREV: http://cr.ope

Re: RFR [9]: 8050142: Optimize java.util.Formatter

Hi, Sherman pointed out that there was a path that could actually take a minor performance hit from this patch, which would be unacceptable. This version takes the minimal approach to addressing this by adding back a method operating on a char[], simplified for the specific usage case (the exp

RFR: 8058887: (fmt) Improve java/util/Formatter test coverage of group separators and width

Hi, previous attempt was considered too trivial a fix, so how about actually improving the test coverage, fixing the link issue in genBasic and upgrade Spp.java to not add thousands of empty lines while we're at it? Rejoice! webrev: http://cr.openjdk.java.net/~redestad/8058887/webrev.03/ Mo

Re: JDK 9 RFR of 8043740: Doubles with large exponents overflow to Infinity incorrectly

Hi Brian, Okay; looks good to go back. Thanks, -Joe On 9/22/2014 8:53 AM, Brian Burkhalter wrote: Hi Joe, Yes, and then some. There are two cases which fail before applying the patch and neither fails thereafter. One of these cases matches the test in the original patch. The remaining case

Re: JDK 9 RFR of 8043740: Doubles with large exponents overflow to Infinity incorrectly

Hi Joe, Yes, and then some. There are two cases which fail before applying the patch and neither fails thereafter. One of these cases matches the test in the original patch. The remaining cases pass both before and after but I added them as edges cases anyway. Thanks, Brian On Sep 21, 2014,

Re: Urgent [9] RFR (S) : JDK-8039915 NumberFormat.format() does not consider required no. of fraction digits properly

Hi Olivier, On Sep 22, 2014, at 7:56 AM, olivier.lagn...@oracle.com wrote: >> and 2) use braces around all the statements contained in if/else blocks (see >> below). Comment #2 is nit-picky. > I tried to keep the same flavour of writing as in HALF_DOWN and HALF_EVEN > cases, i.e. don't use brac

Re: Urgent [9] RFR (S) : JDK-8039915 NumberFormat.format() does not consider required no. of fraction digits properly

Hi Brian, Thanks a lot for your thorough review of the fix ! Please see comments inlined. On 20/09/2014 00:50, Brian Burkhalter wrote: Hello Olivier, By inspection I think that the fix and the test update look good. I verified that the test hits all five branches contained in the else-if bl

RFR (XXS): 8058887: TEST_BUG: java/util/Formatter/genBasic.sh points to old location of Spp.java

Hi, can I have a review and sponsor for this trivial fix to make the jtreg test generator script jdk/test/java/util/Formatter/genBasic.sh work in the new build system? bug: https://bugs.openjdk.java.net/browse/JDK-8058887 webrev: http://cr.openjdk.java.net/~redestad/8058887/webrev.01/ /Claes

Re: RFR (XS) CR 8058643: (str) Re-examine hashCode implementation

On 09/22/2014 06:13 PM, Aleksey Shipilev wrote: > On 09/22/2014 06:06 PM, Aleksey Shipilev wrote: >> Hi again, >> >> On 09/17/2014 06:28 PM, Aleksey Shipilev wrote: >>> Can I have a review and a sponsorship for this tiny readability cleanup >>> in String.hashCode()? >>> http://cr.openjdk.java.net/

Re: RFR (XS) CR 8058643: (str) Re-examine hashCode implementation

On 09/22/2014 06:06 PM, Aleksey Shipilev wrote: > Hi again, > > On 09/17/2014 06:28 PM, Aleksey Shipilev wrote: >> Can I have a review and a sponsorship for this tiny readability cleanup >> in String.hashCode()? >> http://cr.openjdk.java.net/~shade/8058643/webrev.01/ >> https://bugs.openjdk.java

Re: RFR (XS) CR 8058643: (str) Re-examine hashCode implementation

Hi again, On 09/17/2014 06:28 PM, Aleksey Shipilev wrote: > Can I have a review and a sponsorship for this tiny readability cleanup > in String.hashCode()? > http://cr.openjdk.java.net/~shade/8058643/webrev.01/ > https://bugs.openjdk.java.net/browse/JDK-8058643 I think we have enough reviews? H

Re: Urgent [9] RFR (S) : JDK-8039915 NumberFormat.format() does not consider required no. of fraction digits properly

Hi William, Thanks a lot for your time and checks ! On 19/09/2014 22:02, William Price wrote: Hi Oliver, First, sorry about mistyping your name, Olivier! I copied your patch into my shim locally and ran my test cases and still get a couple failures (see output below). Your patch and my vers

Re: Lower overhead String encoding/decoding

Compare with https://bugs.openjdk.java.net/browse/JDK-6695386 Maybe that would help a little. -Ulf Am 22.09.2014 um 13:25 schrieb Richard Warburton: Hi all, A long-standing issue with Strings in Java is the ease and performance of creating a String from a ByteBuffer. People who are using nio

Re: Lower overhead String encoding/decoding

On 22/09/2014 12:25, Richard Warburton wrote: : I've put together a patch that implements this to demonstrate the overall direction. http://cr.openjdk.java.net/~rwarburton/string-patch-webrev-5/ I'm happy to take any feedback on direction or the patch itself or the overall idea/approach. I thi

Lower overhead String encoding/decoding

Hi all, A long-standing issue with Strings in Java is the ease and performance of creating a String from a ByteBuffer. People who are using nio to bring in data off the network will be receiving that data in the form of bytebuffers and converting it to some form of String. For example restful syst

Re: extcheck

On 11/09/2014 17:23, Pavel Rappo wrote: : We don't think it is widely used. And will become even less useful with upcoming modularization. Are there any good reasons to keep this thing in the JDK? Searching for usages on stackoverflow and other sites doesn't come up with much, it would be su

Re: RFR JDK-8044627: Update JNDI to work with modules

On 16/09/2014 12:12, Pavel Rappo wrote: Hi everyone, Could you please review my change for JDK-8044627? Pavel - are you planning to send an updated webrev based on the discussion so far? The other thing that I meant to ask is whether this change will add service configuration files for the