8183912: java.math.BigDecimal.movePointLeft() should return this if called with zero argument

[Roger Riggs]

+1,

Hard to argue with +10x.  :)

Roger

On 12/18/2018 01:03 PM, Brian Burkhalter wrote:
> https://bugs.openjdk.java.net/browse/JDK-8183912 <https://bugs.openjdk.java.net/browse/JDK-8183912>
>
> For the patch included below, the JMH benchmark MovePointLeftZero attached to the above issue, when run with options "-f 1 -wi 5 -w 5 -i 10 -r 10" (one fork, five warmup iterations of five seconds each, ten measurement iterations of ten seconds each), shows an order of magnitude (10X) throughput improvement for a zero left shift. The effect on the positive left shift case appears to be at the level of measurement noise.
>
> Thanks,
>
> Brian
>
> --- a/src/java.base/share/classes/java/math/BigDecimal.java
> +++ b/src/java.base/share/classes/java/math/BigDecimal.java
> @@ -2871,6 +2871,8 @@
>        * @throws ArithmeticException if scale overflows.
>        */
>       public BigDecimal movePointLeft(int n) {
> +        if (n == 0) return this;
> +
>           // Cannot use movePointRight(-n) in case of n==Integer.MIN_VALUE
>           int newScale = checkScale((long)scale + n);
>           BigDecimal num = new BigDecimal(intVal, intCompact, newScale, 0);
> @@ -2893,6 +2895,8 @@
>        * @throws ArithmeticException if scale overflows.
>        */
>       public BigDecimal movePointRight(int n) {
> +        if (n == 0) return this;
> +
>           // Cannot use movePointLeft(-n) in case of n==Integer.MIN_VALUE
>           int newScale = checkScale((long)scale - n);
>           BigDecimal num = new BigDecimal(intVal, intCompact, newScale, 0);
>