| Summary: | Simulation out of memory | ||
|---|---|---|---|
| Product: | UPPAAL | Reporter: | Allan Munck <allmun> |
| Component: | GUI | Assignee: | Marius Mikučionis <marius> |
| Status: | ASSIGNED --- | ||
| Severity: | enhancement | CC: | adavid |
| Priority: | P5 | ||
| Version: | 4.1.18 | ||
| Hardware: | PC | ||
| OS: | Windows 7 | ||
| Architecture: | |||
|
Description
Allan Munck
2014-10-03 13:41:05 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. 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. 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. |