Re: [m-users.] MR_GC_free ?

On Tue, 7 Nov 2023, Volker Wysk wrote:

> Am Mittwoch, dem 08.11.2023 um 05:53 +1100 schrieb Zoltan Somogyi:
>> On 2023-11-08 05:48 +11:00 AEDT, "Volker Wysk" <[email protected]> wrote:
>> > Hi.
>> > 
>> > In the ODBC library, there's space allocated by MR_GC_NEW and explicitly
>> > freed with MR_GC_free. This confuses me. Shouldn't space allocated by
>> > MR_CG_NEW be deallocated by the garbage collector? If it is to be
>> > deallocated explicitly, shouldn't the space be allocated by MR_NEW and be
>> > deallocated by MR_free?
>> 
>> Follow the definition of MR_GC_free in runtime/mercury_memory.h
>> to boehm_gc/include/gc.h.
>
> This leads to this (I couldn't understand the definition of this function):
>
> /* Explicitly deallocate an object.  Dangerous if used incorrectly.     */
> /* Requires a pointer to the base of an object.                         */
> /* An object should not be enabled for finalization (and it should not  */
> /* contain registered disappearing links of any kind) when it is        */
> /* explicitly deallocated.                                              */
> /* GC_free(0) is a no-op, as required by ANSI C for free.               */
> GC_API void GC_CALL GC_free(void *);
>
> So the gc explicitly frees the object and remembers that it has done so, so
> it won't be garbage collected later.

Correct.

> Is it bad style to use MR_GC_NEW and MR_GC_free,

No.

> since it should rather be
> done with MR_NEW/MR_free?

MR_NEW and MR_free allocate and free memory using malloc() and free()
respectively, not with the GC.  It's safer to use the GC versions.
Additionally, foreign_procs that mix memory allocators, especially a
manual allocator, is likely be difficult to debug and maintain.

> (That's what those are there for, aren't they?)

They're there primarily for the use of Mercury's runtime.

Julien.
_______________________________________________
users mailing list
[email protected]
https://lists.mercurylang.org/listinfo/users