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

[David Holmes]

On 22/05/2013 12:46 AM, Vladimir Kozlov wrote:
> On 5/21/13 4:08 AM, David Chase wrote:
>> I believe I was doing monkey-see-monkey-do.
>> Other not-always-present machine features options seemed to be coded
>> that way, so I copied it.
>> Till we know it's a modern processor, it's not safe (I can verify that
>> it does indeed crash if you try new instructions on an old chip).
>
> David C. is correct. We set flags for new instructions to false by
> default because it is most common case (old cpus). Also it allows us to
> track incorrect settings on command line when an instruction is not
> available.

Neither of those statements require that the default value of the flag 
be false. You can have it be true and then verify it is supported - and 
clear it if not; that all happens before anything would issue the new 
instructions. If it is not supported and was asked for on the 
command-line you can detect that too.

I just find it an odd convention because you can't look at globals.hpp 
and the command-line and know the value of the flag. But maybe that 
isn't as common as I think (I tend to mostly look at runtime flags)

Anyway, moving on ...

David

> Vladimir
>
>>
>> David
>>
>> On 2013-05-21, at 12:49 AM, David Holmes <david.holmes at oracle.com> wrote:
>>
>>> 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
>>>>>>
>>>>
>>