On Mar 7, 2008, at 16.24h, Vesa Karvonen wrote: > On Fri, Mar 7, 2008 at 4:39 PM, Sandro Magi <[EMAIL PROTECTED]> > wrote: >> On Fri, Mar 7, 2008 at 8:54 AM, Andreas Rossberg >> <[EMAIL PROTECTED]> wrote: >>> As Guido points out in his answer, the problem is that the Gecode >>> binding can cause the C++ heap to grow much faster than the ML >>> heap. >>> The Alice runtime does not know about the size of the foreign heap, >>> so ML-side GC (which would also release some of the C++ objects) is >>> not triggered early enough. In fact, this is a general problem with >>> FFIs, and I'm not aware of a good solution. >> >> The only solution I've been able to come up with, is to replace >> malloc/free with an implementation that co-operates with the >> runtime. > > Yes, C++ (which, I believe, is used in Alice ML's runtime/vm and > Gecode) allows the implementation of new/delete to be replaced. > Something as simple as keeping track of how much space is being used > and forcing a (full) GC each time it doubles after a previous GC could > do the trick. This policy would ensure that at most twice as much > memory is taken by C++ objects as necessary. The point of comparing > to usage at previous GC is to avoid doing GCs too often.
Yes, but note that approaches like these only work when you can afford to patch the library (or its build process) appropriately. It does not work in cases like the Gtk binding, where we just dynamically link against the DLLs from the standard distribution (because we do not want to build all that ourselves, esp. on Windows). Also, some libraries already replace allocation themselves, so that it is not that easy to redirect. I believe that Gecode falls into that category (Guido will correct me if I'm wrong). - Andreas _______________________________________________ alice-users mailing list [email protected] http://www.ps.uni-sb.de/mailman/listinfo/alice-users
