ABCL 1.8.0
Under the gathering storms of the Fall 2020, we are pleased to release ABCL 1.8.0 as the Ninth major revision of the implementation.
This Ninth Edition of the implementation now supports building and running on the recently released openjdk15 platform. This release is intended as the last major release to support the openjdk6, openjdk7, and openjdk8 platforms, for with abcl-2.0.0 we intend to move the minimum platform to openjdk11 or better in order to efficiently [implement atomic memory compare and swap operations][github/issues/92].
With this release, the implementation of the EXT:JAR-PATHNAME and EXT:URL-PATHNAME subtypes of cl:PATHNAME has been fixed to the point that arbitrary references to ZIP archives within archives now work for read-only stream operations (CL:PROBE-FILE, CL:TRUENAME, CL:OPEN, CL:LOAD, CL:FILE-WRITE-DATE, CL:DIRECTORY, and CL:MERGE-PATHNAMES). The previous versions of the implementation relied on the ability for java.net.URL to open streams of an archive within an archive, behavior that was silently dropped after Java 5, and consequently hasn't worked on common platforms supported by the Bear in a long time. The overhaul of the implementation restores the feasibility of accessing fasls from within jar files. Interested parties may examine the ASDF-JAR contrib for a recipe for packaging and accessing such artifacts. Please consult the ["Beyond ANSI: Pathnames" Section 4.2 of the User Manual][manual] for further details for how namestrings and components of PATHNAME objects have been revised.
A more comprehensive list of [CHANGES][] is available with the source.
[1.8.0]: https://abcl.org/releases/1.8.0/ [asdf-jar]: https://abcl.org/svn/trunk/abcl/contrib/asdf-jar/README.markdown [github/issues/92]: https://github.com/armedbear/abcl/issues/92 [manual]: https://abcl.org/releases/1.8.0/abcl-1.8.0.pdf [CHANGES]: https://abcl.org/svn/tags/1.8.0/CHANGES
Congrats Mark and other developers for maintaining the Bear alive and kicking!
On Fri, 30 Oct 2020 at 12:34, Mark Evenson evenson@panix.com wrote:
ABCL 1.8.0 Under the gathering storms of the Fall 2020, we are pleased to release ABCL 1.8.0 as the Ninth major revision of the implementation. This Ninth Edition of the implementation now supports building and running on the recently released openjdk15 platform. This release is intended as the last major release to support the openjdk6, openjdk7, and openjdk8 platforms, for with abcl-2.0.0 we intend to move the minimum platform to openjdk11 or better in order to efficiently [implement atomic memory compare and swap operations][github/issues/92]. With this release, the implementation of the EXT:JAR-PATHNAME and EXT:URL-PATHNAME subtypes of cl:PATHNAME has been fixed to the point that arbitrary references to ZIP archives within archives now work for read-only stream operations (CL:PROBE-FILE, CL:TRUENAME, CL:OPEN, CL:LOAD, CL:FILE-WRITE-DATE, CL:DIRECTORY, and CL:MERGE-PATHNAMES). The previous versions of the implementation relied on the ability for java.net.URL to open streams of an archive within an archive, behavior that was silently dropped after Java 5, and consequently hasn't worked on common platforms supported by the Bear in a long time. The overhaul of the implementation restores the feasibility of accessing fasls from within jar files. Interested parties may examine the ASDF-JAR contrib for a recipe for packaging and accessing such artifacts. Please consult the ["Beyond ANSI: Pathnames" Section 4.2 of the User Manual][manual] for further details for how namestrings and components of PATHNAME objects have been revised. A more comprehensive list of [CHANGES][] is available with the source. [1.8.0]: https://abcl.org/releases/1.8.0/ [asdf-jar]:https://abcl.org/svn/trunk/abcl/contrib/asdf-jar/README.markdown [github/issues/92]: https://github.com/armedbear/abcl/issues/92 [manual]: https://abcl.org/releases/1.8.0/abcl-1.8.0.pdf [CHANGES]: https://abcl.org/svn/tags/1.8.0/CHANGES
-- "A screaming comes across the sky. It has happened before but there is nothing to compare to it now."
On Fri, Oct 30, 2020 at 6:35 AM Mark Evenson evenson@panix.com wrote:
ABCL 1.8.0 Under the gathering storms of the Fall 2020, we are pleased to release ABCL 1.8.0 as the Ninth major revision of the implementation. This Ninth Edition of the implementation now supports building and running on the recently released openjdk15 platform. This release is intended as the last major release to support the openjdk6, openjdk7, and openjdk8 platforms, for with abcl-2.0.0 we intend to move the minimum platform to openjdk11 or better in order to efficiently [implement atomic memory compare and swap operations][github/issues/92].
My company uses JDK8 and every company I've consulted with still uses JDK8. I have no plans to switch anytime soon and nor do any of the the companies I've consulted with as far as I know. Rather than forcing me to move from JDK8, your exclusion of JDK8 will simply cause me to stop upgrading ABCL.
According to Wikipedia, Oracle extended support of JDK8 ends in 2030. Support for JDK11 ends in 2026. Other companies like Azul plan to support JDK8 for many years to come.
Is it really critical for you to drop JDK8?
Thanks.
Blake McBride
I'd like to add that I care far, far less about "efficiently [implement atomic memory compare and swap operations" than I do about bug fixes and ANSI CL conformance. And it still seems like a lot of work is remaining in those areas.
Thanks!
Blake
On Fri, Oct 30, 2020 at 9:33 AM Blake McBride blake@mcbride.name wrote:
On Fri, Oct 30, 2020 at 6:35 AM Mark Evenson evenson@panix.com wrote:
ABCL 1.8.0 Under the gathering storms of the Fall 2020, we are pleased to release ABCL 1.8.0 as the Ninth major revision of the implementation. This Ninth Edition of the implementation now supports building and running on the recently released openjdk15 platform. This release is intended as the last major release to support the openjdk6, openjdk7, and openjdk8 platforms, for with abcl-2.0.0 we intend to move the minimum platform to openjdk11 or better in order to efficiently [implement atomic memory compare and swap operations][github/issues/92].My company uses JDK8 and every company I've consulted with still uses JDK8. I have no plans to switch anytime soon and nor do any of the the companies I've consulted with as far as I know. Rather than forcing me to move from JDK8, your exclusion of JDK8 will simply cause me to stop upgrading ABCL.
According to Wikipedia, Oracle extended support of JDK8 ends in 2030. Support for JDK11 ends in 2026. Other companies like Azul plan to support JDK8 for many years to come.
Is it really critical for you to drop JDK8?
Thanks.
Blake McBride
On 30/10/2020 15:40, Blake McBride wrote:
I'd like to add that I care far, far less about "efficiently [implement atomic memory compare and swap operations" than I do about bug fixes and ANSI CL conformance. And it still seems like a lot of work is remaining in those areas.
Thanks!
Blake
How about the following solution? Apologies if it's obviously unworkable.
This is the issue: https://github.com/armedbear/abcl/issues/92 which says it requires CAS on a few ABCL functions (svref etc.).
The valuable feature of CAS is that it doesn't require a context switch, unlike Java's "synchronized". So let's weaken the requirement above (very slightly, if at all) to "anything roughly as lightweight as CAS".
Presumably abcl-2 will use some new JDK11 CAS feature to implement svref etc. But it could use a "fallback-CAS" implementation when it finds itself on an old JRE. Say one built upon this (JDK5 feature) as a primitive: https://docs.oracle.com/javase/1.5.0/docs/api/java/util/concurrent/atomic/At...) As long as fallback-CAS spins and doesn't switch context, it'll meet the weakened requirement above.
No?
Then ABCL-2 will work fast on JDK11 and still almost as fast as that even on older versions of Java.
I should probably read up on what specific JDK11 CAS feature abcl-2 relies upon, that doesn't exist in JDK8. I haven't kept up.
Vibhu
On Oct 30, 2020, at 16:22, Vibhu Mohindra vibhu.mohindra@gmail.com wrote:
On 30/10/2020 15:40, Blake McBride wrote:
I'd like to add that I care far, far less about "efficiently [implement atomic memory compare and swap operations" than I do about bug fixes and ANSI CL conformance. And it still seems like a lot of work is remaining in those areas.
Thanks!
Blake
How about the following solution? Apologies if it's obviously unworkable.
This is the issue: https://github.com/armedbear/abcl/issues/92 which says it requires CAS on a few ABCL functions (svref etc.).
The valuable feature of CAS is that it doesn't require a context switch, unlike Java's "synchronized". So let's weaken the requirement above (very slightly, if at all) to "anything roughly as lightweight as CAS".
Presumably abcl-2 will use some new JDK11 CAS feature to implement svref etc. But it could use a "fallback-CAS" implementation when it finds itself on an old JRE. Say one built upon this (JDK5 feature) as a primitive: https://docs.oracle.com/javase/1.5.0/docs/api/java/util/concurrent/atomic/At...) As long as fallback-CAS spins and doesn't switch context, it'll meet the weakened requirement above.
No?
Then ABCL-2 will work fast on JDK11 and still almost as fast as that even on older versions of Java.
I should probably read up on what specific JDK11 CAS feature abcl-2 relies upon, that doesn't exist in JDK8. I haven't kept up.
Vibhu
I think I can keep all the current source running on ABCL2, moving new functionality to some subclass of CONS that implements the CAS semantics I need in my pursuit of running the [QVM][] on ABCL. Therefore we should be able to fold existing bugs into fixing abcl-1.8.0 while proceeding to develop abcl2. This strategy would be somewhat akin to the current mechanism of building support for Alessio’s ScriptEngine code when the underlying JDK supports it.
None-the-less, it would be advisable for people “stuck” on openjdk8 to start to evaluate what it would take to run on openjdk11.
Hopefully, we can somehow please everyone.
[QVM]: https://github.com/rigetti/qvm
On Oct 30, 2020, at 16:22, Vibhu Mohindra vibhu.mohindra@gmail.com wrote:
[…]
I should probably read up on what specific JDK11 CAS feature abcl-2 relies upon, that doesn't exist in JDK8. I haven't kept up.
Vibhu
As far as I understand things, [varhandle][] is what would most easily support taking an arbitray CONS that has been created by the existing implementation, and “silently” replacing it with something that would be a suitable target for subequent arbitrary atmoic CAS semantics. I have no working code, as this is currently supposition from my analysis phase.
VarHandle was implemented with openjdk9, which the Beat never ran on for the burdensome restrictions on package access that were subsequently relaxed into the current long-term ORCL baseline of openjdk11.
As implementation is the sincerest form of flattery, we will see if this claim stand the test of actually working code.
[varhandl]: https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/lang/invok...
Are these companies willing to sponsor JDK 8 support? If they derive value from ABCL it's only fair.
On Fri, Oct 30, 2020 at 5:34 PM Blake McBride blake@mcbride.name wrote:
On Fri, Oct 30, 2020 at 6:35 AM Mark Evenson evenson@panix.com wrote:
ABCL 1.8.0 Under the gathering storms of the Fall 2020, we are pleased to release ABCL 1.8.0 as the Ninth major revision of the implementation. This Ninth Edition of the implementation now supports building and running on the recently released openjdk15 platform. This release is intended as the last major release to support the openjdk6, openjdk7, and openjdk8 platforms, for with abcl-2.0.0 we intend to move the minimum platform to openjdk11 or better in order to efficiently [implement atomic memory compare and swap operations][github/issues/92].My company uses JDK8 and every company I've consulted with still uses JDK8. I have no plans to switch anytime soon and nor do any of the the companies I've consulted with as far as I know. Rather than forcing me to move from JDK8, your exclusion of JDK8 will simply cause me to stop upgrading ABCL.
According to Wikipedia, Oracle extended support of JDK8 ends in 2030. Support for JDK11 ends in 2026. Other companies like Azul plan to support JDK8 for many years to come.
Is it really critical for you to drop JDK8?
Thanks.
Blake McBride
I have provided support in the past and would do so again if possible.
On Fri, Oct 30, 2020 at 9:44 AM Stas Boukarev stassats@gmail.com wrote:
Are these companies willing to sponsor JDK 8 support? If they derive value from ABCL it's only fair.
On Fri, Oct 30, 2020 at 5:34 PM Blake McBride blake@mcbride.name wrote:
On Fri, Oct 30, 2020 at 6:35 AM Mark Evenson evenson@panix.com wrote:
ABCL 1.8.0 Under the gathering storms of the Fall 2020, we are pleased to release ABCL 1.8.0 as the Ninth major revision of the implementation. This Ninth Edition of the implementation now supports building and running on the recently released openjdk15 platform. This release is intended as the last major release to support the openjdk6, openjdk7, and openjdk8 platforms, for with abcl-2.0.0 we intend to move the minimum platform to openjdk11 or better in order to efficiently [implement atomic memory compare and swap operations][github/issues/92].My company uses JDK8 and every company I've consulted with still uses
JDK8. I have no plans to switch anytime soon and nor do any of the the companies I've consulted with as far as I know. Rather than forcing me to move from JDK8, your exclusion of JDK8 will simply cause me to stop upgrading ABCL.
According to Wikipedia, Oracle extended support of JDK8 ends in 2030.
Support for JDK11 ends in 2026. Other companies like Azul plan to support JDK8 for many years to come.
Is it really critical for you to drop JDK8?
Thanks.
Blake McBride
On Oct 30, 2020, at 16:07, Blake McBride blake@mcbride.name wrote:
I have provided support in the past and would do so again if possible.
The direct current mechanism for materially support of ABCL development is provided by the ongoing [ABCL appreciation][] campaign.
If someone wants a more directly responsible arrangement, I would be more than willing to engage in a more mutually beneficial direct commercial relationship.
There will certainly be an abcl-1.8.1 in the near term, but if there was sufficient commercial interest in supporting openjdk8 as a thing, I would be happy to direct more of my efforts towards longer temporal terms.
In any event, regardless of future possible material donations, I am very happy that you find commercial utility with the current ABCL on openjdk8.
yours, Mark
[ABCL appreciation]: https://payments.common-lisp.net/abcl
armedbear-devel@common-lisp.net
-
Alessio Stalla -
Blake McBride -
Mark Evenson -
Stas Boukarev -
Vibhu Mohindra