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