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

[Paul Sandoz]

On Feb 25, 2015, at 11:03 AM, Peter Levart <peter.levart at gmail.com> wrote:

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

I think it simpler just to have one method with a boolean parameter whose default false value means native and true means BigEndian. Otherwise, even simpler, just support native only (like the existing access impls) and let the caller reverse as/when required.


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

To your point with the current unsigned byte Lexicographic comparator prototype if i were to modify to use the unaligned access methods i would want native order and only take the hit of reversing, if required, if two elements are not equal. Note that code will anyway be modified to use a more general array mismatch method leveraging the unaligned access methods using native order (i cannot think of a reason why it not do otherwise).


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

The non-accessibility will, by default, be more strongly enforced by the VM.


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

I do not know.

Paul.

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