[mercury-users] Memory allocation in foreign code in parallel grades

[Peter Wang]

On Sun, 22 Apr 2012 19:21:29 +0200, Christoph Schwering <schwering at kbsg.rwth-aachen.de> wrote:
> Hi everyone,
> 
> I'm using Mercury to implement an interpreter for an action language
> (a dialect of Golog [1]). Most interpreters are written in Prolog, but
> Mercury seems to me to be a great alternative.
> 
> My question, in short, is how one can and should allocate memory in
> foreign C and C++ code when using a parallel grade: with malloc,
> GC_MALLOC, or something else?

Same way as for non-parallel grades, i.e. MR_GC_malloc, etc. for garbage
collected memory or anything that could have pointers to garbage
collected memory.  You can use malloc() or whatever for anything else.

> The foreign code I'd like to interface is the COIN-OR CLP solver [2]
> through the OSI interface [3]. I don't need solver_types. It's very
> simple:
> * there's a foreign_type defined as SolverContext* where SolverContext
>   is a C-typedef,
> * there's a pair of foreign_procs new_solver_context and
>   finalize_solver_context that creates and destroys a SolverContext
>   object with C++ new and delete,
> * a foreign_proc add_constraint which adds a new constraint to the
>   solver context, and
> * a foreign_proc solve.
> The attributes of the foreign_procs are will_not_call_mercury,
> promise_pure, thread_safe.
> Since COIN-OR CLP is written in C++, the underlying C/C++ procedures
> use new/delete and malloc/free.
> Besides the SolverContext* pointer, the other data passed between
> Mercury and C++ are arrays of floats and ints. I copy them, i.e., I
> copy Mercury lists of floats/ints to newly malloced arrays of
> floats/ints which I pass to C++ and the other way around.

That *should* work.  Can you reproduce it with a smaller program?

It does sound like you are retaining a pointer to GC memory somewhere
that the GC doesn't scan.  Perhaps it is something non-obvious, like a
closure.

> I'm using Mercury 11.07.1 under Linux x86_64, GCC 4.6.2 20111027 (Red
> Hat 4.6.2-1), and grade hlc.par.gc.
> 
> With asm_fast.par.gc the memory consumption is very high and I get
> segmentation faults even with one thread. The error message suggests a
> stack overflow due to recursion as reason. This really might be the
> case, but I wonder why this doesn't occur in non-parallel asm_fast.gc?

The very high memory consumption is strange.  The stack overflow message
is generic, so I wouldn't read too much into it.

> And unfortunately, I can't compile the agc grades; the error message
> is that control flow reaches end of non-void functions in array.m. Is
> this a known issue?

The .agc grades aren't finished and no one has been working on it for a
long time, so.. we wait.

Peter
--------------------------------------------------------------------------
mercury-users mailing list
Post messages to:       mercury-users at csse.unimelb.edu.au
Administrative Queries: owner-mercury-users at csse.unimelb.edu.au
Subscriptions:          mercury-users-request at csse.unimelb.edu.au
--------------------------------------------------------------------------