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.
