Avoiding the need of having to load the "full JRE" for every VM invocation was one of the most voted RFE on Sun's bug parade. It was promised for Java 1.4 but it was not sure to be present even in Java 1.5 (http://www.javalobby.org/thread.jspa?forumID=61&threadID=8563 ).

I don't not how much did the JavaLobby request affected the final decision, but in bug's #4416624 evaluation (http://developer.java.sun.com/developer/bugParade/bugs/4416624.html) you can now read that is going to make it.

Lets hope that it is enough to make a difference on the client side.


<quote>
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 xxxxx@xxxxx

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.

xxxxx@xxxxx 2004-01-23

</quote>

So, JITed classes are still private? I'd imagine that once we're up and going, that JIT compiled classes are taking quite a bit of memory independant of the .class files.

So, JITed classes are still private?

I don't expect the implementation of sharing in 1.5 to help noticeably. Ie, useless. JVM sharing might be useful, if Sun gets a chance to pursue it. But generally I don't want Sun to spend time optimizing the memory footprint. Moore's Law is what'll deliver performance soonest. I want Sun to focus on what Moore's Law can't fix: bugs and new features.

Taskmanager shows that the VM size for my IDEA 4 RC1 is 120MB and it's started with -Xms64m -Xmx64m. The second biggest memory hog is MySQL with 38MB, 3rd. is Mozilla Firebird with 20MB. All other applications eat much less memory.

Moore's Law doesn't help you with customers running with 256MB on their machines. Running multiple Java apps consumes hundreds of megabytes which kinda makes them useless since my laptop begins a swap party when I alt+tab between them. That's on 512MB memory.

Even the smallest application can take more memory than the entire web browser. So I would think that the memory consumption and start up time deserves to have a serious look. It's about time.

Memory is and will remain a big problem. Modern SMP boxes have taken to putting memory on the boards with CPUs, this means that to expand memory means buying another CPU board which considerably adds to the cost of what for many PC users is a simply memory upgrade.

Java has a huge problem today in that the only containment vessel it offers is the JVM, i.e. process, thus, if you want to truly isolate applications from each other then that means multiple JVMS and lots of memory.

Given the cost pressures above and the implications of the isolation issues above, then it's clear that something needs to be done to drop the memory usage of a shared JVM instance to just it's data heap and specific classes and JITed code.

Basically, I'd like to see a 'root' JVM running on a box, an application server (in my world). It can spawn child JVMs which are really just JVMs with heaps etc for running each application. The core JVM can have it's own heap and it's own threads, customer applications, RAs etc are forced to run in a child JVM and this can be killed/isolated independently of other components. I like some of the ideas in JSR 1 but I'd like a concept of child JVM made first class and for the root JVM to be able to easily spawn such things and for those to spawn further ones under their direction.

IBM has something like this with the CICS JVM which had these kinds of features in a more limited way. The WebSphere on Z design has parallels with this also but isn't quite at this level yet.

The sooner we can get to a JDK with these kinds of features and APIsets, the faster we'll get to more manageable and reliable systems.

Billy

/Nipsu
Taskmanager shows that the VM size for my IDEA 4 RC1 is 120MB and it's started with -Xms64m -Xmx64m
/Nipsu

How is that possible? -Xmx64m means upper limit of 64m, isn't it?

> Taskmanager shows that the VM size for my IDEA 4 RC1 is 120MB and it's started with -Xms64m -Xmx64m
> /Nipsu
>
> How is that possible? -Xmx64m means upper limit of 64m, isn't it?

64 Megs is just for the heap, that is. The JVM uses another 30+ megs for non-trivial apps.

On Windows, you can get more exact memory consumption measurement with the Procexp tool from Sysinternals.com. Taskmgr is useless for this.
--
Attila

> > Taskmanager shows that the VM size for my IDEA 4 RC1 is 120MB and it's started with -Xms64m -Xmx64m
> > /Nipsu
> >
> > How is that possible? -Xmx64m means upper limit of 64m, isn't it?
>
> 64 Megs is just for the heap, that is. The JVM uses another 30+ megs for non-trivial apps.

+ another 30MB for memory mapped files that IDEA is reserving. Total of 60MB extra.

> --
> Attila

I downloaded the util and the readings are:
IDEA: Virtual Size 512MB, Peak Working set 72MB.
Mozilla: 63MB, 22MB.

One of the things that might have a big impact on startup speed is the amount of data needed to read from HD before the app is up and running. For Mozilla this figure is 4,8MB and with IDEA it's 15,3MB. So that should translate to roughly 4x slower start up speed if the data has to be read from separate files (more small reads is much slower than one big read)

And here're the figures of number of reads:
IDEA ~250000!
Mozilla ~1000

I think the reason why IDEA startup is so slow is now quite clear... quarter a million IO reads might take some time even on fast systems...

memory schmemory

finally we can start running our Ant/Maven tasks without firing up a VM again and again ...

good job they're putting it in the Tiger release

Wouter.

FYI, You are still firing up a VM again and again, albeit with less impact on system resources.

You can already do this in maven using the console plugin.

lol...

there's already a bug on the Tiger!... :)

look at the 4977812 bug... look's like the VM crashes after a call to System.gc()... the crash happen after a while... (sorry about my horrible english)

>
> there's already a bug on the Tiger!... :)

Already at the alpha stage! Oh my... Usually only stable releases have bugs, eh?

So it will be possible to write unix-style pipes&filters command-line utilities! Great. I always thought it was stupid to load the whole of Corba and Swing for these things.

groetjes,
Joost

I might be missing something, it makes a lot of sense for MS CLR to share classes because entire GUI is written or will be written in C# / VB including outlook and parts of Word etc. but what is the use case for java JVM. With today Pentiums 4 and at least 256M of memory, who cares how long does it take to start Jbuilder or IntelliJ, even for applets it is still takes longer to download remote classes then to load installed system in memory. I’m not even talking about serer side where it completely useless (it is still makes sense to write jikes-like native compiler). And who and how would define what classes to be cached and what not, e.g. apache commons, Xerces, log4J, etc.

I agree it is nice to have feature but fixing Swing or even rewriting it with SWT idea in mind would make java desktop more client appealing.

Will this eliminate having 10 java icons if I visit 10 web pages that have java applets on them? I hate having a million icons.

I you run only one Java app, then I guess it does not matter. If you are running multiple ones, then it should help a lot.

JSR-121
http://bitser.net/isolate-interest/
One of isolates could load all classes (do some other initialization) and keep them in memory. Other isolates could get this initialized data thru shared memory. This will boost startup times 10x.

default

Why is CDS not supported on server JVMs too ?
I suppose it will help when a cluster of JVMs are running on the same server.

Mileta

This feature is suitable for inetd service & other isolated JVM interacts with native code (JNI) and RMI. Fast startup also minimize the MTBF too.

MTBF stays the same, recovery time is improved.

Billy

Small correction:
MTBF=Mean Time _Between_ failure
it reduces _downtime_ of the single JVM... unless your other servers (JVMs) can't take the load ;-)

Messi

Fast startup also minimize the MTBF too.

Minimizing MTBF is bad. Presumably one wants it maximized.