RFR (S) : 8014362 : Need to expose some processor features via Unsafe interface
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:
> static final boolean VM_SUPPORTS_LONG_CAS = VMSupportsCS8();
> private static native boolean VMSupportsCS8();
> JNIEXPORT jboolean JNICALL
> 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();
Keep in mind that JVM entry points are VM exported symbols; Unsafe methods are not.
More information about the hotspot-compiler-dev