Review Request: Zero JSR 292 support

[Christian Thalinger]

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.

-- Christian