RE: data_start (was: RE: cygwin issues)

[Jeff Sturm <jsturm at one-point dot com>]

On Wed, 6 Jun 2001, Boehm, Hans wrote:
> 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.

OK.  I didn't know if exclusions are handled efficiently (and didn't
bother to look).

The difficulty is in finding the exception table boundaries reliably.  I
know how to find ELF segment boundaries, but nothing more granular.  Of
course the debug segments have a wealth of information, but as these
aren't loaded they're not available to the collector at runtime.

> 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.

For C/C++, I agree that is the best policy (unless you can assume the code
is disciplined enough not to store pointers in a char array, for
instance).

In gcj-compiled objects, I suspect actual roots are sparse, found mostly
in the class object and static fields.  Vtables and metadata could be
excluded, perhaps by moving them to their own section.  I have no idea if
that would amount to any real benefit though.

> 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?

Hmm... excellent question.  Evidently the bloat is caused by
-fnon-call-exceptions.  Note this comment in dwarf2out_stack_adjust:

  /* If only calls can throw, and we have a frame pointer,
     save up adjustments until we see the CALL_INSN.  */
  else if (! flag_non_call_exceptions
       && cfa.reg != STACK_POINTER_REGNUM)
    return;

This may be the original patch, it has some historical statistics:

http://gcc.gnu.org/ml/gcc/1997-10/msg00569.html

Though my x86 knowledge is very rusty, I think your suggestion might
consume an extra register because %esp cannot be used for displacement
addressing.  But when -fnon-call-exceptions is in effect, that may be the
lesser of two evils.

You might want to ask this same question on the gcc list.

Jeff