Inline only trivial functions, such as `(empty? x)' -> `(null? x)',
to avoid generating too much code.
Bytecode includes a new `inline-variant' form, which records a
version of a function that is suitable for cross-module inlining.
Mostly, the variant let the run-time system to retain a copy
of the bytecode while JITting (and dropping the bytecode of)
the main variant, but it may be different from the main variant
in other ways that make it better for inlining (such a less loop
unrolling).
Related to the already fixed PR 12114 and PR 12133, which motivated the
error, and a few additional typos of the same kind.
(Note that it uses the symbols, but that's how they'll render anyway.)
Although the ".plt" format is going to be replaced, the format is
currently viable for distributing collections, and I have wanted
a raw `unpack' command for a while. It was useful today to fix
problems with `raco pack' and collection links.
The JIT and bytecode compiler disagreed on the definition of
"constant". Now there are two levels: "constant" means constant across
all instantiations, and "fixed" means constant for a given instantation.
The JIT uses this distinction to generate direct-primitive calls
or not. (Without the distinction, a direct jump to `reverse' could
be wrong, because `racket/base' might get instantiated with the
JIT disabled or not.)
Also, fixed a bug in the JIT's `vector-set!' code in the case that
the target vector is a top-/module-level reference that is ready,
fixed, or constant.
managed-compile-zo
make-caching-managed-compile-zo
make-compilation-manager-load/use-compiled-handler
that gets used when compiled files, dep files, and compiled/ directories are created.
`setup/private/path-utils'.
The API is a little different: instead of getting the alist and the
path, there's a curried function that gets the alist and produces a
function to do the substitutions.
`setup/path-relativize'.
`setup/path-relativize' is freed from a bunch of things that were due to
historical baggage, but some remain. (Also, update its docs.)
I originally picked "under" as the preposition to go before
a platform name, but obviously you should build "on" a
platform, and "under" suddenly annoys me. The choice of "on"
is now codified in the documentation style guide. Meanwhile,
"Unix" insted of "X" seems more clear and consistent in the
`racket/gui' docs.
More usefully, this patch also fixes a few out-of-date
platform-specific claims.
- 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.
