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
                                     

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