RE: Eliminating static roots from gcj

[Andrew Haley <aph at redhat dot com>]

Hans,

I have a problem before merging this code to the trunk.

Accesses to String and Class constants is now slower than before.
Previously, such an access was simply

   _CD_<class>[N]

where _CD_<class> was an array in the initialized data section.  With
PIC, this simply generated a PC+offset fetch instruction:

        movq    8+_CD_q(%rip), %rax

Now that we aren't scanning the data sections of objects, we have to
do something like

   class$->constants.data[i]

which generates

        movq    q::class$(%rip), %rax
        movq    56(%rbx), %rax
        movq    8(%rax), %rax

It is possible to cache a pointer to the constant pool in the
initialized data section, so this code sequence could be reduced to

        movq    _CD_q_ref(%rip), %rax
        movq    8(%rax), %rax

but it's still an extra fetch for each method that requires access to
a constant.

There are (at least) two possible ways to improve this.

1.  Allocate every instance of Class in the same memory block as its
    constant pool.  Then, accesses to fields in Class and constants
    can be done as indexes from the same base pointer.  This is
    potentially tricky, because the compiler does not know the size of
    instances of Class, and so constants would have to be at negative
    offsets from the start of the object.  Would this be possible with
    finalization and locking?

2.  When scanning an instance of class, do:

    GC_ptr p = klass->constants.data;
    if (! GC_base (p))
       for (int i = 0; i < klass->constants.size; i++)
	   /* Mark klass->constants[i]  */

    If we do this, we can go back to the same code generation sequence
    as before.

Clearly, ceasing to scan shared objects conservatively is a big
advance for gcj, but I'd prefer it not to be accompanied by
regressions in code quality.

Andrew.