[gecode-users] Memory problem

[Gustavo Gutierrez]

On Thu, Aug 28, 2008 at 8:35 AM, Christian Schulte <cschulte at kth.se> wrote:

>  What is Mozart using these days (yes, ignorance is bliss)? Is it still
> using mmap?
>
As far as i can see in the configure log it tries to allocate with three
different tools: malloc, sbrk and mmap. On Mac OS X it fails to use all but
mmap.


> Maybe that could be the interaction.
>
Gecode spaces are stored out of the mozart heap. I tried to see whether it
was a mozart problem by running a program that created a big list of numbers
and then let the garbage collector to remove it. Looking at process
statistics the heap shrinks so the behavior is the expected.


> But as Guido said, we just use malloc and free and by replacing three lines
> all of Gecode will be using a different allocator. Maybe you could try to
> use Mozart's allocator for Gecode as well.
>
>
>




> Cheers
>
> Christian
>
>
>
> *From:* users-bounces at gecode.org [mailto:users-bounces at gecode.org] *On
> Behalf Of *Gustavo Gutierrez
> *Sent:* Thursday, August 28, 2008 7:44 AM
> *To:* Christian Schulte
> *Cc:* gecode at gecode.org
> *Subject:* Re: [gecode-users] Memory problem
>
>
>
>
>
> 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
>



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