Execution and Lifecycle

Object Lifecycle and Finalizers

Ruby is a garbage-collected language. In the current implementation, the garbage collector may run on any Ruby thread, either when Ruby chooses to invoke it directly before a memory allocation operation, or when it's explicitly invoked by Ruby code, the core library or an extension library. Currently the Ruby VM does not create any hidden Ruby threads for the purpose of garbage collection, finalizers or any other purpose.

Ruby allows you to register one or more finalizers to any value which is not an immediate value (i.e. object values only). A finalizer is a block which can be called when the object can be destroyed, and it is called with 1 parameter, which is the object id of the object which is being finalized.

An object id is currently implemented as a representation of a pointer to the object's memory location. As such they are a unique identifier for currently available objects - note that when an object is freed from memory e.g. by the garbage collector, it is possible for another object to be created with the same object ID.

Ruby has 2 mechanisms for invoking finalizers:

• Garbage collection, as part of freeing an object
• VM destruction

The garbage collector frees objects as follows:

• The garbage collector deems an object to be dead when it is no longer possible for any code to access the object. This includes finalizer code - if a registered finalizer block can access the object it is intended to finalize, e.g. through its closure on local variables, then the garbage collector will never free it
• The garbage collector may choose to free dead objects when it is invoked
• If the garbage collector chooses to free an object, then the object's finalizers will invoked as follows:
• Finalizers will be invoked by some thread at its next interrupt point
• The object being finalized may already have been freed
• It is undefined whether the thread invoking the finalizer is holding any Mutex locks - if the finalizer locks Mutexes, it must be careful that the thread it is running in does not already hold the lock
• Some more specific details of the current implementation of the garbage collector:
• Finalizers will be run at the next interrupt point of the thread running the garbage collector
• Objects with finalizers will be freed directly before the finalizer runs, as part of the interrupt point
• Ruby does not currently permit finalizers to be running on multiple threads at once, or the garbage collector to reentrantly schedule finalizers at an interrupt point when the thread is already running finalizers

Tracing and Coverage

VM Initialization and Destruction

VM Irregular Termination