[
https://issues.apache.org/jira/browse/GROOVY-7484?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14642913#comment-14642913
]
Jochen Theodorou commented on GROOVY-7484:
------------------------------------------
I took a look again and I am starting to understand the issue a bit better. You
create an URLClassLoader, which will also contain a complete Groovy runtime.
You do this a certain number of times, and then memory tuns out. The problem is
actually easy to solve with a workaround... share the runtime for the loaders.
Meaning make one classloader for the runtime, and one for the scripts as a
child to that loader. This way the classes of the runtime are shared.
As for why the OOME happens... that is a bit unclear still. The memory dump is
not 100% clear if this is about memory strongly referenced. There are some
candidates in bean classes we have no control over that may influence. But it
seems a huge part of memory is simply taken by the system class loader itself.
I am starting to think that the size of the groovy-jar is causing this. And
that you don't see a bean or class based memory leak, but a resource problem in
the classloaders. That too would be solved with my suggestion above.
> Permgen leak when load groovy classes via reflection
> ----------------------------------------------------
>
> Key: GROOVY-7484
> URL: https://issues.apache.org/jira/browse/GROOVY-7484
> Project: Groovy
> Issue Type: Bug
> Affects Versions: 2.4.3
> Reporter: Dmitry Baev
>
> PermGen leak when load groovy beans via reflection using different class
> loaders. Sample project to reproduce the problem
> https://github.com/baev/groovy-permgen-leak
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
