[m-users.] Mercury Memory Management
zhtprog at gmail.com
Fri Mar 14 16:36:01 AEDT 2014
On Thu, Mar 13, 2014 at 9:40 PM, Zoltan Somogyi
<zoltan.somogyi at runbox.com>wrote:
> On Thu, 13 Mar 2014 19:14:01 -0700, Haitao Zhang <zhtprog at gmail.com>
> > If I use Mercury purely functionally/declaratively and store all states
> > through the FFI so that when control returns from Mercury there is no
> > to preserve any Mercury data structures, could I disable GC and expect no
> > memory leak?
> No, you cannot expect that.
> > I read that one can compile with no GC and Mercury heap will
> > be reclaimed on backtracking. Does that include returning from a
> > det/semidet predicate?
> No. Returning from a det predicate, and returning from a semidet
> predicate with success, are not backtracking.
I see. Thanks for the tip. So what if one supplies a heap manager in place
of Boehm GC? All this manager does is to track Mercury heap allocated
structures as if Mercury uses a separate heap. Then when returning from
Mercury the caller manually frees all Mercury structures. Anything that
needs to be preserved is done through the CFFI using the regular heap. This
is like a thread execution model with separate heap and shared memory for
communication. Would this work?
> There was a compile time GC branch with activity as recent as 2008, What
> > happened to that branch? What about the region based memory management
> > module?
> Neither is ready for production use, and neither is actively maintained.
> They were built by graduate students who have since finished their studies
> and moved on to other things.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the users