Wed Nov 6 08:52:00 GMT 2002
>>>>> "Adam" == Adam Megacz <email@example.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
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