[gecode-users] Memory problem

[Gustavo Gutierrez]

On Wed, Aug 27, 2008 at 11:10 AM, Christian Schulte <cschulte at kth.se> wrote:

>
>
>
> While I fail to see the practical relevance of your example
>
It is not relevant as that, but it shows a problem that happens in our
development of the next mozart release. As you may know we are interested in
having a mozart gecode integration. Well, by doing some benchmarks we
realize that memory consumption is to high for medium size problems. The
idea is simple: we have a linked list of gecode spaces and the garbage
collector needs to traverse it  to see which of them needs to be removed.
Also, after space propagation we check whether the gecode space has resulted
failed to remove it in eagerly (i.e., do not wait for a grabage collector
run).


> there is an experiment what you could do: you allocate the spaces in the
> same order as you deallocate them. Try and see what happens if you
> deallocate the spaces in inverse order. That is, run the deallocation loop
> backwards so that the space allocated last gets deleted first.
>
>
>

After trying the same problem occurs. Is there a way to instrument gecode to
use a different allocator for memory?, i mean, something similar to STL in
which many of the data structures provided take an optional allocator
template parameter.

Regards,
Gustavo

*From:* users-bounces at gecode.org [mailto:users-bounces at gecode.org] *On
> Behalf Of *Gustavo Gutierrez
> *Sent:* Wednesday, August 27, 2008 10:56 AM
> *To:* gecode at gecode.org
> *Subject:* [gecode-users] Memory problem
>
>
>
> Hi All,
>
> Some time ago someone reported an strange memory behavior in mac os x on
> the gecode list. I do not know whether it was fixed but i think it still
> remains in the current implementation. The problem apparently happens only
> in mac os x. You can get it by replacing the main function of the queens
> example to this one:
>
> int
> main(int argc, char* argv[]) {
>
>   SizeOptions opt("Queens");
>   opt.iterations(500);
>   opt.size(100);
>   opt.propagation(Queens::PROP_
>
> DISTINCT);
>   opt.propagation(Queens::PROP_BINARY, "binary",
>                       "only binary disequality constraints");
>   opt.propagation(Queens::PROP_MIXED, "mixed",
>                       "single distinct and binary disequality
> constraints");
>   opt.propagation(Queens::PROP_DISTINCT, "distinct",
>                       "three distinct constraints");
>   opt.parse(argc,argv);
>   /*
>   Example::run<Queens,DFS,SizeOptions>(opt);
>   */
>   std::vector<Queens*> q;
>   for (unsigned int i=0; i < 100000; i++) {
>     q.push_back(new Queens(opt));
>   }
>   std::cout << "finished insertion" << std::endl;
>
>   for (unsigned int i=0; i < 100000; i++) {
>     Queens *tmp = q[i];
>     delete tmp;
>     q.pop_back();
>   }
>   std::cout << "finished delete" << std::endl;
>
>   int a;
>   std::cin >> a;
>   return 0;
> }
>
> The idea is to create a lot of spaces and to keep pointer to them in an
> array. After the creation all spaces are deleted. The expected behavior is
> to release all the memory allocated in the first loop and to have it
> available by the operating system. I tried in a mac os x running leopard and
> the memory seems to be still used by the process (according to Activity
> Monitor). In a linux machine the memory seems to be released according to
> top.
>
> Another thing is that when using the gecode trunk to try the same problem,
> the de-allocation behaves better, that is, half of the memory is released
> but still some memory is kept by the process.
>
> Do you have any suggestion on how to work around this?
>
>
> Regards,
> --
> Gustavo Gutierrez
>



-- 
Gustavo Gutierrez
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ps.uni-sb.de/pipermail/users/attachments/20080828/4f505391/attachment.htm>