On Sun, 9 Aug 2026 22:30:12 GMT, Shawn Emery <[email protected]> wrote:
>> test/micro/org/openjdk/bench/javax/crypto/full/PolynomialP256Bench.java line
>> 139:
>>
>>> 137: // prevent constant folding. Previously, C2 would perform
>>> constant
>>> 138: // propagation and remove the subsequent dead-code where 0 was
>>> input.
>>> 139: for (int j = 0; j < SET; j++) {
>>
>> We could just do this:
>>
>>
>> MutableIntegerModuloP test1 = X.mutable();
>> MutableIntegerModuloP test2 = one.mutable();
>> for (int i = 0; i< 10000; i++) {
>> int bits = i * 2654435769u;
>> test1.conditionalSet(test2, bits & (1 << 24)); // The exact bit
>> numbers don't matter, but don't use the low bits
>> test1.conditionalSet(test2, bits & (2 << 24));
>> test2.conditionalSet(test1, bits & (4 << 24));
>> test2.conditionalSet(test1, bits & (8 << 24));
>>
>>
>> which should get us something unbiased and unpredictable.
>
> Unfortunately this change would reintroduce cross-call and dead-code
> elimination with C2, while still biasing against opaqueness with intrinsics.
> I've spent the past week going through different designs to keep the
> benchmark relatively close to the original, like you have, with the goal of
> preventing optimizations. For better or for worse, C2 is too good at
> identifying targets and will quite elegantly remove any code that doesn't
> contribute to said target.
Can you explain what is happening here? I wonder if this may not be a problem
with the benchmark, but with the `conditionalSet()` code itself.
You talk about "cross-call" optimization, but what is really happening? If C2
really can see that `conditionalSet(0)` doesn't need to be executed, or that
repeated invocations of `conditionalSet` don't do anything, then that is a
problem with the crypto code. If it is the latter, then it needs to be fixed in
the crypto code, for security reasons.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/32047#discussion_r3750793072
