JDK-6791250 : Tune cache index files
  • Type: Enhancement
  • Component: deploy
  • Sub-Component: deployment_toolkit
  • Affected Version: 6,6u3
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: generic,windows_xp
  • CPU: generic,x86
  • Submitted: 2009-01-07
  • Updated: 2010-09-26
  • Resolved: 2009-05-13
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 6 JDK 7
6u14 b02Fixed 7Fixed
Related Reports
Duplicate :  
JDK-6669543 - Applet updating CacheEntry causes AccessControlException
Relates :  
JDK-6852576 - 1.6.0_14 Jar caching is broken
Relates :  
JDK-6803363 - Regression : cacheviewer doesn't show javaws application launched in 6u14 b02 PIT.
Description
Profiling shows that reading and parsing of idx files takes significant time.
This should be improved.
Comments
EVALUATION 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.
03-02-2009
SUGGESTED FIX http://sa.sfbay.sun.com/projects/deployment_data/6u14/6791250.3/
03-02-2009
EVALUATION 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.
12-01-2009
EVALUATION 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.
07-01-2009