GC_enable_incremental()
Bryce McKinlay
mckinlay@redhat.com
Tue Sep 7 22:21:00 GMT 2004
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
More information about the Java
mailing list