[Gc] Incremental collection in gcj?

kus Kusche Klaus kus at keba.com
Fri May 27 02:02:42 PDT 2005

Ben Hutchings [ben.hutchings at businesswebsoftware.com] wrote:
> kus Kusche Klaus wrote:
> > I tried to run a gcj-compiled program with incremental gc.
> > It failed with a SIGSEGV in GC_restart_handler,
> > executed in a signal handling context within a sigsuspend.
> <snip>
> Where are you seeing this SIGSEGV reported?  If you only see it in a 
> debugger, this is nothing to worry about.  Incremental GC 
> normally uses 
> memory protection and a SIGSEGV handler to detect which pages need 
> re-scanning.

No, I see this SIGSEGV in normal program execution, i.e. the program
dumps core. I analyzed the core post-mortem with gdb.

In the meantime, I upgraded from gcj 3.4.3 to the latest gcj 4.0.1

However, that changed the details of the stack backtrace, but not 
the general problem. As far as I can tell from the attached dump,
the finalizer thread is waiting in some posix thread synchronization
function, and gets some signal (-4 ???).

The signal handler is executing a sigsuspend, and again gets some
signal (24, that would be SIGXCPU, but I can't believe that).

The signal handler is invocing GC_restart_handler.

With gcj 3.4.3, GC_restart_handler was the topmost frame in the dump.

With gcj 4.0.1, the program enters an infinite signal-catch recursion 
on SIGSEGV within GC_restart_handler.

Boehm, Hans [hans.boehm at hp.com] wrote:
> I suspect the problem here is an old bug, and a patch that 
> never made it
> into the 3.4 branch.  If you want to fix it, the patch was applied in
> version
> 1.2 of pthread_stop_world.c in the gcc tree on savannah.gnu.org.
> 4.0 should not have this particular problem, since it uses version 1.3
> of
> that file.

Doesn't seem to be the cause, because the latest gcj 4.0.1 
snapshot shows the same problem.

> Incremental/generational gc is not supported in gcj, though you
> might be able to get it to work.  I don't think anyone has ever
> gone through and made sure that no system calls in libgcj write into
> pointer-containing heap objects.  If they do, those system calls may
> fail, since incremental GC write-protects heap pages.  Unlike
> store instructions, system calls are not always transparently 
> restarted
> after unprotecting the page.

Does the attached stack backtrace give any hints?

Also, should posixthreads work? 
All the GC docu only talks about linuxthreads...

Klaus Kusche                 (Software Development - Control Systems)
KEBA AG             Gewerbepark Urfahr, A-4041 Linz, Austria (Europe)
Tel: +43 / 732 / 7090-3120                 Fax: +43 / 732 / 7090-6301
E-Mail: kus at keba.com                                WWW: www.keba.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gc.core
Type: application/octet-stream
Size: 2574 bytes
Desc: gc.core
Url : https://napali.hpl.hp.com/pipermail/gc/attachments/20050527/8c2d1ae4/gc.obj

More information about the Gc mailing list