[Gc] mixing GC & malloc data....

[Basile Starynkevitch]

Hello all,

Is Boehm's GC (e.g. version 7.2d, packaged on my Debian/Sid) compatible
with malloc (e.g. on recent Linux/x86-64 distributions)? I guess it
should (in particular for C++11 containers whose internal data is
generally allocated with ::operator new which wraps malloc)

In other words, I would suppose that with a code like

void**ptrarr = malloc(5*sizeof(void*));
ptrarr[0] = GC_MALLOC(512);

and assuming that ptrarr is a global (or some local variable still on
the call stack) and that the GC_MALLOC gave 0x12345678 which is only
reachable thru ptrarr[0], I am expecting it to not being released by
Boehm's GC.

In other words, I suppose that Boehm's GC is managing mmap-ed segments
(e.g. those asked by the implementation of my system malloc) even when
they have been mmap-ed by something else that the Boehm's GC internals.

Then I am not sure why a GC_dlopen is needed, since dlopen is doing some
mmap.

Regards.

[Bruce Hoult]

No.

During a GC tracing ptrarr (if it is a global or on the stack/in a
register) will be examined to see if "it looks like a pointer to a GC
object". As it does not point into a page of memory managed by the GC (it
points to memory managed by malloc()) it will be ignored.

It can not be otherwise! The GC has no way of knowing how large the object
pointed to by ptrarr is, and so can not know how much of it to scan for
pointers to GC objects.

If you want the contents of ptrarr to be scanned for pointers to GC objects
then you must allocate it using one of the GC allocation functions.

GC_MALLOC_UNCOLLECTABLE is a good replacement for malloc() for this use.

You might want to read http://hboehm.info/gc/gcinterface.html

On Wed, Sep 9, 2015 at 5:55 PM, Basile Starynkevitch <

Post by Basile Starynkevitch
Hello all,
Is Boehm's GC (e.g. version 7.2d, packaged on my Debian/Sid) compatible
with malloc (e.g. on recent Linux/x86-64 distributions)? I guess it should
(in particular for C++11 containers whose internal data is generally
allocated with ::operator new which wraps malloc)
In other words, I would suppose that with a code like
void**ptrarr = malloc(5*sizeof(void*));
ptrarr[0] = GC_MALLOC(512);
and assuming that ptrarr is a global (or some local variable still on the
call stack) and that the GC_MALLOC gave 0x12345678 which is only reachable
thru ptrarr[0], I am expecting it to not being released by Boehm's GC.
In other words, I suppose that Boehm's GC is managing mmap-ed segments
(e.g. those asked by the implementation of my system malloc) even when they
have been mmap-ed by something else that the Boehm's GC internals.
Then I am not sure why a GC_dlopen is needed, since dlopen is doing some
mmap.
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net mobile: [phone]
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
_______________________________________________
bdwgc mailing list
https://lists.opendylan.org/mailman/listinfo/bdwgc
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.