JDK-8024380 : JSR-292: new internal contract between linker primitives and PopFrame is hard to support
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: hs25,9,10
  • Priority: P5
  • Status: Open
  • Resolution: Unresolved
  • OS: generic
  • CPU: generic
  • Submitted: 2013-09-06
  • Updated: 2018-10-05
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
tbdUnresolved
Related Reports
Relates :  
JDK-7187554 - JSR 292: JVMTI PopFrame needs to handle appendix arguments
Description
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
Comments
Talking to John it seems we can keep the required pattern for some time. I'm downgrading this to a RFE and P5 for the time being.
19-09-2013