Re: Dynamic loading - solutions and more problems

[Matt Welsh <mdw at cs dot berkeley dot edu>]

Bryce McKinlay <bryce@albatross.co.nz> writes:
> Looking at the stack trace it appears that initializeClass() may be getting c
> alled on "ToLoad" before it has actually been prepared/loaded.

First of all, even if "ToLoad" is never referenced by "MainProgram", I get
the same crash for the same reason. So I think you're right that 
initializeClass() is being called -- on "MainProgram" -- too early.

> However... I'm actually not totally convinced that your example is useful. Yo
> u are loading a class with forName() but then referring to that same class
> directly in the code. Therefore, it must be available at compile time, so why
>  not link it the normal way? Or am I missing the point?

You're right that this is a contorted example. However, the problem still
arises if I do either of the following:
	1) Just do a "new ToLoad()" in MainProgram.java
	2) Don't reference ToLoad() at all

So the bug with PrepareConstantTimeTables has nothing to do with loading a
class other than the one being run --- I see it on the most trivial program.
(However, it only shows up when I use -fno-assume-compiled.)

> A more useful situation would to be to dynamically load a class, unknown at c
> ompile time, that implements a known interface or extends a known class, so
> your example would look something like:

Right. However, the case that I'm presenting *should* work, even if it's
somewhat artificial. 

Your new example doesn't work for me. Neither does the following: if I 
have "ToLoad" implement an interface ("ToLoadIF") and then have in 
MainProgram.java:

      Class ToLoadCls = Class.forName("ToLoad2");
      ToLoadIF toload;
      toload = (ToLoadIF)ToLoadCls.newInstance();
      toload.doit();

We get the same failure in loading MainProgram.so, ostensibly because
"ToLoadIF" is being referenced by MainProgram.so, and the loader doesn't
like undefined references.

So the core problem here is that compiling any class down to a .so and 
allowing gij to load it won't work if that class accesses *anything outside
of the classes defined in libgcj). Using -fno-assume-compiled does not solve
the problem because of the bug in PrepareCompiledClasses().

I'm working on tracking this down now.

If there is a newer version of gcj/libgcj that I should try, let me know, but
I am unwilling to use an unstable egcs to do it.

Matt