Ziga Mahkovec writes: > 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 gcj-dbtool isn't just used by Eclipse. It has to be safe when adding a jar in a live system. > > 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. What's the problem with creating 150 separate maps? I don't get it. Andrew.
