Issue #6030 has been updated by Charles Nutter.


It would be possible to bloat up memory use by calling many method names that all hit this logic; saving a hash per name and never releasing it seems unnecessary.

If it's not a big enough deal for MRI to fix, so be it...it was an issue in JRuby because of the additional rooting of JRuby instances, but JRuby support MVM.

For that matter, this also is highly unlikely to work with the MVM stuff, though I know that's still off in experimental-land anyway.

It just seems like a good idea to clean up after the recursive logic is done, rather than leaving a dirty hash lying around.
----------------------------------------
Bug #6030: Thread-local "leak" in rb_exec_recursive*
https://bugs.ruby-lang.org/issues/6030

Author: Charles Nutter
Status: Open
Priority: Normal
Assignee: 
Category: 
Target version: 
ruby -v: 1.9.3 head


I believe there may be a "leak" in the rb_exec_recursive* functions in thread.c.

We have ported these methods for recursion detection in JRuby, and as in MRI they use a map inside a thread-local to track method name + object references. However, none of these method ever clean up the thread local when the recursive walk is complete.

The thread-local data is initialized in thread.c, recursive_list_access, around line 3819 (in 1.9.3 branch):

    if (NIL_P(hash) || TYPE(hash) != T_HASH) {
	hash = rb_hash_new();
	OBJ_UNTRUST(hash);
	rb_thread_local_aset(rb_thread_current(), recursive_key, hash);

As far as I can tell, this thread-local is never cleared, holding a hash reference for as long as the thread is alive.


-- 
http://bugs.ruby-lang.org/