understanding -findirect-dispatch

Adam Megacz gcj@lists.megacz.com
Tue Nov 5 20:06:00 GMT 2002


Okay, I think I figured out a bit more...  again, please help if you
know the answers to these questions.....  I know Bryce is the best
person to answer this, but he doesn't seem to be around.


> 1. When I turn on -findirect-dispatch, if A.foo() calls B.foo(), will
>    there be any relocations in A.o referencing any part of B?

I believe that the answer to this question is "no"; is this correct?


> 2. Instead of putting an entire utf8const into A, why not just put in
>    a relocation for the __MD symbol of foo() in B.o?

Okay, so I realized that each Method instance doesn't get its own
symbol; rather, they're aggregated into a single symbol prefixed with
__MT_.

Would it be possible to modify gcj to emit a symbol for each Method
instance in the __MT_ array, and then fill otables with relocs
referencing the corresponding __MD_ symbols? [*] This technique would
have the following advantages:

1. It would shrink post-link binaries because the class name would
   only appear once in the resulting binary rather than in every class
   whose methods call its methods.

2. --gc-sections would work better because every method X that calls
   method Y will have a reloc for __MD_Y (which in turn has a reloc
   for Y).  This means that if Y is callable, it is also not gc-able
   by --gc-sections.

With this change, there are only two barriers remaining to being able
to use --gc-sections:

1. Foo.class references __MT_Foo, which references each of the
   __MD_Foo. Is there any way to "weaken" the reference from MD to MT
   so that --gc-sections will ignore it?

2. If SuperClass.foo() is reachable, then SubClass.foo() must also be
   reachable.  This is really tricky, since SuperClass cannot be
   expected to have a reference to all its subclasses.  This might be
   where I have to stick in a post-compile, pre-link analysis phase
   that sticks in some extra symbols to complete the reachability
   graph.

   One additional nice-but-not-necessary optimization is that if a
   class's constructors are all unreachable, then its nonstatic
   methods must be unreachable, even if the methods they override
   *are* reachable.  This would be nearly impossible to do with
   --gc-sections.

  - a

______________________________________________________________________________
[*] Failing this, the otable could just be filled with references
    directly to the Method's function pointers (they have symbols).
    In Class.initializeClass(), the function pointer for each method
    could be inserted into a hash table mapping functionptr->Method.
    Constructing a vtable would then involve looking up the otable
    entry in this hash table to get the Method, then using the Method
    to fill in the vtable.

    This might not work properly for abstract methods, though...


-- 
Microsoft follows standards the same way fish follow migrating caribou.



More information about the Java mailing list