After the talk with Hui about his investigation of startup time
I spent few days to look on VM with server compiler startup.
I used jdk 1.5.0_01.b02.

The main difference came when I set -XX:CompilationPolicyChoice=0
which use simple compilation policy (compile only hot methods and OSR
and don't compile caller methods). The default for C2 is
-XX:CompilationPolicyChoice=1 when we try to compile a caller method
which called a hot method.

Client (C1) compiler has CompilationPolicyChoice=0.

Alacrity run confirmed my results:

http://alacrity.sfbay/query/enes.jsp?VersionSelector_baseline=1.5.0%7Ckvn_c2start_bas_174842&VersionSelector=1.5.0%7Ckvn_c2start_cp0_185821&esum=Summary&pval=0.01&type_baseline=o&type_build=o


And here are my manual runs of refWorkload, I ran startup3 andreference_server benchmarks. Full results are in the Comments section.

Here are startup3 improvements Choice=0 vs Choice=1:
18.09% PC P3 win2K 1x0.9GHz 512Mb
12.55% PC P4 win2K 1x1.7GHz 768Mb
16.56% "epiphone" amd64 linux 1x1.8GHz 1Gb
 5.29% "perf-v6" p4 linux 4x3.2GHz 4Gb (2 cpus + HT)
 8.77% SB2500 US3i Sol9 2x1.2GHz 1Gb
 9.21% SB2500 -d64 US3i Sol9 2x1.2GHz 1Gb

The only problem with server benchmarks was jetstream
on x86 (see full results below):
========================================================================
PC P4 win3k 1x1.7GHz
choice=1 jetstream 10 38.01 2.45
----
choice=0 jetstream 10 36.82 3.18 -3.22 0.363
========================================================================
PC P3 win2K 1x0.9GHz
choice=1 jetstream 10 27.68 0.23
----
choice=0 jetstream 10 24.19 0.26 -14.41 0.000
========================================================================
But on amd64 1x1.8GHz it is opposite:
choice=1 jetstream 10 117.21 4.20
----
choice=0 jetstream 10 130.75 6.63 11.55 0.000
========================================================================

I found the cause of the regression in jetstream on Windows.

The jetstream use the "-r 5" option to run 5 times in one VM
and we take the last run (5th) result as result of the benchmark.
The problem is that we can still compile at this time.
With -XX:CompilationPolicyChoice=0 we delay some compilations
and such happens that we have heavy compilation during the last run:

******** Starting run #4 ********
 61 java.nio.ByteBuffer::array (35 bytes)
Read Text: 125
Write Text: 422
Parse Text: 157
Copy Files: 172
******** Starting run #5 ********
 62 java.io.Win32FileSystem::isSlash (18 bytes)
 63 java.io.Win32FileSystem::normalize (231 bytes)
Read Text: 203
Write Text: 421
Parse Text: 156
Copy Files: 156

And on the machine with one cpu the compilation time added to the
final result. We lose even when we have better "Overall Score":

Run's score 52.17:
******** Starting run #5 ********
Read Text: 125
Write Text: 438
Parse Text: 157
Copy Files: 157
Overall Score: 8656

Run's score 46.64:
******** Starting run #5 ********
Read Text: 203
Write Text: 422
Parse Text: 157
Copy Files: 157
Overall Score: 8641
###@###.### 11/4/04 23:22 GMT