Unsafe.{get,put}-X-Unaligned performance

[Paul Sandoz]

Hi Andrew,

On Mar 11, 2015, at 6:27 PM, Andrew Haley <aph at redhat.com> wrote:

> On 03/11/2015 07:10 AM, John Rose wrote:
>>> 
>>> John: I'm waiting for an answer to my question here before I submit
>>> a webrev for approval.
>>> 
>>> http://mail.openjdk.java.net/pipermail/panama-dev/2015-March/000099.html
>> 
>> (Answered.)
> 
> http://cr.openjdk.java.net/~aph/unaligned.jdk.5/
> http://cr.openjdk.java.net/~aph/unaligned.hotspot.5/
> 
> I hope everybody is happy with this, or at least not so unhappy that
> they would want to reject it altogether.
> 

Some minor comment on the JavaDoc. 

I think it more preferable to refer to "underlying platform" or "platform" rather than "machine", at least thats the kind of language i have seen commonly used in other places.

1062      * The write will be atomic with respect to the largest power of
1063      * two that divides the GCD of the offset and the storage size.
1064      * For example, getLongUnaligned will make atomic reads of 2-, 4-,
1065      * or 8-byte storage units if the offset is zero mod 2, 4, or 8,
1066      * respectively.  There are no other guarantees of atomicity.
1067      * <p>
1068      *
1069      * @param o Java heap object in which the value resides, if any, else
1070      *        null
1071      * @param offset The offset in bytes from the start of the object
1072      * @param x the value to store
1073      * @throws RuntimeException No defined exceptions are thrown, not even
1074      *         {@link NullPointerException}
1075      * @since 1.9
1076      */
1077     public final void putLongUnaligned(Object o, long offset, long x) {

s/reads/writes.

In the example it might be worth pointing out that is for 64-bit systems?


> There is no bug ID for this yet.  John, would you like to create a bug
> database entry?  If not, I'll do so.  Then I can go for a RFR, which
> hopefully should be a shoo-in now that we've beaten this thing to
> death.  :-)
> 

We need to include some unit tests before we can push. As i said, if you like i can help you with that and also performing a JPRT run across multiple platforms.

Paul.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20150311/4f22e98c/signature.asc>