Fix 'reloc to avoid a crash on static-generation code, and add
'reloc+offset to report an offset for each entry.
original commit: 4d4195044377f9c619cfb46056e365044069d5bc
In the general form of a function call, the return point embeds 4
words of information: offset to the start of the enclosing function,
frame size, live-veriable mask, and multiple-value return address. In
the common case, however, the multiple-value return address is either
the same as the return address or it is a `values-error` library
function, and the frame size and live-variable mask fit into a word
with bits to spare. This patch implements a more compact return point
for that common case, which shrinks the 4 words to 2 and also avoids a
relocation (= 1 more word).
Multiple-value returns are more complex with this change (i.e.,
require more code), since they must check whether the return point is
compact or not. But multiple-value returns are far less common than
function calls, so saving function-call space is a clear win.
Overall, this change tends to reduce code size by about 10% on x86_64.
original commit: 1f53b5eabef966db01086cb32e544bbf8deacfca
On x86_64, a POPCNT instruction is usually available, and it can speed
up `fxpopcount` operations by a factor of 2-3.
Since POPCNT isn't always available, code using `fxpopcount` is
compiled to a call to a generic implementation. The linker substitutes
a POPCNT instruction when it determines at runtime that POPCNT is
available.
Some measurements on a 2018 MacBook Pro (2.7 GHz Core i7) using the
program below:
popcnt = this implementation, POPCNT discovered
nocnt = this implementation, POPCNT considered unavailable
optcnt = compile to use POPCNT directly (no linker work)
cpcnt = compile to inlined generic (no linker work, no POPCNT)
Since the generic implementation is always a 64-bit popcount, it's not
as good as an inlined version for `fxpopcount32`, but otherwise the
link-edit approach to POPCNT works well:
fxpopcount fxpopcount32
popcnt: 0.098s
nocnt: 0.284s
optcnt 0.109s [slower means noise?]
cpcnt: 0.279s 0.188s
(optimize-level 3)
(time
(let loop ([v #f] [i 100000000])
(if (fx= i 0)
v
(loop (fxpopcount i) (fx- i 1)))))
original commit: 5f090e509f8fe5edc777ed9f0463b20c2e571336
Instead of using `%` to compute the index into an oblist, use a power
of 2 for the oblist length and bit masking to compute an index. (Maybe
the old hashing function was bad; the current hashing function should
produce good hash-code variation at the level of bits.) Also, make the
oblist array a little sparser to reduce bucket chaining.
original commit: fb87fcb8e47902b80654789d059a25bd4a7a8def
After a bignum computation using temporary thread registers W, U, or V
is complete, clear ther register. (The X and Y registers hold only
small bignums, so clearing them doesn't matter in the same way.)
original commit: a9e11fcf9e86aee5d149764476e1fabfeee12f84
It's not available with musl, either, musl intentionally
doesn't provide a preprocessor test, and we're avoiding
(for now) `configure`-time tests in the style of autoconf.
original commit: a9bfb72027fc83ed6bb690d033bc6fed0629dba7
Use the high bit of a byte to continue instead of the low bit.
That way, ASCII strings look like themselves in uncompressed fasl
form.
original commit: 89a8d24cc051123a7b2b6818c5c4aef144d48797
Uninterned symbols are slightly more expensive to allocate than 0- or
1-argument calls to `gensym`, but they're much cheaper to hash (and
print). They're also more consistently distinct when unfasled, and the
fasled form is determinsitic.
original commit: 3167083008031b1f880e76a6f573563c7d9c888c
The result of `mktime` is -1 for an error. The result is also -1 if
the time is 1 second before the epoch. That's not useful, so ignore
it.
original commit: aa8ca31cef223128fd8ed1abdc76beb31a0e077a
The MRG32k3a generator is fast when using unboxed floating-point
arithemtic. Since the Scheme compiler doesn't yet support that,
build MRG32k3a into the kernel and provide access via
`pseudo-random-generator` functions.
original commit: 3dd74679a6c2705440488d8c07c47852eb50a94b
If normal 1-shot continuations are mixed with opportunistic 1-shot
continuations created by `call-setting-continuation-attachment`, then
promoting an opportunistic 1-shot at a GC is wrong unless the whole
chain is promoted.
original commit: 2dfac475666763b60935e382386af4438f3029e0
Also, rename `call-with-current-continuation-attachment` to
`call-getting-continuation-attachment`.
original commit: e2a00e6d641b92918c4911c27ba14949748fd291
Add a shortcut check when refiying the continuation frame in tail
position, which is significantly cheaper when the frame is already
there. We pay down the check by skipping an attachment-lists check
that is not needed if the frame is newly reified.
Aslo, add a one-shot continuation-frame cache, which makes a shallow
temporary attachment cheaper, as in
(let loop ([i N])
(if (zero? i)
0
(loop (call-setting-continuation-attachment
i
(lambda ()
(f (sub1 i)))))))
The cache is just one frame. Keeping a chain of allocated-by-not-GCed
frames doesn't pay off.
Meanwhile, remove the leftover `$shift-attachment` library entry.
original commit: 1f454f536b1d7efe20fe9e793cda31e54e31e5f4
Weak pairs, ephemeron pairs, some symbols, and some ports were handled
incorerctly when locked multiple times.
original commit: 847fc1c84496f67cd363c8411d0023339f4d6246
The `unlock-object` operation was O(N) with N currently locked objects
--- so, O(N^2) to lock N objects and then unlock them --- because
locked objects were stored in and searched in a global list. Also, GC
was O(N) at any generation with N locked objects across generations,
since every locked object was scanned.
Fix these poblems so that locking and unlocking is practically O(1)
and GC is not poportional to locked objects. More precisely, locking
and unlocking is now O(C) for locking an individual object C times to
be balanced by C unlocks. (Since multiple locks on a single object
is rare, this performance seems good enough.)
The implementation replaces the global list with segment-specific
lists. Backpointers are managed using the general generational
support, so that unmodified, old-generation locked objects do not
need to be swept duing a new-generation collection.
original commit: a57d256ca73a3d507792c471facb7e35afbe88b3
p is a pointer that iterates over path, which is buffer.
We should not try to get to an address preceding its start.
Since there was an execution path that leads to that,
guard against it with an additional check.
Signed-off-by: Alexander Shopov <ash@kambanaria.org>
original commit: de8d0e742f44c80735a682bd05019246c2087d56
Move `NORETURN` of 2e3a618b00 to start of function declaration, where
it works for both GCC and MSVC.
original commit: 10fc4a2406ecd34fa686d9d643ee63d7c12d6f97
Merging ".o" files to one "kernel.o" can be convenient for further
linking, but it requires running `ld` directly. Running `ld` directly
sometimes runs into a mismatch between the C compiler and the default
`ld`. It's better to use the more typical approach of collecting
objects into an archive.
original commit: 7d5b60c7566570655e567495d86d546101cf8fb4
Use OSSP UUID on {Free,Open}BSD and native UUID on NetBSD.
Building on OpenBSD requires a filesystem mounted with wxneeded.
original commit: e964d7d01a6d115e469c01626896b683d421d599
A few shift lefts cause ub because of `(1 << n)` where `n` is 31.
The constant 1 is signed causing ub. Initially my fix was to do `(1U << n)` however, I have seen the pattern `((U32)1 << n)` elsewhere in the file so decided to follow this.
Caught by ubsan racketcs.
original commit: a902c9ab67010f521f786e2027d4e197d78975a4
According to ubsan we get several times into undefined behaviour due to signed overflow:
foreign.c:91:21: runtime error: signed integer overflow: 3291370622602663862 * 3 cannot be represented in type 'long int'
This happens only when the symbol name is relatively large like as for the call:
symhash (s=0x5555558caab8 "(cs)set_enable_object_backreferences")
original commit: 1e1c91869443d8a22beeebfcbe6fa14f9c3e2a6e
On a 64-bit platform, the test for "short" arguments to
avoid overflow was incorrect, because `(- (expt 2 30))`
counted as short.
original commit: 6d05b70e86987c0e7a07f221ba5def492300aaaf
- added compress-level parameter to select a compression level for
file writing and changed the default for lz4 compression to do a
better job compressing. finished splitting glz input routines
apart from glz output routines and did a bit of other restructuring.
removed gzxfile struct-as-bytevector wrapper and moved its fd
into glzFile. moved DEACTIVATE to before glzdopen_input calls
in S_new_open_input_fd and S_compress_input_fd, since glzdopen_input
reads from the file and could block. the compress format and now
level are now recorded directly the thread context. replaced
as-gz? flag bit in compressed bytevector header word with a small
number of bits recording the compression format at the bottom of
the header word. flushed a couple of bytevector compression mats
that depended on the old representation. (these last few changes
should make adding new compression formats easier.) added
s-directory build options to choose whether to compress and, if
so, the format and level.
compress-io.h, compress-io.c, new-io.c, equates.h, system.h,
scheme.c, gc.c,
io.ss, cmacros.ss, back.ss, bytevector.ss, primdata.ss, s/Mf-base,
io.ms, mat.ss, bytevector.ms, root-experr*,
release_notes.stex, io.stex, system.stex, objects.stex
- improved the effectiveness of LZ4 boot-file compression to within
15% of gzip by increasing the lz4 output-port in_buffer size to
1<<18. With the previous size (1<<14) LZ4-compressed boot files
were about 50% larger. set the lz4 input-port in_buffer and
out_buffer sizes to 1<<12 and 1<<14. there's no clear win at
present for larger input-port buffer sizes.
compress-io.c
- To reduce the memory hit for the increased output-port in_buffer
size and the corresponding increase in computed out_buffer size,
one output-side out_buffer is now allocated (lazily) per thread
and stored in the thread context. The other buffers are now
directly a part of the lz4File_out and lz4File_in structures
rather than allocated separately.
compress-io.c, scheme.c, gc.c,
cmacros.ss
- split out the buffer emit code from glzwrite_lz4 into a
separate glzemit_lz4 helper that is now also used by gzclose
so we can avoid dealing with a NULL buffer in glzwrite_lz4.
glzwrite_lz4 also uses it to writing large buffers directly and
avoid the memcpy.
compress-io.c
- replaced lz4File_out and lz4File_in mode enumeration with the
compress format and inputp boolean. using switch to check and
raising exceptions for unexpected values to further simplify
adding new compression formats in the future.
compress-io.c
- replaced the never-defined struct lz4File pointer in glzFile
union with the more specific struct lz4File_in_r and Lz4File_out_r
pointers.
compress-io.h, compress-io.c
- added free of lz4 structures to gzclose. also changed file-close
logic generally so that (1) port is marked closed before anything is
freed to avoid dangling pointers in the case of an interrupt or
error, and (2) structures are freed even in the case of a write
or close error, before the error is reported. also now mallocing
glz and lz4 structures after possibility of errors have passed where
possible and freeing them when not.
compress-io.c,
io.ss
- added return-value checks to malloc calls and to a couple of other
C-library calls.
compress-io.c
- corrected EINTR checks to look at errno rather than return codes.
compress-io.c
- added S_ prefixes to the glz* exports
externs.h, compress-io.c, new-io.c, scheme.c, fasl.c
- added entries for mutex-name and mutex-thread
threads.stex
original commit: 722ffabef4c938bc92c0fe07f789a9ba350dc6c6
