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