There is currently a GC bug in the bytecode debug-info handling, due
to the fact that
void read_main_debug_info(struct debug_info *di)
is passed a internal pointer in the middle of a custom block inside
the OCaml heap. I could only observe the bug when such custom blocks
are allocated on the minor heap -- which does not happen with the
current implementation, but becomes possible after GPR#92 for example
(which let custom blocks with finalizer be allocated in the
minor heap).
This commit fixes this issue by moving debug_info chunks from the
OCaml heap to the C land, stored in a dynamic table. They are
allocated when caml_add_debug_info is called, and removed when
caml_remove_debug_info is called.
(Another approach would be to keep the debug_info inside the OCaml
heap, but make sure that there are no dangling internal pointers. See
GPR#228 for an attack of this by Mark Shinwell.)
git-svn-id: http://caml.inria.fr/svn/ocaml/trunk@16356 f963ae5c-01c2-4b8c-9fe0-0dff7051ff02
* PR#6816: reject identifiers following numeric literals without spacing, e.g.
let foo = 1 in (fun a b -> a,b) 23foo
(Hugo Heuzard)
(Thanks to Daniel Bünzli for reminding me.)
git-svn-id: http://caml.inria.fr/svn/ocaml/trunk@16317 f963ae5c-01c2-4b8c-9fe0-0dff7051ff02
(Hongbo Zhang)
when printing recursive module the old version would print no space
before 'and':
A : ... = struct
...
endand B : ... = ...
this tiny PR fixes such problem
git-svn-id: http://caml.inria.fr/svn/ocaml/trunk@16307 f963ae5c-01c2-4b8c-9fe0-0dff7051ff02
(Pierre Chambart)
It now reallocates and reinitialises the whole table only when it is
too small. This avoids quadratic behavior when loading a lot of module
with dynlink.
This was problematic on frama-c when inlining increase the code
size. The frame table initialisation took ~0.5 second. This is quite
noticeable on real examples where the whole frama-c analysis is ~1.5s
long.
Also allows to unregister a frametable.
git-svn-id: http://caml.inria.fr/svn/ocaml/trunk@16260 f963ae5c-01c2-4b8c-9fe0-0dff7051ff02
(Clark Gaebel)
These functions are called every tick of the Async scheduler, and
are the only remaining calls to [caml_c_call] every cycle. It would
be nice to remove them, especially since these functions don't
allocate.
git-svn-id: http://caml.inria.fr/svn/ocaml/trunk@16259 f963ae5c-01c2-4b8c-9fe0-0dff7051ff02
Ratio.float_of_ratio, ensuring that the result is correctly rounded.
The previous implementations were embarassingly imprecise and slow.
git-svn-id: http://caml.inria.fr/svn/ocaml/trunk@16247 f963ae5c-01c2-4b8c-9fe0-0dff7051ff02
configure: deselect ocamlopt, which is not supported
signals_machdep.h: use i386 instruction sequence, not amd64.
git-svn-id: http://caml.inria.fr/svn/ocaml/trunk@16243 f963ae5c-01c2-4b8c-9fe0-0dff7051ff02
The approach implemented is the second one suggested by Benoît Vaugon in the PR:
- The int_of_string functions accept a "0u" prefix meaning "decimal unsigned".
- The '%u' format of the scanf functions adds this "0u" prefix before conversion.
This is consistent with the current handling of unsigned hexa, octal, and binary numbers.
git-svn-id: http://caml.inria.fr/svn/ocaml/trunk@16241 f963ae5c-01c2-4b8c-9fe0-0dff7051ff02
Gabriel Scherer
Damien Doligez
Xavier Leroy
Alain Frisch
Jacques Garrigue
Leo White
Mark Shinwell