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

[John Rose]

On May 13, 2013, at 9:59 AM, Aleksey Shipilev <aleksey.shipilev at oracle.com> wrote:

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

Aleksey, that part about consensus was not quite true.

When binding Java code closely to hardware, via a private JDK/JVM interface, we sometimes resort to Unsafe to create an intrinsic.  We will create more in the future, too.  It is a compiler-team tactic.

> I would resist changing Unsafe for a single
> one-shot consumer in the standard library.

Well, you should have said that in the first place.  You would not recommend changing Unsafe in ways that seem "one-shot".  I agree.  We try to do these things tastefully.

As the original author of Unsafe, and the relevant architect, I intend to continue guiding the evolution of Unsafe in ways that keep it a useful part of our stack.

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

Pretty much.

— John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20130513/147f9e48/attachment.html