On Fri, 2005-03-11 at 10:02 +0000, Andrew Haley wrote: > Ziga Mahkovec writes: > > This seemed a bit unusual and after inspecting the gcj-dbtool sources, I > > found out that in resizeMap(), a new PersistentByteMap is created for > > each jar package that is added -- amounting to almost 150 several-MB > > temporary files created. I don't think this was intentional. > > This is wrong. > > Other running applications may be accessing a .db file while it is in > place, and it is not safe to modify it. The right technique is to > copy the old file to a new one, add to the new one, and then rename > it. Any processes that have the old one mapped will continue to use > it. Ah, I hadn't thought about that. Probably because this happens during installation, where the database was just created, so I wouldn't expect any consumers yet. But I see your point; this could be a problem for deferred installations of certain eclipse packages. > The problem is that the Eclipse installer is doing things in a very > inefficient way. The most efficient way is to generate a separate map > for each jar file, and then merge them all at the end. This is very > fast. It also has the advantage that the resulting file is more > compact. Maybe this could be further improved by creating a single separate map for all new jar files (utilizing a new "--unsafe" gcj-dbtool switch which triggers the behavior in the patch). Then, only two maps would have to be merged, avoiding the need to create 150 separate maps. -- Ziga
