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/6c4b7f3c11b2c8151f4599c9bddf5c0991b...
Congrats!
On Thu, 4 Jun 2020 at 12:28, Mark Evenson evenson@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][].
-- "A screaming comes across the sky. It has happened before but there is nothing to compare to it now."
As released, this will not compile using Java 14.
File: abcl.properties.in, line 13, needs to be changed from
abcl.javac.source=1.6
to
abcl.javac.source=1.8
File src/org/armedbear/lisp/java/swing/REPLConsole.java, line 144, needs to be changed from
yield();
to
Thread.yield();
because the compiler reports that the command "yield" is now a reserved word. Adding the class name makes it clear this is a function reference.
I apologize for not checking these in, but there are other reasons for my not becoming a member of the dev group.
G.A. Baryza
On Thu, Jun 4, 2020 at 6:31 AM Alessio Stalla alessiostalla@gmail.com wrote:
Congrats!
On Thu, 4 Jun 2020 at 12:28, Mark Evenson evenson@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][].
-- "A screaming comes across the sky. It has happened before but there is nothing to compare to it now."
On Jun 4, 2020, at 18:57, Gregory Baryza gabaryza@gmail.com wrote:
As released, this will not compile using Java 14.
File: abcl.properties.in, line 13, needs to be changed from abcl.javac.source=1.6 to abcl.javac.source=1.8
abcl.properties.in is the template for abcl.properties; changing it doesn’t effect the compilation at all.
To compile for openjdk14 one must either edit abcl.properties to the correct properties or use the configuration script as documented in the [README][1].
I will revisit the README to make this situation clearer.
[1]: https://github.com/armedbear/abcl/blob/master/README#L153
File src/org/armedbear/lisp/java/swing/REPLConsole.java, line 144, needs to be changed from yield(); to Thread.yield();
because the compiler reports that the command "yield" is now a reserved word. Adding the class name makes it clear this is a function reference.
The compilation still succeeds: it is merely a warning. I will gladly accept a patch for removing the warning provided the source is still compatible with Java 1.6.
armedbear-devel@common-lisp.net
-
Alessio Stalla -
Gregory Baryza -
Mark Evenson