The Bear Arms for Sharing Byte Vectors with 1.7.0

We are pleased to announce the immediate availability of the ABCL
1.7.0 release.

After consuming a steady diet of java.nio.ByteBuffer objects over the
past month, the Bear has managed to incorporate the use of these
abstractions for arrays specialized on the commonly used unsigned-byte
types (or (unsigned-byte 8) (unsigned-byte 16) (unsigned-byte 32)).
This replacement of the use arrays of primitive bytes is denoted by
the presence of the :NIO keyword in CL:*FEATURES*.

With this :NIO overhaul, we have extended our implementation of ANSI
Common Lisp CL:MAKE-ARRAY with two additional keywords,
viz. :NIO-BUFFER and :NIO-DIRECT.

Now, the :NIO-BUFFER keyword argument to CL:MAKE-ARRAY allows one to construct a vector directly utilizing the contents of an already allocated
java.nio.ByteBuffer object.  When combined with the ability of JNA to
allocate memory on the heap via a malloc() system call, we implemented
shareable byte vectors in CFFI-SYS:MAKE-SHAREABLE-BYTE-VECTOR.

    (let* ((length 16)
           (byte-buffer (java:jstatic "allocate"
                                      "java.nio.ByteBuffer" length)))
      (make-array length :element-type ’(unsigned-byte 8) 
                         :nio-buffer byte-buffer))

When the :NIO-DIRECT keyword argument is called with a non-NIL value,
the implementation creates a byte vector with a "directly allocated"
java.nio.ByteBuffer object.  Such direct buffers typically have
somewhat higher allocation and deallocation costs than non-direct
buffers.  The contents of direct buffers may reside outside of the
normal garbage-collected heap, and so their impact upon the memory
footprint of an application might not be obvious. It is therefore
recommended that direct buffers be allocated primarily for large,
long-lived buffers that are subject to the underlying system’s native
I/O operations.  In general it is best to allocate direct buffers only
when they yield a measurable gain in program performance. In the near
future, we intend to explore the performance gains available CL:LOAD
by accessing direct buffers memory mapped to our on-disk fasl
representation.  Our fasls, as zipped archives, currently require a
new seek() from the beginning for each component they
contain.  With a memory mapped direct buffer we should be able to
simply read from the appropriate byte offset for each component.

A complete overview of the accumulated fixes and changes since the
previous release may be viewed in the file describing our CHANGES.