JDK-6471009 : Significantly higher CPU usage in jvm1.6 build 97/98 vs jvm1.5.0_06-b05 on DOTS ATCJ2 test
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 6
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: solaris,windows_xp,windows_vista
  • CPU: x86
  • Submitted: 2006-09-14
  • Updated: 2011-03-25
  • Resolved: 2007-09-13
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 JDK 7 Other
6u10Fixed 7Fixed hs11Fixed
Related Reports
Duplicate :  
JDK-6763424 - JDK 1.6 classloader geometric slowdown of 20-300x fixed in 1.6.0_10-rc2-b32
Duplicate :  
JDK-6646599 - Classloading in 1.6.0_03-b05 server VM is much slower than 1.5 server VM
Relates :  
JDK-4850474 - dependence information is inaccurate, leading to intermittent COMPILE FAILED
Relates :  
JDK-6653858 - dynamic languages need to be able to load anonymous classes
Relates :  
JDK-6602813 - jstatPrintCompilationOutput1.sh fails intermittently
Relates :  
JDK-6610906 - inexplicable IncompatibleClassChangeError
Description
We are seeing much higher CPU usage on JVM 1.6 than on JVM 1.5 when
running the "DOTS ATCJ2" test on a large Derby / Java DB database.

The test has previously been run with jvm1.5.0_06-b05 on Solaris 10 1/06
s10x_u1wos_19a X86 - SunOS 5.10 Generic_118844-26.
Increased CPU usage is seen with jvm1.6.0-rc-b97 and b98.


The size of the database is ~342GB (du -h: 342G   TESTDB/seg0).
(# tuples in ATCJ2 tables: BID: 3.4 mill., ITEM: 600 mill., REGISTRY:
417 mill.)


--------
* DOTS: see http://ltp.sourceforge.net/dotshowto.php ,
http://db.apache.org/derby/integrate/DOTS_Derby.htm ,
http://db.apache.org/derby/binaries/UsingDotsDerbySystemTest.pdf .
We have adapted DOTS to also run on other OS's than Linux.
Comments
EVALUATION There is still an architectural scalability problem, in that the application uses thousands of small throw-away classes, one per SQL query. It should use anonymous classes. The MLVM functionality should be ported into hotspot and used by derby as an implementation private interface. http://blogs.sun.com/jrose/entry/anonymous_classes_in_the_vm http://openjdk.java.net/projects/mlvm/subprojects.html#AnonymousClasses
23-04-2008
SUGGESTED FIX Webrev: http://prt-web.sfbay.sun.com/net/prt-archiver.sfbay/data/archived_workspaces/main/c2_baseline/2007/20070904143700.jrose.bugs0807/workspace/webrevs/webrev-2007.09.04/index.html Fixed 6471009: Load-time checking of dependencies needs to scale better. Problem: Complete hierarchy rechecking is quadratic in some cases. Solution: Restore "spot checking" logic from previous version of code. Reviewed by: Tom, Steve G., Xiaobin Fix verified (y/n): y Testing: - reproduced the problem in the reduced test case - added tracing code to print amount of dependency test work - demonstrated 1-2 orders of magnitude reduction in the work - PRT (which includes +VerifyDependencies to catch false negatives) Fixed 6597720, 6597724: wrong legal notice Problem: New file introductions and the license shift cross in the mail. Solution: Put on a new license, obtained from a nearby source file. Reviewed by: Iris Fix verified (y/n): y Testing: The License Fairy left me two quarters under my pillow.
13-09-2007
WORK AROUND Force using 'Client VM' ('java -client ....') on 'server hw'! (1.6.0_01-b06 and 1.6.0_02-b05)
22-08-2007
EVALUATION Looks like a scalability problem with the nmethod dependency tracker.
18-10-2006