GC_enable_incremental()

Wed Sep 8 15:31:00 GMT 2004

On Tue, 7 Sep 2004, Bryce McKinlay wrote:
> 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.
I'm now also seeing a problem with "make check" in the GC directory
on IA64. I'll investigate further. The segfault there may indeed be
normal, but it should be caught.
>> >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.

The problem isn't really a system call writing pointers. The problem
is that if a system call writes into the heap, the GC needs to have
been told in advance that that section of memory is pointerfree.
Otherwise the system call may fail, since the memory may not be writable.
And there is not always a way to recover.
It's possible that that we already do this more or less right. But
I'm not sure it has been carefully explored. To do this completely
right, you should check GC_incremental_protection_needs() before
calling GC_enable_incremental(). Even writing to pointerfree sections
of the heap from a system call is unsafe if the physical page size is
larger than the collectors block size. But on X86 it should be fine.
>> Regards
>> Bryce
>