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