URLClassloader and native objects

Sun Jun 13 15:28:00 GMT 2004

Andrew Haley wrote:
> There's no code to allow a jarfile to be separately compiled to a .so
> and loaded automagically, though. It's quite tricky to figure out how
> to do it.

This is one of the things I would like to get to work, once an elegant 
solution is found. In a way its a simpler issue in that the code is 
already compiled, we just need a way to tell gcj to grab a hold of it 
from within a custom classloader.
A variation of the issue I'm having, is when the compiled code already 
exists but is statically linked into my executable. Everything works 
great, and I can even use Class.forName() to grab the object. But my 
CCLs are unable to pull this object out, nor load it from the disk 
because it is combined into the executable. Do you have any insight on 
how I may be able get around this?
An ugly hack I can think of would be to have defineClass return some 
custom data, such that it doesn't define a class with VM bytecode, but 
returns some string that references a native object 
(ugly_native_hack://foo.bar.classname). We'de have to bypass any 
standard bytecode verification in these special cases and pull that 
statically linked image out of storage instead. (Of course this is just 
speculation, I don't know enough about GCJ architecture to say it would 
be possible.) Has this already been accounted for in some design work 
previously?
I'm trying to think of a way to handle it without blatantly breaking any 
of the JVM specs... but its difficult as I think it's a unique GCJ 
situation. A more elegant solution may be to force the application to 
load the .class data anyway from some file, then introspect and get the 
CRC/signature of the object. Then check all statically linked images 
that they match and swap for that image. The issue here is that even 
though two classes may have the same method signatures, they could 
contain different code in the methods and still be incompatible.
A third solution might be to have some eternal override. Maybe a 
directory with SOs or a configuration file that will list objects. Any 
objects in this list, when referenced via defineClass will 'thunk' down 
to use a staticly compiled version, or a native .so regardless of what 
data the application is trying to define the class with. So under a 
normal JVM the application will function fine in the usual way, but in 
GCJ if a native object exists, it will get used. The downside here is 
of course, it contradicts the usage of a custom classloader in the first 
place, as a global override will always give the same object that 
matches a certain name, despite what the application wants/sends. It 
allows a CCL to 'own' a native object though, which fixes the problems 
I've been having under GCJ since I don't have to delegate to the system 
classloader for these objects.
Anyway, if you have some ideas here I would like to hear them... as it's 
the issue I would likely try to address first.
> Great. Well, there's a branch called gcj-abi-2-dev-branch, which you
> should be able to build. -findirect-dispatch enables the new ABI.

I'll start digging through code. GCC is still a bit daunting as I'm new 
to it, so it may take a little while before I'll be able to 
contribute... if you know of some reading offhand (online or off) to 
bring me up to speed that would be great.
- Sal