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.
- A part of contract-out's code generation for struct assumes that
there's no parent struct and uses the provided struct name for
everything. This causes duplicate definitions when there are duplicate
field names where one is in a child struct and another is
in a parent struct. This PR fixes the problem.
- Disallow multiple #:omit-constructor
- Deprecate super-id. This information is unnecessary since we can
extract it from static struct information already. Attempting to
check that super-id is well-formed is error-prone due to how
the super struct type could be contracted which shields us from
detecting that they are indeed the super type.
- Utilize static struct field name information, and provide
the information when exporting a struct.
This PR is largely based on #732.
Fixes: #3266, #3269, #3271, and #3272
