When the GC needs to copy/mark a record, it previously forced a
copy/mark on the record's type descriptor, since the copy/mark needs
information from the descriptor. But the needed information is not in
danger of being overwritten for forwading (since it's after the first
two words of the type descriptor), so it's ok to use the old reference
as-is --- at least in non-counting mode. Simplifying record-type
handling and deferring the record-type update to the sweep phase, the
same as for other components of the record type, makes the GC slightly
faster.
Fall back to `current-directory` when `current-load-relative-directory`
is #f.
This change also affects `deserialize` --- not because byte code
loading uses it directly in this case, but because they share a helper
function, which exposes the issue. This implementation change is
worrying (even though it makes the implementation match the
documentation), but unless we discover that some use of serialization
needs absolute paths deseialized as relative, is seems better to be
consistent everywhere about falling back to `currenrt-directory`. This
aspect of the change can be reverted separately (by adding more code)
if needed.
Closesracket/drracket#421
All allocation is now thread-local, which recovers a small bit of
performance that was lost when adding thread-local allocation
alongside global allocation.
Parallelism uses thread contexts created by Chez Scheme threads (which
correspond to Racket places and future-running threads), but it
creates its own OS-level threads to perform collection. The number of
collection-helper threads is limited to the number of active Chez
Scheme threads. Only the main "sweep" pass runs in parallel --- that
is, after roots have been traversed, and before weak references and
finalization are handled --- but that's the bulk of collection work.
Also, memory-accounting collections always run as single-threaded.
Improved support for thread-location allocation (and using more
fine-grained locks in fasl reading) may provide a small direct
benefit, but the change is mainly intended as setup for more
parallelism in the collector.
There's a trade-off between keeping the distribution sizes small and
making ".boot" files available for convenient embedding, even though
embedding is relatively rare. For Unix platforms, since you have to
build from source to get a static library for embedding anyway, we'll
leave out ".boot" files. For Mac OS, the distribution's "Racket"
framework includes ".boot" files --- even though the framework is
itself unused for a normal distribution build, since signing and
notarization are handled by embedded the boot files in an executable,
but the framework was kept for a kind of backward compatibility. For
Windows, the Racket DLL can be used for embedding, so the ".boot"
files would be the only missing piece; also, they were already
included in a cross-built distribution.
Update "Inside" to note that ".boot" files must be built on Unix and
to clarify the location of ".boot" files on Mac OS.
Closes#3377
The A32 instruction set has an interesting encoding of immediate
values where a larger value sometimes fits in a smaller set of
instructions. That turns out to be a bad property for loading a return
address, because it means that the as label computations push code
further away, a contracting return-address calculation can pull code
back nearer, and this push-and-pull can keep the label allocator from
arriving at a fixpoint.
This became a bigger problem with 8834597c1f, which creates
return-label references that go backwards and where the offset can be
much larger than the normal, forward references.
See #3378: The possibility of mutation should be considered in
`:do-in` in somme rare cases, while it's not clear that there's
anything better to be done for mutation of the list accumulators in
`for/lists`. At least make the pitfalls clearer in the documentation.
This commit doesn't update nanopass itself, but adapts `rktboot`
so it can be used with the main Chez Scheme bbranch. It also
adjust "cpnanopass.ss" to avoid different behavior between the
old and newer versions of nanopass.
The Scheme stack pointer was left in call state when the number of
results is wrong, with the intent of exposing the enclosing function's
frame for debugging purposes, but there's no guanrantee that the
result address is still on the stack (i.e., the continuation make have
been captured). Reinstall the return address before calling the
exception handler.
The tests formerly set `PLTADDONDIR` to separate runs, but that no
longer makes the cache directory separate. Setting `PLTUSERHOME` is a
more complete separation.
