-
Enhancement
-
Resolution: Fixed
-
P4
-
1.2.0, 1.3.0, 1.4.0, 1.4.2, 5.0
-
beta
-
generic, x86
-
generic, solaris_8, windows_95, windows_98, windows_nt, windows_2000
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)
======================================================================
- duplicates
-
JDK-4187333 let multiple VMs share code & constant pools
-
- Closed
-
-
JDK-4287407 Sharing between JVMs
-
- Closed
-
-
JDK-4511554 RFE Class Information Loaded Into Shared Memory
-
- Closed
-
-
JDK-4679557 Faster startup/reduced footprint for subsequent VMs
-
- Closed
-
-
JDK-4834627 sharable copy of the bytecode of JRE classes with multi JVMs running
-
- Closed
-
- relates to
-
JDK-4937400 Classlist for shared classes needs checksum.
-
- Closed
-
-
JDK-4926491 To fix dtrace after sharing is putback
-
- Closed
-
-
JDK-4728032 Install needs to generate shared class files
-
- Closed
-
-
JDK-4172686 Keep the VM running / cleanup & reload application or applet
-
- Closed
-
-
JDK-4914491 Enable to use different heaps in same JVM and share heaps between different JVMs
-
- Closed
-
-
JDK-4317487 RFE: Preventing multiple application instances when launching an application
-
- Closed
-