Binary compatibility and finding compiled classes

Mon Oct 11 09:49:00 GMT 2004

Jakob Praher writes:
 > hi,
 > 
 > Am Don, den 07.10.2004 schrieb Tom Tromey um 19:58:
 > > One thing we'd like to be able to do with the new binary compatibility
 > > code is compile a .jar to a .so, drop it somewhere, and then have the
 > > application pick it up without excessive configuration.
 > this would be a great idea.
 > 
 > > There have been a few different proposals, and implementations, of
 > > this idea. I think it would be useful to clear some of this up now,
 > > before the next release, so we can at least be clear about what is
 > > supported and what is experimental; maybe we can also remove anything
 > > we know we don't want.
 > > 
 > 
 > * as you said the location of any given Class file is denoted by the
 > CodeSource of the Class file.
Um, maybe. I've been running some enterprise-scale apps and the
CodeSource is sometimes less than informative. All you can really
depend on is the byte array itself.
 > why not this simple approach:
 > 
 > create a /var/cache/gcj/socache directory or whatever u call it.
 > 
 > with the the md5 of the CodeSource or full qualified name of the jar
 > file as the entry for the sos.
[ ... ]
 > so when a class gets loaded it is searched whether a cache entry
 > exists.
This is almost entirely done already. The problem happens when you
have a bunch of bytes passed to defineClass and the corresponding
compiled code is in a shared object somewhere -- you then have to map
a checksum to a shared object. For that you need a database of some
kind. 
If we use a scheme similar to that in the ELF format we can do that
with very little runtime overhead. The idea is to have a hash table
that is entirely pointer free, so it can be mmap()ed directly.
Lookups can be done using (on average) a single read operation. It's
very important that access be fast because there may be in access of
10000 compiled classes in a system.
 > Ahh and did you look at making a Inline Cache of indirection table
 > lookups?
Not yet, no. I suspect that if this turns out to be a significant
performance impediment we'd do better to use hash tables in the
objects, as is done by the ELF linker.
Andrew.