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

[David Chase]

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.

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