[m-users.] MR_GC_free ?
Volker Wysk
post at volker-wysk.de
Thu Nov 9 00:26:07 AEDT 2023
Am Mittwoch, dem 08.11.2023 um 12:22 +1100 schrieb Julien Fischer:
>
> 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" <post at volker-wysk.de> 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.
This leads me to the same question as Peter's answer: Can the garbage
collector see inside a C structure, if it is allocated with MR_GC_NEW?
>
> > (That's what those are there for, aren't they?)
>
> They're there primarily for the use of Mercury's runtime.
>
> Julien.
Cheers,
Volker
More information about the users
mailing list