United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
JDK-4321790 : RFE: Scanning /var/sadm/install/contents for fonts increases memory footprint

Details
Type:
Enhancement
Submit Date:
2000-03-15
Status:
Resolved
Updated Date:
2002-10-16
Project Name:
JDK
Resolved Date:
2002-10-16
Component:
client-libs
OS:
solaris_7
Sub-Component:
2d
CPU:
sparc
Priority:
P4
Resolution:
Fixed
Affected Versions:
1.3.0
Fixed Versions:
1.4.2 (mantis)

Related Reports
Relates:
Relates:

Sub Tasks

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



Hardware and Software, Engineered to Work Together