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

[Aleksey Shipilev]

On 05/13/2013 08:17 PM, Christian Thalinger wrote:
>> 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.

Which part is not true? I would resist changing Unsafe for a single
one-shot consumer in the standard library. All other methods in Unsafe
are generic, and frequently-used, and performance-sensitive enough to
warrant being the part of Java interface for things, being candidates
for intrinsifying, etc.

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

So? I thought that's virtue of jvm.h, so I can use that symbol in the
native code. jvm.h is not the part of standard interface, as stated in
the comments there. It also states that "this file contains the
VM-related functions needed by native libraries in the standard Java
API." Looks good enough for me.

-Aleksey.