RFR: 8253089: Windows (MSVC 2017) build fails after JDK-8243208

[Aleksey Shipilev]

On 9/14/20 6:05 PM, Kim Barrett wrote:
> I think changing to using u2 isn't the right solution though.  This throws
> away a lot of bits in the hash-code calculation, potentially making it less
> effective.  

I think this accuracy concern does not apply here, because it does not actually change the computation.

This is because polynomial hash codes enjoy the modulo distributivity, computation uses unsigned 
(non-negative) values, and the fact that the result is finally stored in u2, cutting out whatever 
upper bits hash code had accumulated.

A bit more rigorously:

   M = 2^(sizeof(u2)*8) = 16
   K = 2^(sizeof(unsigned int)*8) = 32  // assume int is 32 bit

   L1: note M and K are power of two, and K=2*M, so (x % K) % M = (x % M) here
     (Translation: cutting out K lower bits, and then M (M < K) lower bits is equivalent to
                   cutting out M lower bits right away)

   new_hashcode = sum_i( (31^k * s[i]) % M) % M

   old_hashcode = sum_i( (31^k * s[i]) % K) % M
                = sum_i(((31^k * s[i]) % K) % M) % M // modulo distributivity
                = sum_i( (31^k * s[i]) % M) % M      // by L1
                = new_hashcode

Or try this ;)
   https://cr.openjdk.java.net/~shade/8253089/mod-hashcode.cpp

> I think a better workaround is to locally suppress the warning,
> which I think is from the multiplication here:
> 
> 61       h = 31*h + (unsigned int) *s;
> 
> So I suggest wrapping that line with targeted warning suppression, i.e.
> using PRAGMA_DIAG_PUSH/POP and PRAGMA_DISABLE_MSVC_WARNING(4307) with an
> appropriate comment. I don't love cluttering code with that kind of thing,
> but I think in this case that's a better solution than changing what's
> being calculated.

I think math thankfully saves us from cluttering the code with compiler pragmas.

-- 
Thanks,
-Aleksey