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