SBCL Internals The pages on this CLiki-driven site can be edited by anybody at any time. No warranty of any kind can therefore be made; any implied warranties of merchantability or fitness for a particular purpose are expressly disclaimed

SSAify IR1

This would immediately solve bugs 233, 188 (partially) and optimization issues 3 and 8.

The first block is our way of performing inline expansion, which produces unexpected references to optimized stuff. If someone finds a new example for the bug 148, it would be a good reason to write COPY-DFO-SEGMENT.

Metainformation on IR1 objects

At least it would be nice to keep a list of node "arguments", so that SUBSTITUTE-CONTINUATION could be automatically generated.

Pattern-matching IR1 modifier

(It probably depends on the preceding item). Massive updating of IR1 is hard and error-prone. A language allowing to "match the subgraph with this picture, transform it to match that one, update necessary counters, flush code, which become dead, trigger off required optimizations" would be very useful. (See also once and only once.)

Move more of GC into Lisp

I think that this would make it a lot easier to experiment with different GC strategies and algorithms, not to mention making the code a lot cleaner and easier to understand. I'm going to try and give this an experimental first pass once I've identified all points of contact in the code.

utf8 encoded file names

It'd be nice if SBCL supported utf8 encoded file names. (done as of SBCL-0.9.17)

weak hash tables

see Bruno Haible's paper for discussion of scalability, but weak hash tables have been implemented as of SBCL-0.9.17.

OOM handling

lose() is suboptimal

dynamically growing stacks

for lighter weight threads

incremental/concurrent gc

Sapphire, Doligez

This page is linked from: index   TODO   Type Checking  

CLiki pages can be edited by anyone at any time. Imagine a fearsomely comprehensive disclaimer of liability. Now fear, comprehensively