You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@maven.apache.org by "kaniska (JIRA)" <ji...@codehaus.org> on 2010/09/08 02:33:32 UTC
[jira] Created: (MAVEN-1867) Facing OutOfMemory as
IsolatedClassloader (plexus-compiler jar) is not closed after JavacCompiler
is done with compilation.
Facing OutOfMemory as IsolatedClassloader (plexus-compiler jar) is not closed after JavacCompiler is done with compilation.
---------------------------------------------------------------------------------------------------------------------------
Key: MAVEN-1867
URL: http://jira.codehaus.org/browse/MAVEN-1867
Project: Maven 1
Issue Type: Bug
Components: core
Affects Versions: 1.2
Environment: Windows 2003 Server
Reporter: kaniska
Priority: Blocker
Attachments: IsolatedClassLoader_Issue.docx
In Eclipse environment for a maven-based project, Auto-build fires Maven-build which in turn executes CompilerMojo, finally creating an IsolatedClassloader for each compile call !
IsolatedClassLoader.addURL(URL) line: 42...
JavacCompiler.compile(CompilerConfiguration) line: 141
CompilerMojo(AbstractCompilerMojo).execute() line: 493...
DefaultBuildPluginManager.executeMojo(MavenSession, MojoExecution) line: 105...
MavenImpl.execute(MavenExecutionRequest, IProgressMonitor) ...
MavenBuilder.build(int, Map, IProgressMonitor) line: 153 ....
AutoBuildJob.run(IProgressMonitor) line: 238
So every single change in maven-v4 project creates a new IsolatedClassloader which is fine.
But the problem is JavacCompiler is not closing the loader which holds huge number of jars (url points to maven-repo) in its url classpath.
It should use ClassLoaderutil.releaseLoader(..) to unload the jars.
GC does not reclaim the isolatedclassloader instances (not sure why).
As a result, IsolatedClassloader instances consume retains the heap.
Eventually maven-application goes OutOfMemory !
Attached is the heapdump analysis of isolatedclassloader that holds the memory.
This is kind of blocking us from building largescale maven app which requires good number of jars in development time for compiling the app source at development time.
Please note that we face this issue at development time whenever developer making changes in source code as explained in the code-flow above.
Please let us know if more information is required.
--
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
[jira] Moved: (MCOMPILER-133) Facing OutOfMemory as
IsolatedClassloader (plexus-compiler jar) is not closed after JavacCompiler
is done with compilation.
Posted by "Benjamin Bentmann (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MCOMPILER-133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Benjamin Bentmann moved MNG-4801 to MCOMPILER-133:
--------------------------------------------------
Complexity: (was: Intermediate)
Key: MCOMPILER-133 (was: MNG-4801)
Project: Maven 2.x Compiler Plugin (was: Maven 2 & 3)
> Facing OutOfMemory as IsolatedClassloader (plexus-compiler jar) is not closed after JavacCompiler is done with compilation.
> ---------------------------------------------------------------------------------------------------------------------------
>
> Key: MCOMPILER-133
> URL: http://jira.codehaus.org/browse/MCOMPILER-133
> Project: Maven 2.x Compiler Plugin
> Issue Type: Bug
> Environment: Windows 2003 Server
> Reporter: kaniska
> Priority: Blocker
> Attachments: IsolatedClassLoader_Issue.docx
>
>
> In Eclipse environment for a maven-based project, Auto-build fires Maven-build which in turn executes CompilerMojo, finally creating an IsolatedClassloader for each compile call !
> IsolatedClassLoader.addURL(URL) line: 42...
> JavacCompiler.compile(CompilerConfiguration) line: 141
> CompilerMojo(AbstractCompilerMojo).execute() line: 493...
> DefaultBuildPluginManager.executeMojo(MavenSession, MojoExecution) line: 105...
> MavenImpl.execute(MavenExecutionRequest, IProgressMonitor) ...
> MavenBuilder.build(int, Map, IProgressMonitor) line: 153 ....
> AutoBuildJob.run(IProgressMonitor) line: 238
> So every single change in maven-v4 project creates a new IsolatedClassloader which is fine.
> But the problem is JavacCompiler is not closing the loader which holds huge number of jars (url points to maven-repo) in its url classpath.
> It should use ClassLoaderutil.releaseLoader(..) to unload the jars.
> GC does not reclaim the isolatedclassloader instances (not sure why).
> As a result, IsolatedClassloader instances consume retains the heap.
> Eventually maven-application goes OutOfMemory !
> Attached is the heapdump analysis of isolatedclassloader that holds the memory.
> This is kind of blocking us from building largescale maven app which requires good number of jars in development time for compiling the app source at development time.
> Please note that we face this issue at development time whenever developer making changes in source code as explained in the code-flow above.
> Please let us know if more information is required.
--
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
[jira] (MCOMPILER-133) Facing OutOfMemory as IsolatedClassloader
(plexus-compiler jar) is not closed after JavacCompiler is done with
compilation.
Posted by "Mark Struberg (JIRA)" <ji...@codehaus.org>.
[ https://jira.codehaus.org/browse/MCOMPILER-133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mark Struberg closed MCOMPILER-133.
-----------------------------------
Resolution: Won't Fix
> Facing OutOfMemory as IsolatedClassloader (plexus-compiler jar) is not closed after JavacCompiler is done with compilation.
> ---------------------------------------------------------------------------------------------------------------------------
>
> Key: MCOMPILER-133
> URL: https://jira.codehaus.org/browse/MCOMPILER-133
> Project: Maven 2.x Compiler Plugin
> Issue Type: Bug
> Environment: Windows 2003 Server
> Reporter: kaniska
> Priority: Blocker
> Attachments: IsolatedClassLoader_Issue.docx
>
>
> In Eclipse environment for a maven-based project, Auto-build fires Maven-build which in turn executes CompilerMojo, finally creating an IsolatedClassloader for each compile call !
> IsolatedClassLoader.addURL(URL) line: 42...
> JavacCompiler.compile(CompilerConfiguration) line: 141
> CompilerMojo(AbstractCompilerMojo).execute() line: 493...
> DefaultBuildPluginManager.executeMojo(MavenSession, MojoExecution) line: 105...
> MavenImpl.execute(MavenExecutionRequest, IProgressMonitor) ...
> MavenBuilder.build(int, Map, IProgressMonitor) line: 153 ....
> AutoBuildJob.run(IProgressMonitor) line: 238
> So every single change in maven-v4 project creates a new IsolatedClassloader which is fine.
> But the problem is JavacCompiler is not closing the loader which holds huge number of jars (url points to maven-repo) in its url classpath.
> It should use ClassLoaderutil.releaseLoader(..) to unload the jars.
> GC does not reclaim the isolatedclassloader instances (not sure why).
> As a result, IsolatedClassloader instances consume retains the heap.
> Eventually maven-application goes OutOfMemory !
> Attached is the heapdump analysis of isolatedclassloader that holds the memory.
> This is kind of blocking us from building largescale maven app which requires good number of jars in development time for compiling the app source at development time.
> Please note that we face this issue at development time whenever developer making changes in source code as explained in the code-flow above.
> Please let us know if more information is required.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MCOMPILER-133) Facing OutOfMemory as
IsolatedClassloader (plexus-compiler jar) is not closed after JavacCompiler
is done with compilation.
Posted by "Benjamin Bentmann (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MCOMPILER-133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=234597#action_234597 ]
Benjamin Bentmann commented on MCOMPILER-133:
---------------------------------------------
IMHO, this is a won't fix on our side. The only {{ClassLoaderUtil}} I know of resides in a vendor-specific package (sun.misc.*) and its use would violate the Java principle. On the other hand, setting fork=true is an easy solution. One could raise this as an issue with the JRE being used (class loader not gc'ed).
> Facing OutOfMemory as IsolatedClassloader (plexus-compiler jar) is not closed after JavacCompiler is done with compilation.
> ---------------------------------------------------------------------------------------------------------------------------
>
> Key: MCOMPILER-133
> URL: http://jira.codehaus.org/browse/MCOMPILER-133
> Project: Maven 2.x Compiler Plugin
> Issue Type: Bug
> Environment: Windows 2003 Server
> Reporter: kaniska
> Priority: Blocker
> Attachments: IsolatedClassLoader_Issue.docx
>
>
> In Eclipse environment for a maven-based project, Auto-build fires Maven-build which in turn executes CompilerMojo, finally creating an IsolatedClassloader for each compile call !
> IsolatedClassLoader.addURL(URL) line: 42...
> JavacCompiler.compile(CompilerConfiguration) line: 141
> CompilerMojo(AbstractCompilerMojo).execute() line: 493...
> DefaultBuildPluginManager.executeMojo(MavenSession, MojoExecution) line: 105...
> MavenImpl.execute(MavenExecutionRequest, IProgressMonitor) ...
> MavenBuilder.build(int, Map, IProgressMonitor) line: 153 ....
> AutoBuildJob.run(IProgressMonitor) line: 238
> So every single change in maven-v4 project creates a new IsolatedClassloader which is fine.
> But the problem is JavacCompiler is not closing the loader which holds huge number of jars (url points to maven-repo) in its url classpath.
> It should use ClassLoaderutil.releaseLoader(..) to unload the jars.
> GC does not reclaim the isolatedclassloader instances (not sure why).
> As a result, IsolatedClassloader instances consume retains the heap.
> Eventually maven-application goes OutOfMemory !
> Attached is the heapdump analysis of isolatedclassloader that holds the memory.
> This is kind of blocking us from building largescale maven app which requires good number of jars in development time for compiling the app source at development time.
> Please note that we face this issue at development time whenever developer making changes in source code as explained in the code-flow above.
> Please let us know if more information is required.
--
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
[jira] (MCOMPILER-133) Facing OutOfMemory as IsolatedClassloader
(plexus-compiler jar) is not closed after JavacCompiler is done with
compilation.
Posted by "Mark Struberg (JIRA)" <ji...@codehaus.org>.
[ https://jira.codehaus.org/browse/MCOMPILER-133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=308503#comment-308503 ]
Mark Struberg commented on MCOMPILER-133:
-----------------------------------------
agree, setting to wont-fix
> Facing OutOfMemory as IsolatedClassloader (plexus-compiler jar) is not closed after JavacCompiler is done with compilation.
> ---------------------------------------------------------------------------------------------------------------------------
>
> Key: MCOMPILER-133
> URL: https://jira.codehaus.org/browse/MCOMPILER-133
> Project: Maven 2.x Compiler Plugin
> Issue Type: Bug
> Environment: Windows 2003 Server
> Reporter: kaniska
> Priority: Blocker
> Attachments: IsolatedClassLoader_Issue.docx
>
>
> In Eclipse environment for a maven-based project, Auto-build fires Maven-build which in turn executes CompilerMojo, finally creating an IsolatedClassloader for each compile call !
> IsolatedClassLoader.addURL(URL) line: 42...
> JavacCompiler.compile(CompilerConfiguration) line: 141
> CompilerMojo(AbstractCompilerMojo).execute() line: 493...
> DefaultBuildPluginManager.executeMojo(MavenSession, MojoExecution) line: 105...
> MavenImpl.execute(MavenExecutionRequest, IProgressMonitor) ...
> MavenBuilder.build(int, Map, IProgressMonitor) line: 153 ....
> AutoBuildJob.run(IProgressMonitor) line: 238
> So every single change in maven-v4 project creates a new IsolatedClassloader which is fine.
> But the problem is JavacCompiler is not closing the loader which holds huge number of jars (url points to maven-repo) in its url classpath.
> It should use ClassLoaderutil.releaseLoader(..) to unload the jars.
> GC does not reclaim the isolatedclassloader instances (not sure why).
> As a result, IsolatedClassloader instances consume retains the heap.
> Eventually maven-application goes OutOfMemory !
> Attached is the heapdump analysis of isolatedclassloader that holds the memory.
> This is kind of blocking us from building largescale maven app which requires good number of jars in development time for compiling the app source at development time.
> Please note that we face this issue at development time whenever developer making changes in source code as explained in the code-flow above.
> Please let us know if more information is required.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Moved: (MNG-4801) Facing OutOfMemory as IsolatedClassloader
(plexus-compiler jar) is not closed after JavacCompiler is done with
compilation.
Posted by "Lukas Theussl (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-4801?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Lukas Theussl moved MAVEN-1867 to MNG-4801:
-------------------------------------------
Complexity: Intermediate
Component/s: (was: core)
Affects Version/s: (was: 1.2)
Key: MNG-4801 (was: MAVEN-1867)
Project: Maven 2 & 3 (was: Maven 1)
> Facing OutOfMemory as IsolatedClassloader (plexus-compiler jar) is not closed after JavacCompiler is done with compilation.
> ---------------------------------------------------------------------------------------------------------------------------
>
> Key: MNG-4801
> URL: http://jira.codehaus.org/browse/MNG-4801
> Project: Maven 2 & 3
> Issue Type: Bug
> Environment: Windows 2003 Server
> Reporter: kaniska
> Priority: Blocker
> Attachments: IsolatedClassLoader_Issue.docx
>
>
> In Eclipse environment for a maven-based project, Auto-build fires Maven-build which in turn executes CompilerMojo, finally creating an IsolatedClassloader for each compile call !
> IsolatedClassLoader.addURL(URL) line: 42...
> JavacCompiler.compile(CompilerConfiguration) line: 141
> CompilerMojo(AbstractCompilerMojo).execute() line: 493...
> DefaultBuildPluginManager.executeMojo(MavenSession, MojoExecution) line: 105...
> MavenImpl.execute(MavenExecutionRequest, IProgressMonitor) ...
> MavenBuilder.build(int, Map, IProgressMonitor) line: 153 ....
> AutoBuildJob.run(IProgressMonitor) line: 238
> So every single change in maven-v4 project creates a new IsolatedClassloader which is fine.
> But the problem is JavacCompiler is not closing the loader which holds huge number of jars (url points to maven-repo) in its url classpath.
> It should use ClassLoaderutil.releaseLoader(..) to unload the jars.
> GC does not reclaim the isolatedclassloader instances (not sure why).
> As a result, IsolatedClassloader instances consume retains the heap.
> Eventually maven-application goes OutOfMemory !
> Attached is the heapdump analysis of isolatedclassloader that holds the memory.
> This is kind of blocking us from building largescale maven app which requires good number of jars in development time for compiling the app source at development time.
> Please note that we face this issue at development time whenever developer making changes in source code as explained in the code-flow above.
> Please let us know if more information is required.
--
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