Re: GCJ's URLClassloader and 'core' protocol

[Sal <gcj at svf dot dreamhost dot com>]

Tom Tromey wrote:

> Andrew> I've never thought about it, to tell you the truth.  It would be
> Andrew> troublesome to use, because the linker automatcially discards
> Andrew> unreferenced classes when building an executable.  You might as well
> Andrew> put stuff into a shared library.
>
> We talked about this a little a while back.  Well, not exactly this,
> but the idea of loading a given shared library just once and then
> creating several class instances, from different class loaders,
> referring to the same object code.
>
> I think the conclusion was that this would make the code more
> inefficient by requiring another load to find the otable, or perhaps
> impossible due to PIC considerations I didn't quite follow.

Maybe you can shed a little light on this for me.

I may be wrong on this... but from what I can gather, the only 
difference between a class loaded by the primordial classloader and one 
loaded by a custom classloader, is some 'tag' that ties each class with 
the class loader that loaded it.  So, when that class requests to create 
another class (ie. via 'new'), its classloader would get the first poke 
at it.  I think this is standard behavior for Java apps.

I haven't seen/understood much of the GCJ internals yet, but if GCJ 
could just 'tag' certain classes as being loaded by a classloader other 
than the system classloader, it would fix my problem.

In other words a statically linked class would be internally 
loaded/referenced the same way that it is now... but just made to 
reference an arbitrary classloader.  Would I be wrong in guessing that 
its just a pointer that needs to be set to point to a different object?

- Sal