RFR: 8257232: CompileThresholdScaling fails to work on 32-bit platforms

[Claes Redestad]

On Sat, 28 Nov 2020 23:34:23 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> CompileThresholdScaling is incorrect on 32-bit platforms.
> 
> If you run the following command on Linux-32:
> java -XX:CompileThresholdScaling=0.75 -version
> It gets the following unexpected warnings:
> intx Tier0InvokeNotifyFreqLog=32 is outside the allowed range [ 0 ... 30 ]
> intx Tier0BackedgeNotifyFreqLog=32 is outside the allowed range [ 0 ... 30 ]
> intx Tier2InvokeNotifyFreqLog=32 is outside the allowed range [ 0 ... 30 ]
> intx Tier2BackedgeNotifyFreqLog=32 is outside the allowed range [ 0 ... 30 ]
> intx Tier3InvokeNotifyFreqLog=32 is outside the allowed range [ 0 ... 30 ]
> intx Tier3BackedgeNotifyFreqLog=32 is outside the allowed range [ 0 ... 30 ]
> intx Tier23InlineeNotifyFreqLog=32 is outside the allowed range [ 0 ... 30 ]
> 
> The failure is that nth_bit(max_freq_bits) [1] = nth_bit(32) [2] = 0 on 32-bit platforms.
> So the scaling logic is wrong.
> It would be better to fix it.
> 
> Thanks.
> Best regards,
> Jie
> 
> [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/compiler/compilerDefinitions.cpp#L125
> [2] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/utilities/globalDefinitions.hpp#L973

Looks good to me.

Just an idea for a future RFE (one which I might pick up and work on myself): If the multiply-loop-based `log2_intptr` is a performance issue here, it could probably be optimized by building a variant based on `count_leading_zeros`. That would require lifting it out from `globalDefinitions.hpp`, so `powerOfTwo.hpp` might be a good place.

src/hotspot/share/compiler/compilerDefinitions.cpp line 127:

> 125:     return 0;
> 126:   } else {
> 127:     intx res = log2_intptr(scaled_freq);

Could be simplified to `return MIN2(log2_intptr(scaled_freq), max_freq_bits);`

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

Marked as reviewed by redestad (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/1499