<div dir="ltr">Hi Andreas,<br><br>No, I haven't had time yet to look at the google code site for V8 (I'm leaving early tomorrow morning on vacation), and as you may imagine they are too busy to talk much right now. I guess I should have said multi-process, since I was referring to the ability to run many separate fully independent processes from a shared VM, which probably translates to some form of concurrency inside the VM. <br>
<br>But as I think you are pointing out, that isn't the same as JavaScript in-language multi-threading or concurrency; I don't know of anything new there. If they wanted to do fancy concurrency, they certainly know how, since we did all that for the JVM (unlike Strongtalk, which is still in 'yield' land), but of course that doesn't mean they did. I believe Lars will be giving a more detailed talk on the architecture at the JAOO conference in Denmark on Sept 30th.<br>
<br>I guess to be more precise, I think the sort of multi-process architecture they are using will be very well suited to apps that want to start, stop, and isolate lots of VM instances compactly and quickly. That sounds great for servers, and desktops too, where each app can run (and maybe garbage collect?) independently in lightweight VM instances.<br>
<br>To me, that sounds quite a bit more OS-like than existing VMs. If each app runs in a different process, then they can't block each other during i/o or callouts (or whatever the plugin equivalent is), and they will be run concurrently on multi-core processors, which are capabilities I normally associate with a multi-threaded VM. But data sharing and communication is another matter, and I don't have an answer there. <br>
<br>There's going to be a lot to find out!<br>-Dave<br><br><div class="gmail_quote">On Tue, Sep 2, 2008 at 11:15 PM, Andreas Raab <span dir="ltr"><<a href="mailto:andreas.raab@gmx.de">andreas.raab@gmx.de</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="Ih2E3d">> state-of-the-art multi-threaded design<br>
<br></div>
Can you say more about this? I can't find any information about V8's thread handling and concurrency options.<br>
</blockquote></div><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Cheers,<br>
- Andreas<br>
<br>
David Griswold wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div><div></div><div class="Wj3C7c">
A little more info on V8.<br>
<br>
I talked briefly with Lars Bak and Robert Griesemer today, (both are on the V8 team, and Lars is the lead) and got a little bit of their perspective on using V8 for other languages. As was to be expected, the VM is targeted to JavaScript semantics, and given the gnarliness of those semantics, there are a few caveats to think about.<br>
<br>
* V8 will get faster as it matures, of course, however:<br>
* There will be issues around things like immediate object<br>
semantics, which don't exactly match up with any other language. Yucky JavaScript!<br>
* A bigger long-term performance issue is that given the dynamic<br>
nature of JavaScript objects (i.e. adding/removing slots on the<br>
fly) there apparently isn't any way around adding an additional<br>
indirection to deal with the object size changing dynamically. That is something that will just have to be lived with. I was<br>
hoping they had some magic there, but apparently not.<br>
<br>
I'm sure that these sorts of things can be worked around, but they do mean that V8 will never in its pure form quite reach the pinnacle of theoretical performance possible for a VM targeted specifically to Smalltalk etc. So it won't be as fast as Strongtalk, although it may get fairly close to VisualWorks performance.<br>
<br>
Nonetheless, I still think it or some derivative will quickly become the dominant dynamic language VM, for the following reasons:<br>
<br>
* Given who the developers are, and with Google behind it, it will<br>
be the fastest JavaScript VM for a long time to come.<br>
* For the same reason, it will be reliable and secure (as much as it<br>
can be, anyway; nothing is perfect).<br>
* It will be supported on the three major platforms (Windows, Linux,<br>
Mac). * It can be used with other browsers, so I'm sure it will be ported<br>
to Firefox (if only as an option). Some or all of the other<br>
browsers may also adopt it, given that it will have a very<br>
hard-to-overcome performance advantage (these sorts of VMs can't<br>
be pulled out of a hat). Although MS and maybe Safari may have<br>
too much of a Not Invented Here problem with it, as well as<br>
standards war issues.<br>
* those things, plus the other architectural advantages it brings,<br>
will make it a primary target for serious web app development,<br>
esp. Google apps.<br>
* So it will be ubiquitous<br>
<br>
So it will be an irresistible platform for other dynamic languages, even if they could theoretically run a bit faster on a custom VM. Remember it will still be a lot easier to run other dynamic languages on JavaScript than it is to run them on Java, since at least JavaScript is fully dynamic, unlike Java.<br>
<br>
And remember, the bottom line is that it is a clean, supported, state-of-the-art multi-threaded design that is fully open-source. So as a last resort, there is always FORK!<br>
<br>
-Dave<br>
<br>
<br></div></div>
------------------------------------------------------------------------<br>
<br>
<br>
</blockquote>
<br>
<br>
</blockquote></div><br></div>