On Thu, Aug 28, 2008 at 8:35 AM, Christian Schulte <[EMAIL PROTECTED]> 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:* [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 > -- Gustavo Gutierrez
_______________________________________________ Gecode users mailing list [EMAIL PROTECTED] https://www.gecode.org/mailman/listinfo/gecode-users
