United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
JDK-4416624 : multiple JVM runtimes do not share memory between themselves

Details
Type:
Enhancement
Submit Date:
2001-02-17
Status:
Closed
Updated Date:
2012-10-13
Project Name:
JDK
Resolved Date:
2004-01-23
Component:
hotspot
OS:
solaris_8,windows_nt,generic,windows_98,windows_95,windows_2000
Sub-Component:
runtime
CPU:
x86,generic
Priority:
P4
Resolution:
Fixed
Affected Versions:
1.2.0,1.3.0,1.4.0,1.4.2,5.0
Fixed Versions:
5.0 (beta)

Related Reports
Duplicate:
Duplicate:
Duplicate:
Duplicate:
Duplicate:
Relates:
Relates:
Relates:
Relates:
Relates:
Relates:

Sub Tasks

Description

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[]){
                System.out.println("Sleeping...");
                try {
                Thread.sleep(10000);
                } catch(Exception err){ }
                System.out.println("Done");
        }
}


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) 
======================================================================

                                    

Comments
CONVERTED DATA

BugTraq+ Release Management Values

COMMIT TO FIX:
tiger-beta

FIXED IN:
tiger-beta

INTEGRATED IN:
tiger-beta


                                     
2004-06-14
WORK AROUND



Name: krC82822			Date: 02/17/2001


none
======================================================================
                                     
2004-06-11
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
                                     
2004-01-23



Hardware and Software, Engineered to Work Together