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

[Vladimir Kozlov]

Okay, I agree with X86_ONLY().

Vladimir

On 5/16/13 7:11 PM, David Holmes wrote:
> On 17/05/2013 11:55 AM, David Chase wrote:
>> Do we have a consensus here?  Vladimir's concerns are exactly mine, but it seems to me that we are faced with
>> conservation of ugliness, unless we do something more involved (a processor-dependent callback to arrange this data,
>> and is a properties string really the right way?)
>>
>> So I can leave it in its slightly disarranged state, or I can do X86_ONLY.  A minor advantage of leaving it as a
>> global flag is that if I set it on the wrong architecture, it just says "no, feature not available", which is in fact
>> true.
>
> I vote with John on this. I much prefer a use of X86_ONLY in shared code than pretending these x86 cpu capabilities
> exists on all supported architectures.
>
> David
> -----
>
>> David
>>
>> On 2013-05-16, at 7:05 PM, John Rose <john.r.rose at oracle.com> wrote:
>>
>>> On May 16, 2013, at 3:57 PM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
>>>
>>>> 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.
>>>
>>> It is probably the least-bad ugly for this use case.  We are not likely to support this clmul-based algorithm other
>>> than on this one point-case.
>>>
>>>> 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?
>>>
>>> By then we will have figured out a better way to manage these processor-sensitive algorithms.  If that better way is
>>> not VM_Version::has_clmul, then that would be wasted generalization.  More likely, I think, we will have a
>>> sun.misc.Processor API and a way to manage specialized code generation from JDK code.
>>>
>>> Worst case is we add ARM64_ONLY(PUTPROP(...)), plus a bunch of ugly ARM assembly code, etc.  The PUTPROP is the least
>>> of our problems!
>>>
>>> — John
>>