[m-users.] MR_GC_free ?

[Peter Wang]

On Wed, 08 Nov 2023 15:03:19 +0100 Volker Wysk <post at volker-wysk.de> wrote:
> Am Mittwoch, dem 08.11.2023 um 14:54 +0100 schrieb Volker Wysk:
> > Am Donnerstag, dem 09.11.2023 um 00:33 +1100 schrieb Julien Fischer:
> > > On Wed, 8 Nov 2023, Volker Wysk wrote:
> > > 
> > > > > 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?
> > > 
> > > Yes it can.  Bear in mind that the Boehm GC is designed to be garbage
> > > collector for C; so far as it is concerned there is no distinction
> > > between Mercury and C data structures.
> > 
> > I'm wondering how it can, but okay. 
> > 

Boehm GC is a conservative garbage collector. It doesn't know anything
about C structures or Mercury structures, as it gets no help from the C
or Mercury compiler. It assumes that any memory word it has allocated to
the user may contain a pointer value. If it sees a value that looks like
a address that it handed out, then it is treated as a live reference to
that object. That means a random value in memory could cause an object
to be live longer than necessary, but it's not usually an issue
(particularly with 64-bit address spaces).

Boehm GC does provide a way to allocate "atomic" objects;
such an object will be assumed not to contain any pointers.

Boehm GC also supports the use of a small number of custom mark
procedures, which could be used to scan objects (more) precisely.
The documentation recommends to use custom mark procedures only in
"exceptional cases"; we don't use them in the Mercury system.

Peter