Hello Aleksey,
Great job! I'm looking into your patch and have got few questions.
Please, excuse my limited understanding of the topic.
1. I have noticed that you have replaced shiftLeft(1) with
shiftLeftOneBit() in the following checks which appear . Is it
performance critical part or just cleaning?
// Checking if: remainder * 2 >= scaledDivisor
remainder.abs().shiftLeftOneBit().compareTo(scaledDivisor.abs())
If this is critical, then can one imagine a way of checking that a
number is twice bigger than another number without copying and
shifting the number? For cases when one number has more binary digits
than another this should be easy.
2. What is the meaning of 2 in the new function name unsignedMultAdd2?
Why not unsignedMultAdd4?
2a. What is the purpose of the following fix? How a function call
(even for a magic function), could be quicker than multiplication
inlined by JIT? Does it mean our JIT poorly inlines multiplication?
 long res = (aDigits[0] & 0xFFFFFFFFL) * (factor);
+ long res = unsignedMultAdd2(aDigits[0], factor, 0, 0);
3. You added a check against shifting zero values. Does adding this
check on a common path add to performance? If zeroes come to shift
function often enough to give a benefit, which caller spams so much
zeroes? Does it worth to patch the caller instead?
4. I have an abstract concern with no idea how to address it. An
integer array in memory is very similar to a long array (if endings
are correct). Is there any way to use 64bit operations for speed up?
Thank you for a thoughtful patch.
On Wed, May 21, 2008 at 7:16 PM, Aleksey Shipilev
<aleksey.shipilev@gmail.com> wrote:
> Hi,
>
> There are bunch of optimizations useful for RSA computation using
> java.math, filed as HARMONY5825 [1].
> Could someone please review this issue?
>
> Thanks,
> Aleksey.
>
> [1] https://issues.apache.org/jira/browse/HARMONY5825
>

With best regards,
Alexei
