[Gc] Segmentation fault with "GC_ENABLE_INCREMENTAL"
Wed, 16 Jul 2003 15:45:25 -0700
Unless Mono specifically supports this by being careful about where system calls can write, this is unlikely to work.
It will almost certainly fail if any system calls (e.g. "read") write to heap sections allocated with GC_malloc, though sometimes sections allocated with GC_malloc_atomic are OK. There are vague plans to hide all of this and make this directly usable in gcj, but I don't think it has happened there yet, either.
I assume you're doing this because you saw unacceptable pause times without incremental collection? Other things that might help a bit are:
1) Making sure that pointer-free objects (e.g. bitmaps, arrays of numbers) are known by the collector to be pointer-free. I don't know whether Mono already does this, or whether you are allocating any other objects to which this might apply.
2) If you are running on a dual processor (or possibly "hyperthreaded" P4), turn on the parallel GC.
> -----Original Message-----
> From: Okehee Goh [mailto:firstname.lastname@example.org]
> Sent: Wednesday, July 16, 2003 2:11 PM
> To: 'email@example.com'; firstname.lastname@example.org
> Subject: [Gc] Segmentation fault with "GC_ENABLE_INCREMENTAL"
> I run Mono-0.25 with "GC_ENABLE_INCREMENTAL" to enable an
> incremental GC.
> But it just gave a segmentation fault.
> One of documents regarding Boehm's GC says that the
> incremental GC can
> cause "unintended system call failure."
> (Refer to the following..)
> Is there anybody who didn't encounter this problem? My
> system is Linux
> kernel 2.4 and i686.
> GC_ENABLE_INCREMENTAL - Turn on incremental collection at
> startup. Note
> depending on platform and collector configuration, this
> may involve write protecting pieces of the heap to
> track modifications. These pieces may include pointerfree
> objects or not. Although this is intended to be
> transparent, it may cause unintended system call failures.
> Use with caution.
> Any suggestion will be appreciated.
> Gc mailing list