JDK-6244337 : Large perf regressions (2%-90%) in b28 (all platforms)
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 6
  • Priority: P1
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2005-03-22
  • Updated: 2013-11-01
  • Resolved: 2005-03-30
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 b30Fixed
Related Reports
Duplicate :  
JDK-6243962 - CORBA performance/bug4901731 fails, regression
Relates :  
JDK-6243940 - VMark/VTest SEGV with Mustang b28 on sol amd
Description
In-development performance regression.
See Comments.
###@###.### 2005-03-22 18:02:15 GMT
Comments
WORK AROUND Dumping using -Xshare:dump -Xmixed seems to work around the problem. ###@###.### 2005-03-24 02:20:46 GMT
24-03-2005
EVALUATION I think that the invocation counters are in a funny state at dump time. -Xshare:dump seems to imply -Xint and this ends up setting UseCompiler to false which has the side effect of changing the meaning of InvocationCounter::reset to wait_for_nothing. This means that we won't compile methods from classes in the shared archive. If you compare the PrintCompilation between the two cases you can see this problem. If you redump using -Xshared:dump -Xmixed the regression appears to go away since this resets UseCompiler to true. This appears to be the unexpected result of some reorganization that occured in the noadapters workspace to unify the setup logic for methodOops. There are a couple of simple fixes that can be done for this, including resetting the invocation counters are load time. ###@###.### 2005-03-24 02:20:46 GMT
24-03-2005