This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Re: GC_enable_incremental()
- From: Bryce McKinlay <mckinlay at redhat dot com>
- To: "Boehm, Hans" <hans dot boehm at hp dot com>
- Cc: "'DHollenbeck'" <dick at softplc dot com>, java at gcc dot gnu dot org
- Date: Tue, 07 Sep 2004 18:01:51 -0400
- Subject: Re: GC_enable_incremental()
- References: <B27561804CF1BE4F8943BB2CB29E18EA062CF3@hplextmp.hpl.hp.com>
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