RFR (S): 8050114: Expose Integer/Long formatUnsigned methods internally (original) (raw)
Mike Duigou mike.duigou at oracle.com
Fri Jul 18 22:59:39 UTC 2014
- Previous message: RFR (S): 8050114: Expose Integer/Long formatUnsigned methods internally
- Next message: Serializable lambda and bytecode rewriters
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
You are correct. I will switch to a do-while.
Mike
On Jul 18 2014, at 15:20 , Ivan Gerasimov <ivan.gerasimov at 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
- Previous message: RFR (S): 8050114: Expose Integer/Long formatUnsigned methods internally
- Next message: Serializable lambda and bytecode rewriters
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]