RFR (S) : 8014362 : Need to expose some processor features via Unsafe interface
john.r.rose at oracle.com
Mon May 13 10:12:42 PDT 2013
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
>> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the hotspot-compiler-dev