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