On 03/03/15 20:48, John Rose wrote: > On Mar 2, 2015, at 11:30 AM, Andrew Haley <a...@redhat.com> wrote: >> >> On 02/25/2015 04:43 PM, Andrew Haley wrote: >> I have done this as much as is possible, but methods which assemble >> and split sub-words are necessarily endian-dependent. I have >> separated the native big- and little-endian code into two classes, >> only one of which will ever be loaded into a system. > > Here is a way to merge the twin classes, using gated "pick" operators: > http://cr.openjdk.java.net/~jrose/draft/Unsafe.NativeEitherEndian.java > > If merging them actually works, then the merged result should be > folded back into Unsafe, and static variables used everywhere. > I think this is better than quasi-duplicate code, if it optimizes right.
That looks very nice. I'll see if it optimizes well. >>>> Suggestion: Have getIntUnaligned take an optional boolean >>>> parameter, which is "bigEndian" (since that's relatively exceptional). >>>> An extra line of code can conditionally swap the bytes, taking >>>> both the flag and the platform into account. Default value of the >>>> boolean is whatever is natural to the platform. If you specifically >>>> want Java's big-endian order, you specify true, etc. >> >> I've done this in Java. I tried some HotSpot intrinsic code to handle >> the "bigEndian" parameter but foundered when I noticed that >> Op_ReverseBytesXX nodes are optional, so an intrinsic might either be >> emitted as an instruction or a call to a native method. This was all >> too messy so I reverted to doing it in Java; the code quality does not >> seem to suffer as a result of this. (Another possibility is to define >> intrinsics which would only be used if Op_ReverseBytesXX nodes were >> supported, but I don't know that such an intrinsic would buy us >> anything.) > > I'm surprised it backed off to a native method. It should have backed > off to bytecode equivalent to what you wrote (see Integer.java for the code). I'm sorry, I misspoke. I mean that reverse may be emitted as a call to a method if the C2 node isn't supported. >> There are several places in the JDK where we have special cases for >> alignment, endianness, and arrays and some could benefit from use of >> these new methods, but except for HeapByteBuffers I haven't changed >> anything. > > It would be good to call them out; we can file followup bugs. Okay. >> I am aware that the code is uncommented. I will fix that once we >> agree about what to do next. >> >> http://cr.openjdk.java.net/~aph/unaligned.hotspot.1/ >> http://cr.openjdk.java.net/~aph/unaligned.jdk.2/ > > I like it! > > I'm a little puzzled by the meaning of UseUnalignedAccesses. > From a portable point of view, it sounds like the JVM will be using special > access operators. > But in fact, it is using the normal aligned memory access operators for > unaligned accesses also. > (Remember, from a portability point of view the normal memory access > operators work only on aligned addresses.) > I don't have a nice replacement name thought. Sure. It's a developer-only flag, and we have something of a tradition of obscurely-named developer flags. But I might be able to think of a better name. Andrew.