JDK-6233627 : Too many uncommon_traps at a mispredicted call site.
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 5.0
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • OS: solaris_1
  • CPU: sparc
  • Submitted: 2005-02-28
  • Updated: 2010-04-02
  • Resolved: 2005-04-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.
Other JDK 6
5.0u4Fixed 6 b32Fixed
Description
Compilation of methods are getting skipped and this creates performance overhead.

This is observed with 5.0 Server version.


###@###.### 2005-2-28 07:54:17 GMT
Comments
SUGGESTED FIX The has been fixed by reverting to a virtual call if too many uncommon traps have been observed at a particular bci. See PRT webrev: http://analemma.sfbay.sun.com/net/prt-archiver.sfbay/data/archived_workspaces/main/c2_baseline/2005/20050401143921.rasbold.c2_baseline5/workspace/webrevs/webrev-2005.04.01/index.html ###@###.### 2005-04-04 15:44:50 GMT
04-04-2005
EVALUATION The compilation skipped problems will be addressed in a fix to bug 6174443, but that does not seem to be the customer's primary problem. The log file shows that we compile the CDRInputStream.<init> method over 100 times, essentially the same way each time, and more that 840,000 uncommon_traps are provoked by the <init> code. The HUGE number of uncommon_traps are probably the source of the performance hit that the customer is experiencing. Looking further at the log file, it looks like each compilation for CDRInputStream.<init> inlines HashMap.get, which inlines HashMap.eq which calls java/lang/Object.equals. The methodData for HashMap.eq shows a single receiver class for the equals() call, so at the equals call site, a predicted call is generated. On a klass miss, we do an uncommon_trap, which is responsible for most of the 840,000 number. The problem can be fixed by either collecting more profiling at the call site for the methodDataOop, or, noticing that a trap has been seen at a particular bci. Either way, the intent on subsequent compiles is to trigger a virtual call at a miss, instead of an uncommon_trap. ###@###.### 2005-2-28 18:24:09 GMT
28-02-2005