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.
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.
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.
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.
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
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.