With this commit, it becomes possible to provide C compiler and preprocessor
flags to use in addition to those defined by the build system.
As required by the GNU coding standards, the flags can be provided
either at configure or at make invocation.
The provided CFLAGS and CPPFLAGS will also be taken into account
when C code is compiled by ocamlc/ocamlopt.
This commit removes the explicit reference to CFLAGS in the
configuration for the xlc compiler, since it is not necessary any longer.
* Fix#9759: Typing without -principal is broken in 4.11 and trunk
* compile stdlib in -principal mode
* never modify generic part of ty_expected_explained
* use generic_instance where possible
* add comment for -no-principal in stdlib__oo.cmi
When the hash function and the internal representation of hash tables
was changed in 4.00, some compatibility code was left so that "old"
hash tables (created with OCaml < 4.00 and marshaled to files)
could still be operated upon by the functions of the new implementation.
This was 9 years ago, so it is reasonable to expect that none of these
"old" hash tables are still in use.
This commit removes the compatibility code in stdlib/hashtbl.ml.
It still tries to detect "old" hash tables and raise an
Invalid_argument exception instead of crashing.
This provides an officially-sanctioned, guaranteed-to-work way to
import a hash table that has been built with an old version of OCaml
(say, before 4.00) and marshaled to persistent storage.
The previous implementation (caml_obj_reachable_words in runtime/obj.c)
was using the mark bits of block headers to detect sharing.
This is not compatible with Multicore OCaml.
This commit reimplements caml_obj_reachable_words to detect sharing
with a hash table of addresses already seen.
The implementation reuses the hash table used to detect sharing
during marshaling (commit 67ada54ce), and other bits of the marshaler,
hence the function caml_obj_reachable_words was moved to runtime/extern.c.
In no-naked-pointers mode, to anticipate the disappearance of the page
table, statically-allocated blocks cannot be treated specially and will
be counted towards the size. This change of semantics is mentioned
in the documentation for Obj.reachable_words.
* camlinternalMod: use closure metadata for copying a closure over another
This change is careful to avoid writing a value into what was
previously a raw field or conversely, clearing fields that change
category first.
We also clear the end of the block, to make it easier to reason about
lifetime of values that could have been referenced there. (We don't
expect this to make a different in practice.)
* Obj: new submodule Closure giving basic access to closure metadata
* Ensure that Obj.new_block returns a sensible uninitialized closure
* Changes
This commit touches neither boot/ocamlc nor boot/ocamllex
It has the side-effect of fixing the cleanup rules which did not use the
$(EXE) extension when removing a file although it was produced with the
$(EXE) extension.
Introduce type Obj.raw_data and functions Obj.raw_field, Obj.set_raw_field to manipulate out-of-heap pointers in no-naked-pointers mode, and more generally all other data that is not a well-formed OCaml value
Some OCaml objects contain data that cannot be safely represented
as an OCaml value (type Obj.t). For example, in no-naked-pointers mode,
this is the case for code pointers inside closures, and for the
"custom operations" pointers inside custom blocks.
This PR introduces a type Obj.raw_data (an alias for nativeint)
to encapsulate this data, and functions
Obj.raw_field / Obj.set_raw_field to read and write the "raw" contents
of fields of blocks.
Note: just like it is wrong to access code pointers and custom operations
using Obj.field / Obj.set_field, it is wrong to access regular fields
possibly containing pointers into the OCaml heap using
Obj.raw_field / Obj.set_raw_field. The OCaml heap block can be
reclaimed or moved after its address was captured by Obj.raw_field.
Symmetrically, Obj.set_raw_field on a regular field bypasses the
write barrier of the GC.
This module provides a purely sequential implementation of the
concurrent atomic references provided by the Multicore OCaml
standard library:
https://github.com/ocaml-multicore/ocaml-multicore/blob/parallel_minor_gc/stdlib/atomic.mli
This sequential implementation is provided in the interest of
compatibility: when people will start writing code to run on
Multicore, it would be nice if their use of Atomic was
backward-compatible with older versions of OCaml without having to
import additional compatibility layers. *)
- Add the key argument in the description of 'merge'
- Note that the keys of 'union f m1 m2' are a subset of the
input keys, not all the keys, since
bindings (union (fun _ _ _ -> None) m m) = []
- Fix grammar in the descriptions of 'filter', 'union', 'merge'
- Fix mismatched variable name in the description of 'partition'
- Note that 'find' and 'find_opt' return values, not bindings
The instrumentation code in the instrumented runtime was replaced
with new APIs to gather runtime statistics and output them in a new format
(Common Trace Format).
This commit also exposes new functions in the Gc module to pause or resume
instrumentation during a program execution (Gc.eventlog_pause and
Gc.eventlog_resume).
The docs on this are out of date: they say runtime warnings are enabled by
default, but the source code has a commit 6c90da4 pointing to
https://github.com/ocaml/ocaml/pull/210 that disables them by default.
It seems like enabling runtime warnings by default never made its way into a
release and the docs could just be updated to say that runtime warnings are
disabled by default.
Signed-off-by: Edwin Török <edvin.torok@citrix.com>
This moves the configure-generated parts of Makefile.common to a
separate (generated) Makefile, allowing Makefile.common to be a normal
Makefile.
OCaml's build system Makefile's now include Makefile.build_config (which
itself includes Makefile.config) but Makefile.config is still installed
as before. This allows configure to generate variables which are
specific to the build process and are not intended to be exported to the
installation.
The Gc.Memprof module provides a low-level API, that will hopefully be
paired with user libraries that provide high-level instrumentation
choices.
A natural question is: how are the higher-level API going to expose
their choice of instrumentation to their users? With the current
Memprof.start API (before this patch), they would have to either
provide their own `start` function wrapping Memprof.start, or provide
a tuple of callbacks for to their users to pass to Memprof.start
themselves.
val start : params -> unit
(* or *)
val callback : params ->
((allocation -> foo option) * (allocation -> bar option) * ... )
With an explicit record, it is easier for libraries to expose an
instrumentation choice (possibility parametrized over
user-provided settings):
val tracker : params -> (foo, bar) Gc.Memprof.tracker
In addition, providing a record instead of optional parameters makes
it much easier to provide "default settings" (helper functions) that
instantiates the types `'minor` and `'ḿajor`, see for example
`simple_tracker` in this patch (which stores the same information for
the minor and major heap, and does not observe promotion), or to later
define checking predicates that can verify that a given choice of
callbacks is sensible (for example: providing a major-dealloc callback
but no promotion callback (dropping all tracked value on promotion) is
probably not a good idea).
Bootstrap: to avoid requiring an awkward bootstrap, this commit keeps
the (now unused) function caml_memprof_start_byt unchanged -- it is
used in the bootstrap binaries, so removing it would break the
build. The intention is to remove it in the following commit.
Printexc.uncaught_exception_handler ceases to be an option ref and becomes
a ref to the handler function initialized to
Printexc.default_uncaught_exception_handler.