[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gcl-devel] Stratified Garbage Collection

From: Camm Maguire
Subject: [Gcl-devel] Stratified Garbage Collection
Date: 18 Jun 2002 10:29:08 -0400

Greetings!  To summarize the gcl portability issues, they are mainly

1) object relocations -- in process of solution with bfd
2) cache flushing -- still a one by one process, several arches
        currently completed
3) fault address detection -- this is an optional feature used in
        enabling the SGC (Stratified Garbage Collection) method, in
        which pages are marked read-only, with write attempts
        triggering segfaults, the handler of which marks the page
        writable and schedules it for GC.  This speeds up maxima's
        'make test' on the order of 15% on my machine, so its
        definitely worth doing if we can.

At least in the Unix world, there is supposedly a portable way to
approach #3 -- that of setting up the signal handlers to use the
siginfo struct, and read the address therein.  Unfortunately, in
linux, this is only supported in the 2.4.x series of kernels, and only
on some arches (i386 ppc arm mips ia64).

I'm writing a configure test to probe for this and enable SGC
accordingly.  All is straightforward, except for the fact that one can
compile on one kernel, and run on another.  Two approaches:

1) This is too rare to worry about -- if one can compile on a siginfo
   capable kernel, just assume that we'll always run on one.  Symptom
   if not -- gcl will likely die with a segfault.

2) We need a little sgc check at startup, and code to disable the SGC
   at runtime if necessary.

What do you all think?

Take care,

Camm Maguire                                            address@hidden
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah

reply via email to

[Prev in Thread] Current Thread [Next in Thread]