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

[Adam Megacz]

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