Martin Muggli wrote:
> I'm also interested in 5.6 (MPS GC) as well as 6.11 (GCed special
> variables) and 6.12 (Precise stack scanning).
The latter two are in section 6 because:
6.11: AFAIK, only one system has run into that limit: kpreid's E (?)
implementation that bound gensymed symbols as special. The task
description might be misleading, so I'll write some details. SBCL
implements thread-local special bindings by allocating indices in
fixed-size (per-thread) tables on demand, as variables are bound
dynamically. Indices are allocated by incrementing a global counter and
are never re-used, even if a symbol is eventually GCed. This isn't
ideal, and could be alleviated by computing the set of indices still in
use during major GCs. I believe that task would constitute a very nice
introduction to the GC… but I don't think its impact would be major.
6.12: I don't think anyone has a good angle for that task. I'm sure
nearly every committer has thought of approaches, but I don't know of
any that seems assuredly workable. If you're not already familiar with
SBCL, it's probably not the best choice.
> I'll be starting a CS PhD program in the fall, working on bioinformatics
> problems where current C++ software uses in excess of .5 TB of RAM. I'd
> like to be able to use SBCL for any work where C/++ isn't truly required,
> so my biggest motivation is space efficiency.
Unless that's mostly unboxed data, I don't think your biggest issue will
be conservativeness as much as the fact that our GC is mostly copying.
If it is mostly unboxed data, conservativeness may very well not be an
issue at all; the vast majority of programs work fine, after all. I also
wouldn't be surprised if you end up doing something like ITA (now
google): they use SB-ALIEN to represent huge data on the C heap. Perhaps
you want to try to come up with a project that would directly help your
> How far from fully precise (and fully collected) would 6.11 and 6.12 put
> SBCL on x64 linux? http://common-lisp.net/~dlw/LispSurvey.html seems to
> suggest that it is already on PPC, but http://www.sbcl.org/manual/History-
> and-Implementation-of-SBCL.html indicates that it wouldn't make sense on
> x86, does x64 have enough registers to justify this for SBCL?
I don't think that being conservative only on registers would be a big
problem, and I'm not convinced that increasing register pressure to
eliminate rare GC issues is a good tradeoff, but opinions on this issue
diverge. Still, if we're ever precise on stack, a partitioned register
set could be a build-time feature, but there's little point until then.
I do feel that stack conservativeness is a pressing issue: the stack is
much bigger than the register file, and stray references can easily hang
around for a very long time.