Although a future thread used an atomic compare-and-swap to
set "is a list" or "not a list" flag on pairs via the
JIT-implemented `list?', the hashing function in the runtime
thread did not; as a result, it might be possible to lose
a hash code due to cache inconsistency (although I'm not
sure it's actually possible, and I couldn't trigger a problem
with a test). Most of the changes are related to using
an atomic compare-and-swap when setting a hash code, as
well as clean-ups to related code. Processor-count tests
avoid using atomic compare-and-swap on uniprocessors, which
might not support the relevant machine instructions.
As significantly, the compare-and-swap operation for the
JIT-implemented `list?' did not actually set flags on
a pair that has a hash code. This could lead to `list?'
tests that were not constant time (but only if the relevant
pair's `eq?' hash code had been used previously).
Unlike syntax, pseudo-syntax is serializable, and it only carries the
information that Performance Report needs. Serializability is
necessary to be able to expand the program inside a sandbox and get
log entries out.
The DrRacket expansion functions don't offer anything more than plain
expand + a sandbox, and using them made the code less readable.
This reverts commit 96eee2b317.
This reverts commit 19ce4d44a5.
This reverts commit 58fbd8ba75.
This reverts commit b305ea9c62.
This reverts commit 860feb30ae.
* a single function to set up all environment parameters.
* improve `getarg's treatment of default thunk
* Add an error display handler that doesn't show the context and instead
add a ,bt command to show it.
With the JIT, the `reverse' function is significantly faster,
while the `member' variants do not really change; the main
benefit is that the operations play well with futures.
The C implementation is still used when the JIT is unavailable,
since the Racket implementations can be much slower in
interpreted mode.
