Also, add `current-directory-for-user' and `srcloc->string', and
adjust the way that source-location paths are reported to be
relative to `current-directory-for-user'.
When starting a thread, the thread was created and partially
initialized before trying to get a name for the thread from the given
thunk, but getting a name for the thunk could trigger scheduler
descisions, which could get confused by the partially initialized
thread.
Creating a stand-alone executable could slow down a program,
because bytecode embedded in an executable was not treated
in the same way as bytecode loaded from files. The difference
was in on-demand parsing of bytecode --- and now it's enabled
for embedded bytecode, too.
The revised `explode-path' runs in time proportional to the
length of the path, instead of quadratic in the number of
path elements. The difference doesn't matter much in my
program, but I'm reluctant to leaving the implementation
as quadratic (which is forced by using `split-path').
The `#%module-begin' of `racket/base' and `scheme/base' now introduces
a suitable `configure-runtime' submodule, instead of using the
`module->language-info' path.
A submodule is a lot easier to work with, as illustrated by the
removal of the `racket/private/lang' and `scheme/private/lang'
languages.
Also, add `#%printing-module-begin', which is the old `#%module-begin'
(i.e., the one that doesn't introduce a `configure-runtime' submodule).
A language can now introduce a `configure-runtime' submodule that
is `dynamic-require'd before the enclosing module.
This new submodule protocol provides a more general and
easier-to-understand way of configuring the run-time environment for
a module's language, as compared to the `module->language-info'
path (through a `get-info' function, via a 'configure-runtime value,
and finally loading the specified module).
The `module->language-info' path remains in place, and it is
checked after a `configure-runtime' submodule is run, since
that order is likely to be the most backward compatible.
If a function is bound by a `letrec' (or internal definition)
that cannot be simplified to `let' or lifted to a constant or
top-/module-level function, and if the `letrec' binding is used in
a non-application position, and if the function has in its closure
a typed binding (i.e., boxed, fixnum, flonum, or extflonum),
then the validator was incorrectly rejecting the function's
bytecode --- because the validator didn't distinguish between typed
arguments and typed closure content.
File under "surprised that we didn't hit this one earlier".
Stress mode forces a GC on every N allocation attempts, and it makes
JIT-generated code always take a slow path.
This mode uncovered only a bad test case and some boring start-up
bugs (boring because start-up is deterministic enough that they
never happen), so far.
The safe-for-space pass could add clearing operations on "typed"
stack positions, which are known to contain a fixnum, flonum, or
extflonum. Non-clearing references, however, were not annotated to
indicate that clearing references were present, since clearing is
not expected on typed positions.
Along the lines of not expecting clearing, the bytecode validator's
encoding of the stack doesn't accomodate both "has a type" and "claims
never to be cleared", so it couldn't detect the bytecode compiler
bug. (Also, this problem didn't show up in the HOSC paper's model of
the validator, because the model pre-dates type tracking.)
Fix the bytecode compiler's space-safety pass so that it never inserts
clearing operations for typed stack positions. Then, the validator can
simply reject any attempt to clear a typed position.
Also, annotate applications generated by lifting as safe-for-space
tail calls.
Merge to v5.3.4
