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
