Changes

New representation of closures, bytecode part

Add a "closure information" field after each code pointer in
a closure.  This field generalizes the "arity" field used by
the native-code compiler, in that it has room both for an arity
(always 0 in bytecode) and for the distance from the closure
to the first environment variable in the closure block.

This makes closures "self-described" and easy to scan for pointers:
everything up to the first env var is out-of-heap code pointers or
integers; everything after the first env var is a well-formed value.

At this point a bootstrap is needed.
 (commit: 9e12857)

New representation of closures, intermediate bootstrap

ocamlc's computations of offsets in closures changed to match changes in the
abstract machine.
 (commit: a1f2166)

New representation of closures, native-code compilation

In code that builds closures, instead of the old arity field,
produce a closure information field encoding arity + position of environment.
 (commit: 7f5a137)

Restrict 'test_locations' to 64-bit archs and update expected outputs

Expected outputs contain integer values for the "closure info"
field of some closures.  These values differ in 32 and 64 bits,
since the arity is stored in top 8 bits.  This test would need
different expected outputs for 32- and 64-bit platforms.

To keep things simple, this commit restricts the test
to only run on 64-bit platforms.  Since this changes the locations
 (commit: e577855)

During major GC, scan the environment part of closures only

Here we start reaping the benefits of the new closure representation.

The fields of a closure block that contain the code pointers need not
be scanned (in general) and must not be scanned (in no-naked-pointers mode).

Here, conservatively, we skip them in no-naked-pointers mode only,
but it would be sound to skip them unconditionally.
 (commit: 843ec62)

Give preallocated atoms the GC color Black

Atoms are zero-sized blocks allocated outside the heap.
It simplifies the GC in no-naked-pointers mode if their headers
have GC color Black, meaning "don't traverse".
In ocamlopt, Black is already used as the color for constant blocks
statically allocated outside the heap.
 (commit: 121dbb9)

No need to special-case zero-sized blocks in no-naked-pointers mode

Now that atoms have black headers, all zero-sized blocks (atoms or
ocamlopt-generated static data) have black headers and will not
be traversed or changed by the major GC.
 (commit: 85f5006)

Changes entry for #9619
 (commit: 59da229)

Limit the number of parameters for an uncurried or untupled function (#9620)

This commit introduces a quantity Lambda.max_arity that is the maximal
number of parameters that a Lambda function can have.

Uncurrying is throttled so that, for example, assuming the limit is 10,
a 15-argument curried function fun x1 ... x15 -> e
becomes a 10-argument function (x1...x10) that returns a 5-argument
function (x11...x15).

Concerning untupling, a function that takes a N-tuple of arguments,
where N is above the limit, remains a function that takes a single
argument that is a tuple.

Currently, max_arity is set to 126 in native-code, to match the new
representation of closures implemented by #9619.  A signed 8-bit field
is used to store the arity.  126 instead of 127 to account for the
extra "environment" argument.

In bytecode the limit is infinity (max_int) because there are no needs
yet for a limit on the number of parameters.
 (commit: 4aa90e9)