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 _______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
