gmane.lisp.openmcl.devel

Gary Byers | 8 Sep 07:37

planned trunk instability

[So much better than "unplanned trunk instability".]

I want to try to merge in a bunch of changes from the win64 branch and
make other changes to the trunk over the next few days.  Some of these
changes may introduce bugs/bootstrapping problems/other instabilities,
and it may take a few days (for some value of "a few") for the dust to
settle.

I'll try to remember to send an "all clear" message at that point.
Until that happens, it's probably wise to avoid updating from the
svn trunk.

headers

Gary Byers | 23 Sep 03:08

Re: planned trunk instability

I think that 15 days counts as "a few", doesn't it ?

As far as I know, we're through making changes to the trunk that
require extensive bootstrapping, at least for a while.  Changes
that have occurred recently include:

- "nearly lock free" hash tables (whose implementation is described at

    <http://trac.clozure.com/openmcl/wiki/Internals/LockFreeHashTables>

    ).  These are not yet enabled by default; a hash table created
    via (make-hash-table ... :LOCK-FREE T) allows concurrent read-write
    access to the resulting hash-table from multiple threads without
    locking overhead for most operations.  (If I understand correctly,
    locking does come into play when the hash table needs to be
    rehashed due to growth or address-based key movement.)  So far,
    the performance results seem to be encouraging, and I think that
    the plan is to make :LOCK-FREE T the default for shared hash-tables
    (and to try to descibe any usage patterns where it wouldn't be
    an appropriate default better than I'm doing here.)  (Thread-private
    hash-tables - created with :SHARED NIL - are likely to still be
    faster when they're appropriate; they already avoid locking
    overhead and don't need to do the memory-synchronization stuff
    that shared lock-free tables need to do on writes.)

-  the win64 port (which had been on its own branch and was badly
    out of synch with the trunk) is now in the trunk and starting
    to approach usability.

-  a 32-bit x86 Linux port has been added; it and the 64-bit x86

(Continue reading)