Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » Epsilon » PeriodicallyUpdateEPackageRegistryMonitorJob eats away heap
PeriodicallyUpdateEPackageRegistryMonitorJob eats away heap [message #922991] Tue, 25 September 2012 14:19 Go to next message
Maarten Bezemer is currently offline Maarten BezemerFriend
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 67 times)
Re: PeriodicallyUpdateEPackageRegistryMonitorJob eats away heap [message #923099 is a reply to message #922991] Tue, 25 September 2012 15:46 Go to previous messageGo to next message
Antonio Garcia-Dominguez is currently offline Antonio Garcia-DominguezFriend
Messages: 310
Registered: January 2010
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?
Re: PeriodicallyUpdateEPackageRegistryMonitorJob eats away heap [message #923124 is a reply to message #922991] Tue, 25 September 2012 16:10 Go to previous messageGo to next message
Maarten Bezemer is currently offline Maarten BezemerFriend
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
Re: PeriodicallyUpdateEPackageRegistryMonitorJob eats away heap [message #923738 is a reply to message #922991] Wed, 26 September 2012 06:35 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 4185
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
Re: PeriodicallyUpdateEPackageRegistryMonitorJob eats away heap [message #923897 is a reply to message #923738] Wed, 26 September 2012 09:41 Go to previous messageGo to next message
Maarten Bezemer is currently offline Maarten BezemerFriend
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)
Re: PeriodicallyUpdateEPackageRegistryMonitorJob eats away heap [message #923952 is a reply to message #923897] Wed, 26 September 2012 10:44 Go to previous messageGo to next message
Maarten Bezemer is currently offline Maarten BezemerFriend
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.
Re: PeriodicallyUpdateEPackageRegistryMonitorJob eats away heap [message #923961 is a reply to message #923897] Wed, 26 September 2012 10:47 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 4185
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)
Re: PeriodicallyUpdateEPackageRegistryMonitorJob eats away heap [message #924106 is a reply to message #923961] Wed, 26 September 2012 14:10 Go to previous messageGo to next message
Maarten Bezemer is currently offline Maarten BezemerFriend
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)
Re: PeriodicallyUpdateEPackageRegistryMonitorJob eats away heap [message #924108 is a reply to message #923961] Wed, 26 September 2012 14:13 Go to previous message
Maarten Bezemer is currently offline Maarten BezemerFriend
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:
  


Current Time: Thu Dec 18 18:31:39 GMT 2014

Powered by FUDForum. Page generated in 0.01982 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software