JDK-4321790 : RFE: Scanning /var/sadm/install/contents for fonts increases memory footprint
  • Type: Enhancement
  • Component: client-libs
  • Sub-Component: 2d
  • Affected Version: 1.3.0
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: solaris_7
  • CPU: sparc
  • Submitted: 2000-03-15
  • Updated: 2002-10-16
  • Resolved: 2002-10-16
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.
Other
1.4.2 mantisFixed
Related Reports
Relates :  
Relates :  
Description

Name: rlT66838			Date: 03/14/2000


java version "1.3beta"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3beta-O)
Java(TM) HotSpot Client VM (build 1.3beta-O-release, 1.3beta-O-release,
interpreted mode)

When no java.awt.fonts property is defined, initializing the
sun.java2d.SunGraphicsEnvironment calls a native method that builds a
font path by scanning the whole /var/sadm/install/contents file for directories
containg .ttf, .pfa or .pfb files.  The /var/sadm/install/contents pkg database
file can get quite large (5.5mbyte on this system with a full solaris 7
installation + the workshop 6 EA release).  Obviously this increases the memory
footprint during startup of a gui java application by the size of the pkg
database file /var/sadm/install/contents.  In the worst case - when the pkg
database file is not cached in main memory - this could add ~ a second to the
startup time of a java application (assuming a disk/filesystem that is capable
of reading files at 5mbyte/sec).  In the best case - when the file is completely
cached in main memory already - it still adds one or two  tenth of a second to
the startup time of the awt.

Since the pkg database file typically doesn't change very often (only when
a new software package or a patch is installed/uninstalled by the administrator)
time can be saved and the memory footprint can be reduced during startup the
AWT by caching the fontpath result determined by scanning the
/var/sadm/install/contents file beween invocations of the jvm.


The suggested solution caches the fontpath in the file
$HOME/.java-awt-fonts-<hostname>   On a subsequent run of a java gui application
the cached fontpath is used instead of scanning the /var/sadm/install/contents
file.  When the pkg database changes because some software was added/removed to
the system, the fontpath cache file is automatically rebuilt.

//Test Case
import java.awt.*;

public class fnt2 {

    public static void main(String[] args) {
        new Font("monospaced", Font.ITALIC, 12);
        System.exit(0);
    }
}


Run "ptime java fnt2" with and without the suggested solution.
(Review ID: 101185) 
suggested_val: 
see attachment for users fix.
###@###.###  2000-03-14

======================================================================

Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: mantis FIXED IN: mantis INTEGRATED IN: mantis mantis-b04
2004-06-14

EVALUATION Some code changes and the use of an "appendedfontpath" key in the font.properties file allows a "hardwiring" of the location of the fonts needed for start-up and resolving of font.properties specified logical fonts. Thus the full search is deferred and occurs only if there is no appendedfontpath, or the application invokes (either directly or indirectly) a GraphicsEnvironment.getAllFonts() call. The benefit to start-up tine is significant (perhaps 25% for a minimal GUI app). The benefits can be extended to other locales by ediiing their appropriate font.properties files. ###@###.### 2002-10-04 ============================
2002-10-04