[Mono-devel-list] RE: [Gc] Segmentation fault with "GC_ENABLE_INCREMENTAL"

[Okehee Goh]

 Hello Dr.Boehm,
 Thank you so much for your reply.
 I am looking at libgc that comes with Mono-0.25. I'd like to understand it
firmly.

 The memory protection during an incremental GC in BoehmGC6.1 seems to be
enabled such that
   (1) SIGSEV is associated to trigger GC_write_fault_handler at
GC_dirty_init(), and GC_write_fault_handler() records pages that violate a
write protection,
   (2) a heap is protected as just read-only during incremental GC at
GC_read_dirty() which is called at stopped_mark(),
   (3) dirty pages are re-visited again at mark_some()...
( os_dep.c is very complicating to support various platforms. I followed
functions for MPROTECT_VDB for my system, i386 and Linux)

 If so, some system calls from Mono, that attempt to write on a protected
heap can cause SIGSEV even though they are nothing to do with application's
memory writing that must be caught for Write Barrier.
 But, why aren't they trapped by GC_write_fault_handler()?
 And also could you give any advice about what to check or what to do to
support the current implementation for an incremental GC with Mono?

 This is another question.
 At the end of GC_write_fault_handler(), it releases the protection of the
page that violates a write protection after recording the page as a dirty
page. But, I couldn't find where the protection for other pages  are
released before starting an application(mutator).

 Thank you so much in advance.

 Regards,

 Okehee


-----Original Message-----
From: Boehm, Hans [mailto:hans_boehm at hp.com]
Sent: Wednesday, July 16, 2003 3:45 PM
To: 'Okehee Goh'; 'gc at linux.hpl.hp.com'; ximian-mono-list at ximian.com
Subject: RE: [Gc] Segmentation fault with "GC_ENABLE_INCREMENTAL"


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.

Hans

> -----Original Message-----
> From: Okehee Goh [mailto:ogoh at asu.edu]
> Sent: Wednesday, July 16, 2003 2:11 PM
> To: 'gc at linux.hpl.hp.com'; ximian-mono-list at ximian.com
> Subject: [Gc] Segmentation fault with "GC_ENABLE_INCREMENTAL"
>
>
>
>
>  Hello,
>  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
> that,
> 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.
>
>  Regards,
>
>  Okehee
>
> _______________________________________________
> Gc mailing list
> Gc at linux.hpl.hp.com
> http://linux.hpl.hp.com/cgi-bin/mailman/listinfo/gc
>