[Gc] On Linux, BDWGC prefers sbrk() over mmap(), why is that so?

Hello BDWGC folks,

During a recent bug chase of mine I stumbled over the fact that, in its
default configuration on Linux, this GC will always try to call sbrk()
before falling back onto mmap() (see GC_unix_get_mem() et al. in os_dep.c).

This is despite the fact that I configure my copy with
--enable-threads=posix.
My system operates in a context where there is a number of threads not
under GC control along with the set of threads the GC do control. On Linux,
brk()/sbrk() is NOT a thread-safe facility and calls to it from non-GC
threads or from other application code (dlopen() is liberally used in this
system) cannot be prevented.

Further more, non-GC threads are very likely to use malloc() et al. for
their memory needs, and malloc() relies on brk()/sbrk() for (at least a
good part of) its business. A clash of some sort between malloc and BDWGC
on their respective use of brk()/sbrk() seems in my opinion to be very
likely, is it not?

The use of mmap() alone (no brk()/sbrk()) seems to be hardcoded in
include/private/gcconfig.h for a number of platform (IRIX, AIX, Solaris,
etc) but not for Linux. Is there some fundamental reason for this?

BTW, access to the use of mmap() through the "configure" interface seem to
have been intentionally removed at some point in the past. One needs to
edit configure.ac in order to use the remnants of it.

Regards,

Jean-Claude Beaudoin

_______________________________________________
bdwgc mailing list
[email protected]
https://lists.opendylan.org/mailman/listinfo/bdwgc