data_start (was: RE: cygwin issues)

Wed Jun 6 08:49:00 GMT 2001

This may be old news to you, but ...
In general, the garbage collector can make use of any information about
static roots that you can generate. My own preference would be to add the
entire static data segment by default, and then use GC_exclude_static_roots
to throw out the junk, like exception tables. In my opinion, this has the
right semantics, in that you can write C/C++ code, have it save pointers to
Java objects in static data, and things will continue to work. (As I
recall, the CNI description didn't seem to be terribly clear on exactly
where you were allowed to save Java pointers. I think the right answer
should be basically anywhere, though that requires a little bit of thought
and infrastructure.)
The current collector implementation is not well-suited to very fine-grained
layout information for static data. But that's purely a data structure
issue for the root set representation, and could be fixed. Excluding entire
sections shouldn't be an issue in any case.
On a slightly related note:
We happened to be looking at gcj3.1 generated code on X86. It looks like
the unwind tables are quite big. I don't understand the details, but it
looked like one issue was the fact that the backend passes parameters by
pushing them one at a time instead of the more RISC-like approach of
decrementing the stack pointer once and then storing all the arguments to
the stack. The net result is that the stack depth is often different at
every instruction, and thus every instruction has its own description. Does
this make sense? Should it be changed?
Hans
> -----Original Message-----
> From: Jeff Sturm [ mailto:jsturm@one-point.com ]
...
>> 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
>>