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