A DESCRIPTION OF THE REQUEST :
I estimate that rt.jar (and others) account for 50% (very conservatively), or as much as 75-90% of a JVM's startup time, especially in the case of the larger rt.jar file size in JRE 5.0.

A very simple confirmation of this measurement can be performed by:

1) measure startup performance of the JRE using a java applet enabled site (e.g. http://java.com/en ). Unless your OS provides a mechanism to clear the disk-cache (need to flush rt.jar), this should be measured after reboot, as should measurement in step 4 below.

2) In the JRE install directory, extract rt.jar's contents (using any 'zip' compatible utility) into some directory listed in system property 'sun.boot.class.path' (for example, <JRE-DIR>/classes, which typically is not already created for you).

3) Move rt.jar from <JRE-DIR>/lib somewhere safe, as a backup.

4) Clear the disk-cache (by rebooting if necessary), then restart a web browser with a java enabled URL, and measure startup time.

A test similar to the above also yields vastly improved execution times for javac and javadoc.

JUSTIFICATION :
Many measurements of JRE startup time that I've seen discussed in forums, have only (or ambiguously) been tests performed immediately after application  (JVM) restart, which does not effectively test the cost of opening rt.jar from disk.

The reason this is not an accurate test is that the OS will eventually flush rt.jar (and others jars) from cache depending on total memory load; subsequently, newly launched JVM instances will require re-read of rt.jar, etc from disk, and further zip-iteration to find and load dependent class files. This operation appears to be the most costly one (far and away) in terms of JVM startup times.

ACTUAL -
Though disk-space untililzation may not be efficient for storing mutiple class files, it may be highly prefereable for user experience, to by default store rt.jar's contents in its own directory (not the example JRE-DIR/classes which is reserved, but perhaps a new JRE-DIR/runtime directory). Testing appears to show that only system properties 'sun.boot.class.path' and 'java.class.path' would need this directory added to them during the bootstrapping stage.

Alternatively, the runtime classes could be packaged (stored) in discrete jar files that would only need to be loaded based on package. For example, java.lang could be its own jar file (java.lang.jar), and java.applet (java.applet.jar) would be its own (along with supporting com.sun class-data). The actually gain (if any) would be dependent on if / how the JVM searches the classpath, or if it knows ahead of time which runtime classes can be found in which jar files -- instead of having to load/search all jars in the classpath.

In these scenarios, potenially superfluous class-data (CORBA, XML, WAV, PNG and GIF files) contained in the current rt.jar, does not need to loaded (by the OS disk-cache) for simple applet or main() cases - nor also in the case of javac and others.