Increemntal GC skips the old-generation compaction phase.
For most applications, that's ok, but it's possible for
fragmentation to get out of hand. Detect that situation
and fall back to non-incremental mode for one major GC.
Memory accounting is enabled on demand; if demand goes
away --- as approximated by no live custodians having
a limit or previously been queried for memory use ---
then stop accounting until demand resumes.
Fix the case that an old-generation finalizer ends up
on a modified page after all old-generation marking
is complete.
Also, make sure epehemerons are checked after previous
marking that may have left the stack empty.
The allocation strategy for immobile objects avoids some fragmentation
in non-incremental mode, but it interferes with finishing up an
incremental major collection, so trade some fragmentation for
an earlier finish (which is far more likely to use less memory
instead of more, despite extra fragmentation).
Really, just improve when majors GCs are forced to trigger
further finalizations. This improvement makes `(collect-garbage)`
followed by `(collect-garbage 'incremental)` move more
reliably into incremental mode.
When `(collect-garbage 'minor)` is combined with incremental
mode, do less incremental work. At the same time, don't
skip an incremental GC just because a major GC is ready.
Although calling `(collect-garbage 'incremental)` in a program with
a periodic task is the best way to request incremental collection, it's
handy for some experiments to have an environment variable that turns
it on permanently.
This change also makes incremental-mode minor collections log as "mIn"
instead of "min", and it changes the first field of the logged
`gc-info` structure to be a mode symbol instead of a boolean.
Incremental GC now works well enough to be useful for some programs
(e.g., games). Memory accounting is still not incremental, so DrRacket
(and running programs in DrRacket) does not really support incremental
collection, although pause times can be much shorter in incremental
mode than by default.
This step is semi-incremental, in that it can happen during
incremental collection, but all finalization is performed at once.
This will work well enoguh if the number of finalizers, weak boxes,
etc., will be small enough relative to the heap size.
Casting a `uintptr_t` to `double` seems not to round to
nearest, so keep all bits while moving to `double` and
use arithmetic to combine them (since the rounding mode
is used correctly for arithmetic).
The strategy of converting a bignum to a flonum by converting on word
boundaries can lose one bit of precision. (If the use of a word
boundary causes a single bit to get rounded away, but the first bit of
the next word is non-zero, then the rounding might have been down when
it should have been up.)
Avoid the problem by aligning relative to the high bit, instead.
Fix even basic readind when extflonums are not supported, but
also fix reading extflonums with large exponents (related to
the other recent changes to number parsing).
Allow a more dynamic (than `impersonator-prop:application-mark`)
determination of continuation marks and associated values to wrap the
call of an impersonated procedure.
When an internal-definition context is used with `local-expand`, the
any binding added to the context affect expansion, but the binding do
not appear in the expansion. As a result, Check Syntax was unable to
draw an arrow from the `s` use to its binding in
(class object%
(define-struct s ())
s)
The general solution is to add the internal-definition context's
bindings to the expansion as a 'disappeared-bindings property. The new
`internal-definitionc-context-track` function does that using a new
`internal-definition-context-binding-identifier` primitive.
Mishandling of the `require`-binding table could cause
`racket/private/pre-base` to export `andmap` as syntax, for example,
instead of as a variable. The syntax-versus-variable distinction
doesn't usually matter, but it affects the order of exports in
bytecode form.
Even though `dynamic-require` might lead to loading source, the
path into the compiler for that source will force compile-time code
as needed.
One benefit of ths change is that `racket -l pict3d` takes about half
as long, because `racket/gui` includes a `dynamic-require` to load a
platform-specific back-end, while `pict3d` can pull in a lot of
compile-time code to cooperate with Typed Racket.
Getting NULL from CTFontCollectionCreateMatchingFontDescriptors()
might indicate a font installation problem; I'm not sure. In any case,
checking for NULL avoids a crash on at least one installation.
This bug is already fixed in the Cairo source repo, so we
can discard the patch on the next Cairo upgrade.
It's not clear which platforms are affected. On OS X, at least,
writing to a global constant can cause a crash.
Thanks to Spencer for making a small example that triggers the bug
(added to the "draw-test" package).
