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