Re: ABCL 1.8.0
Mark Evenson <[email protected]> Fri, 30 Oct 2020 22:14:06 +0100
| Newsgroups | gmane.editors.j.devel |
|---|---|
| Message-ID | <[email protected]> |
> On Oct 30, 2020, at 16:22, Vibhu Mohindra <[email protected]> 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/AtomicBoolean.html#compareAndSet(boolean,%20boolean) > 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 -- "A screaming comes across the sky. It has happened before but there is nothing to compare to it now."