[fedora-java] gcj-dbtool --rebuild

[Andrew Haley]

Bryce McKinlay writes:
 > Andrew Haley wrote:
 > 
 > >Gary Benson writes:
 > > > Thomas Fitzsimmons wrote:
 > > > > Here's what "gcj-dbtool --rebuild" needs to do:
 > > > > 
 > > > > Merge all db files in "$prefix/lib/gcj-$gcc_version/classmap.db.d/" into
 > > > > "$prefix/lib/gcj-$gcc_version/classmap.db".
 > > > >
 > > > > Even better for FC5 would be eliminating the need for individual .db
 > > > > files altogether.
 > > > 
 > > > This would require the hashes to be stored in the .so, which I don't
 > > > think they are at present.  Is this something which is possible?
 > >
 > >Yes.  It is part of the Grand Plan.  But reading the hashes out of a
 > >.so is going to be far slower than out of a .db.  It wouldn't be
 > >practical if you had thousands of them.
 >
 > With hashes stored in the .so's, we'd still want to keep the .db as a 
 > sort of cache. The advantage would be that updating/rebuilding the db 
 > becomes much faster, as dbtool just needs to compare the hashes in each 
 > .so with what is in the database rather than reading all the bytecode 
 > and recomputing the hashes.

Well, we only compute the hashes at package build time, so this won't
affect installation time.

 > It would be too slow for the general case to have libgcj reading
 > hashes from all the shared libraries at runtime, but it would allow
 > things to work better in the case where the classes in a particular
 > .so at runtime don't match the contents of the db - something that
 > could happen during development or in case someone forgets to run
 > dbtool. Currently we just quietly fall back to the interpreter in
 > that case, resulting in (seemingly) mysterious performance
 > problems.

Right.  This is effectively "closing the loop", and it's one reason
for putting the hashes into the DSOs.  It's just one less weird thing
that can go wrong.

Andrew.