JDK-6614597 : Performance variability in jvm2007 xml.validation
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: hs17,7
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic,solaris_9
  • CPU: x86,sparc
  • Submitted: 2007-10-09
  • Updated: 2010-04-03
  • Resolved: 2010-02-09
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
6u21Fixed 7Fixed hs17Fixed
Related Reports
Duplicate :  
Relates :  
Relates :  
Description
We see variability in running the xml.validation workload on some machines. For example these results:

51420.auto.log  306.06  xml.validation
51421.auto.log  362.29  xml.validation
51422.auto.log  1036.78 xml.validation
51423.auto.log  1031.04 xml.validation
51424.auto.log  175.87  xml.validation
51425.auto.log  1029.75 xml.validation
51426.auto.log  1028.60 xml.validation
51427.auto.log  1012.52 xml.validation
51429.auto.log  1042.44 xml.validation
51430.auto.log  1015.50 xml.validation
51431.auto.log  1024.63 xml.validation
51432.auto.log  1040.88 xml.validation
51433.auto.log  1047.75 xml.validation
51434.auto.log  1024.24 xml.validation
51435.auto.log  342.92  xml.validation
51436.auto.log  1023.79 xml.validation
51437.auto.log  1036.47 xml.validation
51438.auto.log  1041.16 xml.validation
51439.auto.log  1048.32 xml.validation
51440.auto.log  1024.52 xml.validation
51441.auto.log  342.56  xml.validation
51442.auto.log  1063.92 xml.validation
51443.auto.log  1027.27 xml.validation
51444.auto.log  1042.93 xml.validation
51445.auto.log  1042.38 xml.validation
51446.auto.log  1044.84 xml.validation
51447.auto.log  1044.75 xml.validation
51448.auto.log  1020.74 xml.validation
51449.auto.log  351.85  xml.validation
51450.auto.log  1056.70 xml.validation
51451.auto.log  1030.40 xml.validation
51452.auto.log  1055.20 xml.validation
51453.auto.log  1028.08 xml.validation
51454.auto.log  1058.68 xml.validation
51455.auto.log  1029.57 xml.validation
51456.auto.log  1032.61 xml.validation

Comments
PUBLIC COMMENTS Problem (from 6614597 Description): This seems to be caused by bad interaction of the mono/bi/megamorphic doCall code in c2 and uncommon traps. One thing that is clearly wrong is that the doCall code will not switch to megamorphic until we hit PerMethodTrapLimit unc-traps. Unfortunatley the unc-trpa code will make a method uncompilable if we hit PerBytecodeRecompilationCutoff traps. In the current sources these values are the same! So doCall is able to be subverted. The settings need to be such that PerMethodTrapLimit < PerBytecodeRecompilationCutoff. On machines with large numbers of threads PerMethodTrapLimit limit is reached very quickly especially for jvm2008 where each thread executes the same code. As result hot methods are marked uncompilable incorrectly. Solution: 1. Add new reason Deoptimization::Reason_bimorphic to force immediate recompilation of bimorphic call sites to megamorphic (with virtual call instead of uncommon trap) and to separate it from the transition of monomorphic call sites to bymorphic. 2. Increment MDO virtual call site total counter only for polimorphic case. 3. Increment overflow_recompile_count and decompile_count only by the thread which changes the state of nmethod to prevent incorrect marking of the method as not compilable. 4. Move mdo->decompile_count() check from methodOopDesc::is_not_compilable() to methodDataOopDesc::inc_decompile_count(). 5. Increase PerBytecodeRecompilationCutoff default value to 200 (it could be not important with these changes). 6. Add "made not compilable <method>" note to PrintCompilation output. 7. Add missing "ttyLocker ttyl;" for LogCompilation output.
02-02-2010

EVALUATION ChangeSet=http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/87684f1a88b5,ChangeRequest=6614597
02-02-2010

EVALUATION This seems to be caused by bad interaction of the mono/bi/megamorphic doCall code in c2 and uncommon traps. One thing that is clearly wrong is that the doCall code will not switch to megamorphic until we hit PerMethodTrapLimit unc-traps. Unfortunatley the unc-trpa code will make a method uncompilable if we hit PerBytecodeRecompilationCutoff traps. In the current sources these values are the same! So doCall is able to be subverted. The settings need to be such that PerMethodTrapLimit < PerBytecodeRecompilationCutoff. In addition it now seems clear that TypeProfileWidth is too narrow (2) if you are trying to do bimorphic inlining. If we don't profile at least 3 receivers we can be fooled about the actual state of the call site. Experiments reveal that adjusting these parameters on their own fixes the problem. The expected solution is to increase TypeProfileWidth and PerBytecodeRecompilationCutoff.
09-10-2007