Sorry for resending it. I missed a few MLs. --
Hi, Please, could I get comments on the following change? Since it's related to security, I would be glad if security experts could also comment on that. webrev: http://cr.openjdk.java.net/~gromero/POWER9/darn/v6_rebased/ It introduces a way to get benefits from hardware instructions in userspace that can delivery a random number and so be used to speed up and avoid blocking in some SecureRandom methods, notably generateSeed() and nextBytes(), without loosing the random number quality. Particularly on Power, the new POWER9 CPUs introduced a hardware instruction called 'darn' that can be used for that purpose. The main idea is to add a new JCA provider called "HWTRNG" (if no better name is suggested), adding new helper methods that can then be intrinsified and that will be used by generateSeed() and nextBytes(). In that sense, this change also adds the proper mechanisms in the Interpreter, C1 Compiler, and C2 compiler (for PPC64, but also paving the way for other platforms) to intrinsify these helper methods that will be used in the end by generateSeed() and nextBytes() methods. The added helpers are: byte[] getRandomSequence0(int) byte[] getRandomSequence1(byte[]) long validRandomLong(void) long randomLong(void) The helpers also take care of checking if the returned random number is valid and attempt 10 times (as recommended by ISA) get a valid random number before falling back to a software alternative (HWTRNG is based mostly on JCA provider NativePRNG and so the fall back mechanism will use the exactly same methods found in NativePRNG and hence behave similarly. Nonetheless, in my experience such a hardware failures (which are the main cause of a returned invalid random number) are quite rare: in my tests I was never able to exhaust the HW RNG and force it to generate an invalid random number). The user, besides having to specify explicitly the use of a non-default provider (HWTRNG), will have to unlock the VM experimental options to effectively use the hardware RNG as an unique random source by passing options "-XX:+UnlockExperimentalVMOptions -XX:+UseRANDOMIntrinsics". On Power, for the Interpreter and C1 Compiler, besides avoiding the blocking effect of a low entropy on /dev/random, I was able to get about 126 Mbps (3x higher than the version without 'darn') on generaSeed() and nextBytes(). The maximum theoretical value on a POWER9 machine is usually 128 Mbps. I'll address the details about the file headers (Copyright, dates, authors, versions, etc) after I get some feedback about this change. Thanks in advance. Best regards, Gustavo