[gecode-users] Memory problem

[Christian Schulte]

Well, not so sure. There could be another workaround: look to the file
gecode/kernel/memory-mananger.icc. There you will find something like:

 

    /**

     * \brief Parameters defining memory management policy for spaces

     * \ingroup FuncMemSpace

     */

    namespace Config {

      /**

       * \brief Minimal size of a heap chunk requested from the OS

       */

      const size_t hcsz_min =  2 * 1024;

 

If you increase hcsz_min to 16 * 1024 that would avoid part of the problem.
One part are the spaces which are very small and few. But per space you will
typically allocate a number of heap chunks. Initially these chunks will be
small and will only dynamically grow when demand justifies it. So, if you
increase, you'll have more slack but more blocks will be returned to the OS.

 

Christian

 

--

Christian Schulte, www.ict.kth.se/~cschulte/

 

From: Guido Tack [mailto:tack at ps.uni-sb.de] 
Sent: Thursday, August 28, 2008 1:06 PM
To: Gustavo Gutierrez
Cc: gecode at gecode.org; Christian Schulte
Subject: Re: [gecode-users] Memory problem

 

Gustavo Gutierrez wrote:

On Thu, Aug 28, 2008 at 9:20 AM, Guido Tack <tack at ps.uni-sb.de> wrote:

I tried to find out more about the Mac OS malloc.

Apparently, Mac OS never frees blocks that are smaller than 15359 bytes, but
rather tries to reuse them for further mallocs in the same process.
http://kevin.sb.org/2007/07/05/malloc-free-space-not-reclaimed/

I tried replacing malloc with ptmalloc3 (as suggested in that article), and
it completely solves the problem.


Now I am wondering if the same problem can occur when using gecode in the
*normal* way, i mean, with gecode search engines as in the examples. Any
comment?

 

That's unlikely.  The problem is that the memory footprint is going to be
the maximum memory used by spaces that are alive at the same time.  In your
example, that's tens of thousands of spaces.  During search, it's never more
than a few spaces (search tree depth / recomputation depth).  If the tree
depth is very big, you're lost anyway as the search is not going to find a
solution.

 

Cheers,

            Guido

 

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