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

Christian Thalinger christian.thalinger at oracle.com
Mon May 13 09:17:10 PDT 2013


On May 10, 2013, at 3:01 PM, Aleksey Shipilev <aleksey.shipilev at oracle.com> wrote:

> 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.

That's not true; ask John Rose.  It's an internal API very close to the VM and therefore should be used for things like this.

> 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

Keep in mind that JVM entry points are VM exported symbols; Unsafe methods are not.

-- Chris

> 
> Thanks,
> -Aleksey.



More information about the hotspot-compiler-dev mailing list