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

Vladimir Kozlov vladimir.kozlov at oracle.com
Thu May 16 15:57:44 PDT 2013


X86_ONLY() is ugly. I would prefer to have something similar to 
VM_Version::has_fast_idiv(): VM_Version::has_clmul(). The drawback is 
you have to define it on all platforms. Which may be not bad if some of 
them have similar feature.

This is an other reason I don't like your approach of using x86 specific 
code in libraries. What if arm64 will have instructions to optimize crc?

Vladimir

On 5/16/13 3:25 PM, David Chase wrote:
>
> On 2013-05-16, at 6:16 PM, John Rose <john.r.rose at oracle.com> wrote:
>
>> On May 16, 2013, at 2:56 PM, Christian Thalinger <christian.thalinger at oracle.com> wrote:
>>
>>> Hmm.  Tao spent a lot of time to move all processor specific flags into the respective globals_<arch>.hpp file.  I don't think we should undo this.
>>
>> I agree.  That opens the question of how to manage the PUTPROP call in shared code (jvm.cpp).
>>
>> David, as a least-bad solution, I suggest protecting the x86-specific names in jvm.cpp with X86_ONLY:
>>
>> +  X86_ONLY(PUTPROP(props, "sun.zip.clmulSupported", UseAVX && UseCLMUL ? "true" : "false"));
>>
>> or:
>>
>> +  PUTPROP(props, "sun.zip.clmulSupported", X86_ONLY(UseAVX && UseCLMUL ||) false ? "true" : "false"));
>>
>> or:
>>
>> +  PUTPROP(props, "sun.zip.clmulSupported", X86_ONLY(UseAVX && UseCLMUL ? "true" :) "false"));
>>
>>>
> That seems entirely reasonable, and allows me to move CLMUL into the x86 file.  I wasn't sure what our attitude was towards #ifdefs in that code.  I'll try to have a new webrev up soon.
>
> David
>


More information about the hotspot-compiler-dev mailing list