RFR 8149469: ByteBuffer API and implementation enhancements for VarHandles

[Paul Sandoz]

> On 18 Feb 2016, at 12:08, Chris Hegarty <chris.hegarty at oracle.com> wrote:
> 
> On 9 Feb 2016, at 15:05, Paul Sandoz <paul.sandoz at oracle.com> wrote:
> 
>> Hi,
>> 
>> This patch contains API and internal enhancements to ByteBuffer:
>> 
>> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8149469-byte-buffer-align-and-unifying-enhancements/webrev/index.html
> 
> This is certainly for advanced/power users feature. I expect it may not be
> used all that widely, but I do see your requirement with VarHandles.
> 

Right.

Note that it is also useful in general if one wants certain guarantees on atomic accesses (if supported by the impl). For example, now that the wider get/put accessors use Unsafe.get/put*Unaligned it’s possible to align things to the most efficient form of plain *and* atomic access on systems that do not support misaligned accesses (or performance-wise even for systems that do since there might be an additional cost). It may be possible to carefully spruce up the spec in that respect in terms of atomicity guarantees with these new methods in place.


> A few specific comments:
> 
> - I find the comment in Buffer.java a little confusing. Specifically where is
>   says that byte[] allocations might no align to a word boundary on 32-bit
>   systems. I think you mean that the alignment will not be 8-byte aligned.
>   I get that slices can be arbitrary.
> 

Yes.


> - The changes to set isReadOnly do not seem related, but you explained
>   off-list that these are in preparation for VarHandlers. They seem benign.
> 

I included all relevant changes required for VHs rather than try and spread ‘em out. There is a lot more we could do to clean things up but i resisted the temptation. And Brian et. al. might be interested in taking on such work… hint hint :-)


> - The computation in misalignment is based on assumptions about layout,
>   that may, or may not, be valid ( but it is had to see otherwise ). You had
>   suggested that UOE could be thrown here?
> 

Yes, an omission on my part, thanks for spotting the discrepancy. We discussed such aspects on valhalla-dev:

  http://mail.openjdk.java.net/pipermail/valhalla-dev/2016-January/001731.html


> - Minor spec issue in alignedSlice: "If rounding results in out-of-bound values
>   then this buffers capacity and limit will be zero.”. You mean "the new byte
>   buffer", right?
> 

Yes, thanks!

See diffs below. Webrev updated.

I still need to think a little more about the upper bound of unitSize, i put a limit of 64 (cache line size) to stop silly values:

- implementation-wise, for non-direct buffers any value above 8 should throw a USO.

- for direct buffers is 64 too small? what about for page size alignment?

Paul.

diff -r 39af902887a4 src/java.base/share/classes/java/nio/Buffer.java
--- a/src/java.base/share/classes/java/nio/Buffer.java	Thu Feb 11 11:59:05 2016 +0100
+++ b/src/java.base/share/classes/java/nio/Buffer.java	Thu Feb 18 16:38:46 2016 +0100
@@ -192,8 +192,8 @@
     // Used by heap byte buffers or direct buffers with Unsafe access
     // For heap byte buffers this field will be the address relative to the
     // array base address and offset into that array. The address might
-    // not align on a word boundary for slices, nor for byte[] allocations
-    // on 32-bit systems.
+    // not align on a word boundary for slices, nor align at a long word
+    // (8 byte) boundary for byte[] allocations on 32-bit systems.
     // For direct buffers it is the start address of the memory region. The
     // address might not align on a word boundary for slices, nor when created
     // using JNI, see NewDirectByteBuffer(void*, long).
diff -r 39af902887a4 src/java.base/share/classes/java/nio/X-Buffer.java.template
--- a/src/java.base/share/classes/java/nio/X-Buffer.java.template	Thu Feb 11 11:59:05 2016 +0100
+++ b/src/java.base/share/classes/java/nio/X-Buffer.java.template	Thu Feb 18 16:38:46 2016 +0100
@@ -1643,6 +1643,15 @@
      *         If the index is negative or the unit size is not a positive
      *         power of 2, or is greater than 64
      *
+     * @throws UnsupportedOperationException
+     *         If the native platform does not guarantee stable misalignment
+     *         values for the given unit size when managing the memory regions
+     *         of buffers of the same kind as this buffer (direct or
+     *         non-direct).  For example, if garbage collection would result
+     *         in the moving of a memory region covered by a non-direct buffer
+     *         from one location to another and both locations have different
+     *         misalignment characteristics.
+     *
      * @see #alignedSlice(int)
      * @since 9
      */
@@ -1665,8 +1674,8 @@
      * position rounded up to the index of the nearest aligned byte for the
      * given unit size, and end at this buffer's limit rounded down to the index
      * of the nearest aligned byte for the given unit size.
-     * If rounding results in out-of-bound values then this buffers capacity and
-     * limit will be zero.  If rounding is within bounds the following
+     * If rounding results in out-of-bound values then the new buffer's capacity
+     * and limit will be zero.  If rounding is within bounds the following
      * expressions will be true for a new buffer {@code nb} and unit size
      * {@code unitSize}:
      * <pre>{@code
@@ -1700,6 +1709,15 @@
      * @throws IllegalArgumentException
      *         If the unit size not a positive power of 2, or is greater than 64
      *
+     * @throws UnsupportedOperationException
+     *         If the native platform does not guarantee stable aligned slices
+     *         for the given unit size when managing the memory regions
+     *         of buffers of the same kind as this buffer (direct or
+     *         non-direct).  For example, if garbage collection would result
+     *         in the moving of a memory region covered by a non-direct buffer
+     *         from one location to another and both locations have different
+     *         alignment characteristics.
+     *
      * @see #misalignment(int, int)
      * @see #slice()
      * @since 9


-------------- 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/nio-dev/attachments/20160218/8158788d/signature.asc>