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
A constant result for foreign-thread use of a callback allows a
callback to return without synchronizing with the Racket thread.
A constant result is thus useful when a callback's work can simply
be skipped if the callback is applied in the "wrong" OS thread.
Bug introduced by 7a8c2ff063: a tree can be deep enough that the
representation of the path to the current item can be too big to
fit into 32 bits. It will always fit in 64 bits, though.
Merge to 5.3.4
These exception types are intended as a hook for a programming
environment to recommend packages that can provide a module that isn't
found (through an uncaught-exception handler). The new exceptions are
generated by the default module name resolver and defaultload
handler. In addition to the exceptions, there's a new
`prop:exn:missing-module' property and `exn:missing-module?', which is
what an environment should use to detect relevant exceptions.
There's also a new `current-module-path-for-load' parameter, which
just provides a commuincation path from the module name resolver to
the the load handler. The parameter is a relatively ugly piece of the
puzzle, but it's the best I could find to squash the new functionality
into the existing stack of handlers.
Fix a problem at the boundary of DWARF-driven backtrace
and frame-driver backtrace, as well as handling of the
JIT's different internal calling conventions.
Also, allow crossing back from frame-driven to DWARF-driven.
... when PWD is defined and when it refers to the same directory
as the result of getcwd().
A shell sets PWD before starting Racket to communicate a preferred
way of referring to the current directory, which may involve soft
links that are not reflected in getpwd().
With this patch racket will never grow beyond of the defaults limits of
the OS and also it doesn't limit the stack size to a fixed value.
Merge to v5.3.4
The output of "/proc/cpuinfo" seems wrong for a Raspberry Pi running
the latest Raspian, because it claims ARMv6-compatible but also claims
"thumb" as a feature and 7 as the CPU architecture. Use the C compiler's
configuraton, instead, which is relatively straightforward and drops
code that will turn out to be dead.
In a minor collection, old-generation pages can be ignored for
the fixup pass. Also, the "moved" bit implies the "marked" bit.
Also, move the mark bits to low and the hash bits to high,
which leads to slightly better generated code for the GC.
The validator was not as smart as the compiler in determining
that a `let' expression could be relied on to produce a
constant-shaped function (without side effect or error) in the case
that a right-hand side expression is a call to a known structure
constructor or predicate.
Closes PR 13679
Merge to v5.3.4
