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