You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@groovy.apache.org by "Vladimir Sitnikov (JIRA)" <ji...@apache.org> on 2015/07/19 16:37:04 UTC
[jira] [Comment Edited] (GROOVY-7498) Native memory leak
[ https://issues.apache.org/jira/browse/GROOVY-7498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14632828#comment-14632828 ]
Vladimir Sitnikov edited comment on GROOVY-7498 at 7/19/15 2:36 PM:
--------------------------------------------------------------------
[~mkuchin], Can you please try looking into a heap dump?
Can you probably share a heap dump? (well, that might include sensitive information, so be careful if you do so)
I happen to benchmark JMeter-JSR223-Groovy stack and it turns out Groovy generated classes leak in a rather interesting way.
The attached !jmeter_jsr223_groovy_leak.png! is a "incoming references to Script15934.
The mechanics is as follows:
{noformat}
Thread -> ThreadGroupContext -WeakHashMap beanInfoCache-> ...
java.beans.MethodDescriptor -SoftReference methodRef->
java.lang.reflect.Method -> class
{noformat}
Even though groovy keeps all its references to the generated class/classLoader safely behind {{WeakReferences}}, java beans cache messes that up by having non-weak reference to the class.
I am not sure if that is related to the original problem, however that looks like a deadly combo of groovy + javabeans.
It looks like {{java.beans.MethodRef.methodRef}} should be weak, not soft.
Just in case: the dump above was taken with Groovy 2.4.3, OracleJDK 1.8.0_40-b25, JMeter 2.13
was (Author: vladimirsitnikov):
[~mkuchin], Can you please try looking into a heap dump?
Can you probably share a heap dump? (well, that might include sensitive information, so be careful if you do so)
I happen to benchmark JMeter-JSR223-Groovy stack and it turns out Groovy generated classes leak in a rather interesting way.
The attached !jmeter_jsr223_groovy_leak.png! is a "incoming references to Script15934.
The mechanics is as follows:
{noformat}
Thread -> ThreadGroupContext -WeakHashMap beanInfoCache-> ...
java.beans.MethodDescriptor -SoftReference methodRef->
java.lang.reflect.Method -> class
{noformat}
Even though groovy keeps all its references to the generated class/classLoader safely behind {{WeakReferences}}, java beans cache messes that up by having non-weak reference to the class.
I am not sure if that is related to the original problem, however that looks like a deadly combo of groovy + javabeans.
It looks like {{java.beans.MethodRef.methodRef}} should be weak, not soft.
> Native memory leak
> ------------------
>
> Key: GROOVY-7498
> URL: https://issues.apache.org/jira/browse/GROOVY-7498
> Project: Groovy
> Issue Type: Bug
> Affects Versions: 2.3.11
> Environment: Ubuntu 14.04 , grails 2.4.5 java 1.7.0_80, tomcat 7.0.56
> Reporter: Max Kuchin
> Attachments: jmeter_jsr223_groovy_leak.png
>
>
> We are experiencing JVM native memory leak after upgrading our web application from grails 2.4.4 (groovy 2.3.7) to grails 2.4.5 (groovy 2.3.11).
> It disappears if we replace groovy-all-2.3.11.jar in web application with groovy-all-2.3.7.jar.
> As a result of the leak JVM native memory usage can grow to 4G in two weeks after start of web application.
> We'd enabled native memory tracking (-XX:NativeMemoryTracking=detail) to gather some details. Here are results of native memory summary snapshot made with command jcmd pid VM.native_memory summary
> Native memory summary after start of application:
> Total: reserved=6039782KB, committed=6039342KB
> - Java Heap (reserved=5447680KB, committed=5447680KB)
> (mmap: reserved=5447680KB, committed=5447680KB)
> - Class (reserved=2944KB, committed=2944KB)
> (classes #19490)
> (malloc=2944KB, #56242)
> - Thread (reserved=131202KB, committed=131202KB)
> (thread #127)
> (stack: reserved=130556KB, committed=130556KB)
> (malloc=402KB, #515)
> (arena=244KB, #254)
> - Code (reserved=54669KB, committed=54261KB)
> (malloc=4749KB, #7615)
> (mmap: reserved=49920KB, committed=49512KB)
> - GC (reserved=350261KB, committed=350261KB)
> (malloc=148081KB, #28742)
> (mmap: reserved=202180KB, committed=202180KB)
> - Compiler (reserved=399KB, committed=399KB)
> (malloc=301KB, #480)
> (arena=98KB, #2)
> - Internal (reserved=14366KB, committed=14334KB)
> (malloc=14334KB, #21616)
> (mmap: reserved=32KB, committed=0KB)
> - Symbol (reserved=20911KB, committed=20911KB)
> (malloc=17355KB, #180610)
> (arena=3556KB, #1)
> - Memory Tracking (reserved=14986KB, committed=14986KB)
> (malloc=14986KB, #492)
> - Pooled Free Chunks (reserved=2365KB, committed=2365KB)
> (malloc=2365KB)
> One day after start:
>
> Total: reserved=6610742KB , committed=6610518KB
> - Java Heap (reserved=5447680KB, committed=5447680KB)
> (mmap: reserved=5447680KB, committed=5447680KB)
> - Class (reserved=5525KB, committed=5525KB)
> (classes #21209)
> (malloc=5525KB, #71960)
> - Thread (reserved=646KB, committed=646KB)
> (thread #127)
> (stack: reserved=130556KB, committed=130556KB)
> (malloc=402KB +13KB, #515)
> (arena=244KB +8KB, #254)
> - Code (reserved=58182KB, committed=57990KB)
> (malloc=8262KB, #11074)
> (mmap: reserved=49920KB, committed=49728KB)
> - GC (reserved=423906KB, committed=423906KB)
> (malloc=221726KB, #82681)
> (mmap: reserved=202180KB, committed=202180KB)
> - Compiler (reserved=440KB, committed=440KB)
> (malloc=342KB +20KB, #513)
> (arena=98KB, #2)
> - Internal (reserved=472055KB, committed=472023KB)
> (malloc=472023KB, #746397)
> (mmap: reserved=32KB, committed=0KB)
> - Symbol (reserved=21668KB +7KB, committed=21668KB +7KB)
> (malloc=17760KB +7KB, #185311)
> (arena=3908KB, #1)
> - Memory Tracking (reserved=49894KB, committed=49894KB)
> (malloc=49894KB +2464KB, #536)
> - Pooled Free Chunks (reserved=191KB, committed=191KB)
> (malloc=191KB)
> There is substantial increase in Internal memory usage and object count:
> 14366KB, #21616 -> 472023KB, #746397
> Native memory summary, one day after start, same application, different groovy version (groovy-all-2.3.7.jar):
> Total: reserved=6098509KB, committed=6099309KB
> - Java Heap (reserved=5447680KB, committed=5447680KB)
> (mmap: reserved=5447680KB, committed=5447680KB)
> - Class (reserved=6263KB, committed=6263KB)
> (classes #21179)
> (malloc=6263KB, #71507)
> - Thread (reserved=117771KB, committed=118799KB)
> (thread #114)
> (stack: reserved=117192KB, committed=118220KB)
> (malloc=360KB, #463)
> (arena=219KB, #228)
> - Code (reserved=58131KB, committed=57935KB)
> (malloc=8211KB, #10858)
> (mmap: reserved=49920KB, committed=49724KB)
> - GC (reserved=383041KB, committed=383041KB)
> (malloc=180861KB, #80128)
> (mmap: reserved=202180KB, committed=202180KB)
> - Compiler (reserved=268KB, committed=268KB)
> (malloc=170KB, #313)
> (arena=98KB, #2)
> - Internal (reserved=41336KB, committed=41304KB)
> (malloc=41304KB, #69639)
> (mmap: reserved=32KB, committed=0KB)
> - Symbol (reserved=21696KB, committed=21696KB)
> (malloc=17788KB, #185505)
> (arena=3908KB, #1)
> - Memory Tracking (reserved=22135KB, committed=22135KB)
> (malloc=22135KB, #432)
> - Pooled Free Chunks (reserved=189KB, committed=189KB)
> (malloc=189KB)
> Internal memory consumption, one day after start, comparing groovy 2.3.7 to groovy 2.3.11:
> 41336KB, #69639 - groovy 2.3.7
> 472023KB, #746397 - groovy 2.3.11, more than 10 times increase.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)