groovy leaves many live class loaders in PermGen?

[David Coppit]

Hi all,

We're investigating why a relatively simple java app is using over 90MB of non-shared RAM with the Oracle HotSpot JVM. Yes, we know that in general it's a bad idea to second-guess the JVM's memory usage, but we're looking for any obvious inefficiences that we could quickly fix in order alleviate some concerns from the broader team.

Java info first:

# java -version
java version "1.7.0_40"
Java(TM) SE Runtime Environment (build 1.7.0_40-b43)
Java HotSpot(TM) 64-Bit Server VM (build 24.0-b56, mixed mode)

We've noticed that one of the major contributors appears to be groovy. If we remove jedis and slf4j, which indirectly use groovy, and also remove our direct usage of groovy, then the JVM loads about 500 classes instead of 2000, and our memory usage drops substantially. (About 700 of the loaded classes are for groovy stuff.)

Part of this could simply be code caching, but we also noticed that there were many groovy class loaders in PermGen -- all of which were live. Is this normal?

# jdk1.7.0_40/bin/jmap -permstat 19129
Attaching to process ID 19129, please wait...
Debugger attached successfully.
Server compiler detected.
JVM version is 24.0-b56
finding class loader instances ..done.
computing per loader stat ..done.
please wait.. computing liveness.....................................done.
class_loader    classes bytes   parent_loader   alive?  type

<bootstrap>     1051    6623888   null          live    <internal>
0x00000000f88c5998      12      232392  0x00000000e3012518      live    org/codehaus/groovy/runtime/callsite/CallSiteClassLoader@0x00000000ddf86520
0x00000000f86c8eb8      1670    12184192        0x00000000f86c8f08      live    sun/misc/Launcher$AppClassLoader@0x00000000dda0af78
0x00000000e2d727d8      12      268736  0x00000000f86c8eb8      live    org/codehaus/groovy/runtime/callsite/CallSiteClassLoader@0x00000000ddf86520
0x00000000f8825f10      16      913688  0x00000000f86c8eb8      live    org/codehaus/groovy/runtime/callsite/CallSiteClassLoader@0x00000000ddf86520
0x00000000f87e8930      12      270368    null          live    org/codehaus/groovy/runtime/callsite/CallSiteClassLoader@0x00000000ddf86520
0x00000000f88fe6a0      12      214968  0x00000000f86c8eb8      live    org/codehaus/groovy/runtime/callsite/CallSiteClassLoader@0x00000000ddf86520
0x00000000e2d3ef40      12      252304  0x00000000f86c8eb8      live    org/codehaus/groovy/runtime/callsite/CallSiteClassLoader@0x00000000ddf86520
0x00000000e2dd0660      12      261800  0x00000000f86c8eb8      live    org/codehaus/groovy/runtime/callsite/CallSiteClassLoader@0x00000000ddf86520
0x00000000f887aba0      12      246064  0x00000000f86c8eb8      live    org/codehaus/groovy/runtime/callsite/CallSiteClassLoader@0x00000000ddf86520
0x00000000e2d90768      13      238808  0x00000000f86c8eb8      live    org/codehaus/groovy/runtime/callsite/CallSiteClassLoader@0x00000000ddf86520
0x00000000f89b66e0      12      217872  0x00000000f86c8eb8      live    org/codehaus/groovy/runtime/callsite/CallSiteClassLoader@0x00000000ddf86520
0x00000000e2d4a088      12      247576  0x00000000f86c8eb8      live    org/codehaus/groovy/runtime/callsite/CallSiteClassLoader@0x00000000ddf86520
0x00000000f88f0ea0      11      220136  0x00000000f86c8eb8      live    org/codehaus/groovy/runtime/callsite/CallSiteClassLoader@0x00000000ddf86520
0x00000000e2ee2180      2       2064    0x00000000f86c8eb8      live    org/codehaus/groovy/reflection/SunClassLoader@0x00000000ddf66fb0
0x00000000f89e22b0      0       0       0x00000000f86c8eb8      live    java/util/ResourceBundle$RBClassLoader@0x00000000de345ec8
0x00000000e2e79bf8      0       0       0x00000000f86c8eb8      live    groovy/lang/GroovyClassLoader@0x00000000de010230
0x00000000f88fda38      14      853216  0x00000000f86c8eb8      live    org/codehaus/groovy/runtime/callsite/CallSiteClassLoader@0x00000000ddf86520
0x00000000f887b1d8      13      850512  0x00000000f86c8eb8      live    org/codehaus/groovy/runtime/callsite/CallSiteClassLoader@0x00000000ddf86520
0x00000000f896a3d0      15      887080    null          live    org/codehaus/groovy/runtime/callsite/CallSiteClassLoader@0x00000000ddf86520
0x00000000f882bee8      14      878576  0x00000000f86c8eb8      live    org/codehaus/groovy/runtime/callsite/CallSiteClassLoader@0x00000000ddf86520
0x00000000e3011d38      1       3024    0x00000000f86c8eb8      dead    sun/reflect/DelegatingClassLoader@0x00000000dd84f480
0x00000000f86c8f08      0       0         null          live    sun/misc/Launcher$ExtClassLoader@0x00000000dd99f4c0
0x00000000f880d4e0      11      245032    null          live    org/codehaus/groovy/runtime/callsite/CallSiteClassLoader@0x00000000ddf86520
0x00000000e2db91a8      11      229856  0x00000000f86c8eb8      live    org/codehaus/groovy/runtime/callsite/CallSiteClassLoader@0x00000000ddf86520
0x00000000e2d7ac88      12      223624  0x00000000f86c8eb8      live    org/codehaus/groovy/runtime/callsite/CallSiteClassLoader@0x00000000ddf86520
0x00000000f8810580      16      884440  0x00000000f86c8eb8      live    org/codehaus/groovy/runtime/callsite/CallSiteClassLoader@0x00000000ddf86520
0x00000000e3012518      35      389656  0x00000000e2e79bf8      live    groovy/lang/GroovyClassLoader$InnerLoader@0x00000000de0b3800

total = 28      3013    27839872            N/A         alive=27, dead=1            N/A

[David Coppit · Accepted solution]

Gah. I saw other threads on groovy and though this would be the best place for my question. I see now that I should be going directly to one of the groovy mailing lists at http://groovy.codehaus.org/Mailing+Lists.

Sorry for the churn.

In case anyone is interested, we found that using groovy-formatted logback config files for a simple Java app was causing tons of groovy classes to be loaded into the JVM, bloating the RSS by over 50 MB. Simply switching to XML addressed this.

[JamieA]

Does this relate to JIRA and the script runner plugin? Or are you talking about an arbitrary java app?