The Chez Scheme change avoids a leak while collecting in counting
mode, which is used by Racket's memory-accounting mode.
Also, add a small repair for 4256214981.
When collecting to the maximum generation with object counts enabled,
a structure type would effectively become permanently reachable.
Also, add `bytes-finalized` to report how many bytes were associated
with guardian-based finalization by the most recent collection.
original commit: 852f5e2de95a26d3500321c4d4d732407945a57a
GitHub switched URLs for tarballs, redirecting to the new one with
a 302. However, old versions of Racket don't follow redirects in
`raco pkg install`, so they broke (before 6.3). Using the new URL
should work for everyone.
Reported by @greghendershott.
Also `--include-deps`, which support the creation of a catalog archive
that is restricted to a specific set of packages. Also
`--fast-file-copy`, which is usefl for speeding up a pipeline of
archiving (helpful to pkg-build).
Chez Scheme now supports a single-pass combination of `collect` and
`compute-size-increments`, which makes a GC with accounting about
twice as fast. Meanwhile, other GC improvements reduce non-accounting
full-collection times by 10-20%.
Much of the GC implementation is now generated from a "Parenthe-C"
description, so update the bootstrap process for that step.
Replace repetitive C code in "gc.c" and "vfasl.c" with an
implementation using a little "Parenthe-C" language, which is a
somewhat declarative description of object tracing. From that
descrition, we generate different kinds of tracing functions, such as
the copy function or the sweep function.
The little language is still bascially C, just with parentheses and
parameterization that is much better than trying to use the C
preprocessor. (The "mkgc.ss" file includes the compiler from
Parenthe-C to C.)
Besides replacing existing code, we also generate a new traversal to
implement `compute-object-sizes`. Finally, the GC can now perform a
fused `collect` and `compute-object-sizes` in a single traversal.
Also improve the way that locked objects are detected during GC. This
can make a significant difference (on the order of 10-20% for a full
collection) when locked objects are long-lived.
original commit: de1f5c41d729ac75822a1f1e633ec6d042c883dc
Only half(!) of the needed space was actually allocated. The extra
space is ony used after a GC, however, and a GC makes the extra room,
so that's why things haven't fallen over completely, but that's more
subtle than intended.
original commit: 3d72bc14b9247d6764809cb651403dbb4063a905
The module is named `hi` but the text said that it was named `hello`
which is quite confusing since `"hello"` is actually the string that
is bound to `greeting`.
This fixes a major issue in arm 32bits, detected by ubsan, where
conversion of type to milliseconds results in overflow.
```
rktio_time.c:92:21: runtime error: signed integer overflow: 1584975753 * 1000 cannot be represented in type 'long int'
```
GCC 9.3 things that `h2` might reach line 385 uninitialized.
```
./hash.c:385:14: warning: 'h2' may be used uninitialized in this function [-Wmaybe-uninitialized]
385 | h = (h + h2) & mask;
| ~~~^~~~~
```
After a reduction like (pair? (list <x> <y>)) => (begin (list <x> <y>) #t) make a semi-shallow
reduction of the argument, so it is further reduced to (begin <x> <y> #t) and even remove <x> or <y>
if they have no side effects.
original commit: fe085761cbd200f4c67025d968d6d1418ab7d3e7
A Chez Scheme garbage collection involves a rendezvous among threads
that are used to implement places and futures (and potentially other
things that create Chez-level threads). The thread that is used to
drive the garbage collection was not formerly specified, and callbacks
like the GC icon in DrRacket can only be run in the initial thread.
When a major collection was run in a non-initial thread, the callback
was simply skipped.
The Racket branch of Chez Scheme now drives a collection in the
initial thread whenever that thread is active. In Racket CS, the
initial thread can be inactive if it's waiting for external events,
and a place can meanwhile trigger a GC. Now, when the Racket CS GC
callback is called for a major collection in any thread other than the
initial one, it defers the major collection to an asynchornous
callback in the main thread (and meanwhile performs a minor
collection).
So, a major collection might now be delayed by just a little while if
the main thread is inactive, such as when it's waiting for external
events, but callbacks like the GC icon in DrRacket will be reliably
invoked for major collections.
