Well, we certainly live in interesting times, at least as far as
JavaScript runtimes go...
Just recently, WebKit got SquirelFish. I was admittedly surprised that
its main innovation seems to be switching from an AST interpreter to a
bytecode model (as Rhino has been doing bytecode from the very start,
and not only Java bytecode for its compiled mode, but also an internal
bytecode format for its interpreted mode).
Then, Mozilla brings out TraceMonkey, which brings execution path
tracing, inlining, and type specialization.
Finally, yesterday Google unveils V8, which, while it had to create
some amenities we already enjoy in JVM (like, precise GC), also brings
some intriguing new dynamic optimizations, like retroactively creating
classes for sufficiently similar objects and then optimizing for these
classes, which is a nice thing to do considering the source language
(JS) is classless.
Whew.
So, I'm thinking here about which of these techniques are adequate for
JVM based language runtimes.
TraceMonkey's type specialization seems like something that'd make
quite a lot of sense. Well, it's trading off memory (multiple versions
of code), for speed. Basically, if you'd have a simplistic
function add(x,y) { return x + y; }
that's invoked as add(1, 2) then as add(1.1, 3.14), then as add("foo",
"bar"), you'd end up with three methods on the Java level:
add(int,int)
add(double,double)
add(String, String)
(Of course, for this to work efficiently, you'd also need a bunch of
type inference, i.e. knowing that you can narrow a numeric value to an
integer etc.) Combined with HotSpot's ability to inline through
invokedynamic, we could probably get the same optimal type narrowed,
inlined code that TraceMonkey can.
The V8's class retrofitting is also quite interesting (making similar
objects instances of a class that's constructed from their similar
attributes, sometime after the objects were constructed as generic
ones); especially tied into the above type specialization. On the
other hand, I'm wondering if type specialization + invokedynamic won't
actually give the same benefits that such class retrofitting would
give. It seems to me that type specialization is a more broadly
applicable, more generic, and thus more powerful concept that allows
for finer-grained (method level) specializations/optimizations than
doing it on a level of whole classes.
So, on the first sight, it appears to me that TraceMonkey's type
specialization is the one feature from these three new JS engines that
would make sense in JVM dynamic language runtimes.
Anyone has any further thoughts on this?
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
-~----------~----~----~----~------~----~------~--~---
