Review Request: Zero JSR 292 support

[Christian Thalinger]

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?

-- Christian