[11] RFR : java.nio.Buffer attachments

[David Lloyd]

I was just wondering if anyone has had a chance to give this a look
and a think.  Thanks!

On Fri, Mar 2, 2018 at 9:58 AM, David Lloyd <david.lloyd at redhat.com> wrote:
> One of the major classic difficulties with NIO programming (and
> therefore, usage of NIO-based frameworks) is the management of
> buffers. This commonly applies specifically to (but is definitely not
> limited to) handling of direct ByteBuffers.  One of the primary
> difficulties relates to the topic of buffer allocation, pooling, and
> reuse.
>
> I contend that a well-behaved buffer pool necessarily has the
> following characteristics:
>
> • An explicit `free` operation (i.e. not normally relying on GC to come around)
> • Some mechanism to help prevent double-free
> • Some mechanism to help prevent other pollution of the pool (i.e.
> pooling buffers that do not belong to the pool)
> • Graceful handling of duplicates, slices, and other types of views
>
> In addition, the following characteristics also may be desirable:
>
> • Allocation of fewer, larger buffer regions backing the pooled
> buffers which may be slices of these regions, maybe even to multiple
> hierarchical levels
> • Some mechanism to signify that the status of a given pooled buffer
> can no longer be determined (i.e. fall back to using a GC-based
> mechanism to release the buffer)
> • Employment of some reasonable amount of fail-safe against usage of
> buffers which have been freed, within practical limits
>
> Existing buffer pools may rely on wrapper objects, which tend to be
> difficult to use with scatter/gather and add a level of indirection to
> common I/O code paths, or (to avoid wrapper objects) they may rely on
> heuristic information acquired from the Buffer API (such as capacity,
> isDirect, isReadOnly, etc.) to make a guess as to whether the buffer
> belongs to the pool, which also comes with several critical
> disadvantages.  A Buffer attachment API would solve these problems far
> more gracefully.
>
> The Buffer attachment API would have to meet the following requirements:
>
> • The attachment must be acquirable for usage by pools and other buffer managers
> • Attachments should be protected from interference by buffer users
> and other attachment implementations
> • No performance degradation to standard I/O and manipulation operations
> • Minimal memory overhead in the existing case where no attachment is present
>
> I've attached a patch which adds a buffer API that meets these
> requirements.  The following implementation points are notable:
>
> • One extra final field is added to java.nio.Buffer to hold the
> optional attachment
> • The BufferAttachment API is "locked down" allowing only the
> implementation of the attachment to create buffers with that
> attachment, preventing attachments from being copied to other buffers
> by misbehaving code
> • While anyone can acquire the BufferAttachment object for a given
> Buffer, all of the members of that class are protected, preventing
> interference
> • Attachments have an opportunity to handle duplicate/slice and view
> creation by returning null, returning a copy of the attachment, or
> returning the same attachment instance, depending on the desired
> behavior
> • Only creating ByteBuffers (direct and heap) and wrapping byte arrays
> are presently supported; other buffer types can be created as views of
> the ByteBuffer, or support can be added (now or at a later time) for
> creating them directly
> • In particular, the patch does not implement a way to add an
> attachment to buffers created via FileChannel mapping or via JNI, or
> other such "back-channel" approaches; these features may potentially
> be added at a later time
>
> Using this attachment API, it is possible to create buffer pool
> implementations with a variety of different behaviors, many of which
> meet the above requirements without the drawbacks of wrapper objects.
> It may also open the door for JDK-managed smart buffer pools in the
> future.
>
> Please review and give feedback at your convenience.  Thanks!
> --
> - DML



-- 
- DML