[Openmcl-devel] new 0.14 binaries (finally!)
gb at clozure.com
Tue Jun 24 04:26:29 UTC 2003
There are (finally) new 0.14 binaries in the testing directory:
There's also a source archive in the testing directory. (It contains
CVS metainformation, so hopefully doing "cvs update" - possibly after
a "cvs login" - from the "ccl" directory in that archive will work.)
The HTML documentation is included in the binary archives. The
documentation source (in LyX format) is now in a separate CVS
- 0.14 isn't binary compatible with 0.13; you presumably want to
maintain separate "ccl" hierarchies for 0.14 and earlier versions.
- 0.14 on OSX depends on functionality introduced in 10.2 (Jaguar).
- Building 0.14 from source on OSX requires Jaguar-specific interface
files (look for the most recent "jaguar-interfaces*.tar.gz" archive
in the testing directory.)
OpenMCL 0.14-030623 Release Notes
First of all: I'm sorry that it's been so long (over a
month) between "stable" (i.e., buildable-from-CVS) 0.14
releases. It's not a good thing if I'm the only person
who's able to run a recent version of 0.14 and that's
been the case since mid-May; I quite honestly expected
to reach a relatively stable point a lot sooner than
this. I'm not sure exactly how, but I'll try to keep
things from getting as badly out of synch with the next
set of low-level changes.
FASL files produced by earlier versions of 0.14 won't
load into the current version (and vice versa.)
There is some good new here; perhaps most notably,
OpenMCL 0.14 now (at least nominally) supports a large
subset of the MOP. ("Nominally" in this case means that
the functionality's there and has been exercised to
some degree, and that deviations from what the MOP
document specifies should be considered bugs.) The
parts of the MOP that're currently unsupported
primarily deal with the generic function invocation
protocol (section 5.5.5 in the AMOP book); it seems
wise to think carefully about various tradeoffs before
deciding how to proceed in this direction.
Euphemistally, there are "lots of opportunities for
performance improvements" in the current CLOS/MOP
implementation. Some of those opportunities have
existed for a long time (SLOT-VALUE has never been very
fast in MCL/OpenMCL, and adding a generic function call
to SLOT-VALUE-USING-CLASS didn't speed it up any) and
others are newly introduced (there's more type- and
bounds-checking going on internally; that extra
paranoia isn't necessary in theory but in practice
helped to catch a lot of bugs before they were able to
-really- foul things up.) I'm fairly confident in
saying that things won't get worse performance-wise
than they currently are, and fairly confident in saying
that they'll get better soon.
There's some documentation on the MOP support in the "mop.html"
file (available on the website and in the "ccl;doc;HTML;"
directory in the binary distributions. Aside from a
checklist showing what's implemented and what isn't
(and some other details), there's a paragraph or two on
CLOS/MOP concurrency issues. It made sense when I wrote
it, but it perhaps doesn't say things quite as clearly
as it might. The short version is that weird things can
happen when threads modify CLOS data structures that
other threads are accessing, the implementation doesn't
yet do as much as it could to minimize this wierdness,
and there may be some limits on what the implementation
-can- do to minimize it. I'll try to think about that
harder and clarify what the implementation can do to
ensure some level of consistency (and what issues
applications that redefine CLOS classes and generic
functions at runtime must deal with.)
Some other recent changes include:
* it should now be possible to call lisp code from
(native) threads that weren't created by lisp. On the
first such callback, the foreign thread will be
connected to the lisp runtime system and lisp stacks
and other data structures (including a lisp process
with default attributes) will be associated with the
thread; all of this should be cleaned up
automatically when the native thread exits.
* The ephemeral garbage collector still doesn't work.
The good news is that there's now a plan that should
allow the EGC to work well with native threads and to
reduce some pervasive EGC-related costs. That
cost-reduction has already taken place: the compiler
has a couple of more (previously dedicated) registers
available to it, and the background-noise associated
with maintaining the EGC write-barrier is now gone.
* PROCESS-INTERRUPT requests that occur during
exception handling are now handled when the exception
handler exits (they'd been silently ignored, which
made it hard to interrupt programs that were consing
hysterically or otherwise generating very frequent exceptions.)
* It should now be possible to continue from
UNDEFINED-FUNCTION-CALL errors again.
* MACPTRs now have a couple of extra fields, intended
to make it easier to cache foreign type information.
Hopefully, two extra fields will be enough to enable
us to recognize that the CLASS-OF some MACPTRs might
be something like #<OBJC-CLASS NS-WINDOW>.
* The partial integration of the lisp condition system
and the ObjC exception system that I mentioned on
openmcl-devel several weeks ago is ... still partial.
The good news is that the runtime support that this
depends on is in the current binaries.
* Standard instances and generic-functions each wound
up with an otherwise unused word; in both cases, the
code invoked by ALLOCATE-INSTANCE fills that word
with a more-or-less random fixnum that can be used as
a hash key. (A few months ago, I was delusionally
trying to get rid of all address-based hashing;
having sobered up, it still seems clear that avoiding
address-based hashing when possible is a good thing.)
* several bug fixes, most of them far too gruesome to
discuss in detail ...
Some known bugs/problems
* I think that I'm ready to admit that there has to be
some better solution to the "shared terminal input"
problem than what OpenMCL implements. This becomes
very obvious when something goes wrong when the lisp
is quitting: one sees a message to the effect that
the initial process needs access to terminal input,
but there's no longer a listener to type (:y 0) to ...
* There are undoubtedly still bugs in the thread code
(missing locking, etc.) and there are likely to be
newly-introduced bugs in CLOS and the MOP. Any help
in finding these would be greatly appreciated; any
suggestions for making it easier to test/use 0.14
would also be greatly appreciated.
Openmcl-devel mailing list
Openmcl-devel at clozure.com
More information about the Openmcl-devel