[m-users.] Too Slow

[Mark Brown]

On Sat, May 2, 2015 at 12:51 AM, Matthias Güdemann
<matthias.guedemann at googlemail.com> wrote:
> Am 1. Mai 2015 14:23:49 MEZ, schrieb Mark Brown <mark at mercurylang.org>:
>>
>> On Fri, May 1, 2015 at 5:54 PM, Peter Wang <novalazy at gmail.com> wrote:
>>>
>>>  On Fri, 01 May 2015 07:02:48 +0100, Matthias Guedemann
>>> <matthias.guedemann at googlemail.com> wrote:
>>>>
>>>>  Hi Peter,
>>>>
>>>>>  You should allocate the mp_ints like this:
>>>>
>>>>
>>>>>      Mp_Int = MR_GC_NEW_ATTRIB(mp_int, MR_ALLOC_ID);
>>>>
>>>>
>>>>>  For the string in
>>>>> mp_to_string you should use
>>>>
>>>>
>>>>>      MR_allocate_aligned_string_msg(S, length, MR_ALLOC_ID);
>>>>
>>>>
>>>>>  or other macros in mercury_string.h
>>>>
>>>>
>>>>  ok, thank you for the hints. Could you point me to the relevant section
>>>>  in the user guide, or is the documentation only in the source files?
>>>
>>>
>>>  Unfortunately the latter (mercury_memory.h and mercury_string.h).
>>>  I think no memory management interface has been documented because
>>>  the existing interface is specific to conservative GCs, if not Boehm
>>>  GC.  Nonetheless, practical code using the foreign language interface
>>>  invariably needs to allocate so I think we should document some of the
>>>  macros and
>>> functions, with caveats.
>>
>>
>> That's done for lists and floats (section 14.3.1), and ought to be
>> done for strings, too. Allocating foreign types on Mercury's heap
>> needs one big caveat, though, namely that no finaliser will be called.
>> If the foreign type needs to be explicitly freed, allocating it on
>> Mercury's heap won't work.
>>
>> 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.
>>
>> Cheers,
>> Mark.
>
> Hi Mark,
>
> thanks for the info. I'll add predicates to clear mp_int values which call
> the finalizers.

Actually, try what Julien said.  ;-)

Since mp_int can be allocated anywhere, maybe the wrapper is not required.

>
> Is this because mp_int is just a struct containing pointers to malloc'ed
> memory? So then the GC frees the memory malloc'ed for mp_int itself, and the
> internal stays stay allocated?

You have to clear them because the library author said so. But yes, it
looks like what you say is what would happen.

Cheers,
Mark.