Organization and symbol lookup for shared libraries

[Andrew Haley <aph at redhat dot com>]

I've been thinking more about Bryce's comments.


Object: A clean and simple way for gcj users to deploy precompiled
Java packages.


Background: On the gcj-abi-2-dev-branch is a new scheme that uses a
database to look up precompiled class files using the bytecode array
of a .class file as the key.  This is good if you have the .class
files around, but not if you don't.

However, users of gcj want a quick way to deploy precompiled libraries
that doesn't require installing .jar or .class files.  They want to
add many packages without slowing down their programs.


So, I propose we do this:

At startup, libgcj will look in each directory in the java.ext.dirs
path to see if there exists a database file.  If there is one, libgcj
will add it to the gnu.gcj.precompiled.db.path.

When libgcj tries to resolve a classname, it will look in each
database for a mapping from

   "somePrefix:classname" -> "shared object name"

and open the shared object if it finds a match.

To make deployment easy, the directory that contains the database may
contain a makefile, which in is simplest form will be like something
rather like this:

----------------------------------------------------------------
gcj.so.db: *.so *.so.*
	gcj-dbtool --addlibs gcj.so.db *.so *.so.*
----------------------------------------------------------------

(This assumes that we can persuade gcj-dbtool to read the list of
classes from a shared library.  This may be tricky to do portably.)

So, all the user of a system will need to do when installing gcj
precompiled packages is move them into an extdir and type "make".


This is, as far as I can see, the easiest way to deploy gcj compiled
packages.  It's also very fast at runtime, because there's only a
single probe for each class, and we only dlopen() a .so file when we
are certain that it contains the class we want.


[An aside: There are large applications where we need to have multiple
.so files (which correspond 1-to-1 with multiple .jar files) that
contain different versions of the same classes.  This will require a
mapping of 
"jar:file///usr/share/java/myjar.jar!/my/code/Foo.class" -> "shared object name" 
but that isn't relevant here.]

Andrew.