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

[David Holmes]

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
>