JDK-6233627 : Too many uncommon_traps at a mispredicted call site.
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.
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
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:
###@###.### 2005-04-04 15:44:50 GMT
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