JDK-6191063 : Improve startup of server VM
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 6
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: solaris_9
  • CPU: sparc
  • Submitted: 2004-11-04
  • Updated: 2010-04-03
  • Resolved: 2004-11-24
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 6
6 b14Fixed
Description
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

Comments
EVALUATION With -XX:CompilationPolicyChoice=0 we compile small hot methods first. So we spent less time in compiler threads and get benefits from compiled methods faster. We also get some performance improvement in benchmarks. I think, it is due to we have more profiling information collected for callers methods now. We compile them too early with CompilationPolicyChoice=1. ###@###.### 11/4/04 23:22 GMT
04-11-2004

SUGGESTED FIX Set default value CompilationPolicyChoice=0 for server VM. ###@###.### 11/4/04 23:22 GMT http://analemma.sfbay.sun.com/net/prt-archiver.sfbay/data/archived_workspaces/main/c2_baseline/2004/20041110152125.kvn.6191063/workspace/webrevs/webrev-2004.11.11/index.html ###@###.### 2004-11-19 00:01:09 GMT
04-11-2004