Well, as much as I'd love to, I personally don't really have the required spare cycles to work on that in the foreseeable future.
Also, while invokedynamic goes a long way toward running dynamic code efficiently on JVM, there are some things that TraceMonkey does specifically for JavaScript (and that other dynamic languages could probably also greatly use), and that HotSpot currently doesn't, mostly to do with efficient type narrowing of values (so not everything has to be treated as a generic, heap-allocated object all the time). Truth be told, HotSpot doesn't actually need to do most of that, as the language-specific source-to-bytecode compiler can take care of that; indeed the bytecode compiler in Rhino with optimization level set to 1 or above will do some such things -- strictly on intraprocedural level. Now, I haven't looked into the TraceMonkey, but have it on my (fairly large, unfortunately) todo list to read through the peer reviewed papers it's based on, and I fully expect I'll find things like type specialization for functions and similar techniques. Also note how the balance of performance goals is usually fairly different for Rhino and for JS runtimes in browsers: in browsers, you want fast startup time for the scripts, so you won't want to run a full gamut of optimizations on your code; HotSpot JIT, esp. the server one will do, as it doesn't mind sacrificing startup performance for long-run throughput. I'll make some further comments on Charlie's follow-up to your mail. Attila. On Aug 28, 2008, at 1:38 PM, Ben Loud wrote: > Attila, > > I've been wondering, are you planning on trying to do version of > Rhino with invokedynamic/ACL etc? > > There's been a lot of buzz about TraceMonkey recently, and alot of > people promoting it by arguing that HotSpot is 'too heavyweight' and > because JavaScript is dynamic, it wouldnt do as good of a job as a > 'specially designed' JIT (see http://ejohn.org/blog/tracemonkey/ for > some amusing comments, including "We just applied the most relevant > research (Andreas's) to JavaScript. Sun would not and will not do > that, because JS is not Java." Seems Mr Eich is not aware of John's > work!). > > Im hoping their critisisms will be proven wrong, so I'd be very > interested to see how they compare. > > 2008/8/27 Attila Szegedi <[EMAIL PROTECTED]> > > Folks, > > as John Rose reported in his weblog, yesterday was the International > Invokedynamic Day: > <http://blogs.sun.com/jrose/entry/international_invokedynamic_day > >, defined as the day when (quote) "... VM has for the first time > processed a full bootstrap cycle for invokedynamic instructions, > linking the constant pool entries, creating the reified call site > object, finding and calling the per-class bootstrap method, linking > the reified call site to a method handle, and then calling the linked > call site 999 more times through the method handle, at full > speed. ..." > > (Apologies John if you wished to post it here too in addition to mlvm- > dev, but I thought I'll just go ahead and bring the good news here > too) > > John's original announcement on mlvm-dev: > <http://mail.openjdk.java.net/pipermail/mlvm-dev/2008-August/000174.html > > > > I probably don't need to illustrate the significance of this to anyone > on this list :-) > > Attila. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "JVM Languages" group. To post to this group, send email to jvm-languages@googlegroups.com 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 -~----------~----~----~----~------~----~------~--~---
