understanding -findirect-dispatch

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.