Eclipse Community Forums: VIATRA » Disadvantages of IMatchUpdateListener

Home » Modeling » VIATRA » Disadvantages of IMatchUpdateListener(Disadvantages of IMatchUpdateLIstener in comparison to Event-Driven VM)

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

Disadvantages of IMatchUpdateListener [message #1830468]

Mon, 27 July 2020 12:45

Nadine Rösl

Messages: 3
Registered: July 2020

Junior Member

Hey,

I'm currently evaluating if Viatra is applicable for our project. We want to monitor an EMF model and get notified immediately if there are model changes. If so, another target model is "invalidated" (flags in the corresponding target model are set), but not updated directly. The target model itself is not queried with Viatra.

Viatra seemed like a fast and easy way to get notified about model changes via the Event-driven VM especially if there are complex relations over multiple objects. But using our EMF model the memory consumption is too high for our requirements. As an alternative we tested the IMatchUpdateListeners together with the advanced query engine and got much better results regarding the memory consumption.

The documentation mentions, that this approach is risky to use:
Be very careful when using match update listeners, as sometimes they are called while the model indexes are in an inconsistent state. For this reason, do not update the underlying model and do not execute further model queries. (Tutorial Section 3.2.4.1)

What does this mean exactly? In which cases does such an inconsistent state occur?
Are there any further downsides or problems using IMatchUpdateListener, if the model is not queried or modified when the listener is notified?

One difference I found were the events triggered on model change. With the Event-driven VM you can catch various events/activation states whereas with the IMatchUpdateListeners there are only Appear and Disappear Notifications for a match. But this seems alright for our usecase.

Thanks in advance,
Nadine

Report message to a moderator

Re: Disadvantages of IMatchUpdateListener [message #1830475 is a reply to message #1830468]

Mon, 27 July 2020 13:35

Gabor Bergmann

Messages: 36
Registered: July 2009

Member

Hi Nadine,

Nadine Rösl wrote on Mon, 27 July 2020 14:45

The documentation mentions, that this approach is risky to use:
Be very careful when using match update listeners, as sometimes they are called while the model indexes are in an inconsistent state. For this reason, do not update the underlying model and do not execute further model queries. (Tutorial Section 3.2.4.1)

What does this mean exactly? In which cases does such an inconsistent state occur?

IMatchUpdateListener is invoked in the midst of EMF delivering its change notifications and Viatra Query updating its stored query results. If you request query results at this point (in the body of either of the interface methods), you may get unpredictable results.

Nadine Rösl wrote on Mon, 27 July 2020 14:45

Are there any further downsides or problems using IMatchUpdateListener, if the model is not queried or modified when the listener is notified?

I can only think of one: transients.

Quick example: imagine an EMF database of people with residence addresses and marriages. Assume a VQL pattern "cohabitingMarriedCouple" that looks for marriages where both spouses cohabit at the same address of residence. If a couple moves from town A to town B and you correspondingly update the residence fields of the two EMF objects representing the two persons, there will be a short transient where one spouse is already updated to the new address but the other one is not. IMatchUpdateListener will let you observe the disappearance of this match of "cohabitingMarriedCouple", and then its re-appearance - even though this is just a short-term transient.

If you modify your output model in a way that the final state of that model depends only on the final query result sets, independently of the exact sequence of transient notifications received, then you should be OK.

Nadine Rösl wrote on Mon, 27 July 2020 14:45

But using our EMF model the memory consumption is too high for our requirements

Just out of curiosity: How large are your models? How many matches do you have of your main patterns (especially those you use as direct preconditions to the rules updating the target model)? What are our memory limits?

It is really surprising that a given set of patterns fit into your memory limits with incremental pattern matching, but the supposedly small overhead of the EVM pushes it through the limit.

Cheers,
Gábor

Report message to a moderator

Re: Disadvantages of IMatchUpdateListener [message #1830514 is a reply to message #1830475]

Tue, 28 July 2020 08:28

Nadine Rösl

Messages: 3
Registered: July 2020

Junior Member

Hey,

Thanks for the quick response. It seems like IMatchUpdateListeners is a good approach for our usecase, as we only catch notifications to invalidate the affected objects in the target model and execute our model transfomation later.

Regarding the memory consumption:
We want to integrate Viatra in an already existing software. As our source and target model are quiet big, we don't want to spend lots of memory for Viatra on top of that. For example: Both models can contain around 50 000 instances of some model elements. So we have multiple queries with large amount of matches.

If you're interested, I have attached some measurements right below with a typical model and typical queries for our project. The scaling is different for the different diagrams.
For the used model two queries exist with 100 000 matches (among others).
On the left you see the memory consumption when loading our source model into the memory, waiting a bit and then unloading it.
In the middle the same model is loaded and an advanced viatra query engine with our queries and IMatchUpdateListeners is created. After some time engine and model are unloaded.
On the right the viatra query engine is used with an EVM and corresponding jobs to our queries instead of IMatchUpdateListeners.
Neither the listeners nor the jobs perform any action.

Especially when initializing the engine or when performing lots of model changes the Listeners seemed to have less and smaller peaks in the memory consumption.

Regards,
Nadine

Attachment: memory_consumption.PNG
(Size: 49.82KB, Downloaded 85 times)

Report message to a moderator

Re: Disadvantages of IMatchUpdateListener [message #1830519 is a reply to message #1830514]

Tue, 28 July 2020 10:38

Gabor Bergmann

Messages: 36
Registered: July 2009

Member

Hey,

I am pretty sure what you are measuring here is total heap consumption at any given moment. In addition to the actual memory footprint of the Java program (strongly reachable objects), it also includes unreachable objects (garbage) which are temporary heap objects that are no longer needed and have simply not been cleaned up by the Garbage Collector (GC) yet. While a large volume of garbage objects do have a negative impact on performance in a roundabout way (slightly increasing the cost of GC), but it is misleading to think of the program as requiring that much excess memory.

A more reliable way of measuring memory is to use a profiler to take a memory dump of the Java VM, and compute the strongly reachable size according to this dump. Or, if you use such a live chart, at least hit "Perform GC" in the steady state to see how much of the heap is actually strongly reachable. There is a segment in your third figure that suggests a fairly moderate heap size, around 3-400 MB (but I do not know whether everything was already loaded here).

Cheers,
Gábor

Report message to a moderator

Re: Disadvantages of IMatchUpdateListener [message #1830521 is a reply to message #1830519]

Tue, 28 July 2020 12:12

Nadine Rösl

Messages: 3
Registered: July 2020

Junior Member

Hi,
I forgot to mention it: the garbage collector was explicitly called after the initialization of the engines and after disposing. Without that, the diagram for the EVM looks worse (then you wouldn't see the segment where it stays at 3-400MB).

So perhaps the memory consumption is pretty equal, when the engine is initialized and only some small changes are made. But before that or when working with the model extensively the differences are visible. I attached another example (like before: left: without Viatra, middle: with Listeners, right: with EVM).
The scenario for this example was:
- Load Model
- Initialize Engine (if used)
- Garbage Collector
- Delete 10 000 entities (which are part of multiple matches of different queries)
- Dispose engine
- Garbage Collector

This is perhaps not the most common use case, but we wanted to know, how Viatra would react in such cases. Even if these are just temporarly peaks in memory consumption, it's interessting to see those differences.

Cheers,
Nadine

Attachment: memory_consumption_2.PNG
(Size: 45.65KB, Downloaded 73 times)

Report message to a moderator

Previous Topic:	Support for transitive closure maintenance via IncSCC
Next Topic:	Can't Find Specific VIATRA Paper Again

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Thu Apr 18 23:00:01 GMT 2024

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter