This change adds many things:
* There is now a proper interface to defining and using foreign
callbacks in Lisp.
* There is now a usable script to build
libsbcl.so ("make-shared-library.sh"), which also slightly adjusts the
runtime to make it more amenable for external use with respect to
signalling.
* There is now a way to use libsbcl.so in conjunction with other
object code to actually initialize Lisp and call Lisp foreign
callables from C directly. (this works, at least on Linux, but support
is not quite complete yet, because we don't have a way to
de-initialize Lisp)
* `save-lisp-and-die' has gained a new argument to support the above.
I guess technically DEFINE-ALIEN-CALLBACK can be removed, since the
DEFINE-ALIEN-CALLABLE interface now supersedes it, but internal stuff
like tests still use it, so that change can wait for now.
Until I realized why it was ignoring the parameters from WITH-PROFILING in
the new test, it took ages to collect 50,000 (= default *MAX-SAMPLES*) traces
in parallel-exec, which already enables the profiler.
So issue a warning about calling it with unclear intent.
This fixes the single biggest problem with
(COMPILE-FILE "dir1/srcfile.lisp" :output-file "dir2/objfile")
by avoiding merging two relative directories into either
dir1/dir/ or dir2/dir1/ (and you don't know which)
Other lisp implementations disagreed with us, with each other,
and even with themselves about this. See the case studies in this
change as to why it's anyone's guess what it was supposed to do,
and how you can't even portably rely on COMPILE-FILE-PATHNAME
to not lie to you.
So, to gives users greater control, if :OUTPUT-FILE has a directory
in it, don't further manipulate it except to merge with *D-P-D*
which could always be bound to #P"". Users who want merging can merge
on their own. (You can't undo merging that was never wanted.)
And since the entire point of COMPILE-FILE-PATHNAME is to tell the
user what our implementation does, it seems fair game to implement
semantics that allow usage on modern content-addressable filesystems,
and make COMPILE-FILE-PATHNAME return the right answer instead of
a random hash based on the fasl file's sha256 sum or whatever.
Making the fasdumper dump literal package references directly makes
sense because we already have fops to do that. Plus, we no longer need
a MAKE-LOAD-FORM for it. Incidentally, both CLISP and CCL don't have
MAKE-LOAD-FORMs for PACKAGEs either, so they must also dump package
literals directly as well.
This makes both target and cross compiled fasls smaller.
Not only do we not need a special cross-compiler method to dump
package literals, we don't need to teach fop-funcall how to deal with
it anymore, though we do need to explicitly descriptorize the package
like we do for symbols when writing them out.
We also reduce dependence on the fopcompiler for making things work on
the cross-compiler and fasls smaller in the target compiler, which is
good for higher debug.
This change provides a better framework for doing memory allocation using
an allocator that does not assume that heap memory is prezeroed, by
separating allocation from zeroing, and deferring the decision to elide
zeroing until IR2 says it's OK to. It fixes the bug that VECTOR-INITIALIZED-P
failed to recognize some of the ways in which the transform could initialize
the data (and so it would zero-fill and then fill with data.)
Consequently it became possible to elide zeroing of dynamic-extent vectors
whose type is safe for GC without clearing the bits. I rolled that aspect into
this change. If there is any objection, it's simple enough to restore strict
backward-compatibility, though only unportable code should care.
SLOT-OBJECT is a PCL convenience, allowing for shared definitions in
class initialization and slot access on conditions, structure objects
and standard objects. The non-PCL parts of the system don't place
a layout for SLOT-OBJECT in the layout-inherits of structures, so
TYPEP was reporting NIL always.
Effectively, though, SLOT-OBJECT is the union of STRUCTURE-OBJECT,
STANDARD-OBJECT and CONDITION, so inform the classoids of this. In
the process delete what must be dead code in CLASS-TEST, because
SYSTEM-CLASSOID has not named a type for quite some time.
The interface to receiving an individual stack trace (MAP-TRACE-SAMPLES)
should have been a list or vector of locations, and I can conceive of no
reason but for the highly specialized usage in 'disassemble' for wanting
to visit each location that had ever been interrupted (MAP-ALL-SAMPLES).
Had these been good APIs with poorly chosen names (or possibly just bad APIs
with well-chosen names) then maybe it would have made sense to avoid
breaking them. But they're just horrible- not general enough to expose,
and incredibly confusing given that "samples" means not 1, not 2,
but 3 different things simultaneously: all instances of the DEFSTRUCT,
all traces captured, and all locations in a trace.
Well, they said "EXPERIMENTAL: Interface subject to change." so
here we are- Consider it changed.
I'm unsure what the use-case for it was. Sampling in a subset
of threads is best done by selectively blocking SIGPROF.
After this change, WITH-PROFILING is more similar to START-PROFILING-
they both defaults to sampling in all threads.
* By suitably restricting rank, it is possible to have every array including
1-dimensional contain its rank in its 0th word, eliminating an IF from
ARRAY-RANK. It also makes space for a second widetag in fancy array headers
so that ARRAY-ELEMENT-TYPE does not need to follow a displacement chain.
* Improve GC by visiting only the slots of a fancy array header
that possibly contain pointers.
* Fix an omission: simple-array must not call scav_boxed, so the code
was wrong after the prior change that affected array-rank-limit.
This will allow use of upper bits in an array header's header word
so that has-fill-pointer-p can become a 1-bit test on _any_ array.
Not to mention it saves an instruction in the array-rank vops.
This undoes parts of 902e9373 in the interest of following the spec by its
intent and de-facto correct interpretation versus a theoretical view
that is of little practical value.
As the test file shows, among all other implementations examined, the consensus
is 8-to-2 against treating (VECTOR NIL) as a string even where support for
(ARRAY NIL) as a type exists. And the minority stance is weak- both outliers
upgrade NIL to their widest character type in MAKE-STRING, proving beyond a
doubt that they don't really think that NIL means empty type in that usage.
So now SBCL goes along with that for maximum compatibility with everyone.
I considered a hypothetical build-time #+vector-nil-is-string feature,
but it's not worth cluttering the code for. Nobody would/should use it.
