JDK-4986249 : A dramatic slowdown with 1.5 build32 client compared to 1.5 server and 1.4.2
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 5.0
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2004-01-30
  • Updated: 2014-01-06
  • Resolved: 2004-05-11
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.
Other
5.0 b51Fixed
Related Reports
Relates :  
Description
###@###.### 2004-01-30

J2SE Version (please include all output from java -version flag):
  java version "1.5.0-beta"
  Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-beta-b32)
  Java HotSpot(TM) Client VM (build 1.5.0-beta-b32, mixed mode)

Does this problem occur on J2SE 1.4 or 1.4.1 or 1.4.2?  
  No

Operating System Configuration Information (be specific):
  Windows XP Professional CZ


Hardware Configuration Information (be specific):
  Laptop Acer TravelMate 541LCi, 512MB RAM, ATI Radeon 9200,
  Mobile P4 2.6GHz

Bug Description:
  A dramatic slowdown was observed in 1.5.0 client compared
  to 1.5.0 server and 1.4.2 both client and server runtimes.
  Below are times of execution under different JVMs:

  1.5.0b32 -server
  3200 ms

  1.5.0b32 -client
  16200 ms !!!

  1.4.2 -client
  8531 ms

  1.4.2 -server
  3500 ms

Steps to Reproduce (be specific):
 - Compile and run test program(BraceWords.java)
 


Comments
This seems to be an architecture anomaly and confined to certain chip versions. An old comment above mentions "some P4's". Running on any newer chips doesn't show that behavior.
06-01-2014

CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: tiger-beta2 FIXED IN: tiger-beta2 INTEGRATED IN: tiger-b51 tiger-beta2
14-06-2004

SUGGESTED FIX http://analemma.sfbay.sun.com/net/prt-archiver.sfbay/export2/archived_workspaces/main/c2_baseline/2004/20040505161658.never.c1/workspace/webrevs/webrev-2004.05.05/index.html
11-06-2004

EVALUATION Not reproducible on a 1.4 GHz Pentium M running Windows XP Professional: 1.4.2 -client: 4026 ms 1.5 b32 -client: 3495 ms 1.5 (latest) -client: 3305 ms 1.4.2 -server: 1422 ms 1.5 b32 -server: 1342 ms 1.5 (latest) -server: 1172 ms ###@###.### 2004-01-30 Here are the results on both Solaris Sparc and WinXP machine: Solaris Sparc(Ulta 80) 1.4.2 -client 104522 -server 38124 1.5(b36) -client 122811 -server 33973 WinXP((Pentium 4, CPU 2.7GHz, 1GB RAM): 1.4.2 -client 7922 -server 3141 1.5(b32) -client 16172 -server 3344 There is a slowdown! ###@###.### 2004-01-30 On some p4's I see a 4x increase in the elapsed time of the benchmark for 1.5.0. This seems to be caused by L1 cache conflicts between the polling page and objects being used in the benchmark. Small changes to the program, that change the allocation cause the huge regression to go away. For instance the program as written won't work if compiled with 1.4.x and run on 1.3.1 because StringBuffer doesn't have an append method which takes a StringBuffer in 1.3.1. Changing the source so it runs on 1.3.1 causes most of the regression to go away. Real programs shouldn't see this in practice but we probably need to do something to mitigate this. ###@###.### 2004-02-12
12-02-2004