java - Can PermGen leak out into native heap? -


we running glassfish application below settings:

-xx:permsize=1g -xx:maxpermsize=2g -xms4g -xmx4g -xx:maxdirectmemorysize=1048576 

jdk version 6u45

we're observing memory leak - java process of glassfish grows - res getting > 15gb (our server has 16gb of physical memory, admins restart glassfish before hitting physical limits), never java.lang.outofmemoryerror.

the output of jmap -permstat after letting application run long time, showing classloaders occupying ~9.5gb (!!!):

class_loader    classes bytes   parent_loader   alive?  type  <bootstrap> 4242    24064120      null      live    <internal> 0x0000000794a4c030  20  274072  0x0000000794a4c098  dead    groovy/lang/groovyclassloader$innerloader@0x0000000609cdc9f0 ... <many, many groovy class loaders> 0x000000077f9c80d8  0   0   0x00000007017859f8  dead    groovy/lang/groovyclassloader@0x0000000609997f00 0x000000076d63b3e0  0   0   0x00000007017859f8  dead    groovy/lang/groovyclassloader@0x0000000609997f00 0x000000075a4c5248  20  261784  0x000000075a4c52b0  dead    groovy/lang/groovyclassloader$innerloader@0x0000000609cdc9f0 0x000000078ea2e998  0   0   0x00000007017859f8  dead    groovy/lang/groovyclassloader@0x0000000609997f00 ... total = 73518   745295  9690318280      n/a     alive=1, dead=73517     n/a     

at same time jmap -heap shows permgen using 700mb:

ps perm generation    capacity = 2147483648 (2048.0mb)    used     = 823831536 (785.6669769287109mb)    free     = 1323652112 (1262.333023071289mb)    38.362645357847214% used 

i thought using -xx:maxpermsize , -xmx can control how memory java process allocate (throwing oom in case needed more). understanding process should take to:

4g (heap) + 2g (permgen) + n*1mb (n thread's stacks) ~= 7.5g (by 500 threads) 

the question

we know leak comes old groovy version , missing permgen sweeping flags, how possible classloaders occupy 9.5gb of memory not belong neither permgen nor java heap?


edit

just clarification - question not how solve memory leak issue, it's how come jvm allows such memory allocation.

not of answer, however. tricky. aware jvm's going use wiggle room garbage collection (especially g1), metaspace : permgen in java8 ( not applicable in case), jit optimization, , direct buffers may reside outside of normal garbage-collected heap.

in either case, analyze heap dump see application behavior. bug in application in jvm. should let application run in outofmemory , see exact cause mentioned.


Comments

Popular posts from this blog

java - Andrioid studio start fail: Fatal error initializing 'null' -

android - Gradle sync Error:Configuration with name 'default' not found -

StringGrid issue in Delphi XE8 firemonkey mobile app -