Review Request: Zero JSR 292 support

[Gary Benson]

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/