This is intended to supplant the concept of deferred-warnings in ASDF by
imparting the ability to the FASLoader to issue warnings about unresolved
function linkage. At last, Lisp can use a more modern paradigm of
separately compiled translation units.
LOAD is totally unchanged if you don't hook into this mechanism in user code.
In fact, this hash function might be shorter. For example, according to the file,
the hash function for #(2 3 5 #xC #xE) performed a mask, two shifts, AREF,
and xor; while the quick function is merely + and LOGAND.
Solves the problem that if you're building in a tree of symlinks where files
aren't on the local machine, load-as-source made 10x too many OS calls.
Based on strace it looks like it still invokes unix-access and unix-open
at least 2x too many times, but there's definitely less lstat() now
for source files that produce no style-warnings or other noise.
This eliminates duplication between compiler/generic/core and compiler/dump.
And code-slots-per-simple-fun is mentioned in far fewer places.
The pristine core consumes 5% less code space, correspondingly more non-code,
but all other things being equal, the CPU's instruction cache will benefit.
This rectifies many awkward aspects of the immobile space fdefns
which it replaces.
All other architectures should be unaffected by the patch.
Tested with with +/- {immobile-space, sb-thread, mark-region}
on linux, and the default config on windows and macOS.
The launchpad complaint was that if we claim the spec permits us to disregard
some type constraints, surely it meant that no matter how spelled; but it would
be very incompatible to force users to put an (OR NULL) in their type,
so this does it for them only at evaluation of the DOLIST result form.
Since this change generally performs more analysis of which declarations are
bound or free, it also hoists the free ones outside the loop like they are
in CCL and CLISP which potentially remove type-checks from inside the loop
for free declarations on lexically visible vars with no SET.
e.g (DECLARE (FIXNUM LOOPVAR FOO)) where FOO is lexically known to be INTEGER,
it still checks for FIXNUM on each loop iteration which seems like a bug.
It was previously renamed in rev 851cbd2b but the new name was too wordy.
The motivation here is the same: some pending changes for x86-64 that make
lisp-to-lisp calls go through a linkage table (almost doing away with
all FDEFNs) is nearly ready to be committed for real now.
Getting to the state that I tested with various combinations of
old/new host, with/without features this morning. (This situation can
be revisited after the sbcl-2.4.4 release.)
This reverts commit b25ec73091.
This hadn't been done ever since rev 790bca74 made SYMBOL-HASH less sensitive
to address-of-NIL. Consequently many of the lines are not needed now.
Additionally, add a small hack to avoid creating journal entries when
the static objects (symbols, fdefns) are changed.
Having a separate slot doesn't buy much other than waste about 200kb
of space in a warm core. The debugger doesn't need accesses to the
cache to be fast.
This also fixes a bug in editcore, allowing us to remove a bunch of
allowed instances that never get dumped as part of COMPILED-DEBUG-INFO
now.
This change significantly reduces the amount of space that debug-info takes
up in an image (about a 50% space reduction in total debug info space
usage). For example, the size of a cold image on an arm64 machine goes
down from 33 MB to 27 MB, and from 34 MB to 29 MB on x86-64.
Based closely on the long-ago-removed minimal debug fun representation
whose only vestiges remained as a block comment. (It was originally
removed as SBCL was being first bootstrapped due to package renaming
issues which are irrelevant now). The main difference with this new
implementation that this packed debug fun representation works on all
debug levels and so we are always able to pack debug funs into byte
vectors.
* COMPILED-DEBUG-FUN is now never dumped. This means there is no need
to have an additional layer of encoding in COMPILED-DEBUG-FUN, and we
can remove things like the :KIND hack and free up 7 fopcodes. The
tricks to do byte encoding previously are now subsumed by the packed
debug fun representation, where everything is byte-packed.
* Replace the test cross-checking the C and lisp implementations of
varint decoding with an end-to-end test demonstrating that the ldb
backtrace code produces the same debug fun names as the Lisp code,
making backtracing more robust to further changes to the debug fun
format.
* The disassembler code now includes local functions again, but it is
still based on PC ranges rather than names so that disassembling
different closures with the same name is correct still.
Why not. It wasn't hard to find the problem, though I do not see how
this affected the number of perfect hashes needed during cross-compile.
Not sure if I should be worried.
Fixes lp#2060059
The COMPILED-DEBUG-FUN-VARS slot was designed to store a packed byte
vector where the names and packages of variables were dumped in a
packed representation with smarts to dump debug variables relative to
the current package or to flag them as uninterned, allowing the
omission of an explicit package name in the packed vector.
Due to bootstrapping reasons however, the initial SBCL commit changed
this to store symbols instead (as a necessity since package names were
dumped by xc like SB!C, not matching how they get loaded as SB!XC,
making the name+package strategy more difficult). The result was
significantly increasing the space usage of debug info relative to CMU
CL, since symbols needed to be loaded interned, taking up more space
to represent, even though most of the time interning is not even
needed outside of debugging contexts. Also space was wasted for
uninterned symbols. The vector for the slot was also no longer
dumpable as a byte vector, wasting a bunch of space. (later mitigated
by a hack on 64-bit where flags got packed together with scs).
Now that the bootstrap no longer involves package renaming and we have
a sane way of doing that, the original design using name+package and a
packed vector for COMPILED-DEBUG-FUN-VARS as in CMU CL can now be
brought back, saving ~400KB from a warm arm64 core. 32-bit targets
should benefit even more, since they didn't do the manual packing
mitigation.
So:
* We can get rid of the "large-fixnums" hack where scs got packed into
the flag, since now we just dump it all as a packed byte vector. In
particular 32-bit targets benefit now too from packing without having
to do manual packing.
* Symbols don't need to be needlessly interned before a debug fun even
gets parsed.
* A few FIXMEs are killed.
The #+ultrafutex feature which is nearly ready for use can acquire + release
a mutex in 1/3rd the time of WITH-MUTEX. This is an improvement upon the old
results in benchmarks/grab-mutex which showed maybe a 1.5x typical speedup.
The new code is NLX-protected but *NOT* async-unwind or interrupt-safe, nor can
it detect deadlocks. It did pass the entire regression suite, less one file.
The rationale is that a debug build of code might demand maximum robustness
while a release build wants sheer speed. This patch is a counterpoint to the
adage that Lisp programmers know the value of everything but the cost of
nothing; you should be able to choose your price for mutexes.
