RFR (S) : 8014362 : Need to expose some processor features via Unsafe interface
david.holmes at oracle.com
Thu May 16 19:11:13 PDT 2013
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
> 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
More information about the hotspot-compiler-dev