JDK-4416624 : multiple JVM runtimes do not share memory between themselves
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 1.2.0,1.3.0,1.4.0,1.4.2,5.0
  • Priority: P4
  • Status: Closed
  • Resolution: Fixed
  • OS:
    generic,solaris_8,windows_95,windows_98,windows_nt,windows_2000 generic,solaris_8,windows_95,windows_98,windows_nt,windows_2000
  • CPU: generic,x86
  • Submitted: 2001-02-17
  • Updated: 2017-05-16
  • Resolved: 2004-01-23
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.
5.0 betaFixed
Related Reports
Duplicate :  
Duplicate :  
Duplicate :  
Duplicate :  
Duplicate :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  

Name: krC82822			Date: 02/17/2001

17 Feb 2001, eval1127@eng -- see also # 4187333.

java version "1.3.0"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.0)
Java HotSpot(TM) Client VM (build 1.3.0, mixed mode)

The java runtime right now is pretty inefficient when it comes to
having multiple runtimes.

You can take the smallest class, run it, and it will take up
X megs of RAM. And the next JVM running it will take up another X megs.
and a third JVM will take up another X megs.
[trivial little program follows below.]

I'm happy to see that 'X' has decreased, from 12 megs for JDK1.2, to
about 6 megs for JDK1.3
But in principle, I would think it could be better still.

If you want java programs to be used as commonly as C programs,
you need to make the runtime similarly efficient about sharing common objects.

One of the reasons C is so memory-efficient is that it has a shared
"libc". The java runtime seems to lack that. I don't think the
common system classes are being shared at all. I guess they're
all being loaded in from "rt.jar" separately.

What the runtime needs is a pre-expanded set of instances of the
standard classes, that can be shared in a .so with additional runtimes.
[Or something similar anyway. Hopefully, you guys can think of something that
 would deliver a similar level of memory sharing]

Here's a trivial class to demonstrate the problem:

public class test {
        public static void main(String args[]){
                try {
                } catch(Exception err){ }

Each invocation in parallel, takes the same amount of additional memory as the
initial jvm invocation does.
6 megs each time, for a 542-byte class that doesnt even attempt to open a
graphics window.

This kind of memory footprint makes it impractical to write small java
utilities. If everyone on a system were to use them, they would quickly swallow
available RAM.
(Review ID: 117186) 

CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: tiger-beta FIXED IN: tiger-beta INTEGRATED IN: tiger-beta

WORK AROUND Name: krC82822 Date: 02/17/2001 none ======================================================================

EVALUATION ###@###.### 2001-10-12 In progress. ------------------------------------------------------------------ Class data sharing (CDS) has been introduced in the 1.5 release as the first step toward addressing this problem. The CDS code was originally developed by Apple Computer, Inc. during their port of the Java HotSpot VM to Mac OS X and was further developed within Sun primarily by ###@###.###. CDS is supported on platforms where the Java HotSpot Client VM is the default, except for Windows 95/98/ME. When the JRE is installed on supported platforms using the Sun provided installer, the installer loads a set of classes from the system jar file into a private internal representation, and dumps that representation to a file, called a "shared archive". If the Sun JRE installer is not being used, the shared archive can be created manually, as is explained in the Java HotSpot VM documentation (linked to from the 1.5.0 release notes). During subsequent JVM invocations, the shared archive is memory-mapped in, saving the cost of loading those classes and allowing much of the JVM's metadata for these classes to be shared among multiple JVM processes. The primary motivation for including CDS in the 1.5 release is the decrease in startup time it provides. CDS produces better results for smaller applications because it eliminates a fixed cost: that of loading certain core classes. The smaller the application relative to the number of core classes it uses, the larger the saved fraction of startup time. The footprint cost of new JVM instances has been reduced in two ways. First, a portion of the shared archive, currently between five and six megabytes, is mapped read-only and therefore shared among multiple JVM processes. Previously this data was replicated in each JVM instance. Second, less data is loaded out of the shared archive because the metadata for unused methods remains completely untouched as opposed to being created and processed during class loading. These savings allow more applications to be run concurrently on the same machine. However, on some operating systems (in particular, Windows), the perceived footprint of the process may increase, because a larger number of pages are being mapped in to the process's address space. Reducing footprint, including perceived footprint, remains a high priority and work is ongoing in this area. The class data sharing work is a step toward reducing the startup time and footprint of Java applications without sacrificing stability or compatibility. In the future we plan to share and cache other data in the archive and extend its functionality to application-level classes to more significantly improve startup performance for larger applications. ###@###.### 2004-01-23