RFR (S) : 8014362 : Need to expose some processor features via Unsafe interface
aleksey.shipilev at oracle.com
Fri May 10 15:01:28 PDT 2013
On 05/11/2013 01:52 AM, David Chase wrote:
> On 2013-05-10, at 5:36 PM, Aleksey Shipilev
> <aleksey.shipilev at oracle.com> wrote:
>> Aha. Ok, so the flag then. I would say go through the JNI like
>> AtomicLong does to catch that flag without contaminating the
>> Unsafe without a good reason.
> I don't understand. Merely going through JNI is not enough -- the
> implementation has to be within hotspot, because that's where the
> flag is. java.util.zip.CRC32 already goes through JNI, but it is
> does not see hotspot symbols (I know, because I tried that first).
> And what should I be contaminating, if not Unsafe?
Native code. Unsafe is very overloaded, and it seems to be the consensus
that we do not change Unsafe without a good reason to do so. I'm not a
maintaner though, and your code might be *the* answer.
But see how AtomicLong handles the same thing:
static final boolean VM_SUPPORTS_LONG_CAS = VMSupportsCS8();
private static native boolean VMSupportsCS8();
JNIEXPORT jboolean JNICALL
JNIEXPORT jboolean JNICALL JVM_SupportsCX8(void);
More information about the hotspot-compiler-dev