[JBoss JIRA] (JBIDE-20750) Slow Memory Leak in JSF tools
by Viacheslav Kabanovich (JIRA)
[ https://issues.jboss.org/browse/JBIDE-20750?page=com.atlassian.jira.plugi... ]
Viacheslav Kabanovich edited comment on JBIDE-20750 at 9/22/15 11:38 PM:
-------------------------------------------------------------------------
I have found one reference to KbProject object that is not released, so the memory leak exists and technically can be resolved by removing this reference only.
When testing results, I compared this solution with the other where also method dispose() was implemented on KbObject.
It turns out that if objects are released for garbage collection in few large structures (like the entire KbProject), JVM may 'tolerate' them as long as it approaches memory limit. On the other hand, if large structures are dissected into 'atoms', JVM may invoke garbage collector even if these objects take in total just a couple of Mb.
was (Author: scabanovich):
I have found one reference to KbProject object that is not released, so the memory leak exists and technically can be resolved by removing this reference only.
When testing results, I compared this solution with the other where also method dispose() was implemented on KbObject.
It turns out that if objects are released for garbage collection in few large structures (like the entire KbObject), JVM may 'tolerate' them as long as it approaches memory limit. On the other hand, if large structures are dissected into 'atoms', JVM may invoke garbage collector even if these objects take in total just a couple of Mb.
> Slow Memory Leak in JSF tools
> -----------------------------
>
> Key: JBIDE-20750
> URL: https://issues.jboss.org/browse/JBIDE-20750
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: jsf
> Affects Versions: 4.3.0.CR1
> Reporter: Denis Golovin
> Assignee: Viacheslav Kabanovich
> Priority: Critical
> Fix For: 4.3.1.Final, 4.4.0.Alpha1
>
> Attachments: .log, heap-snapshot1.png, heap-snapshot2.png, mem-usage.png, oom1.png, oom2.png
>
>
> Opening then closing jsf projects slowly consumes heap memory, whish leads to slowing down overal performance and eventually to GC overhead limit exceeded exceptions.
> Attached screenshot list:
> 1. GC overhead limit exceeded error [^oom1.png];
> 2. Heap Memory Usage timeline [^mem-usage.png];
> 3. Heap Memory Objects filtered for "org.jboss.tools" [^heap-snapshot2.png];
> 4. Heap Memory Objects none filtered [^heap-snapshot1.png];
> 5. OOM Dialog [^oom2.png]ж
> 6. [^.log]
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months
[JBoss JIRA] (JBIDE-20750) Slow Memory Leak in JSF tools
by Viacheslav Kabanovich (JIRA)
[ https://issues.jboss.org/browse/JBIDE-20750?page=com.atlassian.jira.plugi... ]
Viacheslav Kabanovich edited comment on JBIDE-20750 at 9/22/15 11:38 PM:
-------------------------------------------------------------------------
I have found one reference to KbProject object that is not released, so the memory leak exists and technically can be resolved by removing this reference only.
When testing results, I compared this solution with the other where also method dispose() was implemented on KbObject.
It turns out that if objects are released for garbage collection in few large structures (like the entire KbProject), JVM may 'tolerate' them as long as it approaches the memory limit. On the other hand, if large structures are dissected into 'atoms', JVM may invoke garbage collector even if these objects take in total just a couple of Mb.
was (Author: scabanovich):
I have found one reference to KbProject object that is not released, so the memory leak exists and technically can be resolved by removing this reference only.
When testing results, I compared this solution with the other where also method dispose() was implemented on KbObject.
It turns out that if objects are released for garbage collection in few large structures (like the entire KbProject), JVM may 'tolerate' them as long as it approaches memory limit. On the other hand, if large structures are dissected into 'atoms', JVM may invoke garbage collector even if these objects take in total just a couple of Mb.
> Slow Memory Leak in JSF tools
> -----------------------------
>
> Key: JBIDE-20750
> URL: https://issues.jboss.org/browse/JBIDE-20750
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: jsf
> Affects Versions: 4.3.0.CR1
> Reporter: Denis Golovin
> Assignee: Viacheslav Kabanovich
> Priority: Critical
> Fix For: 4.3.1.Final, 4.4.0.Alpha1
>
> Attachments: .log, heap-snapshot1.png, heap-snapshot2.png, mem-usage.png, oom1.png, oom2.png
>
>
> Opening then closing jsf projects slowly consumes heap memory, whish leads to slowing down overal performance and eventually to GC overhead limit exceeded exceptions.
> Attached screenshot list:
> 1. GC overhead limit exceeded error [^oom1.png];
> 2. Heap Memory Usage timeline [^mem-usage.png];
> 3. Heap Memory Objects filtered for "org.jboss.tools" [^heap-snapshot2.png];
> 4. Heap Memory Objects none filtered [^heap-snapshot1.png];
> 5. OOM Dialog [^oom2.png]ж
> 6. [^.log]
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months
[JBoss JIRA] (JBIDE-20750) Slow Memory Leak in JSF tools
by Viacheslav Kabanovich (JIRA)
[ https://issues.jboss.org/browse/JBIDE-20750?page=com.atlassian.jira.plugi... ]
Viacheslav Kabanovich commented on JBIDE-20750:
-----------------------------------------------
I have found one reference to KbProject object that is not released, so the memory leak exists and technically can be resolved by removing this reference only.
When testing results, I compared this solution with the other where also method dispose() was implemented on KbObject.
It turns out that if objects are released for garbage collection in few large structures (like the entire KbObject), JVM may 'tolerate' them as long as it approaches memory limit. On the other hand, if large structures are dissected into 'atoms', JVM may invoke garbage collector even if these objects take in total just a couple of Mb.
> Slow Memory Leak in JSF tools
> -----------------------------
>
> Key: JBIDE-20750
> URL: https://issues.jboss.org/browse/JBIDE-20750
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: jsf
> Affects Versions: 4.3.0.CR1
> Reporter: Denis Golovin
> Assignee: Viacheslav Kabanovich
> Priority: Critical
> Fix For: 4.3.1.Final, 4.4.0.Alpha1
>
> Attachments: .log, heap-snapshot1.png, heap-snapshot2.png, mem-usage.png, oom1.png, oom2.png
>
>
> Opening then closing jsf projects slowly consumes heap memory, whish leads to slowing down overal performance and eventually to GC overhead limit exceeded exceptions.
> Attached screenshot list:
> 1. GC overhead limit exceeded error [^oom1.png];
> 2. Heap Memory Usage timeline [^mem-usage.png];
> 3. Heap Memory Objects filtered for "org.jboss.tools" [^heap-snapshot2.png];
> 4. Heap Memory Objects none filtered [^heap-snapshot1.png];
> 5. OOM Dialog [^oom2.png]ж
> 6. [^.log]
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months
[JBoss JIRA] (JBIDE-20760) docker feature not included in Marketplace entry for JBoss Tools
by Denis Golovin (JIRA)
[ https://issues.jboss.org/browse/JBIDE-20760?page=com.atlassian.jira.plugi... ]
Denis Golovin commented on JBIDE-20760:
---------------------------------------
+1 to live with original feature with a disabled update site, it is not that bad as it would be enabled.
> docker feature not included in Marketplace entry for JBoss Tools
> ----------------------------------------------------------------
>
> Key: JBIDE-20760
> URL: https://issues.jboss.org/browse/JBIDE-20760
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: marketplace
> Affects Versions: 4.3.0.CR1
> Reporter: Nick Boldt
> Assignee: Nick Boldt
> Labels: xtriage
> Fix For: 4.3.0.Final
>
> Attachments: 20760.png
>
>
> Because we removed the docker feature and replaced it with the docker plugins in order to avoid the odious problem of a disabled update site appearing in Eclipse's list of Available Update Sites, we no longer have a way to provide the docker tooling via our Marketplace entry.
> Solution:
> 1. Stop caring if there's an extra *disabled* update site in Eclipse when we install JBT (there's a disabled Mylyn one there too, plus 4 enabled ones for Mars, Mylyn, Eclipse, and WTP, so what's one more?).
> 2. Use the Docker Tooling feature in JBT's CoreTools category & on the Marketplace entry (as we did for Beta2).
> Then, for JBDS, we continue to just use the plugins and include them in the com.jboss.devstudio.core.feature so they're installed OOTB via the BYOE / Core feature (and also via Marketplace).
> Sound good?
> Alternative solutions:
> a. Create a new feature wrapper, just to contain the docker plugins
> b. Update some JBT plugins to depend on the docker plugins so they get installed along with the existing JBT plugin
> c. do nothing
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months