[
http://jira.codehaus.org/browse/JANINO-88?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_99241 ]
Arno Unkrig commented on JANINO-88:
-----------------------------------
{quote}
When would the JSCL be GCed, exactly? It won't, until the classes that were loaded by it were all GCed. All classes loaded by the VM maintain a reference back to their loading ClassLoader. If a class happened to be added into a ThreadLocal, and the ThreadLocal is maintained statically in a class not dynamically loaded, then everything underneath JSCL will never be freed.
{quote}
Yes, but that's only natural! When the last class loaded through the JSCL is GCd, then the JSCL and the JSICL are also available for GC. That's not a memory leak. The resources held by the JSICL (esp. "unitCompilers") are used in case another class needs to be loaded through the JSCL.
Am I missing anything?
CU
Arno
> JavaSourceClassLoader has a memory leak for JavaSourceIClassLoader.
> -------------------------------------------------------------------
>
> Key: JANINO-88
> URL:
http://jira.codehaus.org/browse/JANINO-88> Project: Janino
> Issue Type: Bug
> Reporter: Adam Heath
> Assignee: Arno Unkrig
> Attachments: fix_JavaSourceClassLoader-memleak.patch
>
>
> JavaSourceClassLoader creates a singleton JavaSourceIClassLoader in it's constructor. This is actually a cause for a memory leak in long-running server processes. The simplest fix is to create a new JavaSourceIClassLoader each time in generateByteCodes.
--
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
