Perform slightly less work on every fasl or unfasl of compiled code
that does not need to support `concatenate-object-files`.
original commit: 410985b062a3e2a4cc48da583167254d4adad2d2
Sync with changes from cisco/ChezScheme. The specific code fragments
that are compressed and the chunks that are used for compression
remain essentially the same as before for Racket CS, but a different
organization at the Chez Scheme level takes over some of the work that
was on the Racket CS linklet layer, and load times may improve
slightly.
Merge changes in the way that fasl streams are compressed. The new
approach makes compression explicit in the fasl representation, which
means that tricks like uzing zcat on a fasl file will no longer work
(at least not efficiently).
original commit: 167ac7294a2dc400821e4336f0cfc4de621efe97
This first cut is heavy on describing how backends work, because
that's fresh in mind and relevant to ongoing effort.
original commit: 964ce95dc910e6c1825b341bf05492af5903cc82
Commit 88d57da163 incorrectly merged, because the syntax of `mref` has
changed to support unboxed floating-point arithmetic.
original commit: a8eeb536aecc0e0a363aa68d43edafa7d6c9df52
In CS, if you interrupt an especially tight non-tail recursion, such
as
(let loop ()
(cons 1 (loop)))
then the "context" view of the continuation (as recorded in a
continuation mark set) can take space that is a multiple of the size
of the continuation itself. That's a particular problem if the
too-deep recursion triggers the memory limit in DrRacket, because
DrRacket will then need a multiple of its current heap space to report
"out of memory".
(Note: Just keeping the continuation itself is not a good option,
because that may retain other data referenced by the continuation.)
This commit reduces the heap space used to gather a continuation
context, relying in part on new Chez Scheme support, but mostly it
limits the context length to roughly the same maximum as in BC. The BC
limit is an implementation artifact, but it turns out to have good
properties; informaiton on more than 64k continuation frames is rarely
useful. The limit could be a parameter, but a large built-in limit
seems likely good enough.
(Another note: Adding a limit argument to
`continuation-mark-set->context` doesn't help enough, because it's too
late by that point; too much memory has been used to repersent the
information that's in the mark set.)
The commit also tightens tracking of continuations for memory
accounting, reducing the chance that a thread's large continuation
will be charged to the wrong custodian.
samth said "I don't think the Friendly Environment policy should be thought of as part of copyright issues, or applying only to people who contribute code. Is there a different phrasing that would accomplish what you want here?" I have rephrased the reference to the Friendly Environment Policy and moved it before the License section to avoid confusion with copyright issues.
