Issue #6030 has been updated by Marc-Andre Lafortune.


Hi.

I'm not sure I see where there is a problem.

If `Array#==`, say, is called in a given thread, it's quite likely that it will be called again later on, so why not keep the reference to the empty hash ready for next call?

As long as these hashes are empty at the end of the rb_exec_recursive_*, it's not clear that there is much memory to recoup. It could also affect the performance.
----------------------------------------
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/