This issue tracker is closed. Please visit UPPAAL issue tracker at Github instead.

Bug 585 - Simulation out of memory
Summary: Simulation out of memory
Status: ASSIGNED
Alias: None
Product: UPPAAL
Classification: Unclassified
Component: GUI (show other bugs)
Version: 4.1.18
Hardware: PC Windows 7
: P5 enhancement
Assignee: Marius Mikučionis
URL:
Depends on:
Blocks:
 
Reported: 2014-10-03 13:41 CEST by Allan Munck
Modified: 2014-10-08 11:12 CEST (History)
1 user (show)

See Also:
Architecture:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Allan Munck 2014-10-03 13:41:05 CEST
Random execution in the simulator lead to an uncaught exception reporting out of memory due to heap exhaustion. I have tried to run with the -XX:+AggressiveHeap java JVM option. Using this option helps somewhat, but not entirely. I am not sure if the problem is in the GUI or in the Engine.

My model execute a synchronized loop between two automata. The loops are very small. However, the loops are run for several thousand times, due to the logic of the problem, that I am trying to model.

I found it impossible to debug the model without the random simulator, so I have set the severity to "blocker". My model is available upon request.

Thus issue may be related to bug 365:
http://bugsy.grid.aau.dk/bugzilla3/show_bug.cgi?id=365
Comment 1 Marius Mikučionis 2014-10-03 16:27:44 CEST
bug #365 is about enhancement, thus unrelated.

Could you please attach your model to this bug?

Yes, "head exhaustion" sounds like JVM issue and in principle it is possible to run into it with complex model and very long trace, but I have not seen this apart from SMC data which is very data intensive anyway.

How much memory do you have? 
Which JVM version are you using?
Is it 64bit JVM on 64bit Windows?

Perhaps an explicit option like -Xmx1024M or even more (depending on the size of your computer memory) would be better because AggressiveHeap uses some heuristics, and thus it is not clear that it succeeds to use all the available memory. 

You can also generate random traces by using verifier:
turn on random: Options, Search order, Random depth first
turn on diagnostic trace: Options, Diagnostic trace, Some.
Verify some property, like E<> somedeepstate
this is a bit more efficient than stepping through interactively.
Comment 2 Allan Munck 2014-10-08 10:18:53 CEST
I realized that the problem is due to the fact that uppaal saves all state information including all variables for in all states and for all transitions. My model has several large arrays (several kilobytes each). Removing all arrays solves the problem. However, the arrays are needed to ensure that the algorithm/model is correct. I found a work-around that allow me to use smaller arrays and still get a reasonable model. 

My current model is a coarse abstraction of my problem. To get a more correct model it will be necessary to be able to use large array in the simulator. Also break points or similar is needed to debug the models.

I have tried many combinations of JVM options. I heard that a 64 bit version is not ready for Windows7 yet, so I use the 32 bit JVM on Windows 7. I am able to get ~ 1.2 GB of memory, which is not enough. Tampering with the JVM options is not a final solution. At a later stage, my model will become even more memory hungry.

It seems to me that a feasible solution is to re-design the simulator such that only changed values are saved at each step instead of the entire variable space - if possible. Another solution would be to use a disk-based database as an option.

I am not able to upload my model to a public space due to confidentiality issues. But I can send the model as an email if you provide an email address.
Comment 3 Marius Mikučionis 2014-10-08 11:12:20 CEST
Allan Munck wrote:
"I have tried many combinations of JVM options. I heard that a 64 bit version is
not ready for Windows7 yet, so I use the 32 bit JVM on Windows 7."


We don't have the *engine* (written in C++) for 64bit Windows, but the Java GUI can be run on any JVM, although we test it only the ones provided by Oracle. The 64bit JVMs should work fine, in fact I use it everywhere.
So please go ahead and upgrade to your JVM to 64bits.


I will leave this bug open as a request to compress the states in a trace by reusing the previous variable values, which is a good suggestion.