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