Generate instantiations on-the-fly

[Ivan Beschastnikh]

Currently all instantiations are pre-generated. This allows support for parallelization but creates a huge chunk of memory which makes Texada un-runnable in practical terms for some formulae + trace combinations.

I've created an on-the-fly instantiation generator in truncating_checker @ 5872b6d. It might be useful to refactor this into instantiation tools instead and put the memoization optimizations into the individuals checkers.

Some tests were run in @82df717 and it did not appear that the truncating checker as is saved space. This should be further investigated

[Issue created by carolemieux: 2014-07-16]
[Last updated on bitbucket: 2014-07-23]

[Comment created by carolemieux: 2014-07-23]
abstraction completed, memory leaks resolved 377d4ab

[Comment created by carolemieux: 2014-07-23]
Abstraction completed in rev 39f41b1; problem with pointers and memory leaks still re: "variables" in property_type_miner.

[Comment created by carolemieux: 2014-07-18]
Abstract this into an on-the-fly-instantiation pool creator and allow any checker to use it.

[Comment created by carolemieux: 2014-07-18]
Was indeed a bug and removal of -pg flag, which was probably the cause of mysterious slowdown

Added more correctness checks to truncator in rev 9773b03.

[Comment created by carolemieux: 2014-07-16]
I actually did run this and the linear trace checker by valgrind yesterday, and both had the biggest leak looking like this:

Basically in the spot code there is indeed a new without a delete but the particular function is returning a pointer, so I guess that's okay. (maybe?)

I couldn't really tell if it was something I could fix from my side -- it's again at the call for instantiate(). The fact that the formula destructor is protected complicates this....

However since this was only 300k bytes I suspected it was not the cause of the explosion, which was growing by megabytes.

[Comment created by bestchai: 2014-07-16]
We need to be careful here and make sure that there are no other memory leaks that are responsible for the memory explosion. You should try out some tools to help you with this --

Valgrind:
http://valgrind.org/docs/manual/quick-start.html

Also, related to this is the use of RAII:
http://stackoverflow.com/questions/2321511/what-is-meant-by-resource-acquisition-is-initialization-raii

boost supports this; some more info here:
http://en.wikibooks.org/wiki/More_C%2B%2B_Idioms/Scope_Guard

[Comment created by bestchai: 2014-07-18]
I'm hoping that it's quick and real :-)

[Comment created by carolemieux: 2014-07-18]
This is fixed in the newest revision aa925a3. And memory usage grows a lot more slowly and stays low, but the truncating checker performs far too quickly to be real, so requires some more correctness testing.

[Comment created by carolemieux: 2014-07-16]
This is the current implementation of checking the instantiations. Basically this is part of the body of a loop that goes through each possible position and generates in instantiation function (aka map). That's what inst_map_at_pos is. Node is the property type's spot formula.

I'll need to investigate that more in detail, but I have a suspicion that's it's here that the memory is growing a lot. (I would've wanted to delete that instantiated_form pointer, but ~formula() is protected in SPOT....)

Or maybe the huge memory use has nothing to do with the number of instantiations.... (unlikely)