On Dec 4, 9:08 am, Rémi Forax <[email protected]> wrote: > On 12/04/2010 03:08 PM, Guillaume Laforge wrote: > > > On Sat, Dec 4, 2010 at 13:51, Charles Oliver Nutter > > <[email protected] <mailto:[email protected]>> wrote: > > > [...] > > > This is equivalent to implement your own EA + inlining > > > in your runtime instead of relying on the EA done by hotspot. > > > Perhaps, except that implementing my own EA + inlining is a lot harder > > :) My primary goal with JRuby optimization is to just get all the > > pieces in the right place so that the JVM can do the rest. I don't > > want to write my own optimizers if I can help it. > > > What about writing your own VM? ;-) > > Because > I don't want to write a generational copy-collector GC > in fact, I don't want to debug it :) > I don't want to write a register allocator > + all the optimizations done on SSA nodes > I don't want to know how to implement memory > fences on multiple hardware architectures. > I don't want to do all that stuff alone with no > community support. > > That's why I use the JVM. > But this approach has one main drawback. > The input of the VM is the bytecode is typed [1], > like any assembler. > > So any runtime of a dynamic language has only one > thing to do, transform the dynamic language to > a typed bytecode.
I am not convinced that this is fully true. I think for all practical purposes, as far as implementing languages on top of the VM, we can forget the fact that the JVM is actually software and treat it as an implementation target. Much in the same way that CPU micro- architectures implement a whole host of sophisticated optimizations to speed up the execution of machine code, and that doesn't eliminate the need to implement a whole host of optimizations in the JVM, I dont think you get performance for free simply because you target the JVM. Just as a CPU frees the JVM implementer from having to implement certain kind of optimizations (because of branch prediction, caches, instruction scheduling, etc.), the JVM frees the dynamic language implementer from having to worry about certain kind of opts (GC, allocation, targetting a large variety of CPUs, etc). The JVM cannot optimize the semantics of the dynamic language. That is the job of the VM that is implemented on the JVM. I agree that the VM has to be judicious about what it does, but that is no different from the JVM having to be judicious about what it does based on the characteristics of the CPU it is targetting. So, while the JVM is extremely smart, it can optimize only so much (till the JVM get so smart as to realize the promise of the Futamura projections :) at which time implementers of dynamic languages can satisfy themselves with writing an interpreter). So, while it is true that the runtime of a dynamic language has to transform the dynamic language to a typed bytecode, I think it also means that the rntime has to implement any optimizations (inlining, type guards, unboxing, EA, etc.) in the dynamic language VM which the JVM cannot see through. Subbu. > I strongly believe that > you can't optimize a dynamic language ahead of time > you don't have to optimize the whole code, only hot paths. > you have to optimize execution path and not only functions > you should not try to optimize infrequent things > like operator overflow or monkey patching > instead you should be able to escape from a > generated code and trash it. > > I think we can do that without re-writing a new VM. > I think the VM should be only 'slightly' modified to > ease the implementation of the runtime. > > In my opinion, the next features to implement > in the VM are: > - stack introspection > - immediate wrapper (to avoid boxing) > - coroutine/continuation > > > > > -- > > Guillaume Laforge > > Groovy Project Manager > > Head of Groovy Development at SpringSource > >http://www.springsource.com/g2one > > R�mi > > [1] This is not fully true with the introduction > of invokedynamic. We can generate a AOT bytecode. -- 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=en.
