RFR (S) : 8014362 : Need to expose some processor features via Unsafe interface

Aleksey Shipilev aleksey.shipilev at oracle.com
Fri May 10 13:44:41 PDT 2013

On 05/11/2013 12:33 AM, David Chase wrote:
> FIX:
> 1) add a bit to cpuFeatureFlags for CLMUL.
> 2) expose the CLMUL bit in StdCpuid1Ecx
> 3) add a flag (in the style of UseAES)
> 4) add an unsafe intrinsic.

5) provide fast-path for C1 in c1_GraphBuilder.cpp
6) provide fast-path for C2 in library_call.cpp

> And connect all those dots.
> The unsafe interface returns UseAVX and UseCLMUL because both are necessary to obtain the 3-operand version of the CLMUL instruction.

I'm not sure Unsafe is a good place to have this: while this is the door
into the VM land, Unsafe itself seems generic enough. I think we might
want to have the sun.misc.CPUFeatures or something like that?

But by far the better option seems to invert control: expose the
PCLMULQDQ-compatible method on Java side, and then intrinsify it in
compiler, like we do with AES. See vmSymbols.hpp and library_call.cpp,
search for "_aescrypt_encryptBlock".


More information about the hotspot-compiler-dev mailing list