Re: [m-users.] MR_GC_free ?

Am Donnerstag, dem 09.11.2023 um 14:13 +1100 schrieb Peter Wang:
> On Wed, 08 Nov 2023 15:03:19 +0100 Volker Wysk <[email protected]> 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 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.

Thank you for the explanation! Now I'm prepared to make that ODBC library
thread-safe.

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