Track fixnum results in the same way as flonum results to enable
unboxing, if that turns out to be useful. The intent of the change,
though, is to support other types in the future, such as "extnums".
The output `raco decompile' no longer includes `#%in', `#%flonum',
etc., annotations, which are mostly obvious and difficult to
keep in sync with the implementation. A local-binding name now
reflects a known type, however.
The change includes a bug repair for he bytecode compiler that
is independent of the generalization (i.e., the new test case
triggered the old problem using flonums).
This appears to be an old bug where a check and use are misordered, so
I'm not sure why it hasn't caused more trouble before, but it depends
on a GC happening at the right time.
Closes PR 13245
The JIT was pessimistically using 64-bit jumps for long branches
or any jump between code that is allocated at different times.
Normally, though, code allocation stays within the same 32-bit
range of the heap, so stick to 32-bit jumps until forced by
allocation addresses to use 64-bit jump targets.
In `(if (pair? x) E1 E2)', convert `(car x)' in E1 to
`(unsafe-car x)', and similarly for `(cdr x)'. Also,
`(begin (car x) (cdr x))' converts to `(begin (car x)
(unsafe-cdr x))' since `(car x)' implies a `pair?' test
on `x'.
More consistent clearing avoids a kind of space unsafety. There's just
one buffer per thread, so it's difficult to turn non-clearing into
a detectable leak (I wasn't abel to construct an example), but it
might be possible. More practically, failing to clear the buffer
can make it difficult to debug memory use.
The scheme_is_multiprocessor() function wasn't the right guard
for whether to use a locking compare-and-swap instruction; any
use of pthread-based futures needs the compare-and-swap.
Merge to v5.3.1
This change doesn't speed up anything, so far. GC performance
of pairs (or anything) is determined almost completely by
its size in bytes, and this change doesn't affect the size of
pairs. At the same time, the change mostly replaces the obsolete
"xtagged" support, and I might have a better idea that builds on
this change, so I'm keeping it for now.
Shape information allows the linker to check the importing
module's compile-time expectation against the run-time
value of its imports. The JIT, in turn, can rely on that
checking to better inline structure-type predicates, etc.,
and to more directy call JIT-generated code across
module boundaries.
In addition to checking the "shape" of an import, the import's
JITted vs. non-JITted state must be consistent. To prevent shifts
in JIT state, the `eval-jit-enabled' parameter is now restricted
in its effect to top-level bindings.
This tracking allows the compiler to treat structure sub-type
declarations as generating constant results, and it also allows
the compiler to recognize an applications of a constructor or
predicate as functional.
The JIT takes advantage of known-constant bindings to avoid the
check that a variable is still bound to a structure predicate,
selector, or mutator; that makes the code short enough to really
inline. The inlined version takes about half the time of the
indirect version.
The compiler does not yet track bindings precisely enough to
recognize constants for sub-type declarations.
Turn use of a finalized ffi callout into a reported error,
instead of a crash. Clarify the existence of the finalizer
in the docs. Fix error logging of the finalizer thread.
Merge to v5.3.1
Bytecode changes in two small ways to help the validator:
* a cross-module variable reference preserves the compiler's
annotation on whether the reference is constant, fixed, or other
* lifted procedures now appear in the module body just before the
definitions that use them, instead of at the beginning of the
module body
The new argument gets to chaperone/impersonate a guard at
the prompt, and it is applied when the continuation is applied ---
based on a wrapper on th prompt tag of the continuation (as opposed to
the prompt tag of the prompt).
The new argument gets to filter results that come from a
non-composable continuation that replaces one delimited
by a prompt using the chaperoned/impersonated prompt tag.
For simple structure types (no guards, no auto fields, no
procedure property). Inlined allocation makes structure
allocation a little faster; more significantly, it
make structure allocation future-safe.
When thie JIT guesses that an identifier is bound to a
structure predicate, getter, setter, etc., but that guess
turns out to be wrong, and the call is in a tail position,
then preserve tail-call behavior.
(Changes include some setup to inline structure constructors.)
Avoids a common problem with libffi installed by MacPorts
causing problems with a mismatch between an iconv installed
by MacPorts and the system iconv. (When libffi is installed,
then -I/opt/include for the libffi heads also picks up the
iconv headers, but the ordering of the lib flags doesn't
pick up libiconv from /opt/lib. We could try to hack around
this by ordering the flags just right, but it seems better
to avoid the issue.)
JIT-generated doesn't actually conform to the constraints
of the Win64 stack-unwind protocol. In pariticular,
JITted code might move the stack pointer after a "preamble"
that saves non-volatiles, and the frame pointer isn't in
the right place. So, we can't implement the generic unwind
hook --- but the JIT's stack traversal can interleave its own
unwinding with the OS-supplied unwinding interface.
The new parameter (and supporting environment variables and
command-line flags) can bytecode lookup to a tree other than
where a source file resides, so that sources and generated
compiled files can be kept separate. It also supports storing
bytecode files in a version-specific location (either with
the source or elsewhere).
Clients of scheme_apply(), scheme_eval(), etc. (i.e., the variants
without a leading "_") except aborts to continue jumping out, while
a recent change to make them behavior more like a default prompt
handler caused them to return on errors. Changethe handler to behave
like the default, except that after running a result thunk, the
handler effectively aborts again.
The `make-log-receiver' function now includes a logger-name
filter. This filter is implemented as a low enough level that
it affects `log-level?' tests to check whether a log message
needs to be constructed at all.
The -W and -L flags and PLTSTDERR and PLTSYSLOG environment variables
support filters of the form "<level> <level>@<name> ...", where
<level>@<name> specializes filtering of events for a logger whose
name matches <name> to show <level> and higher.
The old `cast' didn't work right for a mismatch between
a pointer GCableness and the source or target types, and
it didn't work right for an GCable pointer with a non-zero
offset. While those pitfalls were documented, the first
of them definitely has been a source of bugs in code that
I wrote.
Also added `cpointer-gcable?'
