--bootclasspath overriding peer classfiles in a jar

[Adam Megacz]

Andrew Haley <aph@redhat.com> writes:
> I don't understand this: if there is a reference to a pruned method in
> your application, it'll need to be satisfied or it'll fail at runtime.

Well, the whole idea is that the pruner has ensured that the method
cannot be reached.  Usually this is the result of a call to an
instance method where the constructor of the relevant class is
unreachable.  If you can't construct an object, you can't call
instance methods on it.  But the method which calls the pruned method
might be reachable.  For example

  void blah(Foo foo, Bar bar) {
      if (foo != null) {
         foo.foo();
      }
      bar.bar();
  }

If Foo's constructors are unreachable then foo.foo() is prunable.  But
blah isn't prunable since it's still reachable (but we know that the
call to foo.foo() is either never going to be encountered or else it
ought to throw an NPE, which is what will happen anyways when you JMP
to NULL).
  
> If you're not using indirect dispatch, you must compile your code
> against a jar file that contains the same classes and methods as the
> library you will link against.  This is because method table offsets
> must correspond in the jar and the .so.

Bleh.  Okay, I guess I need to hack a new flag in that tells gcj not
to get upset if it can't resolve a method reference.

> It sounds to me like indirect dispatch is what you need.

Yeah, but then we can't dump the reflection data.  That makes a much
bigger difference than method pruning.

  - a

-- 
"It's lucky," he added, after a pause, "that there are such a lot of
islands in the world.  I almost envy you, Mr. Watson."

                                                   -- Mustapha Mond