Load the debug information during runtime startup if OCAMLRUNPARAM=b=2.
This guards against the specific case of running out of fds, since the
debug information can't then be loaded.
Instead, we use a thread-local variable [callback_status] which
contains the index of the corresponding entry when a callback is
running. We can do this since there can only be one running callback
at the same time in a given thread.
This lifts the restriction forbidding the call of Thread.exit from a
memprof callback.
This is done by using a local entry array for each thread, containing
tracked blocks whose allocation callback has not yet been called.
This allows some simplification in the code running callbacks for
young allocations. Indeed, since the entry array is local to one
thread, we know for sure that it cannot be modified during a callback,
and therefore we no longer need to remember the indices of the
corresponding new entries.
In the old days, the interfaces of the labeled modules
(ArrayLabels, BytesLabels, ListLabels, StringLabels)
started with short examples of labelings.
Now, the interfaces of the non-labeled modules
(Array, Bytes, List, String) are automatically generated
from the interfaces of the labeled modules. As a side effect,
the interfaces of Array, Bytes, List and String also start
with short examples of labelings, which is somewhat strange.
This commit reorganizes the documentation as follows:
- The documentation of the StdLabels module is expanded, and includes
the examples of labeled functions previously scattered in
ArrayLabels, BytesLabels, ListLabels, StringLabels.
- Array, Bytes, List, String and their labeled counterparts
briefly mention the labeled modules and point to StdLabels,
but no longer contain examples.
The Spacetime memory profiler is not going to be supported in Multicore OCaml, and is already broken by some of the related changes in OCaml 4.12. The core development team decided to remove Spacetime support from OCaml 4.12.
This is selected at configure-time, option --enable-naked-pointers-checker.
The major GC warns when it detects out-of-heap pointers that could cause the no-naked-pointers runtime system to crash.
This is supported on x86-64 only, but on all ports (Unix and Windows).
Added tests involving naked pointers in tests/runtime-naked-pointers
Co-authored-by: KC Sivaramakrishnan <kc@kcsrk.info>
Co-authored-by: David Allsopp <david.allsopp@metastack.com>
Co-authored-by: Enguerrand Decorne <decorne.en@gmail.com>
`List.equal f foo bar` is nicer than
`List.length foo = List.length bar && List.for_all2 f foo bar`.
Note: with List.compare there is a risk of users having opened the
List module, and then using 'compare' from the stdlib unqualified. For
example:
List.(sort compare foo bar)
Such code will break (type error), and has to be fixed by using
Stdlib.compare. Stdlib is available since OCaml 4.07; people wishing
to support both 4.12 and older releases would have to avoid opening
List, or rebind 'compare' locally.
```ocaml
val left : 'a -> ('a, 'b) t
val right : 'b -> ('a, 'b) t
val is_left : ('a, 'b) t -> bool
val is_right : ('a, 'b) t -> bool
val find_left : ('a, 'b) t -> 'a option
val find_right : ('a, 'b) t -> 'b option
val map_left : ('a1 -> 'a2) -> ('a1, 'b) t -> ('a2, 'b) t
val map_right : ('b1 -> 'b2) -> ('a, 'b1) t -> ('a, 'b2) t
val map : left:('a1 -> 'a2) -> right:('b1 -> 'b2) -> ('a1, 'b1) t -> ('a2, 'b2) t
val fold : left:('a -> 'c) -> right:('b -> 'c) -> ('a, 'b) t -> 'c
val equal :
left:('a -> 'a -> bool) -> right:('b -> 'b -> bool) ->
('a, 'b) t -> ('a, 'b) t -> bool
val compare :
left:('a -> 'a -> int) -> right:('b -> 'b -> int) ->
('a, 'b) t -> ('a, 'b) t -> int
```
Unlike [result], no [either] type is made available in Stdlib,
one needs to access [Either.t] explicitly:
- This type is less common in typical OCaml codebases,
which prefer domain-specific variant types whose constructors
carry more meaning.
- Adding this to Stdlib would raise warnings in existing codebases
that already use a constructor named Left or Right:
+ when opening a module that exports such a name,
warning 45 is raised
+ adding a second constructor of the same name in scope kicks
in the disambiguation mechanisms, and warning 41 may now
be raised by existing code.
If the use becomes more common in the future we can always
revisit this choice.