Eclipse Community Forums: Epsilon » PeriodicallyUpdateEPackageRegistryMonitorJob eats away heap

Help

Home

Home » Modeling » Epsilon » PeriodicallyUpdateEPackageRegistryMonitorJob eats away heap

Show: Today's Messages :: Show Polls :: Message Navigator

PeriodicallyUpdateEPackageRegistryMonitorJob eats away heap [message #922991]

Tue, 25 September 2012 14:19

Maarten Bezemer

Messages: 117
Registered: February 2012

Senior Member

Hello,

When my editor (that uses epsilon for EVL and EGL) is sitting idly (no models are opened), I have problems with my heap getting larger and larger until the GC kicks in to reduce it. This results in a saw-tooth shape when using VisualVM to analyze the problem. (See attachment)

When I disable (paused thread by placing a breakpoint) that runs PeriodicallyUpdateEPackageRegistryMonitorJob the heap does increase at a much lower pace (see attachment were the saw-tooth slope is less steep).

I have no idea what this job is doing, besides caching something (I am not even using concordance I believe. It is just installed) and eating away my heap.

(I know there are other problems, as the saw-tooth is still there)

Is this a know problem or did I do something wrong?

Greetings,
Maarten

Attachment: heap.png
(Size: 19.50KB, Downloaded 181 times)

Report message to a moderator

Re: PeriodicallyUpdateEPackageRegistryMonitorJob eats away heap [message #923099 is a reply to message #922991]

Tue, 25 September 2012 15:46

Antonio Garcia-Dominguez

Messages: 594
Registered: January 2010
Location: Birmingham, UK

Senior Member

Apparently, that class is started as soon as you launch Epsilon and it doesn't really depend on having the Concordance nature set or not. It's using the org.eclipse.ui.startup extension point, and is scheduled to poll the EPackage registry every second.

This looks like a memory leak, but it's not quite clear where it is happening. Could you provide heap dumps for the basic memory usage and the bumps right before GC kicks in? That would be quite useful.

I would also suggest querying the EPackage registry less often. I don't think we need to query it every second. Shouldn't 2 or 5 seconds be enough?

Report message to a moderator

Re: PeriodicallyUpdateEPackageRegistryMonitorJob eats away heap [message #923124 is a reply to message #922991]

Tue, 25 September 2012 16:10

Maarten Bezemer

Messages: 117
Registered: February 2012

Senior Member

I suppose during the EPackage polling lots of objects (of large) classes are created and abandoned in order to get the differences.

As the heapdumps that (VisualVM creates) are quite large, I did not attach them here.

http://dl.dropbox.com/u/9671810/heapdump-normal.hprof
is the heapdump when the polling mechanism is blocked with a breakpoint

http://dl.dropbox.com/u/9671810/heapdump-concordance.hprof
is the heapdump when the polling mechanism is running

Please let me know if I should provide more details

Report message to a moderator

Re: PeriodicallyUpdateEPackageRegistryMonitorJob eats away heap [message #923738 is a reply to message #922991]

Wed, 26 September 2012 06:35

Ed Willink

Messages: 7655
Registered: July 2009

Senior Member

Hi

I think this is a parasitic behaviour of the communication
infrastructure. I see the same thing when profiling MDT/OCL JUnit tests
that are stalled at a breakpoint; no Epsilon at all; single EMF thread
suspended.

Regards

Ed Willink

On 25/09/2012 15:19, Maarten Bezemer wrote:
> Hello,
>
> When my editor (that uses epsilon for EVL and EGL) is sitting idly (no models are opened), I have problems with my heap getting larger and larger until the GC kicks in to reduce it. This results in a saw-tooth shape when using VisualVM to analyze the problem. (See attachment)
>
> When I disable (paused thread by placing a breakpoint) that runs PeriodicallyUpdateEPackageRegistryMonitorJob the heap does increase at a much lower pace (see attachment were the saw-tooth slope is less steep).
>
> I have no idea what this job is doing, besides caching something (I am not even using concordance I believe. It is just installed) and eating away my heap.
>
> (I know there are other problems, as the saw-tooth is still there)
>
> Is this a know problem or did I do something wrong?
>
> Greetings,
> Maarten

Report message to a moderator

Re: PeriodicallyUpdateEPackageRegistryMonitorJob eats away heap [message #923897 is a reply to message #923738]

Wed, 26 September 2012 09:41

Maarten Bezemer

Messages: 117
Registered: February 2012

Senior Member

Ed Willink wrote on Wed, 26 September 2012 08:35

Hi
I think this is a parasitic behaviour of the communication
infrastructure. I see the same thing when profiling MDT/OCL JUnit tests
that are stalled at a breakpoint; no Epsilon at all; single EMF thread
suspended.

So just setting a breakpoint in the Job is not a good way to check if it is the cause of the massive heap usage? (Note that Eclispe and my editor are still properly working when I used the breakpoint)

Any other ideas on how to temporally stop this code (without uninstalling Concordance/Epsilon)

Report message to a moderator

Re: PeriodicallyUpdateEPackageRegistryMonitorJob eats away heap [message #923952 is a reply to message #923897]

Wed, 26 September 2012 10:44

Maarten Bezemer

Messages: 117
Registered: February 2012

Senior Member

I went and manually removed all org.eclipse.epsilon.concordance.* plugins and features from my installation (as I do not require them).
This also prevent the described problem, so I suppose that concordance actually does have something to do with the growing heap problem...

For now I'll leave at this, as I do not require these features. But, please let me know what else I can do to help out and I'll put concordance back in to test/try out things.

Report message to a moderator

Re: PeriodicallyUpdateEPackageRegistryMonitorJob eats away heap [message #923961 is a reply to message #923897]

Wed, 26 September 2012 10:47

Ed Willink

Messages: 7655
Registered: July 2009

Senior Member

Hi

As I suggested, I think the leak is in the communications infrastructure.

Perhaps the server thread by which VisualVM communicates is continually
allocating new packet buffers, which are available for GC when the GC
kicks in.

I generally take a heap dump as soon as I have done a manual GC and then
just filter by interesting package paths.

Regards

Ed Willink

On 26/09/2012 10:41, Maarten Bezemer wrote:
> Ed Willink wrote on Wed, 26 September 2012 08:35
>> Hi
>> I think this is a parasitic behaviour of the communication
>> infrastructure. I see the same thing when profiling MDT/OCL JUnit
>> tests that are stalled at a breakpoint; no Epsilon at all; single EMF
>> thread suspended.
>
>
> So just setting a breakpoint in the Job is not a good way to check if
> it is the cause of the massive heap usage? (Note that Eclispe and my
> editor are still properly working when I used the breakpoint)
>
> Any other ideas on how to temporally stop this code (without
> uninstalling Concordance/Epsilon)

Report message to a moderator

Re: PeriodicallyUpdateEPackageRegistryMonitorJob eats away heap [message #924106 is a reply to message #923961]

Wed, 26 September 2012 14:10

Maarten Bezemer

Messages: 117
Registered: February 2012

Senior Member

Hello Ed,

The leaks are also present without VisualVM (I noticed when I the 'Show heap status' setting on in the Eclipse preferences), so it might be possible that VisualVM adds additional leaks, there are definitely one or more present in the Epsilon concordance code (as they disappeared when I removed the concordance plugins/features).

I'll try your hint to make a heap dump directly after a manual GC and see whether the heap looks different (less clutter from non relevant parts)

Report message to a moderator

Re: PeriodicallyUpdateEPackageRegistryMonitorJob eats away heap [message #924108 is a reply to message #923961]

Wed, 26 September 2012 14:13

Maarten Bezemer

Messages: 117
Registered: February 2012

Senior Member

Ed Willink wrote on Wed, 26 September 2012 12:47

As I suggested, I think the leak is in the communications infrastructure.

Perhaps the server thread by which VisualVM communicates is continually
allocating new packet buffers, which are available for GC when the GC
kicks in.

This might be the case, but I noticed the leak(s) before I knew of VisualVM. So it might be the case that VisualVM adds additional leaks, there is definitely one (or more) present in Epsilon concordance (as it disappeared when I removed the plugins/features)

Ed Willink wrote on Wed, 26 September 2012 12:47

I generally take a heap dump as soon as I have done a manual GC and then
just filter by interesting package paths.

Thanks for the hint, I'll try this and see whether it becomes more clear what causes the problems.

[Updated on: Wed, 26 September 2012 14:13]

Report message to a moderator

Previous Topic:	EGL-EGL model transformations using ETL?
Next Topic:	EGL only write file on changes

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Fri Apr 19 05:23:01 GMT 2024

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter