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
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.
Does this relate to JIRA and the script runner plugin? Or are you talking about an arbitrary java app?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.