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

[David Holmes]

David,

I don't quite understand the handling of UseCLMUL. Why do you set it to 
false initially:

   99   product(bool, UseCLMUL, false, 
           \
  100           "Control whether CLMUL instructions can be used on 
x86/x64")      \

  then force it to true if supported:

  493   // Use CLMUL instructions if available.
  494   if (supports_clmul()) {
  495     if (FLAG_IS_DEFAULT(UseCLMUL)) {
  496       UseCLMUL = true;
  497     }
  498   } else if (UseCLMUL) {

I would expect it to be true by default and set to false if not 
supported. That way the value in globals_x86.hpp really is the default 
value.

That said we seem to handle a number of these flags in what I would 
consider an odd way.

David
-----



On 18/05/2013 7:28 AM, David Chase wrote:
> There was a spacing change that did not get reverted.
> This time, for sure.
> Note that this sets a property that won't get reset without a companion change in the JDK.
> (And the companion change is getting a bit of a pushback, though I hope to find, once I digest
> all the benchmarks I ran this afternoon, that it's not as scary as feared.)
>
> http://cr.openjdk.java.net/~drchase/8014362/webrev.04
>
> On 2013-05-17, at 4:30 PM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
>
>> Somehow globals.hpp showed up in the webrev. Otherwise changes are good.
>>
>> Vladimir
>>
>> On 5/17/13 1:28 PM, David Chase wrote:
>>> New webrev:
>>>
>>> http://cr.openjdk.java.net/~drchase/8014362/webrev.03/
>>>
>>> It compiles (and runs) on both x86 and Sparc.
>>>
>>> David
>>>
>>> On 2013-05-16, at 11:32 PM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
>>>
>>>> Okay, I agree with X86_ONLY().
>>>>
>>>> Vladimir
>>>
>