Janino

JavaSourceClassLoader has a memory leak for JavaSourceIClassLoader.

Details

  • Type: Bug Bug
  • Status: Reopened Reopened
  • Priority: Major Major
  • Resolution: Unresolved
  • Affects Version/s: None
  • Fix Version/s: None
  • Labels:
    None
  • Number of attachments :
    1

Description

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.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Arno Unkrig added a comment -

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

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

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.

Show
Arno Unkrig added a comment - I'm not happy with that change. The important lines of code are: JavaSourceClassLoader.java line 404 /** * Collection of parsed, but uncompiled compilation units. */ private final Set unitCompilers = new HashSet(); // UnitCompiler 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.
Hide
Permalink
Adam Heath added a comment -

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.

Show
Adam Heath added a comment - 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.
Hide
Permalink
Arno Unkrig added a comment -

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.

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

Show
Arno Unkrig added a comment - 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. 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
Hide
Permalink
Arno Unkrig added a comment -

No activity on this one.

Show
Arno Unkrig added a comment - No activity on this one.
Hide
Permalink
Adam Heath added a comment -

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.

Show
Adam Heath added a comment - 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.

People

  • Assignee:
    Matt Fowles
    Reporter:
    Adam Heath
Vote (0)
Watch (0)

Dates

  • Created:
    Updated: