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.