Implement 'atomic-interior allocation and immobile cells using
`make-immobile-bytevector` and `make-immobile-vector`, which avoids
having to unlock through a finalizer.
Also, the Chez Scheme GC can now mostly mark a major generation,
instead of copying it, which can significantly reduce memory
use during a GC for an old, large heap (such as DrRacket's).
Show peak administrative as a parenthesized delta on peak space.
For BC, this extra delta is small, because BC compacts (instead of
copying) old-generation objects. For CS, the extra delta can large ---
typically an extra 50%, but potentially another 100% --- because a
full collection copies all old-generation objects.
Also, for BC, fix cumulative-allocation reporting to include child
places.
Extract invert_limb code for ARM from GMP 6.2.
In order to check for thumb mode availability use defined macro `__thumb__`, which in turns requires us to process the source file with `gcc` instead of `as` in order to access the preprocessor - tested with `clang` as well.
Fixes#3050
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.
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.
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;
| ~~~^~~~~
```
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.
It's still unclear what the specification of syntax->string regarding whitespace
before closing parens should be. The implementation also has not dealt with
the issue. This PR therefore removes whitespace before closing parens from
the tests.
Once the discussion at
https://github.com/racket/racket/issues/3071#issuecomment-601984438
has reached a conclusion and implemented, we can add these tests back.
