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