Re: DecimalFormat regression bug in Java 8?

Hello Lennart, Sorry for the little belated reply. The behaviour you see is due to a fix for JDK-7131459 and is the expected one. While working on the DecimalFormat optimization which you noticed in the code, we discovered a long-standing bug in the DigitList.java class (see bug 7131459

Re: RFR: 8023447: change specification to allow RMI activation to be optional

ing myself they didn't need UOEs added to them, so that's how we ended up with so many cases where throwing UOE is necessary. s'marks On 9/6/13 2:38 AM, Olivier Lagneau wrote: Hi Stuart, I like this, and think this is the right approach for solving the problem. I see h

Re: RFR: 8023447: change specification to allow RMI activation to be optional

Hi Stuart, I like this, and think this is the right approach for solving the problem. I see however that ActivationGroupDesc is not impacted by the change. In the case of an implementation that does not support activation, are we sure there will be no way for a developer to create an instance o

Re: DigitList bug in recent patch

ingMode(RoundingMode.HALF_EVEN); numberFormat.setMinimumFractionDigits(0); numberFormat.setGroupingUsed(false); String ret = numberFormat.format(v); System.out.println(ret); } } -- Best Regards, Olivier. Olivier Lagneau said on date 3/27/2013 5:09 PM: Hi Frank, We discovered som

Re: DigitList bug in recent patch

Hi Frank, We discovered some time ago a long-standing bug in the DigitList.java class (see bug 7131459 ). we have fixed it and this is now in the latest JDK8 builds The fact is that decimal value 78.5 cannot be represented exactly in a binar

Review Request for CR : 7050528 Improve performance of java.text.DecimalFormat.format() call stack

-benchmark is more than x10 on either SPARC or x86 architectures. The footprint cost is ~6kbytes from a static char array constant data to collect digits from integer values. There is an associated regression test, together with a micro-benchmark that may be run optionally. -- Olivier Lagneau

Re: Code Review Request (7161503 subcase) 7142596: RMI JPRT tests are failing

Lagneau wrote: Le 10/07/2012 08:49, Olivier Lagneau a écrit : Now in the 7161503 SetChilEnv case: I think we should just revert to the existing code regarding the DebugExecWatcher and related exception cleanup fix. We must then accept to keep this exception raised each time runwith() is called

Re: Code Review Request (7161503 subcase) 7142596: RMI JPRT tests are failing

Stuart Marks said on date 7/10/2012 10:52 PM: On 7/9/12 11:56 PM, Olivier Lagneau wrote: Le 10/07/2012 08:49, Olivier Lagneau a écrit : Now in the 7161503 SetChilEnv case: I think we should just revert to the existing code regarding the DebugExecWatcher and related exception cleanup fix

Re: Code Review Request (7161503 subcase) 7142596: RMI JPRT tests are failing

Hi Stuart, I am in vacation for 2 days, but I think I need reply anyway now. First thanks for reviewing and giving your time on this. Now in the 7161503 SetChilEnv case: *** SetChildEnv.java The testing of the message string from the IOException causes me great concern. This message is def

Re: Code Review Request (7161503 subcase) 7142596: RMI JPRT tests are failing

Le 10/07/2012 08:49, Olivier Lagneau a écrit : Hi Stuart, I am in vacation for 2 days, but I think I need reply anyway now. First thanks for reviewing and giving your time on this. Now in the 7161503 SetChilEnv case: *** SetChildEnv.java The testing of the message string from the

Re: Request for CR : 7144861 RMI activation tests are too slow (webrev.02)

I made the changes below and checked again all the rmi regression test. This updated webrev is here : http://cr.openjdk.java.net/~olagneau/7144861/webrev.02/ Olivier Olivier Lagneau said on date 5/11/2012 12:18 PM: Stuart Marks said on date 5/11/2012 3:04 AM: Looks good. Just one thing: in

Re: Review Request for CR : 7144861 RMI activation tests are too slow (wrong webev link fixed)

nd if there's nothing else, I'll go ahead with it tomorrow. I am going to provide another webrev containing Darryl's plus your change requests within a couple of hours. Olivier. On 5/10/12 3:20 PM, Olivier Lagneau wrote: Olivier Lagneau said on date 5/11/20

Re: Review Request for CR : 7144861 RMI activation tests are too slow (wrong webev link fixed)

Olivier Lagneau said on date 5/11/2012 12:13 AM: Please find the second webrev with your remarks applied here: http://cr.openjdk.java.net/~olagneau/7144861/webrev.01/ Html link above is buggy. Please go to this correct location: http://cr.openjdk.java.net/~olagneau/7144861/webrev.01 In

Re: Review Request for CR : 7144861 RMI activation tests are too slow

Olivier Lagneau said on date 5/11/2012 12:13 AM: Please find the second webrev with your remarks applied here: http://cr.openjdk.java.net/~olagneau/7144861/webrev.01/ In addition to the way we have agreed (see below) to handle InterruptedException in this fix, I have applied all the other

Re: Review Request for CR : 7144861 RMI activation tests are too slow

outer and inner timer loops, I have kept the current structure of the code, but for sure this should be totally rewritten in a further cleanup of the code. Thanks, Olivier. Stuart Marks said on date 5/10/2012 6:28 AM: On 5/9/12 8:26 AM, Olivier Lagneau wrote: Given that we want to push the code

Re: Review Request for CR : 7144861 RMI activation tests are too slow

Hi Stuarts, David, I agree with your arguments/points discussed below. I understand the argument against swallowing or only reasserting the interrupt when catching IE. I have gone again quickly through all the rmi tests and don't think this code takes into account interuption, or intend to ma

Re: Review Request for CR : 7144861 RMI activation tests are too slow

Thanks david for reviewing too. Please see comments inlined. David Holmes said on date 5/6/2012 2:30 PM: On 5/05/2012 11:50 AM, Stuart Marks wrote: On 03/05/2012 14:09, Olivier Lagneau wrote: Please review this fix for making the jdk regression tests for rmi activation run faster. It brings

Re: Review Request for CR : 7144861 RMI activation tests are too slow

Hi Stuart, Thanks for reviewing. Please see comments inlined. Stuart Marks said on date 5/5/2012 3:50 AM: On 5/3/12 10:53 AM, Alan Bateman wrote: On 03/05/2012 14:09, Olivier Lagneau wrote: Please review this fix for making the jdk regression tests for rmi activation run faster. It brings

Review Request for CR : 7144861 RMI activation tests are too slow

Please review this fix for making the jdk regression tests for rmi activation run faster. It brings a near to x2 speed factor on a Solaris/SPARC machine. The webrev for the fix is here: http://cr.openjdk.java.net/~olagneau/7144861/webrev.00/ This is a speedup only fix that does not attempt to c

Re: RFR: 6988220: java.lang.ObjectName use of String.intern() causes major performance issues at scale

I think I have not been clear enough here. I Agree with Eammon's argument, and anyway ok with this change. Olivier. Olivier Lagneau said on date 2/24/2012 12:38 PM: Hi Éamonn, Eamonn McManus said on date 2/23/2012 8:44 PM: I am not sure it is worth the complexity of extra checks. D

Re: RFR: 6988220: java.lang.ObjectName use of String.intern() causes major performance issues at scale

oving from comparing identity to equality. Thus there will be an impact on the throughput of equals, possibly impacting some applications. Olivier. Éamonn On 23 February 2012 10:52, Olivier Lagneau <mailto:olivier.lagn...@oracle.com>> wrote: Hi Frederic, Performance and typo comme

Re: RFR: 6988220: java.lang.ObjectName use of String.intern() causes major performance issues at scale

canonical names, then domain_length, then ca_array size, then its content, and lastly if all of this fails to filter out, then use String.equals. _canonicalName = (new String(canonical_chars, 0, prop_index)); Typo : useless parentheses. Thanks, Olivier. -- Olivier Lagneau, olivier.lagn

Re: Review Request for CR : 7050528 Improve performance of java.text.DecimalFormat.format() call stack

n mind but forgot to do. Thanks a lot for the patch you provided that fixes the coding style rules too. That will quicken a lot the integration of your suggestions. I will check the perf result of the new code too. Olivier. Joe Darcy said on date 9/14/2011 8:04 AM: Hello Olivier. Olivier Lag

Review Request for CR : 7050528 Improve performance of java.text.DecimalFormat.format() call stack

-USIV arch and ~x10 on Sparc-T4. The footprint cost is ~6kbytes of static char array constant data to collect digits from integer values. New test dedicated at checking fast-path algorithm, as well as micro-benchmark, are coming soon in a subsequent webrev containing them. -- Olivier Lagneau