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

[Aleksey Shipilev]

On 05/11/2013 01:21 AM, David Chase wrote:
>> 5) provide fast-path for C1 in c1_GraphBuilder.cpp 6) provide
>> fast-path for C2 in library_call.cpp
> 
> I'm not sure I understand these two; isn't there just one place that
> the unsafe methods go? Perhaps "intrinsic" is the wrong word -- there
> is no inline substitution, just a call to a C method that accesses
> the flags and returns them.

There is one single place where the minimal Unsafe code should go, and
you covered. I just assumed you want to churn some of the overhead by
inlining that accessor to bypass additional native call. Although if you
are about to cache that on Java side, it does not really matter.

>> 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".
> 
> It's not useful to intrinsify a single instruction without a 128-bit
> datatype mapped to xmm registers exposed in the JVM; otherwise it is
> too slow, which defeats the purpose of doing this.

Aha. Ok, so the flag then. I would say go through the JNI like
AtomicLong does to catch that flag without contaminating the Unsafe
without a good reason.

-Aleksey.