[m-users.] Too Slow

Mark Brown mark at mercurylang.org
Sat May 2 00:59:36 AEST 2015


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.



More information about the users mailing list