sbcl Log

Commit Date  
[266ccb] (20.5 kB) by David Lichteblau David Lichteblau

Add a safepoint-based mechanism to avoid SIGALRM for the TIMER facility

- Retrofits the signal-free timer thread for Windows (thanks to
Anton Kovalenko) to POSIXy platforms.

- Provide os_* functions in the C runtime which simulate the win32
API for waitable timers.

Currently supported on Linux (timerfd), FreeBSD (kqueue), and SunOS
(completion ports). A tentative (untested) implementation is
provided for Darwin's kqueue.

2012-09-19 15:10:28 View
[ebb604] (20.2 kB) by David Lichteblau David Lichteblau

Add odxprint, a replacement for FSHOW which can be configured at run-time

- A new macro odxprint(flag, "fmt", ...) performs the equivalent of
a printf("fmt", ...), but only if `flag' has been enabled at

- Environment variables can be used to set flags, using either
SBCL_DYNDEBUG="flag1 flag2 flag3" syntax, or
SBCL_DYNDEBUG__FLAG1="nonempty string" syntax.

- Lisp feature SB-QSHOW enables support for odxprint-based FSHOW.
(Users who prefer to edit runtime.h to enable QSHOW can still do
so...) SB-QSHOW is enabled by default on Windows, where the
odxprint mechanism was first used.

- Implement FSHOW, FSHOW_SIGNAL on top of odxprint. Corresponding
flags are called fshow, fshow_signal.

- For gencgc_verbose, support a flag of the same name, since it is
conditional on QSHOW (inspite of not being implemented on top of

- Does not yet support odxprint features specific to Windows debugger
integration; output is currently directed to stderr unconditionally.

This commit backports Anton Kovalenko's Windows-specific odxprint to
POSIX and integrates it with FSHOW.

2012-09-11 10:14:50 View
[8cef5f] (20.0 kB) by David Lichteblau David Lichteblau

Mention sb-safepoint, sb-thruption in base-target-features.lisp-expr

2012-09-10 16:32:02 View
[d6f967] (19.3 kB) by Nikodemus Siivola Nikodemus Siivola

killing lutexes, adding timeouts

* Remove all lutex-specific code from the system.
** Use SB-FUTEX for futex-capable platforms, and plain SB-THREAD
** Make non-futex mutexes unfair spinlocks for now, using WAIT-FOR to
provide timeouts and backoff.
** Build non-futex condition variables on top of a queue and WAIT-FOR.

Performance implications: SB-FUTEX builds should perform pretty much the
same, or improve a bit. Threaded non-futex builds are affected as follows:

1. Threads idling on semaphores or condition variables aren't quite as
cheap. Just how costly depends on the OS. On Darwin 1000 idle threads
can chew up a bit over 50% CPU. I will try to address this later.

2. Contested locking around operations that take considerably longer
than a single timeslice suffers mild degradation.

3. Contested locking around operations that don't take long is an order
of magnitude performant.

4. Highly active semaphores perform much better. (Follows from #3.)

* GRAB-MUTEX gets timeout support on all platforms.

* CONDITION-WAIT gets timeout support.

* Disable a bunch of prone-to-hang thread tests on Darwin. (All of them
were already prone to hang prior to this commit.)

* Enable a bunch tests that now /pass/ on Darwin. \o/ This doesn't mean that
the threaded Darwin is fully expected to pass all tests yet, but let's say
it's more likely to do so.

...but still not robust enough to enable threads on Darwin by default.

* GET-MUTEX/GRAB-MUTEX get refactored into two main parts: %TRY-MUTEX and
%WAIT-ON-MUTEX, which are also used directly from CONDITION-WAIT where

2011-11-09 23:00:48 View
[797692] (19.5 kB) by Paul Khuong Paul Khuong

Optional support for zlib-based in-memory deflate/inflate for core files

* As this is based on zlib, only add the dependency when
:SB-CORE-COMPRESSION is enabled as a build-time feature. On x86-64,
compressed cores take about 1/4 the space, but start up in a few
tenths of a second.

Unlike gzexe'd executables, compressed images work without writing
to /tmp.

If :SB-CORE-COMPRESSION is enabled, trigger compression with the

* Also add a NEWS entry for the literal complex-single-float bugfix

2011-08-28 03:23:03 View
[3254e1] (19.3 kB) by Paul Khuong Paul Khuong


* Does the same thing as only returning the first value of %MULTIPLY,
only better on some platforms.

* Implemented vas VOPs on x86, x86-64 and PPC. The PPC code sequence
is fully untested, and merely looks correct.

* VOPs for fixnum first argument are included, but will only be used
when the result is forcibly marked as fixnum, e.g., with TRULY-THE.
Questionnable, but I'd rather err on the side of straightforwardness
rather than put even more pressure on representation selection.

* Use it in the division-by-multiplication transform for unsigned
TRUNCATE by constant.

2011-08-14 20:49:27 View
[65b5ab] (19.1 kB) by Alastair Bridgewater Alastair Bridgewater

"": threads: Add memory-barrier framework.

* New file, src/code/barrier.lisp, containing the baseline

* Added the barrier functions to the compiler function database.

* Export the interface macro, BARRIER, from SB!THREAD and the
underlying barrier functions from SB!VM.

* Document a new architecture-dependent build-time feature,
MEMORY-BARRIER-VOPS, for controlling the behavior and inlining of
the interpreter stubs for the barrier functions.

2010-08-04 17:58:15 View
[11b5ac] (18.9 kB) by Alastair Bridgewater Alastair Bridgewater UD2-BREAKPOINTS feature for x86oid systems

* Add new feature UD2-BREAKPOINTS, enabled by default only on x86oid
darwin targets.

* Use said feature instead of DARWIN for breakpoint trap selection.

* Make breakpoints work when using UD2-BREAKPOINTS (tested on x86 and
x86-64 linux).

* This patch brought to you by lp#309067, which remains valid for
three reasons: First, the test case is still disabled. Second, this
only fixes for x86oids, not for PPC. And third, I didn't actually test
this on a darwin system.

2010-03-01 13:09:00 View
[1baab0] (18.7 kB) by Nikodemus Siivola Nikodemus Siivola enabled threads by default on x86[-64] Linux

I'll let FreeBSD folks make the judgement if threads should be
default there as well.

Also: update INSTALL documentation regarding *FEATURES* a bit, and
make the documentation clear about availability of threads on
different builds.

2009-12-18 14:26:33 View
[49e840] (18.9 kB) by trittweiler trittweiler Add build flag :sb-xref-for-internals.

Enabling :sb-xref-for-internals in customize-target-features.lisp,
will make Sbcl collect Xref data about itself during the build. This
increases the core size drastically by about 5-6mb, but it's useful
for SBCL developers because they can now use M-? (slime-edit-uses) to
get a list of call/expansion/reference sites for internal stuff.

It may be interesting to Lisp advocacy who can now show off with
finding the use sites of standardized functions like CONS, etc. :-)

Additionally -- regardless of :sb-xref-for-internals --, we now also
collect xref data for keywords because they're "fine" names for
functions and macros, and I know of people who use MACROLET on
keywords for their DSLs.

2009-11-12 15:10:04 View
[2230ea] (18.6 kB) by Paul Khuong Paul Khuong Inline unboxed constants on x86[-64]

* New build-time feature: inline-constants, which specifies that SB!C
and SB!VM implement a protocol described in base-target-features.lisp-expr.
Backends implementing that feature are able to load constants from code
components, in a section that follows the actual executable code.

* Implement the protocol on x86 and x86-64, and use it for float constants,
and, on x86-64 only, mid-sized (> 2^(29-32), but still machine-sized)

* Use the new feature in integer and float arithmetic VOPs.

* Adjust a few test cases to take newly consing situations into account.

* Clean-up:
- New build-time feature: float-eql-vops, which disable rewriting EQL
of single and double floats in terms of foo-float*-bits.
- Fix a typo (unused variable lookup) in TWO-ARG-+/-

2009-06-28 21:37:05 View
[a157ed] (16.9 kB) by Paul Khuong Paul Khuong Complex float improvements

* On all platforms:
- Slightly more stable complex-complex float (double and single)
- New transform for real-complex division;
- complex-real and real-complex float addition and subtraction
behave as though the real was first upgraded to a complex, thus
losing the sign of any imaginary zero.

* On x86-64
- Complexes floats are represented packed in a single SSE register;
- VOPs for all four arithmetic operations, complex-complex, but also
complex-real and real-complex, except for complex-complex and
real-complex division;
- VOPs for =, negate and conjugate of complexes (complex-real and
- VOPs for EQL of floats (real and complexes).
- Full register moves for float values in SSE registers should also
speed scalar operations up.

2009-06-25 15:37:05 View
[dcd860] (16.3 kB) by Nikodemus Siivola Nikodemus Siivola adding and fixing the HPUX/HPPA build target

* Patch by Larry Valkama.

2009-01-03 15:50:46 View
[eb01bd] (16.2 kB) by Nikodemus Siivola Nikodemus Siivola document :CYCLE-COUNTER feature in base-target-features.lisp-expr

* Weaseling out from renaming it to :SB-CYCLE-COUNTER, and deferring that
a bit: seems better to take care of all similar features that are really
just built-time conveniences automatically inferred at the same time.

2008-05-19 13:47:17 View
[f318d0] (15.8 kB) by Juho Snellman Juho Snellman remove locking and gc inhibition from hash-tables, power of 2 sizes

This commit removes a bunch of bottlenecks from the hash-table
implementation. It speeds up GETHASH, (SETF GETHASH) and
REMHASH by a factor of 2-4x (on platforms with a real
WITH-PINNED-OBJECTS) depending on the operation. On the flip
side, no automatic locking is done on tables any more, so
multi-threaded applications must do their own locking. (The
locking done by SBCL was always just an implementation detail,
not a part of the external interface). By popular demand it's
also still safe to have multiple readers on the same table
without locking.

Originally GCs were inhibited during most hash-table
operations for two reasons. To prevent the GC from rehashing a
table while a Lisp-side operation is going on, and to prevent
the GC from moving the key after the hash-value has been

More recently, most hash-tables operations have acquired a
lock on the table in order to prevent two concurrent writers
from corrupting the chains. While it's never been the intent
for the standard data structures to be automatically
thread-safe in SBCL, this locking had to be done since corrupt
tables could lead to infinite GC loops.

Both the locking and the without-gcing are expensive
operations relative to the total cost of a hash-table lookup.
This commit removes both the gc inhibition and the locks.
Additionally we switch to power of two table size, which
allows calculating a cheaper hash -> bucket with cheaper
operations than MOD.

* The GC no longer does the rehashing itself, but just marks
the hash-table as needing a rehash, which will then be done
Lisp-side when the table is next accessed. While it's
possible to find cases where the former behaviour has better
performance, they're very contrived.
* The hash-table operations that work on the chains now check
for loops in the chains, and signal an error if one is found.
* The hash-table operations now pin the key before calculating
the hash value (needed for EQ-based hash functions).
* Add a GC epoch value that GETHASH can use to check whether
a GC happened during the lookup. This is needed since another
thread calling GETHASH on the same table might have caused it
to be rehashed.
* Kill the old MUST-REHASH vector header, and replace it with a
slot in the HASH-TABLE structure. The overloading of the header
caused missed rehashings when both the GC and %%PUTHASH modified
it at the same time.
* Switch to power of two table sizes, with a slightly more complex
hash value -> bucket calculation than just taking the low bits,
which in many cases have a very skewed distribution for the existing
SBCL hash functions. Still a lot faster than using MOD.
* Leave in locking and GC inhibition during rehashing (needed to
allow multiple readers to coexist) and for weak hash-tables
(they need some GC support, and the code is much simpler when
all of the logic is in the GC instead of interleaved in the GC and
Lisp-side). Neither of these cases is performance critical.

2007-09-30 23:18:50 View
[6d3a96] (15.5 kB) by Thiemo Seufer Thiemo Seufer Update comment about little-endian MIPS.

2007-09-02 03:04:32 View
[b822fd] (15.5 kB) by Nikodemus Siivola Nikodemus Siivola remove :UNIX from *FEATURES* on Windows

Thanks to Luis Oliveira.

2007-08-29 14:51:55 View
[bfb19d] (15.7 kB) by Nikodemus Siivola Nikodemus Siivola SB-EXT:COMPARE-AND-SWAP

* New macro SB-EXT:COMPARE-AND-SWAP provides a supported interface to
compare-and-swap functionality.

* New info-type :FUNCTION :STRUCTURE-ACCESSOR allows us to map from
defstruct slot-accessor names to defstruct descriptions.

* Add :CAS-TRANS slot keyword to DEFINE-PRIMITIVE object, and the
compiler machinery needed to support compare and swap on primitive
object slots.



* Use a consistent %COMPARE-AND-SWAP-FOO naming scheme for CAS

* Tests.

Tested on x86/Linux & x86/Darwin, x86-64/Darwi, and PPC/Darwin.

2007-07-15 22:28:12 View
[46e428] (15.6 kB) by Juho Snellman Juho Snellman
Support files >2GB on Linux/x86.

* Compile the runtime (and the C type grovelers) with various flags
to enable a 64-bit off_t.
* Add C-side wrappers for various POSIX functions, so that we can
reliably get the largefile versions of them from Lisp-side.

2006-11-12 23:04:57 View
[970dd2] (15.1 kB) by Juho Snellman Juho Snellman
Add an interpreting EVAL, for cases where the compiler is
unsuitable due to e.g. compilation overhead.

* The old EVAL is still the default. To use the new one,

Making the interpreter the default might be the purer
choice, since there's a standard way of ensuring that code
is compiled, and no standard way of ensuring that it's
not. On the other hand, there are practical reasons for
keeping the compiler as the default. The interpreter is very
slow, doesn't have proper debugger support (either for
backtraces or inspecting frames), and it doesn't have
stepper support.

* The interpreter doesn't treat THE or type declarations for
lexical variables as assertions. The regression tests that
assume otherwise have been disabled when running in
interpreted mode. The intepreter will however type-check the
proclaimed types of specials.

2006-09-13 15:59:31 View
[bcc495] (14.9 kB) by William Harold Newman William Harold Newman
comment tweak inspired by Gisle.Salensminde message to sbcl-help

2006-06-14 19:18:45 View
[a4882e] (14.7 kB) by Nikodemus Siivola Nikodemus Siivola global policy / null-lexenv confusion fix
* Do not store the global policy in null-lexenv, but include
it in subsequent lexenvs. Fixes visibility of global policy
* Also actually enable the SB-LDB in default build instead of
just providing the framework to make this a good idea.
(Accidentally left out from from

2006-06-09 20:59:44 View
[402958] (14.6 kB) by Juho Snellman Juho Snellman
Implement SB-THREAD mutexes and waitqueues using only pthread
functionality on platforms that don't support Linux futexes. New
platforms that can be compiled with SB-THREAD:

* Solaris/x86 (seems to be as stable as SBCL threads on Linux)
* OS X/x86 (some known stability problems, but doesn't fail on the
thread regression tests every time)
* FreeBSD/x86 (reportedly "flat-out broken", tends to cause
kernel panics)

While I (Juho) am doing the final merge from lutex-branch to
HEAD, much of the work was done by Cyrus Harmon, based on an
initial implementation by Nathan Froyd. The Solaris work was
funded by Tellme Networks, Inc.

2006-06-03 20:26:52 View
[93be00] (14.0 kB) by Juho Snellman Juho Snellman
Fix saving a core with callbacks on x86 and x86-64, as
discussed on sbcl-devel "CFFI Callbacks on SBCL" on
2005-12-31. Essentially the problem is that the address of
#'ENTER-ALIEN-CALLBACK is hard-coded into the assembly callback
wrappers, and the address of the function can change when
saving a non-purified core.

* Define a static symbol that contains #'ENTER-ALIEN-CALLBACK
in the value slot.
* Change the x86 / x86-64 wrappers to indirect through the
* Add minimal test case
* Add a :alien-callbacks feature

2006-01-06 01:11:07 View
[31f072] (13.9 kB) by Juho Snellman Juho Snellman
Have you ever tried jumping to the definition of a method combination
with M-. only to be thwarted by Slime/SBCL? Yeah, me neither...

* Record source location information for all definition forms.
(Except when (AND (> SPACE DEBUG) (> SPACE 1))).
* On by default, can be disabled by removing :SB-SOURCE-LOCATIONS
from build-features (if you really want to save that last 60kB
of space...)
* Add structure SB-C:DEFINITION-SOURCE-LOCATION for saving the
source locations
* Annotate all definition form macros with calls to
SB-C:SOURCE-LOCATION, which is compiler-macro-expanded
to a D-S-L instance and saved into an appropriate place.
* For cases where no appropriate place exists, add new
info class :SOURCE-LOCATION.
* Some trickery required to get the source locations recorded
for early definitions.
what definition to search for when given a symbol. (I don't
feel too bad about this, since the interface is explicitly
not supported yet).
Returns a list of locations (to support things like
(F-D-S-B-N 'FOO :METHOD) or (F-D-S-B-N 'foo :VOP)).
* Stalate the fasls.

2005-11-06 08:40:28 View
Older >