Since `#%app` (used where an applicable structure might show up)
injects its own `procedure?` test and makes sure that that a procedure
is returned to the function position of the application, use `#3%$app`
to make Chez Scheme suppress a redundant `procedure?` check for the
appliction.
It's not clear that a thread can be descheduled without the current
thread's work counting as progress, but a descheduled thread certainly
shouldn't coun as a no-progress scheduled thread.
Only one instance of each callback is needed. Allowing them to pile up
is inefficient, and possibly it can trigger a reaction that causes
even more to pile up.
(for ([x (in-value 1 2)]) x)
should raises a run time error, not a syntax error.
Fix similar error in other in-something macros.
Fix name of in-directory, when used as a function outside a for.
Unfortunately, MZ_NORETURN spec is causing a few problems - see #2808
It would be great to fix these but due to lack of time, this is a
workaround that should keep things working until all supported
configurations accept MZ_NORETURN properly.
Ensure that floating-point registers used for arguments and results
are preserved while activating or deactivating a thread.
original commit: 1118aef3496943287323a0e83e53c55284239d66
Include an extra part in the Chez Scheme version number, which both
helps indicates the Racket fork and versions it.
original commit: 00678e29bb9f05de2ccaec8585126e967cdcc6f4
Use `call-consuming-continuation-attachment` to implement
`with-continuation-marks`, because that avoids duplicating
a set of checks when in tail position.
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
Looking at `bytes-allocated` usually works, but sometimes lets
memory use spiral out of control. Looking at `current-memory-bytes`
is more reliable, but still makes peak memoy use too high.
Combining those values doesn't limit the peak well enough.
Try the more obvious (in retrospect) approach of comparing
`bytes-allocated` changes and `current-memory-bytes` changes
separately, and triggering a GC if either grows enough.
Commit 1811193285 caused Racket CS to have much higher peak memory
use. Adjust the heuristic again to trigger a major GC when the
`current-memory-bytes` value is the post-GC `bytes-allocated` plus the
post-GC `current-memory-bytes`, which means waiting until
another `bytes-allocated` bytes are allocated (instead of waiting
until the number of newly allocated bytes also catches up to overhead,
such as unserused pages due to locked objects).
Implement a parameter as a Chez Scheme wrapper procedure,
instead of an applicable record. A wrapper procedure can be
applied more directly, saving 10-20% of the time for some
parameter lookups.
The grammar for pregexps includes:
| \p{‹property›} Match (UTF-8 encoded) in ‹property›
| \P{‹property›} Match (UTF-8 encoded) not in ‹property›
and <property> is defined as:
‹property› ::= ‹category› Includes all characters in ‹category›
| ^‹category› Includes all characters not in ‹category›
That is to say, there are two independent ways to negate one of
these character classes. The Racket implementation of regexps
(as opposed to the C implementation) does not recognize negated
categories. This PR fixes that.
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
Some parts of the GC meant to traverse all objects on a page of
'atomic-interior or 'interior objects used "<" to detect the end of
the page, but "<=" was needed. As a result, things could sometimes go
wrong for the last object on a page for platform and size combinations
where the last object ends exactly at the end of the page.
This change consistenly computes the iteration end in a way that makes
both "<" and "<=" work.
Using MPFR bindings from the `math` library could trigger a problem
(but it's difficult to provoke the problem in a reasonably small
example --- difficult enough that I couldn't do it).
