This is the mail archive of the java@gcc.gnu.org mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: GC_enable_incremental()


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]