[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.
> 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
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
> 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
> 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
> 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...
Size: 2574 bytes
Url : https://napali.hpl.hp.com/pipermail/gc/attachments/20050527/8c2d1ae4/gc.obj
More information about the Gc