[avsm]

GC vs reference counting has nothing to do with determinism. For the same inputs, the same allocation profiles and same GC events will happen.

Note that CPython's reference counting is by means automatically simpler than OCaml's incremental GC. CPython has heuristics to detect cycles (which normally cause memory leaks in a pure reference counting system), as well as a number of heuristics to optimise performance based on locality and temporal properties of object allocation. All of these contribute to making the CPython runtime less predictable (but faster).

The OCaml GC is extremely predictable and has very few tricks. It's explained in one chapter of Real World OCaml: https://realworldocaml.org/v1/en/html/understanding-the-garb...

[illumen]

When is the GC activated exactly? When there is not enough memory available. This is the problem, because depending on the data the program is processing this changes.

So if you run your program with different inputs (why would you run it if the inputs are always the same?) then the GC will be activated in entirely different parts of your program!

This makes it non deterministic because objects in OCaml can destruct at different times in your program depending on the inputs. With reference counting, they are destructed at exactly the time when they have no references.

With OCaml GC, the code can run in a different order depending on the GC variables and depending on the program inputs.

The bug in the original article was caused because the GC was finalising it at a time the author did not consider. Probably because the code assumed reference counting behaviour of finalising when there are no references.

"OCaml's automatic memory management guarantees that a value will eventually be freed when it's no longer in use, either via the GC sweeping it or the program terminating"

So, it can guarantee your object will be freed... but only when the program terminates? That's not a very strong promise.

[nightski]

Well of course it can't guarantee that your object will be freed beforehand if the GC does not get a chance to run before the program terminates. It does say if the GC runs it will be freed if no longer in use.

[fzltrp]

> This makes it non deterministic because objects in OCaml can destruct at different times in your program depending on the inputs.

There's clearly a different notion of deterministic there! If your program using ref counting gets a different input, the same object might be released at a different time as well, or am I misunderstanding?

> "OCaml's automatic memory management guarantees that a value will eventually be freed when it's no longer in use, either via the GC sweeping it or the program terminating"

> So, it can guarantee your object will be freed... but only when the program terminates? That's not a very strong promise.

”A or B imply C” is not the same as ”B implies C”. There's a logic mistake there.

[cousin_it]

I think illumen is referring to the concept of "deterministic destruction", which exists in refcounted languages but not in GC'd ones. It's not quite the same as "determinism".

[fzltrp]

Oh, ok. So every python implementations follow that practice?

[cousin_it]

No, just CPython I think.