2009/11/22 Jim White <[email protected]>: > John Wilson wrote: [snip]
> > I think using naive code generation and AOP is a better way to approach > this problem. That wouldn't be constrained by your MOP (or whatever > interpreter strategy) only being able to deal with the calls it > dispatches directly. > > That is essentially what HotSpot does as well. Generate simple code > quickly, profile it, then regenerate with optimization in the critical > areas. Coupled with hot class redefinition ala JRebel, you would then > have a pretty comprehensive solution that could work with many different > JVM languages. Thanks for your suggestions. I probably didn't explain the issue as well as I should have:) Unfortunately there are situations where it is just not possible to generate code of any sort on the fly. For example the security restrictions in your target environment may forbid it. You may be running on an Android phone which runs Java but does not use JVM bytecodes (and is not, strictly, a JVM but is an attractive target nonetheless). My original question was triggered by Charlie talking about the use of interpretation in JRuby and I wondered if the JRuby guys had a desperately clever way of getting round the problems of interpreting a class which extends an arbitrary compiled class 9if it just extends Object there is no problem). I can see how to get round the problems if I'm allowed to generate a shim class which redirects call to the interpreter. It may be that the best bet is to precompile shim classes for every public non final class in the JDK and stick them in the runtime JAR. You still have a problem with subclassing non JVM compiled classes but it gets you further. 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=.
