The fix of the following bug:
  jbs: https://jbs.oracle.com/bugs/browse/JDK-7187554

requires to preserve the code pattern that blocks some JSR-292 related optimizations that make customized variations of direct MHs.

Below is a email exchange with John Rose about this issue:

On 9/4/13 12:01 PM, John Rose wrote:
> Yes, please file this bug. I'm working on MH-related optimizations, and I am finding that preserving the required code pattern is blocking some optimizations, notably making customized variations of direct MHs.
>
> (The required code pattern is that the DMH in Local#0 has a member field which supplies the missing argument to the outgoing linker call. Making a variant DMH with a customized calling sequence is possible, but then it has wrong interactions with the MethodHandleInfo API. It would be easier to make a customized non-DMH, with no member field.)
>
> — John
>
> On Aug 20, 2013, at 12:16 PM, serguei.spitsyn@oracle.com wrote:
>
>> John,
>>
>> Thank you for the comments!
>> In fact, I was very reluctant to implement it the way as it is in the webrev.
>> I'm in favor of the choice #3, and think, it is much better from the stability point of view.
>> Restoring the MemberName slot at deoptimization is not going to cause a performance degradation.
>>
>> If you and Christian are Ok with it I can file a new compiler bug to cover this issue.
>>
>> Thanks,
>> Serguei
>>
>>
>> On 8/12/13 3:30 PM, John Rose wrote:
>>> This fix will be delicate and may have regressions if the exact code shape (of the PopFrame-ed invokestatic call) changes.
>>>
>>> Note that member_name_arg_or_null assumes that the value in Local#0 is a DMH; there will be asserts thrown if this fails. It also assumes that the member name held by the DMH in fact corresponds to the linker call (linkToStatic, linkToVirtual, etc.) being PopFrame-ed.
>>>
>>> In fact, the linker call might in some cases be run from another source than "aload0; getfield member". Requiring that this correspondence exist always is a new internal interface that is hard to document and verify; it may also inhibit present or future optimizations.
>>>
>>> There are other approaches that might be more robust:
>>> 1. Do not allow PopFrame to linker calls, since they (by definition) throw away their trailing MemberName argument.
>>> 2. Do not make such frames visible to the user.
>>> 3. Modify the linker primitives to store a copy of their trailing MemberName argument to a new slot in the interpreter frame and compiled frame. Be sure to populate this new slot on deoptimization.
>>>
>>> — John
>>>
>>> P.S. Sorry about the delay in commenting; I am just digging out from under JVMLS business!
>>>
>>> On Jul 30, 2013, at 10:00 AM, serguei.spitsyn@oracle.com wrote:
>>>
>>>> The updated webrev:
>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/7187554-JVMTI-JSR292.3/
>>>>
>>>> Thanks,
>>>> Serguei