Support obj_free

[wks]

Associated PR: mmtk/mmtk-ruby#8

We add all types that has non-trivial clean-up code in obj_free as candidates for finalization. MMTk-core will put them into a queue when they die.

This PR mainly focuses on recycling off-heap buffers of large arrays and strings. If those off-heap objects are not recycled in time, it may thrash the whole system before being killed by the operating system. So currently the invocation of finalizers is invoked by ruby_xmalloc. When allocating too much off-heap objects using ruby_xmalloc, it will trigger GC, and execute obj_free on ready-to-finalize objects. This gives us a chance to free the off-heap xmalloc-allocated buffers for dead objects.

Known issues:

• We still need to give the Ruby VM a chance to call obj_free when GC is triggered by regular heap allocations, and we want to avoid calling finalizers on the fast path of allocation.
• The GC cannot scan objects that already have obj_free called on them, because it frees the underlying data structures (usually off-heap C objects of T_DATA) which dmark attempts to read. Currently, we change the object type to T_NONE after calling obj_free, and skip T_NONE before calling gc_mark_children. When the feature in mmtk-core is ready (see Add an API to clear the valid-object bit (a.k.a. alloc-bit) mmtk-core#648), we will invalidate the objects by clearing its "valid-object bit" so that mmtk-core will not attempt to call Scanning::scan_object on invalid objects.

[chrisseaton]

Is there anything lighter-weight than full finalisers? Like if we want to delete the C array backing an array object, can we not hook into the GC to do that as soon as the object is found to be dead rather than pushing the work onto a queue?

[wks]

Is there anything lighter-weight than full finalisers? Like if we want to delete the C array backing an array object, can we not hook into the GC to do that as soon as the object is found to be dead rather than pushing the work onto a queue?

Currently, there is no such a mechanism in mmtk-core.

Yes. It is possible to add a hook to the GC (or more precisely, hook into the FinalizerProcessor) to call obj_free immediately when objects die. However, I don't think it helps much.

Finalizable objects still need to be registered into the FinalizerProcessor. This is because most GC algorithms, other than MarkSweep, do not have a "sweep" phase in which the GC goes through all allocated objects to sweep them (and call obj_free when visiting dead objects). They just discard unused chunks as a whole. SemiSpace copies live objects out, and discards the entire from-space without looking at dead objects. Immix can recycle dead blocks or lines at a time, ignoring objects inside. Generational collectors, like SemiSpace, also discards the nursery without looking at dead objects inside. Therefore, to call a particular function (obj_free) on an object when it dies, the VM must tell mmtk-core which object needs such special care. In most languages, very few objects have finalizers. Ruby is a very big exception in that most Ruby objects are subject to finalization (obj_free).

So a hook can be added at the resurrection stage, i.e. the time when a heap traversal has finished, and the FinalizerProcessor scans registered objects to see if they are still alive. Instead of resurrecting an object and adding it into the ready-to-finalize queue, the FinalizerProcessor can call a hook registered by the VM. In the case of Ruby, it is obj_free. If we do this, those objects do not need to be resurrected at all. GC can just treat them as dead.

But this approach has two problems.

It doesn't reduce the amount of work to be done. obj_free has to be called at some time (whether during GC or after GC) by some thread (GC thread or mutator thread) on the same number of objects subject to finalization. Doing it during GC doesn't make the program call less obj_free. It just moves the job from the mutator to the GC.

If obj_free is called during GC, it increases the GC latency. With dfree provided by the user, the time it takes is unbounded. But GC must work as fast as possible to reduce the pause time. The new LXR algorithm does marking concurrently, and minimizes stop-the-world time, to reduce latency. If we call obj_free during GC (and currently it needs to be called on most Ruby objects), then obj_free may become the biggest source of latency.

Therefore, to solve the root problem, we should reduce the number of finalizable objects. In other words, we should make it unnecessary to call obj_free on as many objects as possible. The next thing I will do will be changing the C buffers in objects so that they are allocated by the GC, instead. And I'll start with T_OBJECT, T_STRING and T_ARRAY.

By the way, Section 12.1 of the GC Handbook mentioned the possibility to run finalizers during GC, and listed some down sides, such as (1) it cannot allocate objects during GC, (2) risk of deadlock, and (3) may impose constraints on GC algorithms. Not all of them may apply to Ruby, but I think the idea of adding such a hook to the MMTk API is at least questionable.

Anyway, I'll raise this in our next group meeting.

[chrisseaton]

Ok let's go ahead with this option.

Ruby has so much off-heap memory that is easily freed that it might make sense to think about new ideas for this. The issue I have with pushing work to a queue is that it goes out of cache just to come back into cache. Surely we can do something better for the most common cases. Something to think about.