GC_enable_incremental()

[Bryce McKinlay]

Boehm, Hans wrote:

>The real-time thread is running Java code?
>
>There are several issues with getting incremental collection to work
>in 3.4:
>
>1) There is a bug in pthread_support.c which causes the thread stopping
>signal handler to disable signals and the write to a heap object.  This
>is bad if that object is write protected, something that can happen with
>the incremental collector.  Hence the "killed" message.  This should be
>fixed in the CVS trunk.  The fix should probably be backported to 3.4,
>but it hasn't been.  The problem seems to show up only with 2.6 kernels.
>  
>
Hans, I still see a problem with incremental mode using CVS trunk, on a 
2.6 kernel both on x86 and x86_64:

$ GC_ENABLE_INCREMENTAL=1 ./gctest
Segmentation fault

(gdb) r
Starting program: /home/mckinlay/tests/gctest
[Thread debugging using libthread_db enabled]
[New Thread -151066912 (LWP 8129)]
[New Thread 33545136 (LWP 8132)]
[New Thread 87886768 (LWP 8133)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 33545136 (LWP 8132)]
GC_restart_handler (sig=24) at pthread_stop_world.c:184
184         me->stop_info.signal = SIG_THR_RESTART;

I havn't looked at this extensively. Perhaps this segfault is "normal" 
for incremental mode? The segfault location seems a bit random - I've 
seen it sometimes in GC_finalize, sometimes in GC_restart_handler. It 
does appear to be caused by the GC writing to write-protected heap 
objects, because I can read them fine in gdb.

>2) There hasn't been a systematic effort to get incremental GC debugged
>and tested in the context of gcj.  This is nontrivial, since it can break
>if a system call writes to a pointer-containing section of the heap.
>Hence the library has to play by a stricter set of rules.
>  
>

Is this really a problem? I can't think of any situation where a system 
call would write to pointers on the heap. Unless perhaps 
System.arraycopy() were implemented by a system call on some platform, 
but I don't think this is the case usually.

Regards

Bryce