Profiling shows that reading and parsing of idx files takes significant time.
This should be improved.
Posted Date : 2009-01-07 23:00:25.0

N/A

There are multiple things that should be explored, in particular:
  1) idx files are read using RandomAccessFile that is unbuffered. 
     There are thousands of idx file read calls in the procmon log for start of single FX demo, 
     reading about 1.5Mb of data from idx files (and 3.5 mb from cached jar files) (DisplayShelf FX demo).
     Often requests are to read few bytes only. 
     We should consider buffering to minimize number of syscalls.

  2) separate reading manifests and certificate data 
     In some cases we do not need to read and parse whole idx file.

  3) Perhaps different storage method for manifest data. E.g. cache if latin-1 decoder is enough and 
      use it while reading manifest data (latin-1 is faster than utf-8). 
     May be split some most important manifest data into separate part.
Posted Date : 2009-01-07 23:00:25.0

The idea of the proposed fix is to:
  1) postpone reading of index files till they are needed
  2) use java buffer instead of issueing many syscalls to read few bytes
  3) split reading of manifest and certificates
  4) added touchRef() method that updates usage counters of SoftReferences
     (this helps to keep data in memory a bit longer that is useful in some cases)

I've also added fixed size header to simplify reading of index files.

Side changes:
  1) CacheEntry getManifest/getSignerMap/etc logic is improved to be more robust 
     (not vulnerable to GC-ing data before we get hard ref to them)
  2) Moved "ignore class path attribute" logic to setManifest()
  3) removed emptyMap as it does not seems to be used and was not align with logic in CachedJarFile
  4) Changed cache version number as changes are not backward compatible

There are also couple of new but unused fields to be used by fix for other bug
(caching results of security validation). 

We could update CachedJarFile14 in line with changes for CachedJarFile. 
But people using older JRE do not care about performance that much by definition 
and such change will increase complexity of testing. Therefore, it is skipped for now.

Preliminary refworkload tests had shown 1-2% perf improvement (statistically significant). This is especially good as this change was designed as support fix that helps to implement some other perf improvements.
Posted Date : 2009-01-12 22:07:22.0

This fix increments deployment cache version.
To facilate upgrade from previous versions of JRE we do support in-place upgrade of cache entries from previous version of cache. 

However, if this JRE will upgrade the cache and then older update of JRE 6
will try to use the cache it will download application again.
Posted Date : 2009-02-03 12:21:02.0