Memory Leak with Adopted Threads
--------------------------------
Key: JRUBY-3217
URL: http://jira.codehaus.org/browse/JRUBY-3217
Project: JRuby
Issue Type: Bug
Components: Core Classes/Modules
Affects Versions: JRuby 1.1.5
Reporter: Peter K Chan
In my application, I have detected a memory leak that seems to be caused by
references being kept to java threads that are created outside of the runtime
and later adopted into the runtime.
(noformat}
public class JRubyHelper {
public static boolean invokeWithTimeout(long timeout, String name,
final Runnable runnable) throws InterruptedException {
Thread t = new Thread(runnable);
t.setName(name);
t.start();
t.join(timeout);
if(t.isAlive()) {
t.stop();
return false;
} else {
return true;
}
}
}
Ruby code:
1000.times do |x|
JRubyHelper.invokeWithTimeout(1000, "Thread #{x}") { Time.now }
end
{noformat}
According to heap dump analysis, after the run, the rubyThreadMap member of the
runtime's ThreadService is filled with 1000 entries.
It seems like what happens is that when the java code creates a thread that
subsequently executes ruby code, the jruby runtime adopts the java thread.
However, the adoption creates a strong reference to the java thread, which then
prevents it from being garbage collected, even after it has died.
In the jruby runtime, the type of rubyThreadMap is a weak hash map with java
threads as weak keys and ruby threads as values. However, it seems that the
ruby thread hold a strong reference to the java thread by way of
rubyThread.threadImpl.nativeThread. I am not sure how the GC handles circular
reference that contains weak reference, but I suspect that it is the reason why
the java threads are not cleared from memory.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
