cross-module inlining (was Re: using gcj for a different language - is it possible?)

Wed Feb 11 00:01:00 GMT 2004

Andrew Haley <aph@redhat.com> writes:
> > All the otable_sym's for a given class all have the same
> > section name, so they get merged during linking.
> > _Jv_InitClass() writes the appropriate offsets *over* the
> > _Jv_Method*'s in the otable.

> This seems problematic, because class names in a running Java program
> aren't unique: the same class can be loaded many times by different
> class loaders.

Hrm, but there's only one ClassLoader for compiled (native) code in
gcj, right? I thought ClassLoader.fromBytes() invoked gij...
Actually, I guess you could have multiple native-code loaders in a
dynamically linked binary, but I'm sort of aiming this at static
binaries (which is really the place where section-gc matters).
> > 1. Break up otable_syms[] into a seperate symbol-and-section for each
> > entry. Each otable_sym will be a pointer to the corresponding
> > _Jv_Method rather than a trio of utf8consts. 

> I don't get this. An otable symbol is a symbolic reference to a
> method that gets resolved at runtime. If you're compiling statically
> (and AFAIAA --gc-sections implies that) you know the vtable offset of
> a method at compile time. So what is the otable symbol for?

Well, I think indirect-dispatch is a bit more general than just being
a method for inter-version library compatability. I see it as a
general weakening of the binding between the caller and callee of a
method. This happens to be really useful for versioning, but I think
we can apply it to section-gc as well.
Now, normally indirect-dispatch's binding is so weak that it causes
static linkage with gc-sections to fail -- it's as weak as a
reflective binding, which the linker gc can't "see".
The general idea is this:
 1. Indirect-dispatch eliminates the relocations that section-gc
 normally uses to figure out which sections are reachable
 2. To compensate, we add "dummy relocations" so that a function
 which calls Foo.bar() will have a reloc for Foo.bar()'s MD_*
 entry.
 3. The remaining problematic case is where Foo2 extends Foo and
 overrides bar(). In this case Foo2.bar() still isn't reachable
 by the linker even though it is reachable by method-calls.
 - To compensate, we put a reloc for the symbol "OV_Foo_bar" in
 MD_Foo_bar. We then create a section ".overrides_Foo_bar"
 with that symbol ("OV_Foo_bar") in it. Finally, any method
 which overrides Foo.bar() declares section called
 ".overrides_Foo_bar" -- since the linker merges sections
 with identical names, this will cause Foo2.bar() to be
 reachable
 - This requires a two-line hack to the linker to make it
 merge identically-named sections before gc, rather than
 after.
I guess I was just looking for a sanity check before I throw a bunch
of time at implementing this. If you don't see anything obviously
impossible about this, I'll give it a try and see what happens.
 - a