Weird that this is happening on this 32-bit platform and not others.

@mengzhuo

This will affect on plan9/386 too.
Plan9 ONLY use extendRandom for initial hashkey generate while other platforms read OS random into hashkey first.

This will always had 0 in the first byte. We have three options for this issue:

1. Get random data from OS on plan9 ( I prefer this one but I don't have any plan9 to check. @millerresearch Can you help us?
2. Xor constant primes in the mix32 (slower and it will got failed if data is identical to hashkey: 2^32 -1 )
3. Drop wyhash and revert to cityhash

p.s. plan9 has /dev/random file which we can read from. https://9fans.github.io/plan9port/man/man3/rand.html

Change https://golang.org/cl/302909 mentions this issue: runtime: init hashkey data by /dev/random on plan9

CL 6386 is relevant. Plan9 used to read from /dev/random before that CL, but that was intentionally removed because it was "slow and [...] may block". Perhaps things have changed since 2015 though.

@tmthrgd

CL 6386 is right.
It much more slower and I think maybe we can put const primes into hashkey first for plan9.

read /dev/random
ok  	archive/tar	3.241s
ok  	archive/zip	4.145s
ok  	bufio	3.142s
ok  	bytes	16.037s
ok  	compress/bzip2	2.547s
ok  	compress/flate	3.316s

without /dev/random
ok  	archive/tar	0.257s
ok  	archive/zip	1.246s
ok  	bufio	0.286s
ok  	bytes	12.756s

@wangyi-fudan Any idea how can we initial hashkey without any entropy input?

@0intro, is the GCE-specific slowness described in #10028 still the case? Maybe it's time to investigate that.
What virtualisation technology does GCE use? Can I replicate it at home for debugging or do I need to set up a GCE account and try to do it remotely?

I don't think that's specific to GCE. /dev/random has always been slow and Plan 9 and can block (like /dev/random on Linux).

At some point, I wrote randfs, which replaces /dev/random by a, much faster, pseudo-random generator (similar to /dev/urandom on Linux). It solved the issue, but we finally changed getRandomData, because we didn't really need true random numbers just to improve the distribution of hash values.

If we're going to use the Plan 9's /dev/random, we will have to reintroduce randfs as a dependency to run Go on Plan 9, which wouldn't be very desirable.

I'd prefer options 2. or 3.

What exactly is the requirement for the output produced by getRandomData? Is there a specification somewhere?

What exactly is the requirement for the output produced by getRandomData? Is there a specification somewhere?

For wyhash it only needs a non-zero integer to "mix" (xor + multiply)

Change https://golang.org/cl/303969 mentions this issue: runtime: init plan9 hashkey by time