Unsafe.{get,put}-X-Unaligned; Efficient array comparison intrinsics

[Peter Levart]

On 02/25/2015 09:27 AM, Paul Sandoz wrote:
> On Feb 25, 2015, at 12:20 AM, John Rose <john.r.rose at oracle.com> wrote:
>
>> On Feb 24, 2015, at 7:49 AM, Andrew Haley <aph at redhat.com> wrote:
>>>> There will be only one runtime Unsafe sub-type ever observed in a
>>>> particular VM.
>>> Oh, that's very nice.
>> That doesn't help with B accesses on L platforms and vice versa.
>> Having an optional boolean parameter (gating reverseBytes) will help.
>>

Or having another set of methods (with B/L suffix). I think the desired 
modes are:
-  native order (platform dependent but always fastest)
- BigEndian (platform independent, fast if equal to native order)
- LittleEndian (platform independent, fast if equal to native order)

Having an order that is the opposite of native order is rarely needed, I 
think, since it is platform dependent and slower at the same time.

> Yes, that's a good point.
>
>
>> Also, it makes Unsafe non-final, which frankly gives me the willies.
>> (Technical term, used by folks that have been through too many security escalations.)
>> Let's not create any new ways for industrious hackers to attack Unsafe.
>>
> I was getting nervous about this too :-)

I also felt uncomfortable, but for other reasons (like if intrinsics 
still behave the same in abstract class too). At least in JDK9, Unsafe 
should be hidden from any attackers, right?

Is making class final any safer than making constructor private? Are 
there any known attacks on extending non-final classes with private 
constructors?

Since these methods are unsafe, they naturally belong to Unsafe, but an 
alternative would be an all-Java implementation in a parallel class 
(Unsafe2). It wouldn't be any safer though. I just have a feeling that 
if implementation is in Java, it would be best if methods were as short 
as possible (for inlineability) and with as little conditional branches 
that only depend on platform setup and can't be optimized away in all 
modes of execution (interpreter, C1, C2).

Regards, Peter

> Paul.