Improve startup time of Java. On the client the user should not realize they are
using Java. On the server improve startup time after reload for availability.
This feature is focused on changes required by the JVM itself. The feature has
been split to a new RFE for just library/non jvm changes. The library
changes are tracked under 4665444.

======================================================================

N/A

This feature has been added for Tiger release

======================================================================

I am concerned about the effect of increased class file size due to the
new verifier tables in customer code; this may affect startup time.
Should it become necessary, it might be possible to significantly reduce the
verifier table sizes by omitting method parameters, whose types can be
inferred from the method signature.

  xxxxx@xxxxx   2003-07-30


Class data sharing has been introduced in the 1.5 HotSpot JVM as a step toward
solving this problem. Sharing reduces startup time by eliminating the class load
time for core classes which are shared, and also reduces footprint by allowing
the representation of the loaded classes to be shared among running JVMs.
Detailed performance numbers are in the comments section. Startup time remains a
high priority and work will continue to reduce it in future releases under new
bug IDs.

  xxxxx@xxxxx   2004-05-26

What about having a *cacheable* JIT ?

First, once a class has been verfied, this should be copied 
into the cache and the next time the user use the same 
class (same URL access path and same className) then it 
directly used the .class without passing the class verifier.


Then, (this one is more complex and may require some major 
job in HotSpot) why not store intermediate optimisation 
data computed (cf. JIT generic context) ?

This means that instead of re-optimize the same code each 
time the application start, it reuse the result of the 
previous optimisation at step n-1.

This will not help at first launch but will greatly improve 
the next ones.

É isso aí, vamos agilizar esse negócio. Com tempos de 
inicialização melhores, estaremos pelo menos em pé de 
igualdade com outras linguagens, que apesar de pebas como 
o Perl, por exemplo, parecem mais rápidas. Se para o 
desenvolvedor é difícil ficar 3 ou mais segundos esperando 
uma aplicação inicializar, imaginem para o usuário final? Em 3 
segundos, o usuário já deu 10 clicks no atalho da aplicação... 
aí complica, né?

Yes! If perl can launch in less than a half a second then 
there's no reason Java can't. This factor is IMHO the single 
most important reason why people still think Java is slow.  
Once it launches, it's as fast as or faster than python or perl 
or even C in many cases. But until we get out of the slow-
launch ghetto, many developers (scripters and architects 
alike) will still be reluctant to use Java for "real" applications 
and utilities.

Please add a numerical goal to this feature. I'd say that 
launching in less than one second on a 400 MHz CPU on any 
OS (Mac, Linux, Windows) is a good place to start.

There are many ways one could accomplish this.  One way is 
to delay loading all the various standard libraries, either until 
they're needed, or in a background thread.  Another is to use 
dynamic libraries to ensure that all launches but the very first 
one will use the same executable code.  Another is to set up 
a de facto "java demon" that launches and stays resident; if 
the java demon is live, then running java from the command 
line should send a message to the demon and have the demon 
execute the code and then wait for the demon to return the 
result.  (The message may be sent using RPC or TCP or 
Windows messaging or whatever is appropriate for the 
platform.) I'm sure the propellerheads at Sun have lots of 
good ideas about which strategy would be most effective -- 
all that really matters is that the startup time goes down.

[BTW, that "cacheable JIT" comment is irrelevant to this issue 
and should be removed or turned into a separate RFC.]

I just did a simple benchmark.  On my Linux box, Perl takes 
0.03sec to launch and print "foo".  Python takes 0.1sec. Java 
takes 3.0 sec.  That's exactly 100 times slower than Perl, and 
30 times slower than Python.

[alex@edamame alex]$ time perl -e "print \"foo\""
foo
real    0m0.214s
user    0m0.010s
sys     0m0.010s
[alex@edamame alex]$ time perl -e "print \"foo\""
foo
real    0m0.027s
user    0m0.020s
sys     0m0.010s
[alex@edamame alex]$ time python -c "print 'foo'"
foo

real    0m0.518s
user    0m0.130s
sys     0m0.030s
[alex@edamame alex]$ time python -c "print 'foo'"
foo

real    0m0.138s
user    0m0.100s
sys     0m0.040s
[alex@edamame alex]$ time java Foo
foo

real    0m3.489s
user    0m2.410s
sys     0m0.160s
[alex@edamame alex]$ time java Foo
foo

real    0m3.086s
user    0m2.580s
sys     0m0.100s

Yes java startup times on both the server and client should be 
reduced to less than what it is for something like perl. Speed 
of everything java needs to be improved if java has to be all 
pervasive. Just the API's will not do the trick.

An my working PC I have a little web server up all the time,
when a freshly launched java program could just hook into an
allready running JVM instead starting a new one entirely
from scratch, that would help me with startup. Wouldn't help
those people who do not have Java running all the time?
Well, next step would be to work like M$-IE or Mozilla,
preload some stuff on startup and keep it a JVM running in
memory, just to hop on with your task. What this would
require is some thoughts about safe separation of tasks
within a JVM.

i hope SUN can think about this!

Do not act like IBM again lost their OS/2 and PC battle!

Hope J2SE 1.5 will include the shared JVM to improve java
performence!

JVM in shared space, java.lang & runtime instantiated. 

Note that the 30K applet with almost unnoticeable startup of 
100's of instances was with Sun's 1.3.1 Plug-In.

The 1.4.x Plug-In (1.4.1_01 is what I tested) actually got *a 
lot* worse in this regard -- at least on Windows -- as 
compared to the 1.3.1 (1.3.1_6 is what I tested here).

Granted 1.4.1 is a lot more stable in the browser than 1.3.1, 
but it would appear we've taken a *big* step back in startup 
times.

I had a 30K applet where hundreds of instances could start in 
MSIE without the user noticing that an applet was present!  
Now it takes seconds to launch just one!

Of course 1.3.1 (at least on Windows) had issues with loading 
multiple instances of small, quick-loading applets like mine....  
[3 or more instances of empty subclass of Applet in 1 page 
would hang any version Netscape when 1.3.1_01a, 1.3.1_02, 
or 1.3.1_03 were used -- I didn't get around to testing _04, 
_05, and _06 in this regard.  5-10 instances of a small, signed 
applet would hang MSIE in many 1.3.1_0x versions as well IF 
(and only if) permissions had not yet been granted -- a hang 
would occur trying to bring up the grant/deny permissions 
dialog.]

I just noticed this was reported against "tiger".  If 1.5 is 
worse than 1.4 in this regard, then we're really in trouble!

This is the biggest problem in user acceptance of Desktop
applications written in Java.  People complain that the app
is too slow, but mostly they are refering to the startup time.

Couldn't agree more. I use a couple of Java apps (Jedit for 
one) in a predominately M$ world. Whenever I try to run 
anything Java based that 'loooong delay' due to the startup 
time turns them off immediately to Java.

Well, with perl there are fewer libraries being loaded, for 
example, if you were to write an MDI application in Perl, it 
wouldn't load in half a second on any OS at 400Mhz, that's 
too much to expect, but, being able to get say, a splash 
screen immediately would be good, perhaps the order of 
operation of the JVM loading is wrong, maybe some of the 
code should be executed to see which libraries need to be 
loaded first?  I'm not sure on how the operation goes, I 
haven't looked at the source code (obviously) but, I think 
some comparison to text-only java applications should be 
made, I'm guessing it's the GUI that is really slowing down 
these applications.  Applets have the applet server running at 
all times, perhaps some kind of initial stub should be loaded at 
runtime?  It could be an "Optional performance enhancement" 
choice when installing java or something.  I'd do opt-out in 
windows, since the average joe won't know the difference...

I agree with the splashscreen idea. It would also be helpful
to put a status line to the bottom of the splashscreen and
informing the user what it is doing at the moment. The user
percpetion does benefit from that a lot. Still this is
obviously second best to a real enhancement of performance.

Splash screen or not, the perl vs. python vs. Java example
provided above was a simple "hello, world" program, not
anything more complicated like a GUI.

Just for testing I did run HW (hello world in java) through
my profiler (jmp): "java -Xrunjmp HW". This is the number of
events that took place:

c_class_load: 376
c_class_unload: 0
c_object_alloc: 4902
c_object_move: 0
c_object_free: 0
c_thread_start: 6   (Note: one thread is for jmp) 
c_thread_end: 2
c_method_entry: 14559
c_method_exit: 14559

Now, I would like to know why hello world requires 376
classes and _15 thousand_ method calls. 

For comparison "java -Xrunjmp -version"
c_class_load: 327
c_class_unload: 0
c_object_alloc: 2907
c_object_move: 0
c_object_free: 0
c_thread_start: 5      (one thread is for jmp)
c_thread_end: 1
c_method_entry: 470
c_method_exit: 470

Even here we have a lot of classes that loads, but not so
many method calls. 


How about lazy initialization of the Finalizer thread? 
How about lazy initialization of the Reference Handler thread?

I've been thinking a bit about the startup issue. One of the 
first things that the JVM does is to open up & read rt.jar. In 
1.4.1 that means it has to read 750K of data. Adding a small 
bootstrap jar that contains just the 400-500 classes to run a 
basic reduces that memory footprint. It also improves startup 
time because the boot jar is small and can be cached (maybe 
even preloaded by using a better format.
Another issue is the charmap[][][] object in Character.class. 
It takes forever to instantiate and wastes tons of memory. 
Rewriting it would really improve things. (Same goes for digits
[], DigitTens[] and DigitOnes[] in Integer.class)

If the next JDK will implement a shared JVM, I would like to 
have it running on Windows as a service, with the option to 
start this service at boot time. I feel like many Microsoft apps 
(MSIE, Office apps, etc) have a short startup time because 
some core components are loaded at boot time.

For a specific example of just how unbearably slow the Java
browser plugin is, visit the following two sites:

https://www.cusa-hfs.com/cgi-bin/hfssvc/afs/

https://www.mortgageselect.com/Calcs/HomeLoan.asp

Each take at least 30 seconds for the applet to go from
"loaded" to "started" status, even on a Pentium 4 1.3 GHz
with 256MB RAM.

The same two sites under Netscape 4.8 (which has built-in
Microsoft Java VM) start in about 3 seconds.

Once the applet has started, it seems to run at normal speed.

IMHO, this slow loading is probably one of the biggest
reasons to avoid the use of Java applets.  Java is such a
fantastic technology, but if the user experience is still so
poor after so many years of development, how can it possible
compete?

Totally Agreed

A strong YES. For my client apps, I've had to add code that
prevents a second instance (which is pain in itself) because
the user isn't sure that the first "double-click" worked (5
seconds on 1.8 P4 with 512MB). I've had to apologize for
this for a good 2 years, and my response "Java is better,
safer, etc.", falls on deaf ears.

One of the primary reasons that this occurs is that many of 
Sun's classes do not have 'initialization' methods.  Instead, 
either the constructors, or worse yet, the static initialization 
loads stuff.  Here's a simple test.  Execute 'java -verbose x' 
where 'x' is a class that does not exist.  Look how many 
classes are loaded just to get to the point of telling you that 
there is no 'x' class.  Until the list is just the exact set 
needed, startup will be slow.  In jdk1.1.6 this generated 45 
lines of output.  In jdk1.4.1_01 it generates 265 lines of 
output.  That's a significant change in number of classes 
used to just get the VM to check whether the user provided 
a valid class name.

I think the performance of Java is good but it should be 
better. When I start some large Java programs on my 
computer (350 MHz) I sometimes wait 5 (!) minutes. Please 
excuse my bad english.

I fully agree that this is probably the largest remaining
reason why users think java is slow and are resistant to
using it.

Fixing this would be a great boon to all java developers.

The idea of having some 'warm started' JVM which you could
copy into a chunk of fresh memory with the user code seems
like the best idea to me.

I have made some newsticker applets and games in the past 
written in java for the company I work for.  These applets are 
compiling extremely slowly on java 1.4x.  My computers are a 
celeron 733 and a pentium II 366.  Both machines have 
192mb of ram and running the windows millenium os.  Both 
computers have visited windows update and are very up to 
date.  The ticker applets are taking up to 30 seconds or more 
on these two machines and other comparable machines when 
running java 1.4x including java 1.42.  These applets are very 
small, maybe 10K.  When running the java that came with the 
browser or java 1.1x, 1.2x,1.3x the applets compile almost 
instantly and actually seem to run quicker than java 1.4 on 
these machines.  My home machine running winxp 256mb of 
ram, a xp1700 processor java 1.4x compiles these applets 
almost instantly like pre java 1.4x releases did on my older 
machines.  My ticker applets make use of loops which loop for 
almost ever. It looks like to me the java 1.4x slow startup is 
due to one of the following reasons.
1. java 1.4x using a winxp specific feature or code
2. java 1.4x optimized for newer processors
3. hotspot detecting the loops and optimizing them, taking 
much more time to compile

I think we need to find out why java 1.4x is so slow on older 
computer configurations and how to fix it.  I think if the 
problem is found that future java 1.4x installs should test the 
system configuration and setup java not to use those fetures 
on these older configurations. For example if hotspot is the 
culprit it should be disabled on older computers at the time of 
install.  If its a os thing then maybe multiple versions of the 
jre for windows is necessary.  Please visit these webpages 
and experiment with different java's and different computer 
configurations.  Sun needs to worry about java working on 
real world applications and not synthetic benchmarks.
Sites to test
1. http://www.glcomm.com (newsticker)
2. http://www.furby.com (games section, games by xbx)
3. http://www.mullinconsulting.com (newsticker)
4. http://www.plannedparenthoodaction.org (newsticker)

Yes! For the love of god fix this!

1.4.2 claims some startup times, but it doesn't feel much 
faster - will tiger be much better?

Please fix this.

Learn from .NET (they learned from you too). Get the engine 
preloaded.

Warpper Class in order to  load quickly and in backgroung load 
the Class

In order to increase the startup time of the Sun JVM, can 
they make it being loaded once the OS is started? They can 
do the same tricks as netscape does. Once you have 
everything preloaded in memory, you can load your java 
app/applet fast. What's more, (correct me if i am wrong) the 
longer that the JVM loads, the more code internally being 
compiled to native by hotspot VM. It means it would faster. 
Isn't it? 

Step back and think about the consequences of what you're
asking for a second.  Preloading apps is only efficient if
you have a fat client machine with lots of spare resources,
which seems to be the whole philosophy of object-oriented
programming these days--ease of coding is priority number
one, and optimization/efficiency will be taken care of by
forcing people to buy bigger and faster machines.  However,
this is not reality--Java is already widely criticized for
being such a high-level language and requiring the
elefantine CPU and memory resources that it does, and if
this continunes then people could decide to abandon the
technology rather than compensate for it.  Let us not forget
PeopleSoft marketing their products as being "Java free" a
few years back for this very reason.

The philosophy here should be to improve efficiency, not to
take the "easy way out" and preload.  It is bad enough that
every new app seems to want to preload to the system tray. 
It's all smoke and mirrors in the end--instead of the Java
engine taking an extra 45 seconds to load on an older
machine, it takes an extra 45 seconds to get the machine
booted.  Furthermore, by preloading you're using valuable
system resources 100% of the time when a user may not even
have a need for the Java engine 99% of the time.

I vote no to arbitrary pre-loading and yes to rethinking
what is causing the delay.  The reason the Microsoft VM
loads and runs fast is not merely because it is preloaded or
is non-compliant, but because it is organized in a much
different way than the Sun Java engine.  Perhaps we should
examine this more closely when considering design.

I don't care what you have to do! JUST MAKE IT LOAD 
FASTER.  This should be a priority for Java.

Java needs a serious reworked from the geneous from Sun. 
Both from JVM start up time.  Pre-loaded (like Mozilla, and
OpenOffice).  Smart preloaded (does not load on System start
up, but if a Java app starts, then a resident module is
loaded and stay there if next java apps).  Swing also needs
a major rework.  I hope the Moore's law would help Java. 
But when I run Java apps on 2.6 GHz, and it still pauses for
10 seconds sometimes, swing is still very slow, Netbeans
still start up slow.  To improve this level of slowness, you
need about 20 times in performance which translates to about
7 to 10 years.  This is too long.

This is killing us - FIX IT PLEASE!!!

about pre loading - can make it pre load on sys start 
controlled by an option.
And even if the user has disabled it - the first time 
some one does use java - in browser or as an app - 
then use that version  as the "pre-loaded" for 
subsequent java instances/ uses

tested 1.5beta(alpha? different things said in download) 

For "java -Xrunjmp HelloWorld" I now get (compared to 1.4.2_03)
c_class_load: 358      (+20)
c_class_unload: 0
c_object_alloc: 1491   (-1889)
c_object_move: 0
c_object_free: 0
c_thread_start: 7   (+1)
c_thread_end: 2
c_method_entry: 6766  (+2414)
c_method_exit: 6762    (+2410)

So it seems to allocate a lot less objects, but enter more
methods. 
Will be interesting to see what happens. 

When I started programming with Java 4 years ago, I 
was shocked by how slowly my programs are. Now, on 
a machine which is ten times faster, the same small 
programs are only A LITTLE FASTER. I really love Java 
but startup time of swing applications is disgraceful. 

@Sun: Please do something!. My clients say "life is too 
short for waiting until your Java prog starts". 

have anyone tried to break the rt.jar  into a bunch of
smaller jars, per module type, like core, awt, swing, io,
net, xml, etc...?

I think, since class loading is the main cost, opening smaller
jar  (possibly compressed or not, whichever is faster
between decompress or file read) would lead to perf improvements

Guys stop this debate .. you should know java comes 
free and sun needs to earn some money .. this is their 
way to do just that ..first thurst java on the world then 
since its slower and likely to be more solw in 
upcoming version ..you need to buy more slowaris 
boxes to run it ....HowZTHAT

Easy! Use an apple. the JRE is part of the OS, java 
apps and applets start more or less instantly.

Save a memory image of a prewarmed jvm, and resume it from disk, that way you dont wast memory and you still have the positive effect of prewarming

   I suggest  JVM should provide  a alternative way to disable the verification of bytecode when loading class.

Maybe you should juat convert the Java files to native, then redistribute them for different platforms. FAST and SECURE!
Java is slow because it has to load all the classes at runtime. 
But if we have a tool that PRE-LOADS the necessary classes when they are required, we can simulate a faster Java 

A couple points that hopefully everyone will find very poignant to this topic:

1) Most of the JVM initial startup time is caused by disk activity (just watch yours after a reboot), at least in part due to loading rt.jar. Another signifigant portion may be due to CPU time required to unzip and cache in memory, the rt.jar, (etc) data files. As several people have mentioned; THESE COSTS are aggregated into other system's boot times (the libraries are loaded at boot time, making the boot time look bad, not the specific runtime iteself): EXAMPLES: The Mac JVM, and .NET. Java clearly needs to take the same approach (imo :-) - it seems for windows that the attempt to solve this was made with the 'tray icon', but it's class file data (in a OS furnished disk-cache context) seems to get forced into swap, or is simply not shared.

2) Has anyone noticed *how much faster* an applet loads on a Linux box, than windows, when a browser is restarted (after an inital load time)? For me the difference appears to be 2-3 time faster, *even though* my Linux box is half the CPU speef, with 25% less phys memory.. There seems to be some optimization on Unix that could REALLY benefit windows...

3) As eluded to by other people, I know from experience that "unzipping' rt.jar (and others) can have a MASSIVE effect on increasing startup time... okay, okay, I never used it for runtime (runtime, it seems, insists on reading rt.jar even if its contents are unzipped and put into classpath) - instead I found in a web/jsp environmet that compiles were (if I remember) ~10 times faster if rt.jar's contents were in the classpath as folder/files. Obviously, this isn't efficient space-wise for client runtime eviroments, but its still a good measure of the cost of rt.jar... Perhaps only the most commonly used classes should be in rt.jar; the others (corba, applets, etc) in their own jars and only loaded in the contexts where they're needed. rt.jar is arguably becoming a bloated monolith. 

(sidenote - for some reason the old trick for JSPs of unzipping rt.jat int the classpath no longer works for me; Sun may be forcing compile-time class loads from rt.jar nowadays, perhaps for signer-verification, & java.* overriding/spoofing type security reasons - I dont know for sure)

I'm using Tiger and still I see significant time spent waiting for the JVM to load. In my case I have a C DLL that dynamically loads the JVM. It takes upwards of 20secs to load and start. This is not satisfactory.
I am going to have to force the JVM to be pre-loaded. I will do this using a Windows NT Service that loads the jvm on startup.