sbcl Log

Commit Date  
[26cad2] by Paul Khuong Paul Khuong

Fix a non-gencgc build failure in UNSAFE-CLEAR-ROOTS

Introduced in 4084b6b9 (armload of DEFINE-HASH-CACHE changes).

2011-07-08 17:04:07 Tree
[ba12c5] by Paul Khuong Paul Khuong

Small cleanups

* Wrap some asserts with with-test in defstruct.impure.lisp

* Remove two unused variables in remap_free_pages.

* Fix the allocation region size estimate in sb-sprof.

2011-07-06 06:16:17 Tree
[0bce93] by Paul Khuong Paul Khuong

More conservative defaults in GENCGC

* Set GENCGC-ALLOC-GRANULARITY to 0, and thus fully disable the minimal
allocation size logic by default.

* Explicitly zero out pages that fall outside GENCGC-RELEASE-GRANULARITY,
instead of leaving them dirty, when releasing address space.

* Set large_object_size to 4 * MAX(PAGE_SIZE, GENCGC_ALLOC_GRANULARITY,

* I'm getting very strange failures in some branches that I can't replicate
on master, but let's be extra careful for now.

2011-07-06 01:46:06 Tree
[c179ad] by Paul Khuong Paul Khuong

Fix the build - gencgc broken since (4 commits ago)

Sloppy merge.

2011-07-03 17:25:27 Tree
[c2404a] by Nikodemus Siivola Nikodemus Siivola

teach debugger about &MORE arguments

LIST-LOCALS displays SB-DEBUG::MORE = (...list of more args...)
in addition to the more-context and count.

EVAL-IN-FRAME bindss SB-DEBUG::MORE when appropriate.

2011-07-03 15:52:32 Tree
[4cd96b] by Nikodemus Siivola Nikodemus Siivola

inhibit &REST -> &MORE conversion when DEBUG is 3

Explicitly inhibit in BREAK.

2011-07-03 15:24:12 Tree
[e8571b] by Paul Khuong Paul Khuong

Allocate at least gencgc_alloc_granularity bytes at a time, if possible

* While we have large cards, it doesn't really matter, but tuning that
might help some applications that cons a lot of medium-sized objects.

* Defaults to GENCGC_ALLOC_GRANULARITY, and should always be a multiple

is a no-op.

2011-07-03 16:45:42 Tree
[87cce4] by Paul Khuong Paul Khuong

Release address space to the OS at gencgc_release_granularity

* Some platforms perform better on large, aligned mmap/munmap calls.
The GC will only perform such calls in chunks of
gencgc_release_granularity bytes, aligned at that many bytes.

* gencgc_release_granularity defaults to GENCGC_RELEASE_GRANULARITY,
and should always be a power of 2, as well as a multiple of the OS
page size and of GENCGC_CARD_BYTES.

this patch a no-op.

* Also, fix an assumption that BACKEND_PAGE_BYTES = 1024*sizeof(long)
in a safety check in gc_free_heap.

2011-07-03 16:45:42 Tree
[5c0a88] by Paul Khuong Paul Khuong

Split GENCGC_PAGE_BYTES in 3 constants

* We still have BACKEND_PAGE_BYTES, which should be a conservative
over-approximation of the OS's page size.

* GENCGC_PAGE_BYTES is mostly replaced by GENCGC_CARD_BYTES, the
byte granularity at which we track writes to old generations.
While we're using mprotect-based write barriers, this should be
a multiple of BACKEND_PAGE_BYTES.

* GENCGC_ALLOC_GRANULARITY is the minimum size we attempt to make
each allocation region. Should be a multiple of GENCGC_CARD_BYTES.
While we have largeish cards, this shouldn't ever be an issue, but
it might if we ever go down to < 1k cards.

* GENCGC_RELEASE_GRANULARITY is the minimum size at which we release
address space to the OS. This should always be a multiple of

* For now, all three new constants are equal to BACKEND_PAGE_BYTES.

2011-07-03 16:45:42 Tree
[9effe6] by Paul Khuong Paul Khuong

Lazier zero_dirty_pages in gencgc

Upon allocation, only zero out pages that haven't already been cleared.

2011-07-03 01:52:50 Tree
[57d30b] by Paul Khuong Paul Khuong

Differentiate between object slot initialisation and mutation

INIT-SLOT and SET-SLOT VOPs do the same thing on every platform for

2011-07-03 01:05:31 Tree
[e3f278] by Paul Khuong Paul Khuong

Fix an off-by-one in MAP-ALLOCATED-OBJECTS

The bug would be extremely hard to tickle with current gencgc, but
that's going to change soon.

2011-07-02 23:59:54 Tree
[cc27e3] by Christophe Rhodes Christophe Rhodes

restarts for PRINT-NOT-READABLE errors

Two restarts: USE-VALUE, to provide a value to be printed instead
(under the same printer control variable bindings), and
SB-EXT:PRINT-UNDREADABLY, printing the same object but with
*PRINT-READABLY* bound to NIL. Only minimally tested, but should
meet requirements for lp#801255.

2011-06-29 14:52:35 Tree
[d9479b] by Nikodemus Siivola Nikodemus Siivola

export SIZE-T and OFF-T from SB-ALIEN

They're pretty common interface types.

2011-06-26 17:47:44 Tree
[e498af] by Nikodemus Siivola Nikodemus Siivola

fix bogus test in arith.pure.lisp

Didn't actually call the slow-path at all. Thanks to Lutz Euler for the

2011-06-26 17:40:22 Tree
[a3c77b] by Paul Khuong Paul Khuong

Get alignment right for block headers on x86-64, this time

We want to align the code in the block, not the trampoline that
leads to the block. In theory, we could take the trampoline into
account when inserting alignment, but really?

2011-06-24 03:17:22 Tree
[ce118e] by Paul Khuong Paul Khuong

Microoptimisation for block headers on x86-64

Only emit a jmp over the header if a predecessor falls through to
the current block, and it there is a trampoline. Otherwise, it's
not worth the cost of a branch to skip a few NOPs.

2011-06-23 15:05:54 Tree
[6596b1] by Paul Khuong Paul Khuong

Let register allocation handle unused TNs due to constant folding

Type-directed constant folding can leave lambda-vars that are neither dead
nor read from or written to. Ideally, it seems like we should make sure to
transform those into REF to CONSTANTs, but the optimisation doesn't seem
guaranteed to fire. It looks like the TN could simply not be allocated
in ASSIGN-LAMBDA-VAR-TNS, but I'm not sure how to test for that situation
ahead of time yet.

Kludges over lp#729765.

2011-06-22 01:12:36 Tree
[99a669] by Paul Khuong Paul Khuong

Unboxed implicit value cells on x86[-64]

Implicit value cells are used for bindings that are only closed
over by dynamic-extent functions.

The logic would have to be somewhat modified on platforms with
NFP. As is, only implement support for unboxed implicit value
cells on x86oids (for signed and unsigned words, SAPs and float
reals and complexes).

2011-06-21 04:31:00 Tree
[56a2db] by Paul Khuong Paul Khuong

Compiler support for specialised implicit value cells

Enables the use of non-T stack TNs for closed-over dynamic-extent variables.

SB!VM:PRIMITIVE-TYPE-INDIRECT-CELL-TYPE takes a primitive-type and returns
NIL, or a list of 4 values:
- the primitive type of the implicit indirect value cell
- the SC of that cell
- a function that takes the NODE, BLOCK, FP, VALUE and RESULT, and
emits a reference to that cell.
- a function that takes the NODE, BLOCK, FP, NEW-VALUE and VALUE, and
emits a write to that cell.

Some correctness tests to make sure codegen is correct (without verifying

2011-06-21 03:52:45 Tree
[8b6a52] by Paul Khuong Paul Khuong

Restore the build on x86

Bad copy-pasta in 293488f3.

2011-06-21 03:51:07 Tree
[293488] by Paul Khuong Paul Khuong

Inline local call trampolines on x86[-64]

Allow the insertion of code before entry to blocks from
drop0throughs, jumps, and calls. Used on x86oids to insert
the code to move return addresses to the right location
on local calls without trampolines.

2011-06-21 02:07:52 Tree
[65a29e] by Paul Khuong Paul Khuong

Faster MAP[-INTO] when (> SPEED SPACE)

Expand into WITH-ARRAY-DATA for non-simple vectors in such cases,
and avoid hairy vector accesses.

Also make sure to exploit that in conset code.

2011-06-21 00:44:07 Tree
[74a297] by Paul Khuong Paul Khuong

More constraint propagation in the presence of assignment

When SPEED = 3 > COMPILATION-SPEED, propagate type in code
like (cond ((eql (the fixnum x) y) (setf x 42) y) ...).

2011-06-20 01:04:20 Tree
[fb24d8] by Paul Khuong Paul Khuong

Less constraint propagation when COMPILATION-SPEED > SPEED

Propagate much fewer EQL constraints, and propagate fewer constraints
to EQL variables. Can results in a few orders of magnitude speed ups
in compilation times.

2011-06-18 20:36:02 Tree
Older >

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks