caml_input_value_from_string (unused since e227fb007d)
caml_ml_flush_partial, caml_ml_output_partial (unused since 705054b3)
caml_obj_is_block (unused since b1f93a66)
* Introducing codefrag: a new runtime module to work with code fragments
This module collects all the operations on code fragments performed in
various places of the runtime systems. Applies both to bytecode and
to native code.
The implementation is based on skiplists, so that "lookup fragment by
PC" and "lookup fragment by number" are efficient (logarithmic in the
number of code fragments). "Lookup fragment by digest" remains
linear-time.
The new module also improves the handling of digests: now it is
possible to mark a code fragment as "no digest" i.e. not marshal-able.
* Use the new "codefrag" runtime module for marshaling and for the
debugger interface
Replace the previous handling of code fragments with calls to the
functions provided by the "codefrag" runtime module.
Introduce caml_process_pending_actions and
caml_process_pending_actions_exn: a variant of the former which does
not raise but returns a value that has to be checked against
Is_exception_value.
I keep the current conventions from caml_callback{,_exn}: For a
resource-safe interface, we mostly care about the _exn variants, but
every time there is a public _exn function I provide a function that
raises directly for convenience.
They are introduced and documented in caml/signals.h.
Private functions are converted to their _exn variant on the way as
needed: for internal functions of the runtime, it is desirable to go
towards a complete elimination of functions that raise implicitly.
Get rid of the distant logic of caml_raise_in_async_callback. Instead,
caml_process_pending_events takes care itself of its something_to_do
"resource". This avoids calling the former function in places
unrelated to asynchronous callbacks.
In 8691, caml_check_urgent_gc was merged with the function that runs
asynchronous callbacks. The rationale was that caml_check_urgent_gc
already runs finalisers, and so could have run any asynchronous
callbacks.
We agreed on a different strategy: we know that users could not rely
on asynchronous callbacks being called at this point, so take the
opportunity to make it callback-safe, like was done for allocation
functions.
The new check_urgent_gc no longer calls finalisers (nor any
callbacks), and instead two internal functions are introduced:
* caml_do_urgent_gc_and_callbacks : function to perform actions
unconditionally.
* caml_check_urgent_gc_and_callbacks : function that checks for
something to do, and then executes all actions (GC and callbacks).
Allocations ignored by this version
- Marshalling
- In the minor heap by natively-compiled OCaml code
Allocations potentially sampled
- In the major heap
- In the minor heap by C code and OCaml code in bytecode mode
Adds a new marshal code CODE_CUSTOM_LEN, which stores the lengths
(for both 32- and 64-bit) of each marshalled custom block. The
marshaller only uses CODE_CUSTOM_LEN, but the unmarshaller still
understands CODE_CUSTOM (So, old files still unmarshal, but new ones
don't work on old versions).
This allows the unmarshaller to know exactly how much memory is
needed before calling a custom `deserialize` function.