Request for reviews (M): 6614597: Performance variability in jvm2008 xml.validation

[Vladimir Kozlov]

http://cr.openjdk.java.net/~kvn/6614597/webrev.06

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
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 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()
    to methodDataOopDesc::inc_decompile_count().
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.

Reviewed by:

Fix verified (y/n): y, jvm2008

Other testing:
JPRT, refworkload