Hi Rémi, Yikes, sorry if that came across a little too strongly. I haven't followed the discussions on this group much, and I suppose this matter has been discussed many times before, so apologies if this is a rehash of old discussions.
I happened to glance at an email digest today and that line caught my eye, and I expressed my opinion. In any case, I see that further down in your message, you are suggesting that there are optimizations that might need to be implemented in a dynamic language VM, so maybe I was just indulging in a strawman argument. Regards, Subbu. On Dec 5, 9:58 am, Subbu Sastry <[email protected]> wrote: > On Dec 4, 9:08 am, 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.
