[ruby-core:18607] Re: Memory "leak" due to inline caching?

Excerpts from Headius: Charles Oliver Nutter's message of Sun Sep 14 02:09:18 +0300 2008:
> <snip />
>
> - The method object contains a reference to the class in which it was 
> defined
> - The cache holds a hard reference to the method object, to allow it to 
> be quickly invoked later
> - If the method's class goes away, the reference chain keeps it alive
>
> <snip />
>
> I've been treating it as a low-priority issue, and I believe the 
> original reporter worked around it. But it does seem like a systemic 
> problem with inline caching in Ruby. I would expect it to affect 
> Rubinius, IronRuby, and Maglev as well.

I discussed this on IRC with Charlie earlier, but continuing
the topic here, I think Rubinius and presumably 1.9 are in
a fundamentally different position here because we are able
to use non-managed objects internally, e.g. just using C++
memory management in our case. In contrast, for JRuby (and
presumably IronRuby, not sure about MagLev and MacRuby) in
addition to the objects held in the cache, the cache _itself_
is implemented using the underlying VM's objects which would
then necessitate the Weakref-type solution.

It does still certainly require ensuring that those entries
are in fact destroyed in Rubinius as well even though it is
simple to just "not count" the reference to the Module held
by the cache to eliminate the false positive. So when the
Module is destroyed, its entries must still be removed from
the cache (or alternatively always check whether the cache
entry is still valid.)

Additionally, similar cases may exist elsewhere in the logic
so it is certainly a good thing to try to carve out a policy
for handling them even if each implementation ends up doing
it differently.

In the grand scale of things, this particular issue is probably
not one of the most severe, but it does at least impact collecting
MetaClasses (I would assume collecting actual Modules or Classes
to be far rarer, if not altogether nonexistent.)

--
Eero (rue)