Re: [eclipse-users] Overflow of the global/trail stack in spite of garbage collection!

From: Joachim Schimpf <jschimpf_at_...5...>
Date: Fri, 27 Oct 2006 01:07:46 +0100
Giuseppe Di Guglielmo wrote:
> Dear All,
> I have tried the following example
> p :-  X :: -536870912..536870911, 
>       Y :: -536870912..536870911, 
>      (X #= 0) and (neg(Y #= 0)) ,  
>      indomain(X, random), 
>      indomain(Y, random), 
>      writeln(X), 
>      writeln(Y).
> and eclipse gave me the error
>  
>  *** Overflow of the global/trail stack in spite of garbage collection!
>  You are probably out of virtual memory (swap space).
>  Peak sizes were: global stack 56620 kbytes, trail stack 4180 kbytes

Such large domains only work well with constraints that affect the bounds,
like #>=, cumulative, etc.  If you exclude internal values (such as 0 here),
lib(ic) will switch to a bitmap representation, which in this case means
that a single one of your variables already occupies 130MB of memory.
Sometimes Eclipse makes it very easy to do very inefficient things :-)

Apart from the memory issue, such a model is not practical because your
search space even with only 2 variables is already of size
?- N is (536870912 - -536870912) ^ 2.
N = 1152921504606846976
In scheduling problems, one usually uses more meaningful decision
variables, like booleans that represent to ordering between jobs.
Look at some relevant literature, or look at the jobshop example
on the Eclipse web site.


> 
> So I tried with the -g 512M option (see
> http://eclipse.crosscoreop.com:8080/eclipse/faq/index.html#Error%20messages8
> )
> 
> Now how can I increase the global stack size when I call ECLiPSe from C++ ?

You can do that (see ec_set_option()), but this is the wrong time to
worry about embedding your Eclipse solver into a C++ program.
We recommend that you develop your Eclipse code using an interactive
Eclipse, e.g. tkeclipse, and once you have a program that actually
solves some problem, link it to your C++ program.  This will certainly
save you time.


-- Joachim
Received on Fri Oct 27 2006 - 01:08:24 CEST

This archive was generated by hypermail 2.3.0 : Tue Apr 16 2024 - 09:13:19 CEST