This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Re: Binary compatibility and finding compiled classes
- From: Andrew Haley <aph at redhat dot com>
- To: Jakob Praher <jpraher at yahoo dot de>
- Cc: Tom Tromey <tromey at redhat dot com>, "java at gcc dot gnu dot org" <java at gcc dot gnu dot org>
- Date: Mon, 11 Oct 2004 10:49:29 +0100
- Subject: Re: Binary compatibility and finding compiled classes
- References: <m34ql6mmuv.fsf@localhost.localdomain><1097433873.6296.52.camel@jaques2>
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.