Re: RFR (S): 8050114: Expose Integer/Long formatUnsigned methods internally

2014-07-18 Thread Claes Redestad 

Hi,

 Mike Duigou suggested some simplifications to the formatUnsigned 
methods. Shows a slight speed-upon some micros as well:


 http://cr.openjdk.java.net/~redestad/8050114/webrev.2/

/Claes

On 2014-07-13 00:26, Claes Redestad wrote:

Hi,

 please review this patch to expose formatUnsignedInt/-Long through 
JavaLangAccess.


 webrev: http://cr.openjdk.java.net/~redestad/8050114/webrev.1/
 bug: https://bugs.openjdk.java.net/browse/JDK-8050114

 The behavior of the methods have been adjusted to be zero-padding in 
case the number formatted is shorter than the specified length, since 
that simplifies use cases for which this utility is exposed 
internally, e.g., JDK-8006627 
https://bugs.openjdk.java.net/browse/JDK-8006627. Microbenchmarks 
show that this does not adversely affect performance of current uses 
through toHexString, toOctalString etc.


 Thanks!

 /Claes

Re: RFR (S): 8050114: Expose Integer/Long formatUnsigned methods internally

2014-07-18 Thread Mike Duigou 
Looks good. I will complete some additional testing and push this changeset for 
you.

On Jul 18 2014, at 14:14 , Claes Redestad claes.redes...@oracle.com wrote:

 Hi,
 
 Mike Duigou suggested some simplifications to the formatUnsigned methods. 
 Shows a slight speed-upon some micros as well:
 
 http://cr.openjdk.java.net/~redestad/8050114/webrev.2/
 
 /Claes
 
 On 2014-07-13 00:26, Claes Redestad wrote:
 Hi,
 
 please review this patch to expose formatUnsignedInt/-Long through 
 JavaLangAccess.
 
 webrev: http://cr.openjdk.java.net/~redestad/8050114/webrev.1/
 bug: https://bugs.openjdk.java.net/browse/JDK-8050114
 
 The behavior of the methods have been adjusted to be zero-padding in case 
 the number formatted is shorter than the specified length, since that 
 simplifies use cases for which this utility is exposed internally, e.g., 
 JDK-8006627 https://bugs.openjdk.java.net/browse/JDK-8006627. 
 Microbenchmarks show that this does not adversely affect performance of 
 current uses through toHexString, toOctalString etc.

All of the existing users of this method pre-size their char buffer and use a 
zero offset so there are no changes in behaviour. (In case anyone was wondering)

Mike

Re: RFR (S): 8050114: Expose Integer/Long formatUnsigned methods internally

2014-07-18 Thread Ivan Gerasimov 

Hi Claes!

Wouldn't it be better to use do-while here:

 339 while (charPos  offset) {
 340 buf[--charPos] = Integer.digits[val  mask];
 341 val = shift;
 342 }

given the precondition

 // assert len  0  (offset + len) = buf.length : illegal length;

(charPos  offset) condition should always hold for the first time.

This would save one comparison.

Sincerely yours,
Ivan

On 19.07.2014 1:14, Claes Redestad wrote:

Hi,

 Mike Duigou suggested some simplifications to the formatUnsigned 
methods. Shows a slight speed-upon some micros as well:


 http://cr.openjdk.java.net/~redestad/8050114/webrev.2/

/Claes

On 2014-07-13 00:26, Claes Redestad wrote:

Hi,

 please review this patch to expose formatUnsignedInt/-Long through 
JavaLangAccess.


 webrev: http://cr.openjdk.java.net/~redestad/8050114/webrev.1/
 bug: https://bugs.openjdk.java.net/browse/JDK-8050114

 The behavior of the methods have been adjusted to be zero-padding in 
case the number formatted is shorter than the specified length, since 
that simplifies use cases for which this utility is exposed 
internally, e.g., JDK-8006627 
https://bugs.openjdk.java.net/browse/JDK-8006627. Microbenchmarks 
show that this does not adversely affect performance of current uses 
through toHexString, toOctalString etc.


 Thanks!

 /Claes

Re: RFR (S): 8050114: Expose Integer/Long formatUnsigned methods internally

2014-07-18 Thread Mike Duigou 
You are correct. I will switch to a do-while.

Mike

On Jul 18 2014, at 15:20 , Ivan Gerasimov ivan.gerasi...@oracle.com wrote:

 Hi Claes!
 
 Wouldn't it be better to use do-while here:
  339 while (charPos  offset) {
  340 buf[--charPos] = Integer.digits[val  mask];
  341 val = shift;
  342 }
 given the precondition 
  // assert len  0  (offset + len) = buf.length : illegal length;
 (charPos  offset) condition should always hold for the first time.
 
 This would save one comparison.
 
 Sincerely yours,
 Ivan
 
 On 19.07.2014 1:14, Claes Redestad wrote:
 Hi, 
 
  Mike Duigou suggested some simplifications to the formatUnsigned methods. 
 Shows a slight speed-upon some micros as well: 
 
  http://cr.openjdk.java.net/~redestad/8050114/webrev.2/ 
 
 /Claes 
 
 On 2014-07-13 00:26, Claes Redestad wrote: 
 Hi, 
 
  please review this patch to expose formatUnsignedInt/-Long through 
 JavaLangAccess. 
 
  webrev: http://cr.openjdk.java.net/~redestad/8050114/webrev.1/ 
  bug: https://bugs.openjdk.java.net/browse/JDK-8050114 
 
  The behavior of the methods have been adjusted to be zero-padding in case 
 the number formatted is shorter than the specified length, since that 
 simplifies use cases for which this utility is exposed internally, e.g., 
 JDK-8006627 https://bugs.openjdk.java.net/browse/JDK-8006627. 
 Microbenchmarks show that this does not adversely affect performance of 
 current uses through toHexString, toOctalString etc. 
 
  Thanks! 
 
  /Claes