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:

 AtomicLong.java:
    static final boolean VM_SUPPORTS_LONG_CAS = VMSupportsCS8();
    private static native boolean VMSupportsCS8();

 AtomicLong.c:
   JNIEXPORT jboolean JNICALL
Java_java_util_concurrent_atomic_AtomicLong_VMSupportsCS8(JNIEnv *env,
jclass cls)
{
    return JVM_SupportsCX8();
}

 jvm.h:
   JNIEXPORT jboolean JNICALL JVM_SupportsCX8(void);

 jvm.c:
   JVM_LEAF(jboolean, JVM_SupportsCX8())
     JVMWrapper("JVM_SupportsCX8");
     return VM_Version::supports_cx8();
   JVM_END

Thanks,
-Aleksey.


More information about the hotspot-compiler-dev mailing list