That is really beyond our control: apparently the memory management is Mac OS is not very sophisticated (which does not come as a surprise to me).
While I fail to see the practical relevance of your example 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. Cheers Christian -- Christian Schulte, www.ict.kth.se/~cschulte/ 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
_______________________________________________ Gecode users mailing list [EMAIL PROTECTED] https://www.gecode.org/mailman/listinfo/gecode-users
