Review Request: Zero JSR 292 support

[Christian Thalinger]

On Apr 11, 2011, at 7:47 PM, Christian Thalinger wrote:
> On Apr 11, 2011, at 3:16 PM, Gary Benson wrote:
>> Christian Thalinger wrote:
>>> On Apr 5, 2011, at 3:46 PM, Gary Benson wrote:
>>>> Christian Thalinger wrote:
>>>>> On Apr 4, 2011, at 10:34 AM, Gary Benson wrote:
>>>>>> John Rose wrote:
>>>>>>> On Apr 1, 2011, at 7:33 AM, Gary Benson wrote:
>>>>>>>> This webrev adds support for JSR 292 to Zero:
>>>>>>>> 
>>>>>>>> http://cr.openjdk.java.net/~gbenson/zero-jsr292-01/
>>>>>>> 
>>>>>>> Most impressive!  I think this matches the following
>>>>>>> previously filed bug:
>>>>>>> 
>>>>>>> 6829195  JSR 292 needs to support the C++ interpreter
>>>>>> 
>>>>>> Partially, yes, in that it implements invokedynamic and
>>>>>> fast_aldc* in the bytecode interpreter.  For the sparc or x86
>>>>>> ports you would also need to write the method handle entries
>>>>>> and add frame manager support for the call_method_handle
>>>>>> message.
>>>>> 
>>>>> How much work would that be?
>>>> 
>>>> I'm not sure.  Actually, thinking about it, the method handle
>>>> entries are already there (the template and C++ interpreters have
>>>> the same ABI, no?)  You could check by trying to run the method
>>>> handles tests.  If that's the case, the only extra bit is adding
>>>> support for call_method_handle.  There's a potential trap,
>>>> however, in that the calls to
>>>> InterpreterRuntime::resolve_invokedynamic and
>>>> InterpreterRuntime::resolve_ldc from BytecodeInterpreter::run
>>>> enter VM mode and end up reentering the C++ interpreter.  I don't
>>>> know that the assembly language ports can handle this.  They're
>>>> certainly written to avoid it, but that might be simply because
>>>> BytecodeInterpreter::run has a huge stack frame and they didn't
>>>> want too many of those on the stack.  If it is a problem I have
>>>> some partially written code that would work around this but once
>>>> I realised Zero didn't need it I stopped working on it.
>>> 
>>> I'm not exactly sure how to proceed here.  Should we try to
>>> implement the missing parts of 6829195 or should we file a
>>> separate bug for Zero and push this?
>> 
>> I wouldn't want to make direct x86 and sparc support for this
>> a prerequisite for the Zero code going in.  If it's possible to
>> commit as a partial fix for 6829195 then we could do that, but
>> if partial fixes aren't possible then maybe make a new bug and
>> do it that way.
> 
> Partial fixes are not possible, we need a new CR for that.   I will take care of it tomorrow.

7035870: JSR 292: Zero support

-- Christian