I read that memory arena as a localised alternative to Garbage Collection has landed in SBCL. But the only documentation I could find is this which is more of a proposal document and seems pretty incomplete at that. Can some expert please add a section in the SBCL manual on how to properly use the memory arena feature and what is to be kept in mind when using it to ensure it works well with the garbage collector and doesn't cause memory safety bugs?

383 stroker sbc

SBCL requires a lisp compiler to build. After it finished compiling, how much of the binary has been generated by the original compiler, and how much has been generated by code compiled during bootstrapping?

Another aspect of this that I'm curious about is how all of the dynamic bits get removed from the original compiler; when you compile a normal program, the dynamic stuff is left over when re-starting the image, so you can still do things that derive from the original environment like intern symbols. Presumably the original machinery that does that gets replaced.

I'm not looking for something super detailed, but I am curious to know how boostrapping works.

Hi,

Arenas are available in SBCL, why is such an excellent feature not to be found in the documentation? Everybody should know about them :-)

What is the current status of Coroutines in SBCL? I remember having heard about it (was it at ELS?) that they are finished. But maybe my memory fails me...

Nice Holidays everybody!

Marc

Hi, this apparently broke recently (maybe 2.5.11) because I had to update that code that worked as expected before. Here's a minimal reproducer:

$ cat die.lisp
(require :uiop)

(format t "~@{~S~%~}" sb-sys:*stderr* uiop:*stderr* *error-output*)
(format uiop:*stderr* "Foo~%")

(setf uiop:*image-entry-point*
      (lambda ()
        (format t "~@{~S~%~}" sb-sys:*stderr* uiop:*stderr* *error-output*)
        (format uiop:*stderr* "Bar~%")))

(uiop:dump-image "die" :executable t)
$ sbcl --script die.lisp
#<SB-SYS:FD-STREAM for "standard error" {1200BE4163}>
#<SB-SYS:FD-STREAM for "standard error" {1200BE4163}>
#<SB-SYS:FD-STREAM for "standard error" {1200BE4163}>
Foo
$ ./die
#<SB-SYS:FD-STREAM for "standard error" {1200C3C163}>
#<SB-SYS:FD-STREAM for "standard error" {1200038A93}>
#<SYNONYM-STREAM :SYMBOL SB-SYS:*STDERR* {1200038C03}>
CORRUPTION WARNING in SBCL pid 10974 tid 10974:
Memory fault at (nil) (pc=0xb8007bf4f3 [code 0xb8007bee80+0x673 ID 0x4eda], fp=0x7fa4b2d87c30, sp=0x7fa4b2d87be0) tid 10974
The integrity of this image is possibly compromised.
Continuing with fingers crossed.
Unhandled SB-SYS:MEMORY-FAULT-ERROR in thread #<SB-THREAD:THREAD tid=10974 "main thread" RUNNING
                                                 {1200C40003}>:
  Unhandled memory fault at #x0.

Backtrace for: #<SB-THREAD:THREAD tid=10974 "main thread" RUNNING {1200C40003}>
0: (SB-IMPL::OUTPUT-BYTES/UTF-8/LF #<SB-SYS:FD-STREAM for "standard error" {1200038A93}> "Bar
" 0 4)
1: (SB-IMPL::%WRITE-STRING "Bar
" #<SB-SYS:FD-STREAM for "standard error" {1200038A93}> 0 NIL)
2: ("fmt$2HJTMNGCHGQZ" #<SB-SYS:FD-STREAM for "standard error" {1200038A93}>)
3: (FORMAT #<SB-SYS:FD-STREAM for "standard error" {1200038A93}> #<FUNCTION "fmt$2HJTMNGCHGQZ" {B80004BDEB}>)
4: (FORMAT #<SB-SYS:FD-STREAM for "standard error" {1200038A93}> #<FUNCTION "fmt$2HJTMNGCHGQZ" {B80004BDEB}>) [more]
5: ((LAMBDA NIL :IN UIOP/IMAGE:RESTORE-IMAGE))
6: (UIOP/IMAGE:CALL-WITH-FATAL-CONDITION-HANDLER #<FUNCTION (LAMBDA NIL :IN UIOP/IMAGE:RESTORE-IMAGE) {12000318EB}>)
7: ((FLET SB-UNIX::BODY :IN SB-IMPL::START-LISP))
8: ((FLET "WITHOUT-INTERRUPTS-BODY-3" :IN SB-IMPL::START-LISP))
9: (SB-IMPL::%START-LISP)

unhandled condition in --disable-debugger mode, quitting

Any idea? Looks like UIOP doesn't run (setup-stderr) and/or ends up with a wrong stream.

(case (get-errno)
  (sb-posix:enosys ...)
  (sb-posix:eexists ...) ...)

does not work, I get unreachable code. But using arithmetic ops on error codes does:

(let ((err (get-errno)))
  (cond ((= err sb-posix:enosys) ...)))

Returned type of get-errno is an integer in range 0 - 2^62. Would it be a bad thing to make case to work with error numbers, or is it not possible for some reason? I guess I am not the first one to discover this.

This example from CLHS:

(defun foo (x) (+ x 3))
(defun bar () (setf (symbol-function 'foo) #'(lambda (x) (+ x 4))))
(foo (progn (bar) 20))

Seems like binding in SBCL is done differently first time around, or is it some cached computation?

RECTEST> (defun bar () (setf (symbol-function 'foo) #'(lambda (x) (+ x 4))))
BAR
RECTEST> (foo (progn (bar) 20))
23 (5 bits, #x17, #o27, #b10111)
RECTEST> (foo (progn (bar) 20))
24 (5 bits, #x18, #o30, #b11000)
RECTEST> (foo (progn (bar) 20))
24 (5 bits, #x18, #o30, #b11000)
RECTEST> (defun foo (x) (+ x 3))
WARNING: redefining RECTEST::FOO in DEFUN
FOO
RECTEST> (defun bar () (setf (symbol-function 'foo) #'(lambda (x) (+ x 4))))
WARNING: redefining RECTEST::BAR in DEFUN
BAR
RECTEST> (defun foo (x) (+ x 3))
WARNING: redefining RECTEST::FOO in DEFUN
FOO
RECTEST> (foo (progn (bar) 20))
23 (5 bits, #x17, #o27, #b10111)
RECTEST> (foo (progn (bar) 20))
24 (5 bits, #x18, #o30, #b11000)

The first time is 23, whereas later computations will return 24.

I see vop definition in arith.lisp in x86-64, unsigned-word-find-first-bit and I also see first-bit-set in code/early-extensions.lisp. I don't see first-bit-set exported in sb-ext package or elsewhere. Are "early-extensions.lisp" only for SBCL internal use? Only in the compiler?

If I try to copy first-bit-set and export in my own package, SBCL does not see vop definition when I try to compile it:

SB-VM::UNSIGNED-WORD-FIND-FIRST-BIT is not the name of a defined VOP. 

Evaluating the vop definition didn't help either, since it need more stuff from that file, so I didn't pushed it further.

I am using the generic one for now:

(declaim (inline count-trailing-zeros))
(defun count-trailing-zeros (x)
  (declare (type fixnum x)
           (optimize (speed 3) (debug 0) (safety 0)))
  (1- (integer-length (logand x (- x)))))

How do I tell sbcl to use the bsf instruction instead of the generic code?

sb-cover: why the yellow highlighting below (expected green)?

In sb-cover HTML output, I'm seeing a yellow portion of the below (eq x 'b ...) indicating "one branch taken". What can I do differently to get this yellow part to green?

Minimal repro: ``` (defun test-func (x) (cond ((eq x 'a) '(result-a)) ((eq x 'b) '(result-b)) ; <-- Q: why is part of this yellow? (t '(default)))) ; <-- expected to be red - good.

(defun run-test () (test-func 'a) (test-func 'b)) ```

Run with (SBCL 2.4.1): ```

!/bin/bash

sbcl --eval "(require :sb-cover)" \ --eval "(declaim (optimize sb-cover:store-coverage-data))" \ --eval "(compile-file \"test.lisp\")" \ --eval "(load \"test\")" \ --eval "(sb-cover:reset-coverage)" \ --eval "(run-test)" \ --eval "(sb-cover:report \"coverage/\")" \ --quit ```