RFR: 8355719: Reduce memory consumption of BigInteger.pow() [v46]

[Raffaello Giulietti]

On Tue, 29 Apr 2025 17:00:25 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> fabioromano1 has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Adjust the type of operand
>>  - Use a more loose formula to do range check
>>    
>>    Use a more loose formula to do range check, in order not to exclude a priori values that may be inside the supported range
>
> I must have screwed up something in my previous benchmarks, probably when copying the master branch (current) `BigInteger` into the PR branch for the "before" figures.
> 
> Here's indeed a more favorable picture (but certainly not a 50% enhancement in allocation rate).
> I obtain comparable results with more iterations (`make test TEST="micro:java.math.BigIntegerPow" MICRO="WARMUP_ITER=3;ITER=3;OPTIONS=-prof gc"`).
> 
> I'll delete my previous misleading results.
> Sorry for the noise.
> 
> macOS 15.4.1 / M1 Pro / 32 GiB / java 25-internal
> 
> _before_
> 
> Benchmark                                   Mode  Cnt            Score           Error   Units
> BigIntegerPow.testPowL                      avgt    3   7828857180.333 ± 723831405.464   ns/op
> BigIntegerPow.testPowL:gc.alloc.rate        avgt    3         4766.633 ±       440.607  MB/sec
> BigIntegerPow.testPowL:gc.alloc.rate.norm   avgt    3  39130646080.000 ±         0.001    B/op
> BigIntegerPow.testPowL:gc.count             avgt    3          260.000                  counts
> BigIntegerPow.testPowL:gc.time              avgt    3          190.000                      ms
> BigIntegerPow.testPowM                      avgt    3   7784905013.667 ± 751070238.685   ns/op
> BigIntegerPow.testPowM:gc.alloc.rate        avgt    3         4737.671 ±       455.843  MB/sec
> BigIntegerPow.testPowM:gc.alloc.rate.norm   avgt    3  38674111834.667 ±       337.057    B/op
> BigIntegerPow.testPowM:gc.count             avgt    3          257.000                  counts
> BigIntegerPow.testPowM:gc.time              avgt    3          192.000                      ms
> BigIntegerPow.testPowS                      avgt    3   7615946041.333 ± 505408224.968   ns/op
> BigIntegerPow.testPowS:gc.alloc.rate        avgt    3         4622.726 ±       306.660  MB/sec
> BigIntegerPow.testPowS:gc.alloc.rate.norm   avgt    3  36917399656.000 ±         0.001    B/op
> BigIntegerPow.testPowS:gc.count             avgt    3          246.000                  counts
> BigIntegerPow.testPowS:gc.time              avgt    3          184.000                      ms
> BigIntegerPow.testPowXL                     avgt    3   7806063305.667 ± 841981680.300   ns/op
> BigIntegerPow.testPowXL:gc.alloc.rate       avgt    3         4795.153 ±       515.480  MB/sec
> BigIntegerPow.testPowXL:gc.alloc.rate.norm  avgt    3  39249581269.333 ±       337.057    B/op
> BigIntegerPow.testPowXL:gc.count            avgt    3          261.000                  counts
> BigIntegerPow.testPowXL:gc.time             avgt    3      ...

> @rgiulietti Although there could be no significant differences, the method to compute powers of longs could be useful, since it is used both by BigInteger.pow() and the possible implementation of nth root, so this PR might not be thrown away, or at least not completely.

Please keep going...

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24690#issuecomment-2839626328