Eclipse Community Forums: Epsilon » PeriodicallyUpdateEPackageRegistryMonitorJob eats away heap

Home » Modeling » Epsilon » PeriodicallyUpdateEPackageRegistryMonitorJob eats away heap

PeriodicallyUpdateEPackageRegistryMonitorJob eats away heap [message #922991]

Tue, 25 September 2012 10:19

Eclipse User

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 211 times)

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

Tue, 25 September 2012 11:46

Eclipse User

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?

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

Tue, 25 September 2012 12:10

Eclipse User

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

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

Wed, 26 September 2012 02:35

Eclipse User

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

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

Wed, 26 September 2012 05:41

Eclipse User

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)

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

Wed, 26 September 2012 06:44

Eclipse User

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.

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

Wed, 26 September 2012 06:47

Eclipse User

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)

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

Wed, 26 September 2012 10:10

Eclipse User

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)

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

Wed, 26 September 2012 10:13

Eclipse User

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 10:13] by Moderator

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

Goto Forum:

-=] Back to Top [=-

Current Time: Tue Jul 22 18:01:00 EDT 2025

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter