Request for reviews (M): 6614597: Performance variability in jvm2008 xml.validation
Vladimir.Kozlov at Sun.COM
Thu Jan 21 16:37:17 PST 2010
Fixed 6614597: Performance variability in jvm2008 xml.validation
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
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 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.
3. Move mdo->decompile_count() check from methodOopDesc::is_not_compilable()
4. Increase PerBytecodeRecompilationCutoff default value to 200
(it could be not important with these changes).
5. Add "made not compilable <method>" note to PrintCompilation output.
6. Add missing "ttyLocker ttyl;" for LogCompilation output.
Fix verified (y/n): y, jvm2008
More information about the hotspot-compiler-dev