This is the mail archive of the java@gcc.gnu.org mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Binary compatibility and finding compiled classes


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]