On Feb 25, 2015, at 11:03 AM, Peter Levart <peter.lev...@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.r...@oracle.com> >> wrote: >> >> >>> On Feb 24, 2015, at 7:49 AM, Andrew Haley <a...@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. >> >
