I suppose different JVMs tackle it different ways, but on the IBM iSeries JVM we kept a virtual function table for each class and called through that. Interpreted functions contained a pointer to the interpreter in the VFT, and a pointer to the method table entry in the "this" class was passed as a hidden parameter, to identify the method to the interpreter. A fairly straight-forward setup.
The only real complication was parameter mapping between the interpreter stack and the standard register-based scheme for compiled code. "Glue" code was used for that. On Nov 3, 8:17 am, John Wilson <[email protected]> wrote: > On Rémi's recent thread Charlie talked about the advantages of having > an interpreted mode in a language implementation to allow profiling > before deciding on code generation strategies. I'm starting a new > thread to ask implementation questions about this. > > I think this is interesting but I'd like to hear some more about the > actual mechanics of doing it. There's no problem in writing an > interpreter, of course. It's pretty trivial for any language which has > a MOP. The problem I have is how to deal with a class in language X > which subclasses a non trivial (i.e. not java.lang.Object) Java > object. > > if I have a Java class > > class C { > public void foo() { > bar(); > } > > public void bar() { > // some stuff > } > > } > > then I have a X class > > class D extends C { > public void bar() { > // some other stuff > } > > } > > For every instance of D I can instantiate C and delegate calls to it > in the interpreter. The MOP can use its normal refection black magic > to get at things like protected instance variables and methods. > However I can't get the call of bar in foo to call the interpreter > back. > > The only thing I can think of is to generated code to subclass C with > a shim class that has helper methods which allows the interpreter to > decide how calls are to be dispatched: > > class C$shim extends C { > public void foo() { > if (D has a matching method) { > // invoke the interpreter > } else { > super foo(); > } > public void bar() { > if (D has a matching method) { > // invoke the interpreter > } else { > super bar(); > } > > } > > Is this a problem in JRuby, Charlie? If so do you have a nicer way of > dealing with it? > > John Wilson -- You received this message because you are subscribed to the Google Groups "JVM Languages" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/jvm-languages?hl=.
