[m-users.] Too Slow

[Peter Wang]

On Sat, 2 May 2015 01:07:26 +1000 (AEST), Julien Fischer <jfischer at opturion.com> wrote:
> 
> Hi Peter,
> 
> On Sat, 2 May 2015, Peter Wang wrote:
> 
> > On Fri, 1 May 2015 23:23:49 +1000, Mark Brown <mark at mercurylang.org> wrote:
> >>
> >> Unfortunately, libtommath falls into this category - it expects
> >> mp_ints to be cleared when they're done with. So the code still leaks
> >> even with the above changes.
> >
> > It's not very convenient, but libtommath does provide a way to override
> > the allocation functions that it uses: by defining the preprocessor
> > symbols XMALLOC/XREALLOC/XCALLOC/XFREE when building the library, e.g.
> >
> >    CFLAGS='-DXMALLOC=MR_GC_malloc -DXREALLOC=MR_GC_realloc \
> > 	    -DXCALLOC=MR_GC_calloc -DXFREE=GC_free' make
> 
> That might cause a few problems given that there is (currently) no such
> function as MR_GC_calloc! ;-)
> 
> Also, defining those macros on the command line is going to be a PITA
> for clients of the libtommath binding.  It would be better done inside a
> foreign_decl pragam, just before the inclusion tommath.h (suitably
> protected by checks that the macros are not already defined).

For convenience, it's feasible to build all the necessary libtommath C
files as part of the Mercury module:

    :- pragma foreign_decl("C", "
	#define XMALLOC     MR_GC_malloc
	#define XREALLOC    MR_GC_realloc
	#define XCALLOC     _fake_calloc /* unused */
	#define XFREE       GC_free
	#include ""tommath.h""
    ").

    :- pragma foreign_code("C", include_file("bncore.c")).
    :- pragma foreign_code("C", include_file("bn_error.c")).
    etc.

> Of course, the above definitions will also only work so long as
> libtommath doesn't store any pointers to GC allocated memory in non-GC
> allocated memory.

It doesn't, as far as I can tell.

Peter