ABCL-1.7.0 released

[Alessio Stalla]

Congrats!

On Thu, 4 Jun 2020 at 12:28, Mark Evenson <evenson at panix.com> wrote:

> We are pleased to announce the immediate availablity 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.
>
> The :NIO-BUFFER keyword argument 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 measureable gain in program performance. In the near
> future, we intend to exploring 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 of the fasl for each component they
> contain.  With a memory mapped direct buffer we should be able to
> simply read from the appropiate byte offset for each component.
>
> A complete overview of the accumulated fixes and changes since the
> previous release may be viewed in [CHANGES][].
>
> [ABCL 1.7.0 release]: https://abcl.org/releases/1.7.0/
> [java.nio.ByteBuffer]:
> https://www.doc.ic.ac.uk/csg-old/java/jdk6docs/api/java/nio/ByteBuffer.html
> [CFFI-SYS:MAKE-SHAREABLE-BYTE-VECTOR]:
> https://github.com/cffi/cffi/commit/47136ad9a97c2df98dbcd13a068e14489ced5b03
> [CHANGES]: https://abcl.org/svn/tags/1.7.0/CHANGES
> [CL:MAKE-ARRAY]:
> https://github.com/armedbear/abcl/commit/6c4b7f3c11b2c8151f4599c9bddf5c0991bc6154
>
> --
> "A screaming comes across the sky.  It has happened before but there is
> nothing
> to compare to it now."
>
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/armedbear-devel/attachments/20200604/08ed35a6/attachment.htm>