24764 - implement open jar file cache

Status: VERIFIED FIXED

(Core :: Networking, defect, P3)

Description

[Warren Harris]

We need a cache to manage open jar files. We determined that we needed such a 
thing in 4.x in order to increase java classpath performance, and minimize the 
number of open file descriptors to jar files. Now we need this if we want to 
package chrome files into jars. (Hopefully we can steal some code from mozilla 
classic for this.)

This facility should probably live in libjar, rather than in the jar protocol.

Here's a comment from Dan on the subject: "Before putting resources into JARs we 
need a JAR service manager of some kind. Opening JARs is expensive since the 
entire archive directory structure has to be parsed and a hash-table created. 
Rather than creating the low-level JAR reader component directly, people should 
instead ask this service for the archive so it can give refcounted interface 
pointers back in the case where the archive is already open."

Comment 1

[Warren Harris]

Of course, a related part of this is hooking it up to the jar: protocol so that 
the jar files it uses come from the open jar file cache.

Comment 2

[Eli Goldberg]

QA Assigning to tever.

Comment 3

[Jim Roskind]

PDT was trying to make a beta1 call... what element of performance should be 
sped up by this change? Basic startup?  Other?  For that element, how do we 
currently compare with 4.x?

Comment 4

[Daniel Veditz [:dveditz]]

This is to compensate for the horrible extreme *loss* of performance when we 
move XUL files et al into jar files and try to access them with the 
stateless "jar:" protocol. Opening and closing these jar files for each 
XUL/CSS/JS file we need will be far worse than just grabbing the equivalent 
file on disk unless there's a service that will return handles to open jar 
files rather than reopening them.

A simple first pass at this would be for nsJAR to keep a list of open archives, 
and for the chrome service to keep at least one extra handle to each opened 
archive. This would be quick to implement and do the job for beta1.

Comment 5

[Phil Peterson]

PDT+

Comment 6

[Warren Harris]

Adding perf keyword.

Erasing PDT+ designation because chriss says we don't need to ship the beta 
with jar files now.

Comment 7

[Daniel Veditz [:dveditz]]

Zlib as a component needs to go away -- we don't own it and any bugs there 
probably surface in a particular area of the product. This bug has nothing to 
do with Zlib in any case.

Guessing at networking for the component. Maybe some Chrome thing instead. 
Since warren owns it networking it is.

Comment 8

[Warren Harris]

Moving to M15.

Comment 9

[Warren Harris]

Marking beta2.

Comment 10

[Warren Harris]

Moving to M17 which is now considered part of beta2.

Comment 11

[Peter Trudelle]

Mass-adding beta2 keyword to all skins bugs.

Comment 12

[leger]

Putting on [nsbeta2+][6/01] radar.  This work must be done by 06/01 or we may 
pull this for PR2.

Comment 13

[Warren Harris]

Checked in.

Comment 14

[Tom Everingham]

verif.
NT 2000060622