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

Aleksey Shipilev 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();

Java_java_util_concurrent_atomic_AtomicLong_VMSupportsCS8(JNIEnv *env,
jclass cls)
    return JVM_SupportsCX8();

   JNIEXPORT jboolean JNICALL JVM_SupportsCX8(void);

   JVM_LEAF(jboolean, JVM_SupportsCX8())
     return VM_Version::supports_cx8();


More information about the hotspot-compiler-dev mailing list