In a real set of bindings we have a C finalizer that closes the handle automatically. When testing this we have code which looks something like the simplified example below: let handle_closed = ref 0 let final _ = incr handle_closed let () = assert (!handle_closed = 0) let () = let obj = ref […

Without flambda, the following code doesn’t work: let obj = ref [] let () = Gc.finalise obj Here, even if obj does not appear in the .mli file, it is considered a toplevel value and never collected. With flambda, the criterion for toplevel values is not syntactic anymore; anything not under a fun…

I would expect obj to be lifted to an immortal toplevel binding. It should be possible to prevent this by installing the finalizer in a noinline function and calling it. See section 8.2 .

Thanks, that worked. The upstream fix: ocaml: Fix guestfs_065_implicit_close.ml for OCaml 5 · libguestfs/libguestfs@7d4e9c9 · GitHub

OCaml 5: forcing objects to be collected and finalized

Learning

rwmjones June 27, 2023, 12:25pm 2

Here’s the real test: libguestfs/ocaml/t/guestfs_065_implicit_close.ml at master · libguestfs/libguestfs · GitHub

Topic		Replies	Views
OCaml heap "fsck" and forcing collection of unreachable objects Community gc	3	546	May 31, 2023
Downsides to calling Gc.full_major at exit? Learning bindings	15	1823	April 25, 2020
Finalizers, value lifetimes and `Sys.opaque_identity` flambda , optimization	0	991	October 22, 2018
Question on "Attaching Finalizer Functions to Values" Learning	2	837	October 8, 2018
GC omitting an increasing pile of garbage until OOM ensues Ecosystem	5	374	April 29, 2025

OCaml 5: forcing objects to be collected and finalized

Related topics