Function to run finalizers

[pclayton]

This continues from the thread 'Running finalizers on exit' on the MLton-user list.

In summary, it was observered that exiting using Posix.Process.exit does not run finalizers so a function to explicitly run finalizers would be useful. A function

val gcAndFinalize : unit -> unit

was proposed that garbage collects and finalizes as much as possible. I now think that fullGCAndFinalize would be a slightly better name as some compilers may offer different levels of GC.

Since then, I have wondered whether it could be useful to provide a more general finalization function

val finalize : (unit -> unit) -> bool

which

1. allows the caller to specify the GC function as the argument, and
2. evaluates the GC function once and then runs finalizers synchronously, returning a flag indicating whether any finalizers were run (so false means there are no more finalizers that can be run).

The synchronous nature gives more predictable timing and the choice of GC function and return flag allow the caller to trade-off time versus completeness. This would give some control over scheduling of GC and finalization to an application, potentially reducing the likelihood of a user experiencing pauses.

Also, this should allow fullGCAndFinalize to be implemented as

while finalize MLton.GC.collect do ()

[MatthewFluet]

This continues from the thread 'Running finalizers on exit' on the MLton-user list.

In summary, it was observered that exiting using Posix.Process.exit does not run finalizers so a function to explicitly run finalizers would be useful. A function

val gcAndFinalize : unit -> unit

was proposed that garbage collects and finalizes as much as possible. I now think that fullGCAndFinalize would be a slightly better name as some compilers may offer different levels of GC.

Something to gc and finalize as much as possible makes sense. I don't object to fullGCAndFinalize, though I think that "full" is somewhat implied --- what is the point of "as much as possible" if the GC doesn't guarantee to find all dead objects at each collection.

Since then, I have wondered whether it could be useful to provide a more general finalization function

val finalize : (unit -> unit) -> bool

which

1. allows the caller to specify the GC function as the argument, and

2. evaluates the GC function once and then runs finalizers synchronously, returning a flag indicating whether any finalizers were run (so false means there are no more finalizers that can be run).

The synchronous nature gives more predictable timing and the choice of GC function and return flag allow the caller to trade-off time versus completeness. This would give some control over scheduling of GC and finalization to an application, potentially reducing the likelihood of a user experiencing pauses.

Maybe. Again, it is unclear to me the utility of GCing with anything other than a full GC if the purpose is to trigger the execution of finalizers. And, I'm not sure about the predictability of the timing, unless this kind of behavior is also paired with a choice to disable the processing of finalizers at the GC signal (and moving all of the finalizer processing back to the user).

Maybe an even more general solution is to separate the identification pending finalizers from the execution of them. The Finalize module could expose a pendingFinalizers queue, where the GC enqueues and the mutator can choose when and how many finalizers to run. Then, the finalize: (unit -> unit) -> bool could be implemented on top of that.