What is Mozart using these days (yes, ignorance is bliss)? Is it still using mmap? Maybe that could be the interaction. 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gustavo Gutierrez Sent: Thursday, August 28, 2008 7:44 AM To: Christian Schulte Cc: [EMAIL PROTECTED] Subject: Re: [gecode-users] Memory problem On Wed, Aug 27, 2008 at 11:10 AM, Christian Schulte <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gustavo Gutierrez Sent: Wednesday, August 27, 2008 10:56 AM To: [EMAIL PROTECTED] 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
_______________________________________________ Gecode users mailing list [EMAIL PROTECTED] https://www.gecode.org/mailman/listinfo/gecode-users
