data_start (was: RE: cygwin issues)

Tue Jun 5 20:43:00 GMT 2001

On 2001年5月31日, Boehm, Hans wrote:
> Unless its needed for some embedded platforms, we might consider getting rid
> of that in the trunk, or for some later version. Recent versions of the GC
> under Linux should
>> 1) Look for __data_start, and if that fails
> 2) Look for data_start, and if that fails
> 3) Look for _end, and walk backwards until they encounter an unwritable
> address
>> I claim at least the 3rd step should work everywhere, though it's suboptimal
> in several respects.

Depending on how you use gcj, _end makes little difference. I push most
of my class archives into shared libs, so the main executable is usually
tiny.
Anyway, I've been toying with the data_start issue for another reason.
Right now, the static roots found by GC span entire writable data
segments. This works reliably but is perhaps a little inefficient. Is
there some way the data segment could be scanned precisely, perhaps with
help from the compiler?
I ran a little experiment. The .eh_frame section is between data and bss,
and contains no roots. I wrote an ugly hack to exclude .eh_frame from the
root set for libgcj. That cuts the overall extent of static roots by ~75%,
from 2MB to 0.5MB. With this single change GCBench runs about 1.2%
faster than before.
The difficulty is detecting section boundaries reliably. ELF doesn't
provide much help. It is a little easier when linking with -Bsymbolic, in
which case global symbols can be used to mark the beginning and end of
data, and a static initializer can invoke GC_add_roots. But as we know,
-Bsymbolic creates other problems that are hard to solve.
Jeff