[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
three:
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
- [Gcl-devel] Stratified Garbage Collection,
Camm Maguire <=