JSR 292 provides a GuardWithTest idiom is allow selection between two different method handles based on a boolean test.  In earlier versions of the JDK code this was done with a bunch of little wrapper methods for different arities.  This resulted in a call site for a each call which allowed existing constant folding code to statically bind the call sites.  Because this didn't scale it was replaced with a new idiom that looks more like (test ? a : b).invoke() which only have a single call site.  This interferes with inlining making the code perform terribly.  We need a new bimorhphic inline for invokedynamic callsites to deal with this.
The fix for this CR also eliminated the following failure:

JDK 7 b143 and b144 crashed in compiler thread:

#  SIGSEGV (0xb) at pc=0x40302332, pid=17315, tid=1125669792
#
# JRE version: 7.0-b144
# Java VM: Java HotSpot(TM) Client VM (21.0-b14 compiled mode, sharing linux-x86 )
# Problematic frame:
# V  [libjvm.so+0x17a332]  CompileTask::print_compilation_impl(outputStream*, methodOopDesc*, int, int, bool, int, bool, char const*)+0x62

Stack: [0x43105000,0x43186000],  sp=0x43184ec0,  free space=511k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x17a332]  CompileTask::print_compilation_impl(outputStream*, methodOopDesc*, int, int, bool, int, bool, char const*)+0x62;;  CompileTask::print_compilation_impl(outputStream*, methodOopDesc*, int, int, bool, int, bool, char const*)+0x62
V  [libjvm.so+0x35c882]  nmethod::log_state_change() const+0x192;;  nmethod::log_state_change() const+0x192
V  [libjvm.so+0x35dc07]  nmethod::make_not_entrant_or_zombie(unsigned int)+0x117;;  nmethod::make_not_entrant_or_zombie(unsigned int)+0x117
V  [libjvm.so+0x3f4bea]  NMethodSweeper::process_nmethod(nmethod*)+0x18a;;  NMethodSweeper::process_nmethod(nmethod*)+0x18a
V  [libjvm.so+0x3f4d94]  NMethodSweeper::sweep_code_cache()+0xc4;;  NMethodSweeper::sweep_code_cache()+0xc4
V  [libjvm.so+0x3f4e50]  NMethodSweeper::possibly_sweep()+0x70;;  NMethodSweeper::possibly_sweep()+0x70
V  [libjvm.so+0x17a01d]  CompileQueue::get()+0x1d;;  CompileQueue::get()+0x1d
V  [libjvm.so+0x17cfa7]  CompileBroker::compiler_thread_loop()+0x117;;  CompileBroker::compiler_thread_loop()+0x117
V  [libjvm.so+0x4274c8]  compiler_thread_entry(JavaThread*, Thread*)+0x18;;  _ZL21compiler_thread_entryP10JavaThreadP6Thread+0x18
V  [libjvm.so+0x42ec08]  JavaThread::run()+0x178;;  JavaThread::run()+0x178
V  [libjvm.so+0x379341]  java_start(Thread*)+0x111;;  _ZL10java_startP6Thread+0x111
C  [libpthread.so.0+0x535b]  start_thread+0x8b

VM flags were: -XX:+AggressiveOpts -XX:+PrintCompilation