Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » VIATRA » Disadvantages of IMatchUpdateListener(Disadvantages of IMatchUpdateLIstener in comparison to Event-Driven VM)
Disadvantages of IMatchUpdateListener [message #1830468] Mon, 27 July 2020 12:45 Go to next message
Nadine Rösl is currently offline Nadine RöslFriend
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
Re: Disadvantages of IMatchUpdateListener [message #1830475 is a reply to message #1830468] Mon, 27 July 2020 13:35 Go to previous messageGo to next message
Gabor Bergmann is currently offline Gabor BergmannFriend
Messages: 35
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
Re: Disadvantages of IMatchUpdateListener [message #1830514 is a reply to message #1830475] Tue, 28 July 2020 08:28 Go to previous messageGo to next message
Nadine Rösl is currently offline Nadine RöslFriend
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
Re: Disadvantages of IMatchUpdateListener [message #1830519 is a reply to message #1830514] Tue, 28 July 2020 10:38 Go to previous messageGo to next message
Gabor Bergmann is currently offline Gabor BergmannFriend
Messages: 35
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
Re: Disadvantages of IMatchUpdateListener [message #1830521 is a reply to message #1830519] Tue, 28 July 2020 12:12 Go to previous message
Nadine Rösl is currently offline Nadine RöslFriend
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
Previous Topic:Support for transitive closure maintenance via IncSCC
Next Topic:Can't Find Specific VIATRA Paper Again
Goto Forum:
  


Current Time: Sun Oct 25 23:38:39 GMT 2020

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

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

Back to the top