Checking that the optimized and non-optimized versions return the same
results is unnecessary. Optimization logs, which are checked against
an expected log, already contain the results.
(that is, I think that the complaints coming from the
tests\deinprogramm\test-docs-complete.rkt message are
now pointing out things for which there is actually no
documentation, instead of pointing out the need for
different declare-exporting declarations)
- the `lam' structure from `compiler/zo-struct' changed to include a
`toplevel-map' field
This change helps solve a finalization problem in `racket/draw',
which in turn sigificantly reduces the peak memory use of `raco setup'
during the doc-building phase (because some documents load `racket/draw'
to render images, and multiple copies of `racket/draw' were retained
before finalization was fixed).
The change is an extreme way to solve a specific finalization
problem, but it's a kind of space-safety improvement; space safety
almost never matters, but when it does, then working around a lack of
space safety is practically impossible. In this case, it's not clear
how to otherwise solve the `racket/draw' finalization problem.
The improvement doesn't change the representation of closures, but it
requires special cooperation with the GC. All closures in a module
continue to share the same array of globals (plus syntax objects);
that is, instead of completely flat closures, Racket uses a two-level
environment where top-/module-level variables are grouped
together. The code half of a closure now records which
top-/module-level variables the body code actually uses, and the mark
phase of GC consults this information to retain only parts of the
top-/module-level environment frame that are actually used by some
closure (or all of the frame if it is accessible through some other
route). In other words, the GC supports a kind of "dependent
reference" to an array that is indexed by positions into the array
--- except that the code is more in the "Racket" directory instead of
the "GC" directory, since it's so specific to the closure
representation.
