[janino-dev] [jira] Created: (JANINO-88) JavaSourceClassLoader has a memory leak for JavaSourceIClassLoader.

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

    [ http://jira.codehaus.org/browse/JANINO-88?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_96320 ]

Arno Unkrig commented on JANINO-88:
-----------------------------------

I'm not happy with that change. The important lines of code are:

{code:title=JavaSourceClassLoader.java line 404}
    /**
     * Collection of parsed, but uncompiled compilation units.
     */
    private final Set unitCompilers = new HashSet(); // UnitCompiler
{code}

If I apply your change, then JSCL will no longer keep parsed but uncompiled CUs. That's probably a HUGE performance hit!

Anyway, why do you consider the singleton JSICL a memory leak? It is only references by the JSCL, and hence freed if the JSCL is GCed.

> 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

    [ http://jira.codehaus.org/browse/JANINO-88?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_96410 ]

Adam Heath commented on JANINO-88:
----------------------------------

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.

I found this issue, while tracking down several memory leaks in a long-running server process.  Made use of jconsole and jhat in java 1.6.

> 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

     [ http://jira.codehaus.org/browse/JANINO-88?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Work on JANINO-88 stopped by Arno Unkrig.

> 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

     [ http://jira.codehaus.org/browse/JANINO-88?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Work on JANINO-88 started by Arno Unkrig.

> 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

    [ 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

     [ http://jira.codehaus.org/browse/JANINO-88?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Arno Unkrig resolved JANINO-88.
-------------------------------

    Resolution: Won't Fix

No activity on this one.

> 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

    [ http://jira.codehaus.org/browse/JANINO-88?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=145626#action_145626 ]

Adam Heath commented on JANINO-88:
----------------------------------

A memory leak is not just something that can't be freed due to self referential loops.  There's no need to keep the iClassLoader around after the classes have been parsed/compiled.  Disconnecting this allows more memory to be freed earlier(freeing iClassLoader), so that it is available to the rest of the system.

Sorry for taking so long to get back; got busy with work, and forgot about checking back.

> 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

     [ http://jira.codehaus.org/browse/JANINO-88?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Arno Unkrig reopened JANINO-88:
-------------------------------

> 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