understanding -findirect-dispatch

Tom Tromey tromey@redhat.com
Wed Nov 6 08:52:00 GMT 2002

>>>>> "Adam" == Adam Megacz <gcj@lists.megacz.com> writes:

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

Yeah.  I've never looked at -findirect-dispatch.

Looking at it now, I think the idea is to make compiled classes more
like interpreted ones: we don't fill in the vtable, nor do we even
compute a method's index into the vtable.

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

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

I think so.

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

I think the point is to do all method lookups during class
initialization.  This lets us implement Java-style binary
compatibility.  Any sort of cross-object reference like this would
defeat that.

Note that -findirect-dispatch hasn't been finished.
So if, say, references to static methods looks like an inconsistency,
that is actually just an unfinished bit.

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

I thought GNU ld would unify Utf8Consts.

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

I don't remember what _MD_ is.  What version of gcj are you using?  I
looked a bit in the source and couldn't find a reference to this.
It rings a bell, but I don't see anything matching that in libgcj.

Adam> Constructing a vtable would then involve looking up the otable
Adam> entry in this hash table to get the Method, then using the
Adam> Method to fill in the vtable.

Yeah.  Another way to get rid of the extra references would be to
leave the `ncode' field empty in _Jv_Method, then fill it in at
class-init time by reading from the vtable.  This is easy and cheap
now that we have _Jv_Method.index.  Also this would halve the number
of relocs at startup, so it is probably worthwhile on that basis
alone; as I understand it, relocs dominate our startup time.


More information about the Java mailing list